Re: [Bug-gnupod] Patch to support ReplayGain / mp3gain

[H. Langos]

On Thu, May 07, 2009 at 10:51:04AM +0200, Richard van den Berg wrote:
> On 5/7/09 10:09 AM, H. Langos wrote:
>> Did you check when (at which version) MP3::Info gained APE support?
>
> I did just now and APE support was added in MP3::Info v1.20, Saturday,  
> January 7, 2006
>
>> It would
>> be good to check for this in configure.ac as it already is done for utf8
>> support.
>>   
>
> Configure.ac is now checking for v1.01 from 2002. I guess we can just  
> change the UTF8 warning into an APE warning and check for v1.20?

I'd prefer a separate check and warning. I know, checking for software
versions from 2002 seems strange but there is a lot of old stuff out there...

I might even add a check for VERSION <= 1.23 as 1.23 still contains a bug
that treats ULT tags other than USLT... I run into it occasionally and a
warning would remind me to apply that 1 line patch to fix it...

>> Also making sure that older versions don't choke on those extra parameters
>> would be good. (A short look at the code should be enough.)
>>   
>
> I checked and version 1.13 (10 March 2005) should not have any issues 
> with the additional parameters passed to get_mp3tag().

Ok. Good to know! So a simple warning about this in configure.ac should be 
enough.

>> Are you sure there is always at least one whitespace between the numbers and
>> the "dB" string? When reading the replaygain related web pages I see that
>> most people tend to write stuff like "-12dB" or "6dB". I wouldn't be
>> surprised if some programers followed that example. Or is there some standard
>> definition for this?
>>   
>
> I was actually thinking the same thing. The space is the way mp3gain  
> does it, but it is not very common to use a space, no. Since mp3gain is  
> the de facto software to use for calculating ReplayGain it doesn't  
> really matter though. We can change the \s+ to \s* for completeness  
> sake. The \s+ was in the code I borrowed, and I just didn't touch it.

The check can then probably be changed from
  if($gain =~ /(.*)\s+dB$/) {
to
  if($gain =~ /(.*?)\s*dB$/) {

The "?" is important otherwise the (.*) would swallow up any white space 
that \s* could have matched.

>> BTW: While you're at it ... have you ever seen RVA / RVA2 / XRVA tags
>> in the wild?
>>   
>
> I tag 99% of my own files, but I did see RVA2 tags on some iTunes  
> mangled files, yes. Note that iTunes uses iTunNORM for Sound Check and  
> RVA2 for that volume slider thingie. I read a post of someone who volume  
> leveled his whole collection using that slider.. yikes. I so prefer  
> mp3gain. :-)

Well, the way itunes presents the data is not really that important to me.
I only installed iTunes once after buying my iPod. I was so disapointed
that I stopped using it after a couple of days. Nowerdays I wouldn't let 
it come anywhere near my iPod. :-)

What's important is the fact that there seems to be a standard that defines
how volume adjustment data can be stored in id3 tags. Apart from that iTunNORM
stuff that only seems to store peak information.

Here's a short round up:

RGAD
 The RGAD tag as proposed by David Robinson seems not to have made it into
 general use: http://www.id3.org/Replay_Gain_Adjustment

RVAD
 Instead there's the RVAD tag that allows one adjustment value per
 channel(instead of the "Radio" and "Audiophile" adjustement levels defined 
 in RGAD for all channels): 
 http://www.id3.org/id3v2.3.0#head-d3d2bfba9882a197c1b55a80f52bb676653d3604

RVA2
 A most flexible definition seems RVA2 as defined in id3v2.4.0 . It allows to 
 define several adjustment sets. Using an "Identification" string that could 
take
 the role of the "Radio" vs, "Audiophile" distinctions AND in each of those
 adjustment sets each channel can have a different adjustment 
 level: http://www.id3.org/id3v2.4.0-frames?highlight=(RVA2)

XRVA
 This TAG is just a "backport" of RVA2 to id3v2.3.0:
 http://www.id3.org/Experimental_RVA2?highlight=(RVA2)


So I wonder why the author of mp3gain decided to store the information in an
ascii APE tags comment instead of using the existing standard. (He definetly 
was aware of it as he states in the FAQ that he "uses David Robinson's 
Replay Gain algorithm to calculate how loud the file actually sounds to a 
human's ears.")

But then again I wonder why the main() function in mp3gain is around 1300
lines long and at times 8 levels deep. :-)

I took a look at the source code of normalize and it seems to be able to 
write to id3v2.3 using XRVA and id3v2.4 using RVA2. Maybe this would be
interesting for you too? http://normalize.nongnu.org/

cheers
-henrik