FEATURE REQUEST: The ability to disable all metadata tagging within foobar

With the release of 1.1.12, the developers have seen fit to implement a new way of handling custom TXXX frames within foobar that borks them everywhere else. Frames with the same name are now renamed by appending [1],[2],[3], etc. which makes them essentially different tags and no longer able to be used as intended outside of foobar. (Maybe inside too, idk, I did a separate portable install of 1.1.12 to investigate beforehand. At least the changes were vaguely referenced in the changelog.)

Also, multiple TCON frames (genre) are now joined into one frame and separated by a "/" with no spaces. This isn't so bad if you don't already utilize forward slashes within your genres, but if you do, guess what...

Oh and using the replaygain scanner on your files will alter your tags and change them as mentioned above.

So, how about it developers? Will give give us the means to disable your ability to manipulate our files according to your whims? What you've done isn't part of the id3v2.3 standard. I've been trying to understand the tagging in foobar, but it's just impossible. On one hand there's this almost strict adherence to specifications no one else abides by, while on the other hand, there are deviations from the standard implemented that conflict with the other deviations other software/hardware developers have implemented. If foobar's tagging were a person, it'd be simultaneously OCD and schizotypal. I wish someone could explain the reasoning behind this change. Was there an angry mob clamoring for it? If so, it's not apparent in the forums.

If you insist that this behavior is problematic for you, we can add a toggle to write tags like they were written before. However, this is against the ID3v2 specification which SPECIFICALLY says: no multiple TCON frames, no multiple TXXX frames with the same description.

QUOTE

Oh and using the replaygain scanner on your files will alter your tags and change them as mentioned above.

Disabling all tag writing like you suggest will also make ReplayGain scanner non-functional, not sure how that's going to help you.

From now on, please test beta versions and report such findings before a stable version has been released. There has been no feedback at all regarding the ID3v2 changes as far as I am aware of during the beta cycle.

PSI'd like to know:* How exactly you tag your genres so using slash as a multi-value delimiter is an issue (note: multiple TCON frames = most other software ignores all but the first one so that's not good either)* What other software that you use recognizes multiple TXXX frames with the same description* What exactly you use multiple TXXX frames for... so I can understand your usage pattern and maybe we can come up with a solution that is acceptable to both sides here. I do not insist that the 1.1.12 way of writing ID3v2 tags is an improvement - it is just a (likely misguided) attempt at improving specification compliance and compatibility with other software. But as you can see, the only way for me to find out whether this is a change for better or worse was to release a new "stable" fb2k with this change.

The thing that really annoyed me was that upgrading from 1.1.11 to 1.1.12, I lost playback statistics (foo_playcount 3.0.2) on several hundred MP3s because foobar2000 decided to do something really strange with YEAR vs DATE tag fields.

@PeterFirst had to do some research as i did not know what TCON or TXXX is. I found this old ID3v2.4 wiki that helped a bit:

If i understand correctly, all other (custom) tags are TXXX?But what does "no multiple TXXX frames with the same description" mean?Does it result in no more support for multivalued custom tags as of 1.1.12a?(or am i too confused to understand? in that case you can ignore the following but please explain 'same desciption': )

