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.

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.

Except of that non APE-aware players will:

- display absolutely nothing- display truncated info if you also write to ID3v1

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.

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.

I'm not trying to obsolete it but rather to keep it for backward compatiblity. It's imho exactly what foobar does for now (if set up like mentioned before) and your idea thus wouldn't worsen anything

Edit:

QUOTE (Lyx @ Feb 13 2008, 23:53)

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).

Ok, after reading through this again I see now that actually it isn't the same. But I still think that another approach to handle a "ID3v2 + APE" situation, would do better: If foobar choses, in that particular situation, to eliminate any APE tags in order not to mess up with differing tag-values, it should a least read out the APE tag and merge any tag fields ony specified there and NOT in ID3v2 into the latter. At least, any unexpected loss of information would be avoided that way.On the other hand: it wouldn't hurt so much to implement an option like "Leave tags not matching selected scheme intact" - and disable it by default. Would it?

FYI:metamp3 does convert APE2 RG tags to ID3 tags (v2.3 ISO-8859-1 supported only) if they exist, and removes the APE2 RG tags. It also converts the undo-info to ID3 2.3 tags, so you may undo the applied RG by using metamp3. Additionally it can compute new RG tags stored as ID3 v2.3 tags, or apply them and create undo tags.

Make sure that any existing ID3 tags are v2.3 ISO-8859-1 before applying metamp3, otherwise it will corrupt your existing tags. I forgot to make a check for this.

Basically metamp3 does what mp3gain does, but stores tags as ID3 instead of APE2. Unfortunately the command line arguments are not compatible with mp3gain's, and some switches are missing. Maybe someday I'll do something with these issues.

/edit: I noted that undo info are written as a TXXX tag named "mp3gain_undo". I suppose "replaygain_undo" or "replaygain_undo_info" would be better. A de-facto standard should be established so that other application could utlilise this tag.

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'd have to ask Glen, but I think it was partly a simple "this is how you store this information" - nothing more, nothing less. mp3gain was the only application that supported the feature, and anything that came along later needed to copy the approach. foobar2k didn't because of it's attitude to tagging. I wonder if it wouldn't have been possible to allow foobar2k to put the ReplayGain info in APE2 tags, whatever tagging scheme was used for everything else?

I wonder if it wouldn't have been possible to allow foobar2k to put the ReplayGain info in APE2 tags, whatever tagging scheme was used for everything else?

Actually it is! I'd recently updated to foobar 0.9.5.1 beta 2 and was very happily surprised that it now properly reads out and keeps all the tags written by mp3gain, regardless of tagging scheme - though this change isn't listed in the accordíng topic. Seems like Peter secretly fixed it for us

Update: When "force prefered tag writing scheme" is enabled, writing ID3v1+ID3v2 tags, foobar now exactly does what I suggested:

QUOTE

If foobar choses, in that particular situation, to eliminate any APE tags in order not to mess up with differing tag-values, it should a least read out the APE tag and merge any tag fields ony specified there and NOT in ID3v2 into the latter. At least, any unexpected loss of information would be avoided that way.

When you chose APE or ID3v1 + APE, former ID3v2 data is merged into the APE tag, so you'll still be able to undo changes with mp3gain.With "force"-option disabled, ALL fields are written as ID3v2 as well as APE. Be aware that the priority is APE < ID3v2, so after undoing gain changes with mp3gain, foobar will override the updated values in APE with the previous ones, still present in id3v2!The only way to avoid this, I guess, is to strip off any ID3v2 tags by forcing APE tag writing.

QUOTE (tycho @ Feb 14 2008, 11:49)

FYI:metamp3 does convert APE2 RG tags to ID3 tags (v2.3 ISO-8859-1 supported only) if they exist, and removes the APE2 RG tags. It also converts the undo-info to ID3 2.3 tags, so you may undo the applied RG by using metamp3. Additionally it can compute new RG tags stored as ID3 v2.3 tags, or apply them and create undo tags.

That's a great alternative to mp3gain... did you ever thought about making a replaygain plugin out of it?

MP3Gain doesn't detect RG information when it's stored in the ID3 tags so how are people recommending to do the scan in Foobar2000? To do that you would have to add APE tags in Foobar to your files anyway. MP3Gain can't apply any adjustments before doing its own analysis and storing that info in the APE regardless. This is really just a problem of Foobar not having the ability to mix ID3 and APE or anything else really. It's an issue here no matter what.

MP3Gain adjusts the actual data so that it can be played back at a normalized level in non-ReplayGain-aware players. foobar2000 is an RG-aware player. It also happens to have the ability to alter an mp3's global gain field but it isn't necessary for RG-adjusted playback.

MP3Gain adjusts the actual data so that it can be played back at a normalized level in non-ReplayGain-aware players. foobar2000 is an RG-aware player. It also happens to have the ability to alter an mp3's global gain field but it isn't necessary for RG-adjusted playback.

Yes, I did... You seem to have a long history of misunderstanding me. I actually have no idea why and don't know how to modify what I said to make it clearer.

I was asking what was meant when the suggestion was made. Without adding APE tags, scanning in Foobar by default adds to the ID3 tags, as was mentioned. MP3Gain doesn't read RG information from ID3 tags and stores it's own undo values in APE so APE is necessary regardless. Using MP3Gain would screw up how Foobar displays Album, Artist, and Track information regardless since it doesn't look at ID3 when it detects APE...

I posted the thought to be explained differently or told some methodology that I may be overlooking. Not sure what you even responded to but you sure seem adamant about saying that I didn't read the thread...

Questions are good; comments are good. This is a forum where inquiries such as these are meant to be explained by people who may know better.

Questions are good; comments are good. This is a forum where inquiries such as these are meant to be explained by people who may know better.

Two things come to mind.

One: This thread is very old, the questions you asked are already ANSWERED IN THIS THREAD! Foobar2000 changed and FIXED that one small issue 5 years ago!

Two: This forum is NOT 'a forum where inquiries such as these are meant to be explained by people who may know better.' That is just what YOU WANT TO HAVE HAPPEN. It is NOT WHY I AM HERE. It is NOT WHY GREYNOL is here!

This forum is for people interested in an intersection between computers (digital) and music (analog), and the software, code, used to make that intersection happen. To share ideas, communicate, and discuss digital audio. It is NOT A FREE SCHOOL OF YOUR CONVENIENCE!

Now your questions have been being answered, many times the answer is to GO LEARN MORE (with URL Links for you to follow up and read!) because we are NOT YOUR TEACHERS.

I understand you want to have friends in far places explain these things to you. Your understanding is very good so far, but show some respect for these REAL PEOPLE who you are pestering with your questions. Most of the data you request is already explained in the wiki and forums.

RESPECT THESE PEOPLE! They are not here just to 'help me learn moar!'.