Replaygain and MP3Gain

I was confused about the differences between Replaygain and MP3Gain, so wrote this note explaining the difference. I hope this is the correct forum, please move it if it would be better somewhere else.

I realise that the FAQ has a section "Replaygain: WaveGain vs. MP3Gain" but that doesn't obviously cover the features I describe below.

I illustrate the difference by describing adjustment of playback volume using MP3Gain and Foobar2000 (a Replaygain-aware MP3 player). I'm assuming the reader is familiar with the priciples behind Replaygain.

------------------------------------------------------------------------- -

An MP3 file is composed of many blocks of audio, one after the other. Each block corresponds to a few milliseconds of music. Each block has a global gain field which tells an MP3 file player how loud to play that block. In addition to these global gain fields, each MP3 file can also have a Replaygain header which applies to the whole file, and which tells a Replaygain-aware MP3 player how loud to play that file.

MP3Gain determines the Replaygain values for the MP3 file. MP3Gain then writes to the global gain header of every block, adjusting them all up or down by the same amount in order to achieve those Replaygain values. MP3Gain also writes a Replaygain header which applies to the whole MP3 file. Since MP3Gain has adjusted the global gain field for each block to give the right volume, the volume adjustments in that Replaygain header will be small. This MP3 file will then play at the right volume in all players, whether or not they are Replaygain-aware.

Foobar2000 doesn't write to the global gain field of individual blocks. It determines and writes only the Replaygain header which applies to the whole MP3 file. The value it writes to the Replaygain header will therefore be different to that written by MP3Gain since each block is left with it's original global gain field setting.

It is potentially easy to screw this up.

For example, let's say we have a file which is VERY LOUD. We use Foobar2000 to adjust the Replaygain header, which of course writes a value which tells a Replaygain-aware player to turn everything down a lot.

Now suppose we use MP3Gain to adjust the playback volume. And suppose that this time MP3Gain is set to IGNORE tags in the file (i.e. "Options" > "Tags" > "Ignore (do not read or write tags)" is checked). It will still adjust the global gain field of each block (and turn them all down), but it will ignore the Replaygain header, i.e. leave it at the setting which Foobar2000 used.

If we then play our MP3 file in a player which is NOT Replaygain-aware, everything will be fine - the MP3 file will play at the right volume because the global gain field for each individual block has been turned down.

BUT what happens if we then play the MP3 file in an Replaygain-aware player? Now the file will be played much too quietly because the global gain field settings for each block have been turned down AND the Replaygain header for the whole MP3 file is still telling the player to turn down the whole file.

The safest solution to all this is to make sure that if you use MP3Gain on your files, it is NOT set to ignore tags in the file. Then it won't matter which you use to adjust the Replaygain (Foobar2000 or MP3Gain, in any order) since either will set the value of Replaygain correctly.

Edit: Correction. Since I wrote the above paragraph I have got to know foobar2000 better.

There are several different types of headers (usually called "tags") which hold information about an MP3 file - two of the most common are ID3 and APE. Most MP3 taggers and CD rippers use ID3 tags to hold artist information. MP3Gain uses APE tags to hold MP3Gain and Replaygain information.

Because foobar2000 ignores ID3 tags if it finds an APE tag, it is better NOT to let MP3Gain add tags to MP3 files if you intend to use foobar2000 as your MP3 player. If you do let MP3Gain write tags, you will find that foobar2000 will not display Artist/Album/Track etc correctly unless that information is also in the APE tag. Since most MP3 taggers use the ID3 tags to store that information, it will almost certainly not be displayed.

You will lose very little by not letting MP3Gain write tags - each individual block of music has had it's global gain header adjusted so it will always play correctly to within 1.5dB (MP3Gain's accuracy). To set MP3Gain to not write tags to the file make sure "Options" > "Tags" > "Ignore (do not read or write tags)" is NOT checked. MP3Gain can also remove tags which it has previously added. If you want the ReplayGain correction to be exact, you can use foobar2000 to adjust the ReplayGain. foobar2000 can be configured to write ReplayGain values to ID3 tags so any previously-stored Artist/Album/Track information is not lost.

