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.

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.

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.

Lxy: thanks for this very comprohensive response. I guess I'm much wiser now

QUOTE (Lyx @ Feb 13 2008, 17:18)

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.

I understand the design concept you explained in (1) and it seems reasonable to me. I also appreciate the approach of establishing a proper order out of the confusion of various tag formats. It's just a pitty that on the one hand mp3gain doesn't care about such a philosophy and foobar on the other hand doesn't offer any possibility, to keep these undo-information in a tidied-up form. The best possible solution however, would be achieved if foobar introduced it's own funtionality to undo gain changes - and convert the tag-mess created by mp3gain accordingly (I hope Peter reads this ).

I understand the design concept you explained in (1) and it seems reasonable to me. I also appreciate the approach of establishing a proper order out of the confusion of various tag formats. It's just a pitty that on the one hand mp3gain doesn't care about such a philosophy and foobar on the other hand doesn't offer any possibility, to keep these undo-information in a tidied-up form. The best possible solution however, would be achieved if foobar introduced it's own funtionality to undo gain changes - and convert the tag-mess created by mp3gain accordingly (I hope Peter reads this :rolleyes:).

Perhaps that would be the most efficient approach, yes. Store "frame-gain" undo-information in the same format as mp3gain, but instead use either APE or ID3v2, depending on which tag-type is the primary one of the file. Then read mp3gain stuff and transfer the metadata accordingly.

It's perhaps interesting to know how this weird situation came into being at all. At the early days of foobar and mp3gain, APE-tags in mp3s were something really exotic. It was something which theoretically is possible, but which typically isn't implemented in apps.

Then two things happened:1. Foobar was the first player to really push APE in MP3, by even defaulting to it. Because of the standards-mess which ID3v2 is, it tried to push APE as a replacement - a clean start - from ID3v2. APE basically can do whatever ID3v2 can, but does it cleaner, simplier and more reliable. The approach failed, because the inertia of ID3v2 was just too big. So foobar transitioned into a new strategy by defaulting to ID3v2, but adhering as much as reasonable to to the standard (for example by using unicode only, instead of anonymous system codepages).

2. MP3gain appeared. I can only guess as to its motives for storing undo information in an APE-tag, but i would suspect that the idea was "safety by obfuscation". As already mentioned, at the time nearly every player was unaware of APE. This means that other players would be completely blind to the APE-tag and just ignore it. So perhaps the idea was, to "hide" the undo-information from other apps, by using an unknown tag-type (APE).

I wonder what this foobar option Force prefered tag writing scheme on all files regardless of existing tags is supposed to do, if not exactly what it suggests - but then our our problem should become solved by unchecking it. Which isn't so (another hope has vanished )

I wonder what this foobar option Force prefered tag writing scheme on all files regardless of existing tags is supposed to do, if not exactly what it suggests - but then our our problem should become solved by unchecking it. Which isn't so (another hope has vanished :cry: )

Normally, foobar respects the tags already existing in a file IF (and only if).... it is "id3v2", "id3v1 + id3v2", "ape", "ape + id3v1". Thus, "which tags to use" is a "per file choice". One can manually switch the scheme, by adding the coresponding command to the contextmenu (i think its not there by default).

The setting in the advanced preferences which you talk about is an "override" for the above. It means that foobar should automatically "convert" the tagging scheme of every mp3 it writes to, to the default scheme set in the advanced preferences. So, by enabling that checkbox you switch from "per-file tagscheme" to "global tagscheme".

Since "ID3v2 + APE" is not part of the available schemes, it does not solve your conflict.

EDIT: Possibly there is another solution which could be implemented on foobar's side, which would do away with such conflicts alltogether.... but i dont know enough technical details to know if there are problems with it.

1. Allow to read from any combination of ID3v1, ID3v2 and APE. Read the tags in the order "APE > ID3v2 > ID3v1". Merge the results. If any metadatafield exists in more than one of the available tags, then just give priority to the higher order tag-type. Discard anything else.

2. Allow writing to ID3v2 and APE simultaneusly, regardless of it being pointless from an idealistic POV. However, always sync all tags which are written to, when writing. Thus, if a file had mixed metadata in ID3v1, ID3v2 and APE, then the resulting written file will have the same metadata written to all tagtypes (taking into account tagtype limits, i.e. with ID3v1). Thus, in the mp3gain-scenario, the stuff written in ID3v2 would be mirrored to APE, and the undo-data in the APE-tag would be mirrored to ID3v2.

EDIT: Possibly there is another solution which could be implemented on foobar's side, which would do away with such conflicts alltogether.... but i dont know enough technical details to know if there are problems with it.

1. Allow to read from any combination of ID3v1, ID3v2 and APE. Read the tags in the order "APE > ID3v2 > ID3v1". Merge the results. If any metadatafield exists in more than one of the available tags, then just give priority to the higher order tag-type. Discard anything else.

