Help - Search - Members - Calendar
Full Version: MP3gain not correctly "undoing"
Hydrogenaudio Forums > Lossy Audio Compression > MP3 > MP3 - Tech
dimm0k
Before I go ahead with using mp3gain on my iPod library I decided to run a test by first making a backup of my library to another drive. Then I had mp3gain go through my entire library, undo the changes and remove the tags and then compare the mp3gain'd library with the original. For the most part it was able to undo the changes and go back to the original, however there were quite a few that did not match up to the original. The file size was the same, but the contents were not. Anyone heard of this before?
Bourne
The files that won't "Undo" properly is because there is no "Undo" information anymore. It happened to me once when I told Windows Media Player to "watch over" my music folder - it automatically re-wrote all file tag fields. Watch for software monitoring and "updating", changing tags of songs you bring into the directory. If you changed your tag manually using certain software you might have lost this information by doing it.

To fix it, get LameTag+LameTagGUI and open those files. They have Actual Music CRC and Music CRC fields. If the CRCs don't match, they are altered. You can use MP3Gain and bring the levels up (or down) in steps of 1.5 and check if the CRC match each time you change it (remember one step at once). When the CRCs match, you restored the original file.

If they were not encoded with Lame, they probably won't have any of this information and your only hope will check MP3Gain old logs (if you kept them) to see how much they were lowered.
tycho
Actually, because the OP indicated that only a small set of files didn't match the originals, I think there is a different reason. When you apply replaygain without the wrap option, peak values that should be increased beyond 255, will stay at 255. When you undo these values, they will go below the original value.

You can use the wrap (/w) option to allow for lossless undoable gain change. However, the wrap options has the disadvantage that the mp3 may change high peak values to near silent ones when applying positive gains, and vise versa when applying negative gains.

edit: As "wrapping" (or overflow/underflow) only will occur quite seldom, it has been suggested that all the wrapped frames should be stored in a tag instead of actually being wrapped, which would allow for lossless undoable gain, without the disadvantage mentioned. Someone just have to implement it...
Junon
QUOTE (Bourne @ Sep 7 2007, 06:16) *
It happened to me once when I told Windows Media Player to "watch over" my music folder - it automatically re-wrote all file tag fields.

Are you sure you weren't using metamp3 instead? Unlike this ID3v2 tool, mp3gain writes APEv2 tags, which can't be handled by Windows Media Player.
dimm0k
QUOTE (tycho @ Sep 7 2007, 02:27) *
Actually, because the OP indicated that only a small set of files didn't match the originals, I think there is a different reason. When you apply replaygain without the wrap option, peak values that should be increased beyond 255, will stay at 255. When you undo these values, they will go below the original value.

You can use the wrap (/w) option to allow for lossless undoable gain change. However, the wrap options has the disadvantage that the mp3 may change high peak values to near silent ones when applying positive gains, and vise versa when applying negative gains.

edit: As "wrapping" (or overflow/underflow) only will occur quite seldom, it has been suggested that all the wrapped frames should be stored in a tag instead of actually being wrapped, which would allow for lossless undoable gain, without the disadvantage mentioned. Someone just have to implement it...


Thank you for the explanation on the w switch. Unfortunately it doesn't look to be the issue unless I'm using it wrong. I tried mp3gain -a -k -p -w on an mp3 that I knew would result in a mismatch with the original and after running that I ran mp3gain -u -p followed by mp3gain -s d -p. The file sizes remained the same as the original, however comparing it to the original failed.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2009 Invision Power Services, Inc.