The above correction may not apply to players other than foobar2000.

------------------------------------------------------------------------- -

Note that the advantage of using MP3Gain is that the global gain header for each block MUST be supported by all MP3 players, hardware or software. The Replaygain header is not supported by all players.

Experts, do you confirm the above ? Can I include it in the FAQ ?

IIRC it's not a 'global gain header' but a 'global gain field' in each frame header.

Also



The wording doesn't make it clear the Replaygain header doesn't necessarily be supported for the file to still sound right.

IIRC, I had problems with mp3gain screwing up my tags when I set it to not ignore them.

For example, I'd ripped and encoded a CD in EAC which correctly tagged the mp3 files. Then I ran mp3gain album mode on them (set to not ignore tags). Loaded them into fb2k and the tags were gone, thus having to use masstagger to set them.

On the next CD rip/encode I did everything the same except told mp3gain to ignore tags, and then the tags were recognized when loaded into fb2k.

It didn't exactly mess up your tags; it actually didn't touch them. Rather it appended an additional APEv2 tag to the end of your file with the gain info. Foobar does not support mixing APEv2 and ID3v2 tags, so it ignored the ID3v2 tags and read the APEv2.

One solution would be to use APEv2 tags on your files.

But the thing is, I've never used ID3v2; I've always had EAC use v1.1. Regardless, I'll give it a try again when I'm at home to verify it.

I don't know that EAC can add APE tags. Can it?

I can confirm this behaviour when using this procedure, EAC adds id3v1.1 tags, mp3gain adds APEv2 tag to store undo info, Foobar2000 doesn't display any tags, but Winamp does. The id3v1.1 tags are still there. If I tell mp3gain to remove all tags it added, the problem is solved. Perhaps there is a way to tell Foobar to ignore APEv2 tags and only read id3v1.1 tags instead.

I can confirm that using only APE tags will solve this dilemma. If you rip a CD with EAC to MP3 and choose NOT to tag them, you can safely mp3gain or masstag the files via foobar in any order you please and the information will be written, displayed, and played correctly.

This is will the ignore tags option of mp3gain left unchecked.

To solve this problem you can:

A) Use foobar2000 to calculate the RG info and then apply it on mp3gain
or
B) Scan the files and apply the gain in p3gain then use tag.exe to write ape2 tags and delete the unneeded id3v1 tags.

I've edited my original post in response to some of the comments here. I'm glad if it proves useful.

I realise that there are other issues with MP3Gain and Replaygain. For example, the Replaygain header always allows track OR album gain to be selected in your MP3 player, but if MP3Gain is set to ignore tags then it is necessary to make this decision beforehand. And then there are the tagging problems discussed above.

The purpose of my post was to describe the differences between volume adjustments as implemented by Replaygain and MP3Gain as I couldn't find that information elsewhere.

Added a correction concerning ID3/APE tags after poking foobar2000 with a sharp stick for a few weeks.

I assume that each block is scaled by an identical value? Is that true? If so, you might want to explicitly state it, to avoid questions like this one. :-)

(n.b. When the blocks are scaled with non-identical scale factors, it is called "compression.")

Thanks for your advice.

I want to be careful with wording here. I don't know if the value in the global gain headers are logarithmic or linear, so "scaling" might not be quite the right word. I also don't want to mention decibels etc etc too much - I want to keep it as plainly-worded as possible. I know I have just added a mention of 1.5dB in my recent edit.

I've edited the 4th paragraph to say: "MP3Gain then writes to the global gain header of every block, adjusting them all up or down by the same amount in order to achieve those Replaygain values."

Do you think this sums up your suggestion without being technical?

B is essentially what I do. Perhaps it would be possible to ask Glen to add an option to copy ID3 fields to ape in the next mp3gain release?

