Hello. I noticed that using MP3Gain v1.0.0 on certain LAME encoded MP3 files would cause the Lame tags present in the files to disappear when viewing them in Encspot (and presumably other programs). This seems to happen quite often, and can be annoying to say the least. Changing the gain value back to the file's original value does not solve the problem either. Below is a 30kb file that exhibits this behavior (having the rest of the song present has nothing to do with it from what I can tell, as the Lame tag is located at the beginning of each file.) As you can see, the file below has a lame tag present in it, but after you replay-gain it, the tag vanishes (or should I say gets corrupted - looking at the two files side by side in a hex-editor shows that MP3Gain inserts values such as 0F where there used to be a long string of 00 values - by changing these back to 00 the Lame tag re-appears.)

Rename the file from .mp_ to .mp3 for testing - Test File (You might have to right click and select "Save target as...")

PS - You need to hit the refresh all button in Encspot or restart the program entirely when comparing the file before and after.

-Thanks for your time-

Update - When testing with Lame v3.90.2 & Razorlame, the problem presents itself with all CBR files but not with VBR.

With CBR files, the LAME tag doesn't look like an Xing tag; it's identified by the string "Info" instead of "Xing". This is making MP3Gain try to decode the frame that the LAME tag lives inside of, maybe?

The Lame tag uses "XING" as sync word for vbr/abr, but "INFO" for cbr.
It is perfectly possible that mp3gain is trying to adjust the gain inside the tag.
However, theorically it should not matter as the tag is supposed to be a valid mp3 frame

Exactly. I hadn't noticed it before, and no one else had pointed it out. It's an easy enough fix now that I know, so it'll be changed for next version.

And the LAME tag "disappears" because the change mp3gain makes (not knowing that it's a special frame) invalidates the CRC.

-Glen