Allow mp3gain to be used without altering audio data

[GoogleCodeExporter]

> What steps will reproduce the problem?
1. Choose to encode a rip to mp3
2. Enable replaygain (in either modus)
3. Rip a CD

> What is the expected output? What do you see instead?
Expected/desired: ReplayGain tags are added to the tracks' metadata.  Audio
data remains untouched.
Actual: Audio data is altered according to the ReplayGain modus chosen. 
Tags are added, including undo information and new values for album and
track gain to reflect the altered audio data.

Rubyripper currently applies replaygain to mp3 files by altering audio data
(albeit reversibly) in either album mode (-a) or track mode (-r).

This would be undesirable for someone who wants the original volume in a
player that does not read APEv2 tags.  It could also be dangerous if the
APEv2 tags are somehow lost.  (If RG tags for unaltered audio data are
lost, the user needs only rescan their files).

It is, however, possible to use the mp3gain utility with no extra
parameters so that it only writes tags and does not alter the audio data.

Furthermore, it is also possible to convert the APEv2 tags that mp3gain
writes to more common id3v2 tags that programs like Rockbox and Foobar2000
(but not, iirc, Amarok 1.4's RG script) can understand.
(example in python: http://rasher.dk/rockbox/rgfix.py)

As for how to put this wish into effect, I would suggest adding another
entry to the ReplayGain settings combobox (Album / Audiophile modus, Track
modus, Tags only (both modes)), with the new option causing mp3gain to be
run with no non-file parameters.

Original issue reported on code.google.com by Dhr...@gmail.com on 4 Jun 2009 at 4:51

[GoogleCodeExporter]

I might be wrong, but somehow I thought mp3gain is not writing any tags. Be it 
APEv2
tags or ID3 tags. The solution offered in the python file is kinda hackish.

Mp3 was not build to support replaygain. Using the solution in the python file 
is
only supported on a limited amount of players. The extra value of supporting it 
is
not worth the extra effort in my humble opinion. That the replaygaining is 
lossy is
not that important for Mp3. Otherwise you'd use a lossless codec. Anyway, I am 
not
much in favour of adding an extra option to support a shortcoming of a single 
codec.

You can ofcourse use a modern format that is more free in this regard like 
vorbis or
flac. I suppose you have your reasons to use mp3 though.

Original comment by rubyripp...@gmail.com on 23 Jun 2009 at 9:11

• Changed state: WontFix

[GoogleCodeExporter]

I'd be willing to implement it myself (and I already looked into doing so), but 
the
distro I'm currently using doesn't appear to have the GTK/Gnome bindings for 
Ruby,
so I can't test it[1] right at the moment.

And, for the record, I generally do rip to FLAC first for archival and then 
encode
from that to Ogg Vorbis after my tagging is done.  I would, however, like to be 
able
to recommend the 'proper' way to friends.

[1] on second thought, I probably could at least test the functionality part 
with
the CLI frontend and config file tweaking...

Original comment by Dhr...@gmail.com on 26 Jun 2009 at 3:43

[GoogleCodeExporter]

I will also use the feature of having mp3gain not to change the audio frames.

I made a commit in my fork for this and also attach a patch for others to use.
http://github.com/JonnyJD/rubyripper/commit/bd61b144df428851acfe99e1862002203b93
6069

With this change you can set gainTagsOnly=true in order for mp3gain to write 
tags
only (and don't do anything with wavgain). The default is false, because that 
is what
happens now.

Amarok 2.1 understands APEv2 tags now with taglib and so does foobar.
If you still need ID3v2: recent versions of mp3gain have an option "-s i", 
writing
ID3v2 tags.

PS:
I use mp3 because I can play that everywhere. I also tested the quality a lot 
and it
was still better than vorbis (vorbis had some issues with electronic music). 
However,
I also rip to flac for my archive.

Original comment by goo...@JonnyJD.net on 27 Nov 2009 at 5:39

Attachments:

• gainTagsOnly.patch

[GoogleCodeExporter]

Original comment by boukewou...@gmail.com on 27 Nov 2009 at 10:24

• Changed state: Accepted

[GoogleCodeExporter]

Thanks for the patch, I finally had some time to merge this thing. The code was 
nice 
to read, so I just had to merge it all :)

Original comment by boukewou...@gmail.com on 4 Feb 2010 at 8:34

• Changed state: Fixed