Absolutely! Thanks for taking the comment in the spirit it was offered.

-- Rick

Or maybe ask fb2k developers to improve the tag reading? Seems a bit more logical to me. Fb2k is an excellant player, but why can't it handle tags that are not in sync? I asked once in the fb2k forum, but never got an answer unfortunately.

i still have some doubts ...

on mp3gain, to what tags it refers on Options/Tags? Glogal (mp3gain) or Frame?

If Global,

"Options" > "Tags" > "Ignore (do not read or write tags)"
would make mp3gain ignore foobar's correction, which is the oposite we want

"Options" > "Tags" > "Recalculate (do not read tags)"
would make mp3gain recalculate the global tag, after computing the frame ones, which we would like

"Options" > "Tags" > "Don't check while adding files"
it would do as if the file has never been gained, either glogally, or by frame?

i allways used MP3gain, and have no problem with foobar reading my tags ... so i don't get this also.

and what should i do, if i want to apply mp3gain to my files, and play them throug fb2k (but not use fb2k gain calculus)?

UP the question!

Global


That's right.


That's right.


Reading the Help file, with this option MP3Gain doesn't read the tags for each file while it is adding the files, but would read them later when it came to correct the gain for each file.

The end result will be exactly the same as if NO options are checked, but the files will load faster when a directory is selected.


Great! There's a couple of reasons why this might happen (a) because you have MP3Gain set to "Ignore (do not read or write tags)" or (b) because your MP3 Artist/Album/Track etc information is stored in APE tags, not ID3 tags. So when Foobar finds the APE tag, it finds ALL the information.


In Foobar preferences, Playback tab, Replaygain box, select "disabled". Foobar will ignore the Replaygain information, but your MP3 will still play at the correct level because MP3Gain has adjusted the gain headers of all the individual blocks of music (which Foobar cannot ignore).

so, it i run replaygain, with "Options" > "Tags" > "Recalculate (do not read tags)" checked, it would clean the fb2k calculations ... so i don't need to disable the replaygain box in foobar ...



i don't use APE tags ... and i don't have MP3Gain set to Ignore (do not read or write tags) either ... :|

