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

[H. Langos]

On Sun, May 10, 2009 at 10:35:57AM +0200, Richard van den Berg wrote:
> On 5/10/09 1:35 AM, H. Langos wrote:
>> I guess we should go this way:
>>
>> 1. Use RVA2/XRVA or (if the former is missing) REPLAY_GAIN_x to compute a
>>    new "soundcheck" value. 
>>
>> If the first step didn't yield any information: 2. Use iTunNORM's 
>> "soundcheck" value and RVA "volume" adjustment.
>>
>> This would probably work for most people.
>>   
>
> Agreed. All we really need to make this happen is a parsing of the RVAD  
> tag that iTunes creates for the volume adjustment.

I guess I can take care of that this week. Could you send me a short
mp3 with manualy adjusted volume to different levels? The shortes mp3 you
have should do. I just need it in different versions. One version with
-100% adjustment, one with 0, one with +50% and one with +100%. 
I have a pretty good idea now how iTunes stores it in the RVAD tag but I'd
like some real samples to confirm.

>  For the rest I can write the code myself. ;-)

Go for it! :-)

> Do you want to wait until we have a all of the above working before you  
> commit my current ReplayGain patches to CVS?

I hope I get around to commit those changes tomorrow.
>>> I just checked and MP3::Info returns each TXXX tag as an individual   
>>> value (not a hash). So TXXX:replaygain_track_gain="-2 dB" becomes   
>>> $hs{REPLAYGAIN_TRACK_GAIN}="-2 dB". This means the TXXX tags 
>>> overwrite  the APE ReplayGain tags by default. I just tested this, 
>>> and it works;  when ReplayGain data is set differently in the APE tag 
>>> and TXXX tag, the  TXXX is used by gnupod. Sweet.
>>>     
>>
>> Great. Did you check if that works with the parameters that FileMagic.pm uses
>> for its get_mp3tag() call?
>>   
>
> Yes. I tested this with an actual mp3 and the CVS version of gnupod with  
> my patches applied. It worked without additional modifications.

Great! 


BTW: I just took a look at my collection to see what I've got to play with...
That iTunNORM comments are stranger than I thought. Browsing through the 
tags of my collection I've found what I can probably best describe as two 
distinct "populations" of them. 
One that group has rather high values 

|'COM' => [
|           {
|             'iTunNORM' => ' 0000036E 00000346 000038E3 00003948 00081667 
00081667 00008000 00008000 002EFF85 00153
|           },
|           'www.DJRiver.com - Official Site.^@'
|         ],

and one that show _very_ low values:

|  'iTunNORM' => ' 00000028 00000054 0000148A 00001CCD ...

which translates to something like +14dB. 


There is even a couple of files that have two iTunNORM tags. One in the 
ordinary COMM tag and one in a TXXX tag. But what is realy freaky is that
those two tags differ:

|'COMM' => [
|            {
|              'iTunNORM' => ' 0000004B 00000090 0000011B 00000206 00007547 
000186E5 0000203C 00002AA5 00038287 0003
|            },
|            ' YEAR: 2004^@'
|          ],
|'ITUNNORM' => '0000005D 000000B8 0000027F 000003FF 00034608 0001D991 00002BF7 
0000393E 0003487E 000336C6',

What a mess :-)

I didn't see any RVA tags but that may be because my tag reader is 
ignoring them. I'll have to check manualy. If in doubt .. use hexdump -C :-)

cheers
-henrik