[Top][All Lists]

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

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

From: Richard van den Berg
Subject: Re: [Bug-gnupod] Patch to support ReplayGain / mp3gain
Date: Sat, 09 May 2009 12:13:01 +0200
User-agent: Thunderbird (Macintosh/20090302)

On 5/9/09 9:14 AM, Frank Blendinger wrote:
I'll talk to the mpd developers to see if they are willing to support
RVA2/RGAD and/or APE tags.

I used mpd before switching to a Squeezebox. IIRC it is written in perl. If they are using MP3::Info adding APE support is easy; just add an extra option to the get_mp3tag() call.

Do I understand you correctly that this could lead to have two gain
values added on top of each other? I don't think you'd want that...

That depends. It gives the user some manual control over the desired volume to use. If someone feels that applying the automatic algorithm makes a track too loud or too quiet, he can manually set an RVA value to compensate for it. This could be preferred over adjusting the normalized value directly because when the files are rescanned by the normalization algorithm, the RVA tag will not be reset. This is how iTunes does it (iTunNORM is set by the Sound Check algorithm, while RVAD can be set manually with a volume slider, they are both combined at playback). I'm not saying I prefer combining these tags, but it's how the iPod works: the Sound Check and Volume values are combined at playback (which Sound Check is enabled on the iPod). With my patch the Replay Gain data is converted to the iTunesDB Sound Check value while gnupod already translates RVA2 values the iTunesDB Volume value.

So far we've only established that the "normalize" software writes RVA2 tags (iTunes writes RVAD which gnupod currently ignores). Using both normalize and mp3gain is silly and makes no sense, but would indeed result in these two algorithms being used on top of each other unless you disable Sound Check on the iPod.

I think this would destroy the whole "have all songs at the same average
volume level" concept, when you apply something else on top of the
ReplayGain data.

I agree, and I think Apple implemented it this way because Sound Check uses a crappy algorithm. When you use Replay Gain there is really no need for manual adjustments or combining the values.

To have only ReplayGain and nothing else applied in the iPod, I will
have to not use the --max-vol-adj parameter and not use Sound Check,

ReplayGain is stored as a Sound Check value, so you will have to enable Sound Check on your iPod. Leave the --max-vol-adj alone so gnupod ignores the RVA tags (0 is the default).

At least according to the mpd guys, those TXXX tags are quite common, so
it might help some people if those are supported in gnupod. Personally,
I'm going to keep the APE tags on my files, so I don't care that much.

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.



reply via email to

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