Hey, I've been in on some discussion the past few days over ideal tagging structure and setup, and foobar is the program that I think has the future capacity to best deal with all of this. The requisit changes in foobar2000 wouldn't be overly large, I think; basically, I'd like for replaygain tag settings to be able to be specified seperately from the rest of tag settings (so, you could write replaygain tags in apev2, for compatibility with mp3gain.exe, but have foobar set so that the rest of tags write in id3v1 + id3v2, for example). The other thing I'd really like to see for the masstagger and for one-song-at-a-time updating, is a setting to write id3v1 and add id3v2 only if necessary - that is, if the desired information overflows id3v1 fields.
The main post is here

Right.


Okay.


Room to expand does not mean room to perpetuate ass-backwards design flaws. Your problem is with the mp3gain author, not with foobar2000. I don't care if he felt it was "safe" to assume that the APE tags would never be seen or touched by anything because "nobody" supports them anyway.

Besides which, the information which mp3gain writes to the APE tags is only for undoing a process which alters the MP3 bitstream headers. Since foobar2000 does not alter the actual bitstream, there is nothing to undo. Two completely different forms of ReplayGain data.


Let us continue perpetuating the idea that MP3 is more than just a raw bitstream, and actually supports things like tagging.

On second thought, let's do what we should have in the first place, and wrap the damn bitstream in a container which supports its own tag standards, like Matroska or MPEG-4. And while we're at it, we get proper gapless support through the requisite minimum container support.*

( I suppose it is wrong to say this, since MPEG-4 does not have a tagging standard, per se, but at least the tagging doesn't suck like ID3, and it's early enough in the game to expect gapless support from random players. Too bad we can't expect most people to support MP3-in-MP4, though. Some people don't want to have to reencode their entire collection of legitimately ripped music to AAC. )

I do understand the distinction you're making. But actually, mp3gain does both forms of replaygain data. It does write replaygain information, to apev2 tags, when scanning files, the same as foobar2000 does. The undo information that it writes (also to apev2) is written only when mp3gain modifies the actual bitstream. See my post here for more on this.
The reason that I'd like to be able to use mp3gain to actually alter the bitstream (albeit in 1.5 dB increments) is because most software (and by far most hardware) players don't read or apply replaygain tags.
Do you think that foobar's adoption of mp3gain.exe's ape-tag-writing is perpetuation of the ass-backwards design flaw? Or were you referring to some other aspect of mp3gain's function?

I agree with where you're going here. However, I don't forsee this happening. I had been tagging all of my files with apev2, but I don't forsee most players reading ape tags in the future, which is why I'd like to switch to id3.

The reason I've made this proposal is that it could be adopted easily but would still have the functionality that I want. If you have a better (feasible) proposal, put it out there by all means. This isn't a challenge; I'm not wedded to my proposal other than to the functionality I think it would provide, and would happily go with something else if it would have the same functionality.

Afaik that's what you can already do with foobar2000 0.9.

Well, sort of. With foobar 0.9b, you can set it to strip unnecessary id3v2 tags when you re-tag. But I don't think you can set it to write id3v1 and only id3v2 *if necessary* as the default setting that applies whenever you write or update or mass-tag. For that, you only have the choices:
id3v1
id3v2
id3v1 + id3v2
apev2
apev2 + id3v1

I'd like to see id3v1 + id3v2-if-necessary in that first drop-down list in the tag-preferences menu.

Well ... I just tried and it does what you want:
added tags with a short field length to an mp3 --> id3v1 tags were written
added one test tag with a long field length --> id3v2 tag was created

"id3v1+id3v2" is the same as "id3v2-if-necessary". It only writes the id3v2 if your tagging goes past the limits of id3v1.

This is good to know. I should have tested more carefully. Thanks for the correction.

Then, the main thing I want is for replaygain tags to be treated as a seperate bit of data from other tag fields, so that replaygain tags can still be written in apev2 format even if my main tagging prefs are specified as id3v1 + id3v2. The reasons I'd like to see this are referenced here.

This isn't correct, actually. I just tested a variety of files in foobar 0.9b, and it only works as described above when starting out and editing the tags of a file that already has id3v1 but not id3v2.
* If a file starts out with no tags, then id3v1 + id3v2 will write both types of tags even if all the information fits in id3v1 fields
* If a file starts out with id3v1 and id3v2, editing tags with prefs set to id3v2 + id3v2 will keep the id3v2 along with the id3v1, even if the id3v2 is unnecessary.

I'd really like to see foobar 0.9 add a specific option for id3v1 + id3v2 only if necessary. The guts of that setting appear to be available, but would just require some tweaking of the settings. My desired setting would
1. when editing tags of a file that has id3v1 only, would add id3v2 only if necessary
2. when editing tags of a file that has id3v1 and id3v2 tags, would delete the id3v2 tags if they're unnecessary
3. when tagging a file that's starting out with no tags whatsoever, would add id3v1 and add id3v2 only if necessary.

Currently, foobar 0.9b can only do point #1, but not #2 and 3.
Thanks - all work from devs is much, much appreciated.

I didn't set it to write id3v1&id3v2 but the default setting "Add id3v1" in the first dropdown menu. The second one is also left at default value (change to id3v1 and id3v2). This way I got the result described above (id3v1 if field is not too long, otherwise id3v2).

gotcha. That makes sense, and works... I should have caught that. Thanks for pointing it out.
So now, the only point that I'd like to see that is missing is:
2. when editing tags of a file that has id3v1 and id3v2 tags, would delete the id3v2 tags if they're unnecessary

I'd still also like to see replaygain tags treated as a seperate entity from other tags, so I could set replaygain tags to be written in apev2 format (for compatibility with mp3gain), which is a somewhat seperate issue from what's just being discussed in the last few posts.

Why? What for?


I'll go out on a limb on that one on and say "Not gonna happen." for the sake of metadata consistency between the different places metadata can be stored in.