2. Allow writing to ID3v2 and APE simultaneusly, regardless of it being pointless from an idealistic POV. However, always sync all tags which are written to, when writing. Thus, if a file had mixed metadata in ID3v1, ID3v2 and APE, then the resulting written file will have the same metadata written to all tagtypes (taking into account tagtype limits, i.e. with ID3v1). Thus, in the mp3gain-scenario, the stuff written in ID3v2 would be mirrored to APE, and the undo-data in the APE-tag would be mirrored to ID3v2.

I think you've got it. That would be a less principled but imho much more practiable and yet logical consisent approach (as for merging, the tag priority order would also apply: e.g. if there is a tag specified both in APE only or both in APE and ID3v2, the APE tag will be synced to IDv2 [truncation will be applied if nessesary]; if there is a tag specified in ID3v2 only, it will be synced to to APE).Strangely enough, that there actually seems to be not a single program capable of merging different tag types in the described manner - or anyhow.... Mp3Tag uses a priority APE > ID3v2 > ID3v1 when reading out tag information but isn't capable of merging at all. Could it be that hard to implement?

Meanwile I figured out a dirty little hack for our problem. So throw away all of yor ideals and go through the following procedure ,

You need Mp3tag in order to do this.

Apply MP3Gain to your files if you haven't already. (Edit: if you haven't, and you're fine with ID3v1 + APE tags, you can skip this whole procedure and read on at the bottom of this post)

Start Mp3tag and make shure it's set up to read APE tags (Options/Tags/Mpeg).

Add the files/folder you applied MP3Gain to.

Hit Ctr-A and File/Export...

Add a new export config. Name it mp3gain or something, the e. Paste the following script in to the textfile that pops up:

If you've done everything right, you've got mp3s with neat APE tags containing all of the information from the former ID3v2 tags plus MP3Gain which will be kept for now on by foobar.

The only downside on this solution is that you have to dispense ID3v2 tags. There is another, real dirty option if you can't go without them: simply disable "force prefered track writing scheme" in step (7) - but be very aware of the consequences - foobar now writes MP3Gain and Replaygain Information into the ID3v2 tag and keeps them also in APE tag (why now and not before? Edit: Because they are now copied from ID3v2 to APE). So if you later change the Gain using MP3Gain, only the APE values will be affected whether the ID3v2 tag remains untouched and now contains wrong values. To update these, you'd have to go through the whole procedure again...

Edit:

QUOTE (Bourne @ Feb 13 2008, 18:49)

If you run MP3Gain through your files, they will get tagged with APEv2 tags. If you open these same files in FB2k and update *a single field of any kind* in the tags, the undo information will be gone. The only workaround for this is to set FB2K to manipulate APEv2 tags only, like creating MP3 files only with APEv2 tags and removing any kind of ID3Vx tags. After you know your tags are ALL and ONLY APEv2, then you can change the files in MP3Gain and update tags in FB2K, and the UNDO information will be preserved.

I developed the method above because this suggestion didn't work. When stripping the ID3 tags, foobar still discards the original APE and overwrites it with the former ID3v2 content. But it indeed makes your life easier if you haven't mp3gained your files yet. Just do as in step (7), rewrite tags on all of your files (check it with Mp3tag, they should have only ID3v1 and APE now) and subsequently, apply mp3gain.

If APE always gets priority over ID3v2.... and both, ID3v2 and APE are in a file, with both being in sync.... then this means that changes to ID3v2 metadata made by any other tagging app, will later be overwritten by foobar, since APE is still there and gets priority.

If APE always gets priority over ID3v2.... and both, ID3v2 and APE are in a file, with both being in sync.... then this means that changes to ID3v2 metadata made by any other tagging app, will later be overwritten by foobar, since APE is still there and gets priority.

But its't that the case with foobars current behavior - when it's se to APE and "force prefered track writing scheme" disabled?It wouldn't be a logical flow if properly explained: only the highest priority tag contains the actual file information, all the others are written for backwards-compatibility only. If I only use foobar and mp3gain to touch my files, everything will be fine. And if my hardware player isn't capable of reading APE tags (is there actually anyone that is?), there are id3v2 with the same information.

But its't that the case with foobars current behavior - when it's se to APE and "force prefered track writing scheme" disabled?It wouldn't be a logical flow if properly explained: only the highest priority tag contains the actual file information, all the others are written for backwards-compatibility only. If I only use foobar and mp3gain to touch my files, everything will be fine. And if my hardware player isn't capable of reading APE tags (is there actually anyone that is?), there are id3v2 with the same information.

You're trying to obsolete ID3v2 again - it didn't work before and wont work now. My idea doesn't improve things in practice, but just make stuff worse.