I struggled with this issue when I first started using mp3gain with Foobar too.
Now I make sure that my mp3s have proper APE tags BEFORE I mp3gain them. There are two ways that I do this:
1) For mp3s that have info in ID3 tags, I use a tag editor to make sure the info is correct, load them into Foobar and have Foobar rewrite the tags as APE tags, which it will do by default when you right-click and select "rewrite tags from database" (the type of tags Foobar writes when it performs that action are set in the standard inputs section of the preferences). Then I mp3gain normally.
2) For ripping new CDs, I use EAC with wapet.exe (http://www.saunalahti.fi/~cse/files/wapet.zip) with the command line at http://www.hydrogenaudio.org/forums/index....t=ST&f=15&t=203 to write the APE tags at the time of encoding. Then I mp3gain normally and all is right with the world.

Ermmmm... it's not that simple. Trouble is, Foobar will write it's Replaygain information to the tag type you have set up in Preferences > Playback > Input > Standard inputs. If you have that set to "ID3v2 and ID3v1" then that's the tags it will use.

If you then MP3Gain the file, it will write ReplayGain values to an APE2 tag. Your file will now have two lots of ReplayGain info in two different tags.

Fortunately, Foobar will see the APE2 tag written by MP3Gain and ignore everything else, including the ID3 tags which it earlier wrote itself. So MP3Gain will effectively have hidden the tags which Foobar wrote, even though they are still there.

If you set Foobar's Preferences > Playback > Input > Standard inputs to "APE2 and ID3v1" then everything WILL happen as you suggest - then Foobar will write it's ReplayGain va;ues to an APE tag and MP3Gain will "clean" it.

Hope this helps!

another solution would be if MP3Gain would read/support ID3v2 tags in which foobar has written the replaygain values.

this would be acceptable for me because i have an CD-MP3 player in my car which supports ID3v2 and i want to use MP3Gain with it.

Just wanted to note that the tag issues I referenced in my post seem to be resolved using the new foobar2000 0.9beta, probably due to it's new ability to merge tag types. Hurrah!

I'm just starting to use MP3Gain on my MP3 files. I noticed this behaviour. The "clipping may occur" warning has me a bit concerned. Why would it compute values that may cause clipping? Should I do something to make it so that clipping won't occur?

Edit: I added the /k switch but still get the warning when I do

mp3gain.exe *.mp3 >mp3gain.log
mp3gain.exe /a /c /k *.mp3

I was being stupid. The log doesn't know that I later specify the /k option. Worked like a champ. Feel like a chump!

this entire thread has been VERY interesting.

Isn't the easiest thing to just use MP3Gain to adjust the gain values in the files and not worry about the ReplayGain tags? Then the files should play properly on any MP3 device.

is there some downside to doing this versus using ReplayGain tags?

The files are modified? That's about it, really... I guess if you drive it to clipping, then it doesn't have a peak tag for an RG-supporting player to scale down with.

With MP3Gain you must choose between Track RG and Album RG. With RG metadata you can have both.

But truthfully if your CD is not mastered to be seamless between tracks, you can just ignore Album RG.

How does the peak tag work?

Is there some sort of standard in the meantime?
I'd find it great if RG values would be stored in APEv2 and/or id3 as metadata only by more or less every programm and for any format that can handle those.
For formats that can't handle metadata I can imagine the player of choice's media library handling the RG values for those files.

I'm just curious if there is that kind of consensus because it would make it easier for new players to handle RG values properly.
II may try to convince the Aqualung developers to use RG instead of their own RVA-System which seems to be very similar to replaygain but is, as far as I know, uniquely supported by aqualung.
Convincing them might be difficult if every program handles and tags RG in a different way.

Maybe someone with more insight can comment on this.

"MP3Gain determines the Replaygain values for the MP3 file. MP3Gain then writes to the global gain header of every block, adjusting them all up or down by the same amount in order to achieve those Replaygain "


I have read conflicting things about how to operate the MP3Gain GUI and what it does. If i only want to write to the global gain header of an MP3file (and not worry about writing the ReplayGain tags), what actions do i take in the GUI?

I've read that hitting the "track analysis" button will modify the "volume bits" (i assume that is the global gain header) but in my experience i have to hit the "Gain" button to actually alter the volume of the files.

I'd like to modify the volume of my MP3s so they play consistently in my iPod as well as my Squeezebox. the iPod, of course, does not recognize ReplayGain tags, but my Squeezebox does. If i understand correctly, i can modify the global gain header and it will work the same way in both my iPod and my Squeezebox (i would NOT use the Volume Adjustment option in my Squeezebox).

Can anyone help me with this?

The de-facto RG tag fields are :

replaygain_track_gain
replaygain_track_peak
replaygain_album_gain
replaygain_album_peak

They where originally proposed by Garf for making an RG standard for Vorbis and where then implemented in VorbisGain and since then everyone has followed.

For MP3, then mp3gain.exe sets the four above tags + between 1 and 3 others depending on the situation as APEv2 tags, but as APEv2 tags on MP3's never really has catched up, then fb2k and Winamp sets the four above tags as ID3v2 TXXX frames and in which i believe will sooner or later become the de-facto standard for MP3 RG tags(if it isn't allready).

Disable tagging and then apply track/album gain

When analyzing in MP3Gain, then mp3gain.exe will RG scan the files and set APEv2 RG tags on them, but the global gain fields in the headers of each MP3 frame aren't touched. This is the same if you just run "mp3gain *.mp3".

Load the MP3's into MP3Gain and apply track or album gain.

Thanks!