Assuming my assumptions are correct:1- TCON is fine for me, GENRE has always been a single value in my tags. (But i use multivalue TXXX frames for STYLE and CATEGORY)2- I only use foobar. It perfectly fits all my audio needs since 0.8.3. (Ripping, tagging, managment, administration and playback, kudo's to you for this wonderfull piece of software.) If i should use anything else i would be happy to see other applications recognize the standard fields mentioned in the wiki above. My TXXX frames are rather foobar specific i don't need them anywhere else.3- If TXXX really is the custom part in TAGS, it should be as flexible as possible. If a user defines them in Advanced>Display>Properties dialog>Multivalue fields they should be treated as such. I have a bunch of multivalued TAGS like _ARTIST_GROUPS, _ARTIST_MEMBERS, _ARTIST_FEATURING, _ARTIST_REMIX... (and a lot more).

having the same issue myself with 1.1.12a.i didn't seem to notice this behavior in the 1.1.12 betas, was it added in beta 6?seems like Genre is the only field I'm having an issue with.

I use Pop/Rock as a Genre and don't want this to become multi-valued; i consider a single genre.Similarly, I use forward slash in my Style and Mood tags.Basically following the AllMusic standards.

It would be beneficial to have an override for the Genre behavior.

If this is going to a permanent move going forward perhaps, I can probably figure out a way to replace the / with a dash ( - ) or something.although the thought retagging 50k+ files to accomodate the / change doesn't sound that appealing.

I thought UNCHECKING "Preferences>Advanced>Tagging>MP3>ID3v2 revision and quirks>Map TPE2 to Album Artist (more compatible)" would achieve my goal, but apparently not. Am I missing something obvious? When converting to MP3, I have been using the foobar2000 "MP3 (LAME)" preset, so no special command lines or anything. Preferences are set to write tags in ID3v2.4.

I use Pop/Rock as a Genre and don't want this to become multi-valued; i consider a single genre.Similarly, I use forward slash in my Style and Mood tags.Basically following the AllMusic standards.

That's what i do too. The discogs tagger for fb2k itself also knows single genres that contain a slash: for me it seems it's not only allmusic or discogs standard but a widespread method for naming genres. Hope to get the old behaviour back at least as option.

Edit

Concerning the multiple TXXX-Frames: So far the only program other than fb2k that supports TXXX-frames is Jriver MC but they neither use multiple frames nor an enumeration but the semicolon as delimiter that would be interpreted in fb2k as literal sign. Helium Music Manager uses that semicolon also for the TCON frame. It looks like that - if a tool at all offers multiple values - that method to use semicolon inside one frame is common.(id3v2 is indeed a horrible standard)

ID3v2.3 is terrible...except for all of the current alternatives (borrowing heavily from Churchill's comment on democracy).

Thus, I like the recent changes to TXXX frames, since this is more consistent with ID3v2.3. JRiver has no problems I can see in dealing with TXXX frames with unique descriptions, regardless of how JRiver handles TXXX frames with duplicate descriptors. I only use about 6 different audio applications, but none seem to have difficulty in handling TXXX frames with unique descriptors, and I stopped trying to figure out how they handled TXXX frames with duplicate descriptors (since it varies and is thus complicated).

I also support deviations from and extensions to the ID3v2.3 spec where helpful to enhance compatibility with other popular programs, so I support how Foobar2000 handles TPE2, album artist and band. I don't care how TCON is handled, as long as what is decided is clearly documented. I hope at the end of the day the page http://wiki.hydrogenaudio.org/index.php?ti...ID3_Tag_Mapping is enhanced to clarify exactly which frames handle multiple values (ID3v2.3 spec seems to only indicate TCOM, TOLY, and TOPE frames), and clearly indicate the characters users must enter to separate values, the character Foobar2000 displays to separate values, and the character written to files to separate values.

Lastly, however Foobar2000 deals with multiple mp3 tags with the same field name of "comment", or any user attempts at multivalue entries for comments, it would be helpful if the ID3 tag mapping wiki page had a note clarifying that as well.

Edit: Neotheone, I've not noticed any problems in my TYER tags that display in Foobar2000 as "Date", but I've only looked at this in passing - can you please describe in a much more detailed manner (with examples) what you observed that concerns you regarding year and date?

I hope at the end of the day the page http://wiki.hydrogenaudio.org/index.php?ti...ID3_Tag_Mapping is enhanced to clarify exactly which frames handle multiple values (ID3v2.3 spec seems to only indicate TCOM, TOLY, and TOPE frames), and clearly indicate the characters users must enter to separate values, the character Foobar2000 displays to separate values, and the character written to files to separate values.

Lastly, however Foobar2000 deals with multiple mp3 tags with the same field name of "comment", or any user attempts at multivalue entries for comments, it would be helpful if the ID3 tag mapping wiki page had a note clarifying that as well.

Agreed. An update to the wiki would be very helpful in better understanding the changes and potential user impacts.

I guess i am more than just a bit confused, but i am learning (slowly). Didn't know there was such a confusion about tagframes.

Now i got a choice:a- Just trust the foobar developpers (as i have been doing for years)b- Or study some more to devellop my own opinion like a true nerd, and afterwards, euhm put my faith in Peter and the team.

Thus, I like the recent changes to TXXX frames, since this is more consistent with ID3v2.3. JRiver has no problems I can see in dealing with TXXX frames with unique descriptions, regardless of how JRiver handles TXXX frames with duplicate descriptors.

In Jriver (Jukebox) i so far had no success to build a library field from a TXXX-frame which contains the enumeration inside the brackets although this enumeration element is part of the library field name. Also it doesn't semm to recognize these enumerated frames if i leave out the enumeration element from library field name.

To tie in with my previous post where i said that the most programs (if using multiple values at all) are using a single frame with semicolon seperated values: adopting that in fb2k would turn the way how foobar2000 handled multiple values upside down and in some cases it also would be uncompliant to standards (artist and genre in id3v2.3) but it would increase compatibility to other programs. Furthermore such an irritating behaviour like using a slash in artist or genre field to see it magically transformed to a semicolon would disappear: the easiest for unexperienced users without any knowledge about frames is indeed to specify a multivalue tag and to use the semicolon for seperating them in properties dialog. Mainly for Txxx-frames or frames that aren't multivalue fields by standard using semicolon for a single frame seems for me the best way to achieve compatibility and compliance since in the latter case the standard doesn't tell how the semicolon as literal sign in a value should be interpreted by a program (if i'm wrong please correct me).

As i didn't use multiple genres i decided to take a look with the slash in genre field. It indeed works that way: a slash only seperates multiple values if it is a mp3 file and id3v2.3 version, in each other file type the slash is just a literal sign.

Sorry, but that is an absolutely counterintuitive and ugly solution although it might be compliant to id3v2.3 standard (the same for multiple artists i guess). The price is that the user has to consider what files he is tagging to estimate the result!

The question is: what is it worth to comply with the standard fully? Not using the slash as delimiter for TCON doesn't make it uncompatible with other programs but removes a highly irritating behaviour that automatically leads users without knowledge about frames or mp3 tagging standards to puzzle about that - in my eyes the latter should be avoided: fb2k's behaviour should be understandable without all this "geeky" knowledge! It seems - to say it sarcastic - that the actual aim of id3v2 standard is to achieve incombatibility beetween all programs handling it because this standard is so crazy that each program is forced to look for special solitions in some cases. But what is a standard worth when it doesn't lead to compatibility?

q-stankovic, I share much of your frustration with tag specs and the complexities of ID3 specifically, but it seems users currently need "geeky" knowledge to determine practices and compatibility across different applications. ID3 is hardly a standard in the formal sense (standards group, approval body,compliance certification etc) but it's the best we seem to have right now. Until a gazillionaire funds an effort to develop and implement a true standard suitable for audio that developers will quickly adopt, or until Apple assimilates everything, we can only try to understand how to deal with ID3 as best we can.

Without derailing this thread, I am confident that Foobar2000 writes a null character to ID3v2.3 tags to delineate multivalue entries and thus is entirely consistent with ID3v2.3 in this area, and I think that's a very good thing for compatibility with other applications. Given that, I don't care what character Foobar2000 requires a user to enter, and what character Foobar2000 might display to separate entries, as long as I know what it is. In other words, just because Foobar2000 may ask a user to enter a certain character to delineate a value, and this character is different than what another application may ask a user to enter, don't assume that the tag field itself is written in an incompatable manner. Yes, this is geeky, but but I'm not a gazillionaire that can change this. Yet.

I'm pretty happy with the current direction of Foobar2000 developers in managing the tradeoffs of strict compliance with ID3 versus compatibility with other applications, so philosophical views notwithstanding, what specific suggestions do you have?

Regarding TPE2 Album Aritst vs Band:This a regression in 1.1.12, thanks for the report.

Regarding multi-value TXXX again:Maybe I'll just revert to the previous behavior since despite of being not strictly spec compliant it is less likely to cause trouble with other software.

Regarding mulit-value TCON:I'm open to suggestions how to do this yet keep foobar2000 tagging compatible with apps that do not recognize multiple TCON frames (iTunes, WMP).Semicolon as a separator sounds like a good starting point.

Edit: Neotheone, I've not noticed any problems in my TYER tags that display in Foobar2000 as "Date", but I've only looked at this in passing - can you please describe in a much more detailed manner (with examples) what you observed that concerns you regarding year and date?

Regarding mulit-value TCON:I'm open to suggestions how to do this yet keep foobar2000 tagging compatible with apps that do not recognize multiple TCON frames (iTunes, WMP).Semicolon as a separator sounds like a good starting point.

Jriver and Helium Music Manager do recognize multiple TCON frames but to treat them in their library as multiple values in HMM you have to "extract" them: doing that transforms the slash in a - guess!;) - semicolon, it transforms any other sign used as delimiter to a semicolon. In Jriver the full content (all multiple values) is treated as single value: to show in their library the single values you have to use the LIST-function that also is able to use any other sign as sign for recognizing single values. The TCOM frame gets a funny treatment in HMM: the tag editor reads the whole content but the library only the first value. Also here the semicolon would give more compatibility. The last argument is valid for WMP/iTunes too.

How do you think about removing or at least making optional fb2k's behaviour to use slash as seperator for special fields? It is not only confusing because it is only related to mp3's with id3v2.3 tags but also because it is related only to a few special fields and for artist it furthermore require a space left and right to slash that makes it even uglier. As i already said: the compliance to standard doesn't serve any purpose, it is the purpose itself

Regarding multi-value TXXX again:Maybe I'll just revert to the previous behavior since despite of being not strictly spec compliant it is less likely to cause trouble with other software.

Can you explain exactly how multi-value TXXX worked in previous versions because I think I'm seeing something different than you and others have described.

I ran into this issue today using v1.1.10 trying to write a custom multi-value tag in both fb2k and a tagger I wrote myself which uses the compliant id3lib. It appears that when using 2.4 tags the frame is laid out like this: TXXX<DESCRIPTOR>First Value<NULL>Second Value<NULL>, and is not using multiple TXXX frames. Multiple TXXX frames with the same descriptor isn't compliant, but I think my tagging software could have handled it. What I was seeing was the id3lib frame parser encountering the first NULL and returning. If you actually are writing multiple TXXX frames with the same descriptor, then maybe id3lib is somehow concatenating them.

I couldn't figure out any workaround so I ended up having to re-appropriate the TDE3 (conductor frame) for my own purposes.

Also, I tried using TOLY which I thought would handle multiple values and is even less likely than TDE3 to be used, but apparently foobar doesn't understand ORIGLYRICIST or the TOLY frame. No matter what I tried I couldn't make foobar display the frame... hence having to use TDE3.

This frame is intended for one-string text information concerning the audio file in a similar way to the other "T"-frames. The frame body consists of a description of the string, represented as a terminated string, followed by the actual string. There may be more than one "TXXX" frame in each tag, but only one with the same description.

id3lib does not enforce proper frame formatting, it will let you write as many values to a frame as you want, regardless of how many that particular frame is supposed to support.

If you want a library that enforces strict compliance, try libid3tag, if you can stomach the silly notion of a library being GPL.

I wrote up a big long post detailing how you were completely wrong and id3lib seemed extremely strict, then I checked and I've been using libid3tag

So that explains why I can't get it to load more than 1 string per TXXX. I might modify the libid3tag source at some point to do this for TXXX frames, but I'm going to have to wait and see what foobar ends up doing to get around this. I don't particularly care how compliant the library is, but I do care that it works flawlessly with how foobar decides to handle these things.