Remove or update ReplayGain info
Analyzes and adjusts the volume of MP3 files
Brought to you by:
snelg
Menu
▾
▴
#40 Remove or update ReplayGain info
I can understand how logically speaking it might seem like this is unimportant since MP3Gain essentially modifies the file to no longer need ReplayGain in theory, but there are a few reasons why it needs to deal with the actual ReplayGain info. First, due to the way it works it can't really get the volume levels quite as accurately set as the actual ReplayGain algorithms (since it's limited to 1.5dB adjustments) so technically ReplayGain can cover that extra little difference (no big deal, I know, but it seems harmless enough to go ahead and do that much.) More importantly though, when MP3Gain modifies a file, it leaves the original ReplayGain tag intact. So suddenly most music is way off since it's already processed to be x amount less (well, usually less anyway) and then any existing ReplayGain tag still says to process by the same amount (or close to it anyway since it can be just under 1.5dB different) thus resulting in it being off potentially by a fair amount (and definitely enough to notice.) This is kind of annoying because there is enough of a difference between the two to be quite noticable. Especially in extreme cases. So much music these days is WAY too high. I've seen a very rare few that scanned as over 100dB before ReplayGain/MP3Gain is applied! (No, I have no idea where 100dB came from since this is all pretty much from 16-bit sources which I swear I've read maxes at 96dB.) So once the file is fixed with MP3Gain, ReplayGain can actually tell a player to lower it from 89dB all the way down to, say, 77dB. Every time I use MP3Gain I must manually update all of the ReplayGain tags, which is kind of annoying.
I classified this in "GUI improvements" because, rather than suggesting that ReplayGain be fully implemented into MP3Gain itself, it strikes me that you could just throw in a basic option to automatically run it through the command-line version of ReplayGain (if present.) This way it wouldn't really require anything complex to truly implement. That said, even if it just simply removed ReplayGain info it would be a good start. Then actually rescanning isn't really necessary except to perfectionists. At least it wouldn't be anything even they would have to rush to fix since jumping from one song to the next would no longer potentially result in a 12dB difference.
Old problem but here is a potential solution...
Let's say you normalized with -a -d 4 -c
The replaygain values will be off by -4dB since they are modeled around 89dB and you normalized to 93dB. Replaygain will always try to lower the volume to 89dB. If you adjust the replaygain values by subtracting the 4dB then you must add that 4dB back when loading the files the next time. If you don't, mp3gain will assume the current values are based on 89dB. If you do the same -a -d 4 -c then it will raise the volume since it thinks they are at 89dB currently.
How will mp3gain know to add back the 4dB the next time. You create a new tag and put a value of 93.0. This give you a normalized reference point.
Load the file - if the dBlevel_tag exists then adjust the replaygain values back to their original value by doing...
x = (replaygain_album_gain - (dBlevel_tag - 89))
y = (replaygain_track_gain - (dBlevel_tag - 89))
You must restore the original replaygain values before any new calculations are done.
If you use a previous version of mp3gain later then you must use -s r to force recalculation.
My current aacgain mod sets a "normalization_level_dB" tag (currently for aac files only) and sets it to "93.0" if that's what I normalized to.
If you use -m then you have to adjust the dBlevel tag accordingly. If you use -g later then you would have to read the existing normalization_level_dB and adjust it's value by adding ( (-g i) x 1.5)
Last edit: DeanL 2019-01-21