One thing confuses me: if sounds like if i do an "analysis" with MP3Gain that it will write RG tags to the files -- if that's correct, why don't the files show an new "date modified" value in Windows Explorer? if MP3Gain is writing these tags to the files, doesn't that modify the files?

And when does it actually write the tags? if you load a bunch of files in and do an analysis, it will tell you how the files differ from the target volume value. But if you change the target volume value, it immediately updates the difference amount for all the files -- but too quickly to actually be writing to the files. Is "analysis" really writing anything to the files?

Correct.

Press F5 to update Windows Explorer. If still not showing, then check if you have disabled tagging. If tagging isn't disabled, then whenever you reload some MP3's that you have analyzed before, then the RG info will be displayed immidiately, without the need to rescan the MP3's again.

Right after the analysis is finished.
Yes, "Analysis" is really writing to the files, but the RG tags that's set during analyzing are relative to the de-facto reference loudness i.e. 89dB(the RG spec. is actually 83dB, but that is outdated and never used anymore). If you then apply an e.g. value of 92dB right after you have analyzed the MP3's, then the RG tags is altered to reflect the new change in loudness.

Hello,

after diving through all of these topics concerning the usage of mp3gain and, respectively, foobar's replaygain, I still got stuck with the following problem, as before mentioned in these topics:

http://www.hydrogenaudio.org/forums/index....showtopic=52283
http://www.hydrogenaudio.org/forums/index....showtopic=57038

