Feature Request: A way to see each Tag's ID3 Frame association?

Is there any way in Mp3tag when viewing tag's contents to readily see what ID3 frame it is read from? Unless I'm mistaken currently you have to delve into the Tag mappings web page to see what frame the field is reading/writing to, and even then it's an assumption on the user's part. This could be very handy to readily see if, for instance, a tag is mistakenly in a TXXX frame rather than its proper frame.

Could you give an example for this behaviour?

And then I wonder how you would remedy this mistake.

One example is where another software took the TORY (Original Release Year) frame and rewrote it to a TXXX frame called Original Release Time. Bringing it up in Mp3tag showed it as Original Release Time, but there is no way to readily see whether it was coming from a TDOR, TDRC, or TXXX frame, when it should have been rewritten to the TORY frame. No bug on the part of Mp3tag, but its reliability is such that one can use it to find tag bugs from other programs, and seeing the frame associations to a field name would aid that.
The remedy would be to use Mp3tag to copy the bad tag to the correct one, and delete the bogus one, and make sure the other offending software's configuration is fixed, reported, or avoided.

This would assume that you have knowledge of the naming conventions for user-defined fields ... which you can see: all fields that come from a frame have fieldnames in one word. A field with 3 words like "Original Release Time" cannot be correct.

The correct names would be ORIGYEAR or RELEASETIME

The transformation process form a user-defined field to a standard field will probably never happen as MP3tag would have to guess/interpret what data can be found in which field and then move it to another field.

Prince's "1999" would then probably fill the YEAR field and leave empty the title ...

Ok, so single word tags could wind up in different frames, either way. YEAR could be coming from TYER, TDRC, or TXXX frame. Seeing the frame ID would remove the assumptions and guesswork as to which one it's in, and clarify which one needs correcting or deleting. How is this a bad thing?

It is not bad as such. I only try to find the benefit.
I am not sure if there is a software around that creates a TXXX frame with the name YEAR.
In general I would assume that any TXXX frame that looks like a standard field would still not be displayed in the standard field. If you had TXXX/Year, then YEAR would be left empty.
This should make you suspicious.
The case you stated shows a user-defined field that has a name that sounds like a standard field but is actually none.
But as users are free to name their fields in any way they like, one can never be sure if the similarity is intentional or just accidental.

Also: what about mappings for e.g. ogg vorbis or other user-defined mappings.

By now it is like that: if the data appears only in field with names that cannot be taken from the mp3tag menus, it is very likely that it is a user-defined field. So the information is there, somehow.

Yes, it can happen to a standard tag like YEAR. Below is an example of goofed up tags from other tagging software:

"Before" (good) ID3 frames & Mp3tag display :

"After" (bad) ID3 frames & tag display:

There's a TYER, TDRC, and TXXX, all with the year 1970 in them. And one can see the difficulty in the Mp3tag display telling what is what without seeing the frame associations, and required a separate utility to see which tags went with which frame (there's both a BAND tag and ARTIST tag, and YEAR displays twice). Yes it's not common, and what happened above is not Mp3tag's fault, but it is a very useful tool that if it could go a step further to show the frames it would be an even better tool and not require a separate utility to see that information.

I see a huge benefit in bringing information out of the dark and into the light, as is needed in the above example.

Another reason seeing the frame association is helpful.

The frame display could be blank for non-MP3's, if need be.

It was just a suggestion, if it's a huge pain to display this available information, then never mind - I'm still a big fan, it's the best tagger around. :wink:

I support this feature request. It would be a big help to me also.

I come from a MP3 centric world however and I am guessing this could get complicated with mixed tag formats.

More information is never a bad thing, especially if it can be optionally switched on and off as required.

I always include the frame code in my tag panel field descriptions, but it would be good to see them in the extended tags panel also.

Being able to see the "real" field/frame names would also be really helpful when you're writing scripts/programs/apps that read or modify tags. With appreciations to Oblio for the workaround tip, I would love to see an mp3tag option to automatically display tag name->field/frame name associations within the program (in column heads, the tag panel, certainly in the Extended Tags box).

(By the way, the ability to resize the Extended Tags box, or just a bigger box, would also be a a good thing. Why is it so small? Why not make it resizable and permit full screen?)

Very many appreciations for Mp3tag,

In my MP3tag the extended tags dialogue is resizable. see the bottom right corner.

As for the field names:
Please also consider the following workflow: you want to change the tag format bei it from V1 to V2.3, from V2.3 to V1, the same with V2.4.
What should be displayed?
That what has been read?
That what will be written?
Or all kinds of everything?

No criticism, just asking.
And for the programmers: you find a list of fields supported by Mp3tag in the help: Tag Field Mappings – Mp3tag Documentation
perhaps you can build your own table of names.

I see a problem here as you can load many different file types at the same time and you then have to cope with vorbis comments, chunks, atoms and perhaps frames. I doubt that they all can be displayed at once in a sensible way.

Just to clarify (and to put an early end to a possibly long-winding discussion): it's not planned to display internal ID3 frame names (or MP4 atom names) from within the program.