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.
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 :rolleyes:).
Lyx: ....still growing wiser ;)...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: )
Except of that non APE-aware players will:- display absolutely nothing- display truncated info if you also write to ID3v1
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.
Quote from: Northpack on 13 February, 2008, 08:02:46 PMI think you've got it.Nope, i dont. There is a severe logical flaw in my idea: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.
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.
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).
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 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?
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.
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.
I figured out a dirty little hack for our problem.
Paste the following script in to the textfile that pops up:Code: [Select]$filename(Export.MP3Gain.txt,ANSI)$loop(%_path%)^|%_PATH%|%REPLAYGAIN_TRACK_GAIN%|%REPLAYGAIN_TRACK_PEAK%|%REPLAYGAIN_ALBUM_GAIN%|%REPLAYGAIN_ALBUM_PEAK%|%MP3GAIN_MINMAX%|%MP3GAIN_ALBUM_MINMAX%|%MP3GAIN_UNDO%|$$loopend()
13.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.
Did you read the entire discussion before you posted?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.
...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.