(I'll post it here anyway because this seems to be to most comprehensive one)

In spite of that I prefer the simplicity of replaygain's concept - to write a single header which enables the decoder to do track- as well as album-gain on the fly - I really appreciate the functionality of mp3gain, simply because my hardware player doesn't support that replaygain header (as it is the fate of many great concepts which don't get the appropriate promotion...). My problem is, though: when i make any change to the ID3 tag with foobar later, the tag holding the origininal gain values which mp3gain wrote to the file in order to make the gain change reversible, gets lost (I don't know which kind of tag holds this information, though it can't be identical with the replaygain tag).

On the other hand, if I do the same thing mp3gain does with foobar ("apply track/album replaygain to mp3 data"), it seems that foobar won't store any such information of the origininal gain and thus it becomes irreversible (the function "remove replaygain info from files" just strips the ordinary replaygain tag, not the gain information applied to the mp3 data)

Here's an example: if i track-gain a bunch of mp3s in order to play them shuffled on my hardware-player, it's important for me to keep the original gain value, so that the intended relative volume of each track remains intact, when I want to listen a whole album. Now that would be fine with mp3gain: I'd just have to "undo gain changes" later. But when foobar comes in - which is really essential as a player and tagger for me - the according information get lost. However, when I use foobar instead of mp3gain, such information won't be maintained at all. Now isn't that an absolutely unnecessary annoyance? It could easily be avoided, either if Foobar would simply maintain the tags written by mp3gain, or even better, write it's own tags containing undo-information (so one wouldn't need mp3gain at all).

Does maybe someone know any workaround on this problem? Is there a chance that the beforementioned functionality could be implemented in future foobar versions (it would make the best mp3 player out there even better)?

PS. Please excuse my mediocre English. I hope it's enough to be roughly understood, though.

If you had not said anything then I never would have guessed that English wasn't your native language, so stop apologising.

Here is a - from my understanding - safe procedure to have BOTH, mp3gain-style block-modification and foobar-style RG-tagging:

- use mp3gain or foobar to apply ALBUMGAIN to the individual frames. Leave the target-value at the de-facto standard 89db. Do not bother adding undo-information.

- then scan the mp3 with foobars replaygain and add RG-tagfields for albumgain and trackgain.


Why? Well, the situation afterwards will be the following:
- non-replaygain aware players will correctly play your files in albumgain mode
- the relative differences in loudness between tracks, as well as seamless trackchanges, will be kept intact, because albumgain was used. Because of this, you can also use any tag-based RG-scanner like foobars, to analyze the files, without strange things happening
- RG-tagfield aware players will be able to make use of albumgain or trackgain, so you get the full functionality of tag-based replaygain

The deciding choice in this scheme is to irreversibly albumgain the mp3-file without bothering to add undo-information. Because of this, all the mentioned conflicts and issues become irrelevant. But since albumgain was used, there isn't really any need to undo the changes, because relative differences in loudness between tracks will be kept intact.

The only downside i can think of is of purely informative nature: The tagbased albumgain-value will always be near zero (because the file was already albumgained by mp3gain). So, if it is important to you to afterwards see the "true" albumgain value of an album, then you may dislike this scheme. Notice that this does not really hurt normal usage in practice - it just means that you have one less "nice number" to look at.

Sorry

Thanks for your reply. I agree with you that the loss of original gain-values isn't that serious when album-gain is applied instead of track based gain, since the relative volume levels remain, but the underlying problem for me is the irreversible change to the mp3-data. I'm just bothered because there actually is a simple and adequate method to safe this undo-information - but replaygain somehow manages to discard it. So why should I irreversebly alter my whole mp3 collection just because foobar is oddly at odds with mp3gain!?

I have one stupid question....

Turning an MP3 gain down to -8.0dB and then playing it on a stereo with volume much louder than the original gain it had (playing at let's say +8.0dB) will it have the exact sound/feeling/bass/treble/stuff that the original gain?

I ask this because I have read "replaygain" is not perfect. So just making sure...

7.5dB or 9dB - mp3gain only works in multiples of 1.5dB.

With 24 bit decoding from a 16 bit source - identical, except any decoder related clipping will be removed.

With 16 bit decoding from a 16 bit source - identical, except any decoder related clipping will be removed, and any information in the last 1 or 2 bits will be rounded away or dithered depending on the decoder (i.e. effectively noise is introduced at -96dB in the final 16-bit decode).

Cheers,
David.

There will be no difference in the overall sound of the track because all frequencies are affected by the same amount of gain change (no equalizing is done). Howewer, if there's a very quiet sound in a certain frequency area, which was hardly audible even on original gain, it may sink under the noise-floor of your playback equipment when lowering the gain. But i guess this is rather a theoretical concern because most music produced today is heavily dnr-compressed, so that there shouldn't be much of a risk this could actually produce audible consequences...

David...

So, consider two WAV files, one processed and one original.
One of them I WAVEGAIN it down to -12.00 and the original I leave alone.
If I play the one that has been processed with a higher volume (+12.00 from that starting point) will be equally loud identical to the original file?

I know MP3Gain does it by 1.5 steps, but foobar2000 does not calculate with that limitation, unless it's not saying it properly....



Hmm... I sometimes DO NOTICE some kind of ANNOYANCE when I replaygain very clip-pressed albums and play them "as the old good CD back in the 80's". It just doesn't sound the same, and the sound gets really flat. I mean, they sound better loud & left alone.. could it be what you're saying?

Clipped and precise, and faster than me
But now as this topic is hounoured by your presence... could you maybe comment on the mp3gain stuff?

I know what you mean. But that's due to the inferior production standarts today... which are revealed when the stuff is played back on a reasonable gain level and compared with a sound production of good ol' times...

I just never knew what that was... you put it right... "if there's a very quiet sound in a certain frequency area, which was hardly audible even on original gain, it may sink under the noise-floor of your playback equipment when lowering the gain."

I actually find this very annoying and end up not applying the ReplayGain on the songs for the stereo playback. (on the PC with headphones is fine).

For this to happen in practice, you need uncompressed classical music and a playback-level which is at an ear-damaging 100 dB..... but then again, at such large dynamic range, the ATH-model of the mp3-encoder may be a much more serious issue.

...either that, or you need a highly defective equipment-part in your playback chain.... something which has an insanely high noisefloor. I do not just mean bad equipment - i really mean defective.

However, in spite of the above, there is another explanation with a much higher degree of probability: Placebo.

oh yes it's placebo and the dogma of the enigma is outbursting into a ship clouded by noise shaping skull nonbrain case of /mnt but you're not root then you can't do it.

Uhm... sounds like the lyrics of a Current 93 song

When I read out the APEv2 tags written by Mp3gain with Mp3tag, it correctly displays the following fields:



After doing any change to the tags with foobar, the MP3GAIN_* fields are vanished. I even tried to outsmart foobar by some script like <copy "MP3_GAIN_UNDO" to "MP3_GAIN_UNDO">, but it's futile. foobar just doesn't recognize the tags written by mp3gain. The REPLAYGAIN_* fields are all recalculated after a tag change - so foobar doesn't seem to recognize them either. I also tried to check "compatibility mode" in Preferences/Advanced/Tagging, but without any success.

So what's about these APE tags written by Mp3gain that Mp3tag reads them correctly but foobar doesn't handle them at all?

To understand this behaviour, a bit of background information is necessary. You need to be aware of the following:

1. Foobar2000 is NOT designed around the idea of the user manually managing tag-types. It is especially not designed for having different kinds of metadata in different tag-types simultaneusly. The approach which foobar uses is to "abstract" metadata: The user only enters the desired metadata, and foobar automatically cares about how to store it. This way, metadata-manipulation across different filetypes works identical on the user-side and therefore is compatible with each other. No matter if you manipulate metadata about an MP3, or metadata about a FLAC, it is always the same procedure and interface. This however can only work, if there is "metadata integrity" - meaning that all metadata of a given filetype is stored the same way and there are not multiple tags in a single file with conflicting metadata. In short: this approach is only feasible when all files and metadata are "in sync". It does not matter if you agree with this approach or not - it just matters that foobar is designed around this approach... therefore, if you cannot live with it, then foobar is the wrong tool for your needs.

2. Foobar currently does not do any merging of metadata when reading files. In the case of mp3, it only reads from the selected (advanced preferences) tag-type and ignores the rest. As for "why?" - well, i dont know the full story, so a dev-reply would be needed for the full picture. What i know however is, that in the past there was no robust idea on how to merge multiple tagtypes when reading - what i mean is the "ruleset when merging". Part of the problem is that when the same metadata field exists in multiple tagtypes (dupe-info), then how should a machine decide which one is preferable? A machine does not understand what metadata like TRACKTITLE says... its just a bunch of random letters to it.

3. For MP3, foobar supports the following tagging schemes: ID3v2, ID3v1 + ID3v2, APE, ID3v1 + APE. Why is there no APE + ID3v2? Well, because ideally, there is absolutely no point to it. APE is a "replacement" for ID3v2, not an addition. The point of using APE tags is getting rid of ID3v2 and its conflicting standards. If you use ID3v2, then there is no point in APE. HOWEVER, for whatever strange reasons, mp3gain uses exactly this weird and senseless combination of tagtypes. The mess starts here.... continue reading....

4. When foobar changes metadata, then it works the following way: First read metadata according to the above rules. Save it in RAM temporarily. Then modify this read metadata according to the user. Then REPLACE the metadata in the file, with this modified metadata.... therefore dropping all unsupported metadata. Why? Well, read "1." again... the whole point of foobars metadata management is that the metadata in files is in sync without the user having to care about it.

From my POV, what we have here is the combination of two design-flaws..... a flaw in mp3gain, and a flaw in foobar. Just one of the flaws is sufficient, to render the current undo-information of mp3gain useless. The flaw on foobar2000's side is that it has not even the slightest capability of merging tagtypes when READING. What FB2k IMO should do in the current scenario, is reading the APE-metadata of mp3gain, and then delete the APE tag and save the undo-information in ID3v2, therefore not causing any dataloss, but making the undo-data incompatible with mp3gain.

The flaw in mp3gain is using a stupid combination of tagtypes. It should write its undo-information in the already existing tagtype instead - so, usually as ID3v2.