The most recent ID3 standard is something like a decade old and even then never was "agreed upon". So there are a lot of common field in other tagging systems that all get mapped to TXXX or TIPL. Yate has ten custom fields that are great but are not enough to map to even half of the fields common to Vorbis, APE3 and the internal name for MusicBrainz even. There is a nice table here http://picard.musicbrainz.org/docs/mappings/.

MusicBrainz is great in that it has these additional fields and ID3 is great in that it can have all kinds of stuff put into it by mapping but if I want to create a panel that has many of these common fields I am limited by only ten custom fields in Yate. The UD Text at least lets me see and with a extra clicks get into fields to edit them but things that would better be displayed on more relevant panels are forced into one UD Text panel.

One way may be just to add more custom fields I can map too and ten I can make actions to get the data from the UD Text field and put it into the appropriate fields but it would be slicker if there was a preference to enable/disable a bunch of these common fields and enabling them would force some routine in Yate to automatically do the mapping.

I demoed Jaikoz of a while and it was nice enough to have many/most of these fields in it but there was so much I didn't like about using the app and its really non-mac UI that it didn't work for me.

But fields like barcode, asin, script, original year, producer, arranger, mixer, and show are ones I would like but also the common IDs for MusicBrainz/AcoustID and Discogs make sense to me to have the option of enabling internal fields for. Then I can use my custom fields for things that are not so common like guitar tabs, sheet music, midi, vocoder system, detail on what movie/tv show/anime/game the track is from and episode [opening/closing] stuff that will likely never have an official tag but something I still want to keep track of.

I suspect this request would be some work though so I suppose I've no choice but to pick my ten custom fields carefully. But, thank you in advance for at least considering the suggestion.

I had not seen that I could do that low-level mapping with actions - Thanks! But, without a way to display that is custom panels in a nice and pretty way it doesn't really do me any good.

I understand what you are saying about a trade off and I bet you are right about there always being more fields and obviously adding a lot of this data to every music file is just going to make them that much larger. But, it sure is handy to have pertinent information in the music file and if a particular field is not used by someone then there is not point allocating any space to it and no penalty for there being the option to put the data there if the user wanted it. Or is there something I'm not understanding about how this works?

Oh I see now what you meant. I was not aware that there were such complications in adding more fields. I'm hoping that others will want the flexibility of more fields.

I'm looking forward to it. 😀 There were a lot of nice things (especially in regards to actions) in the last release and I haven't had time to really use them all yet. I've been a little stymied by not having more than three custom panels but being able to more quickly get to all the built-in panels is nice with the panel picker. Thanks a lot for that!

Five is definitely better than three for me. Until I see how the mapping is going to work I'm not sure about it yet. Because I've created UDTI fields that don't exist in ID3 or FLAC but are useful to me, such as sheet music and guitar tab, there isn't anything to map these to so I would prefer to make a custom panel similar to the existing one for the lyrics. I've been contemplating also adding in midi information as well. That would use of three custom panels right there. Or, maybe you could add a tabs feature to custom panels, then I could use one custom panel and have multiple tabs. Yate then becomes not only my tagger app but also my only GUI to access this other metadata I've decided to save in the audio file so that I don't have to keep track of all these files independently. But mine is undoubtedly not the normal use case.

I think normalizing the names will help a lot. I don't personally care what the storage names are, it is the display name that matters the most. Most useful though would be something that defined the data that should be in the field. The info on the ID3 website is old but detailed, Musicbrainz help is really hit and miss, their links for IDs for example all land on the same useless page.