bug-gnupod
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: H. Langos
Subject: Re: [Bug-gnupod] Patch to support ReplayGain / mp3gain
Date: Fri, 8 May 2009 14:26:20 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Thu, May 07, 2009 at 09:16:51PM +0200, Richard van den Berg wrote:
> On 5/7/09 5:06 PM, H. Langos wrote:
>> 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.
>
> Nice research. RVA2 is definitely the standard to use, and gnupod  
> already has support for it. 

See, I wasn't aware of that. Eventhough I have been changing a lot of 
code less than 3 lines above that area. :-) 

BTW: I just added XRVA support as it is a too simple to let it pass.

> The problem is that there is not a lot of  
> software that writes RVA2 tags. (The only ones I know about are iTunes  
> and normalize). 

Could you send me a sample of an iTunes generated RVA2 tag? Would be
interesting to see what they actually use. I.e. which identification string
they use, which channels they adjust and if they add any peak data.
(The first 20kb of the mp3 file should easily be enough unless it contains 
album art.)

> mp3gain should really be changed to write RVA2 tags  
> instead of APE ones.

Yeap. And if mp3gain can't be changed to do write RVA2 tags by itself, maybe 
there is a way to make mp3gain only do the analysis and pass its result to a 
programm that can write those RVA2 tags?

>> 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.")
>>   
>
> mp3gain is one of  the first implementations of the Replay Gain  
> algorithm for mp3 files.

According to http://jwz.livejournal.com/370342.html?thread=4232358#t4232358 
it is the only implementation. Every other implementation seems to be cut'n 
paste.

> Please note that the algorithm for calculating  
> the volume adjustment in itself has nothing to do with the way of  
> storing it.

ACK that.

> I think mp3gain predates the RVAD/RVA2 standards so they  
> went for an APE tag instead.

Well, AFAIK the original proposal of David Robinson already contained the 
RGAD tag definition. That would have been easy enough to use or expand on.

Using "Radio" for track gain and "Audiophile" for album gain would have 
been easy and apparently correct.

> It would have been nicer if they had stuck  
> it in a custom X??? ID3 frame instead. It would have been easier to port  
> it to RVA2 now.

Do you know if the author of mp3gain is still active? reachable? alife?

>> 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/
>>   
>
> I used normalize for a long time before I switched to mp3gain. Normalize  
> is nice, but the mp3gain algorithm is better.

So how do we get mp3gain's analysis results into RVA2 / XRVA tags?

> And I like the concept of  
> not altering the data, but just tagging it and only changing the volume  
> during playback. It seems normalize can do that now too. The way I used  
> normalize (before mp3 support was added) was letting it change the  
> volume of the wav files before encoding them to mp3.

Are you sure about the non desctructivnes of mp3gain?
I've read up on it and it looks more messy the deeper I look ...

....... http://jwz.livejournal.com/370342.html?thread=4241574#t4241574 ....
>> mp3gain doesn't just write tags, it modifies the mp3 frames
>> somewhat destructively, and adds APE tags so it can reverse
>> it. This is rather backward.
>
> Well, there is no destruction going on. It just saves a gain value 
> in the mp3 frames. Which has the benefit that it works on all mp3 
> players without special replaygain support and using the info in the 
> APE tags, it can be completely undone.
> The APE thing is weird. I would prefer it used ID3v2. I asked the 
> author why he chose APE. His answer was that at the time he heard 
> lots of horror stories about ID3v2 problems.
........................................................................

If you've got a strong stomach you might want to read the whole 
thread: http://jwz.livejournal.com/370342.html

If this is all true, than your patch for gnupod is in vain as the volume 
of those files was already changed by mp3gain. Reading the APE tag and 
acting on the information would either double the adjustment or cancel 
it out, depending on wether mp3gain stores the information on what it 
did, or how to undo its action.

Seems like you should 
* backup an mp3, 
* run mp3gain on it and 
* run a "cmp -l file.mp3 backup.mp3" then 
* try to undo the changes that mp3gain made and 
* once more do the "cmp -l file.mp3 backup.mp3" 
just to make sure that it realy undid the changes...

good luck
-henrik





reply via email to

[Prev in Thread] Current Thread [Next in Thread]