Options > Tags > Mapping user interface

General Discussion
#1

I truly love the new custom tag mapping ability of Mp3tag 2.45. It works perfectly. Really, far better than I would have expected, the seamless nature of it is extraordinary. From saved actions to column values and the Tag Panel, there's zero confusion once you've set up the mappings to your liking.

But I have a couple of suggestions for the user interface in options. I apologize for not bringing this up prior to the 2.45 release.

#1
The two columns should be reversed in their order. The names you're mapping should be on the left and what you're mapping them to should be on the right. People think from left to right, as in:

TRACK -> TRACKNUMBER

#2
The column headers have almost no meaning to the end user. They probably mean something to the programmer, but that's of little practical use. I would suggest (after swapping the column aorder) something more understandable:

Field Name & Map To

#3
There's some confusion when mapping to a field name that Mp3tag also maps internally, as in the many mapping for ID3v2 frames. The confusion stems from the included VorbisComment mappings, which many users may use as examples. These fields are not mapped again, while any ID3v2 mappings get mapped twice. With the VorbisComment mappings, it puts the Mp3tag internal field name in one column, while it's the opposite with ID3v2 mappings. I'd like to suggest that color highlighting any internally mapped field names would be a good idea.

#4
Particularly because of #3, a dedicated Help page for User-defined mappings would be welcome, explaining how the process works and how names may be mapped twice by Mp3tag. Give additional examples, particularly for mapping ID3v2 names. IMO, this should be a separate page from the existing Mappings help page, which is already quite long. Provide links between the two Help pages.

As I read it, the current Help regarding User-defined mappings is wrong.

Given the pre-defined VorbisComment mappings, the "Source" is not the Mp3tag internal field name, but the name read and written in the tag.

#2

Thanks for the valuable feedback! I'll try to improve it to the next version.

Kind regards,
Florian

#3

Thanks for a great program. More on tag mapping confusion...

I really want to understand this, but I'm struggling.

A comprehensive explanation of tag mapping would be a great help. There seems to be a lot of ambiguity - I don't know whether the above post has helped my understanding or not.

On the help page, these two consecutive sentences appear to contradict each other:

There you can create mappings for a specific tag type (APEv2, ID3v2, MP4, VorbisComment or WMA) and provide a Source name (Mp3tag's internal name) and a target name (your preferred field name).
After reading tags from files, Mp3tag translates all source field names to their respective target (and vice-versa when writing tags).

Presumably Mp3Tag translates preferred names to internal names on a read, and vice-versa on a write.

Further up the page:

Please note that fields of VorbisComments (used with FLAC, OGG, SPX) and of APEv2 tags are not mapped internally by Mp3tag but are displayed with their actual name.

Does this mean that the purpose of mapping VorbisComments is to marry up one preferred name to another? E.g. mapping COMPOSERSORT to COMPOSERSORTORDER will ensure that COMPOSERSORT is read into COMPOSERSORTORDER, can be manipulated as such in MP3Tag, and will be written out as COMPOSERSORT (and COMPOSERSORTORDER too?).

I don't think that this is the case, because DATE is mapped to YEAR by default, yet if you try exporting both, only YEAR yields a value. To further add to the confusion here, both YEAR and DATE are listed as Extended Fields in the interface.

Sorry if I'm being dim, but I'm trying to get a large number of FLAC files consistently tagged, and there seem to be a number of rules that it would be helpful to understand that don't seem to be documented. My aim is to have a comprehensive and consistent library of tags in FLAC files, which I can then map to the more limited tag support of other formats (esp. M4A). This would include fields that could be useful in the future but aren't supported by programs / formats now such as CONDUCTORSORTORDER.

Thanks

Jamie