How to better handle multiple file types


I'm not sure how many other people have multiple file types in their music libraries. I have both Flac and mp3 files and increasingly, ogg vorbis as well. I'm finding the task of creating actions to tag the various files in the same way becoming more and more difficult as the number of file types and the number of my action groups increases.

This was an earlier discussion, with a failed attempt at addressing the problem:

While looking at the C:\Program Files\Mp3tag\help\main_tags.html help page for the current Mp3tag mappings, it occurred to me: Why have these mappings fixed and inflexible? What if users could define their own mappings?

My proposal:

  • Keep Mp3tag's current tag mappings in a user-readable and modifiable text file. Load this file when Mp3tag starts up.
  • Permit users to also have a custom tag mapping file (so that the default Mp3tag file doesn't have to be edited, just for safety sake). Load this file after the default mappings each time Mp3tag starts up. This way the default mappings may be overridden or new ones defined.

    Tag mappings would be defined by tag type (id3v1, id3v2.3 etc) and/or by file extension.

  • When an action, field or column references a defined tag, map it to the tag name defined. If an action references a tag that is not defined, don't translate it, just use it as-is wherever possible.
The syntax of the tag mapping file might be something like:
MYTAG=Some Tag


A file extension begins with a dot (.), while a tag type does not. The tag types would have to be predefined and limited to those recognized by Mp3tag. Recognition of both file extensions and tag names would be case-insensitive, but the tag written would maintain the capitization as listed in the definition.

This way, the actions themselves don't have to deal with all the intracies of dealing with different file types according to file extension or whatever. It makes it very simple for Mp3tag to add new tags, without having to hard-code them, plus users can add their own without needing to wait for a new release of Mp3tag.


I support this suggestion / approve this proposal.

Well meant to Florian, the latest program development using proprietary 'config-file-database' should be stopped resp. turned back to human readable and editable INI-file-database (and maybe registry-database-support).



I think this is not so easy to implement because it could lead to corrupt tags if not handled with care by the users.


Maybe another way to address this problem would be to remove the differences in mappings between the different tag versions. Can you come up with a list of inconsistencies?

To DetlevD: Seems like you're very disappointed by the new format of the configuration file, but this won't change my mind on this topic. I've already explained this change and I won't change it again.

Best regards,


I'm not sure what you mean by differences in the mappings.

Again, I'm not quite sure what you mean. The only kind of inconsistency there might be would be if the tag from one system had some different type of meaning within another system - a semantic difference, if you will. But unfortunately, there are no real standards and nobody is really recognized as a standards body for many of the tagging systems, so meaning is very difficult to figure out. Application differences in interpretation of tags ends up being a greater decider of standards. And different applications may expect different tags (within a given tag system). Users end up at the mercy of these applications.

An example:

ALBUMSORTORDER maps to TSOA in ID3v2.4. What if someone tags a Flac or ogg vorbis file using 'ALBUMSORTORDER'? I haven't tried it, but I'd assume it doesn't map at all and gets stored as ALBUMSORTORDER. Now, my main audio application does not recognize this tag - instead it expects ALBUMSORT. I've seen proposals from non-authoritative authors for a vorbis tag of 'ALBUM SORT' (with a space). You can easily see the confusion and the incompatibilites introduced.

My application also recognizes TSOP (ID3v2) and ARTISTSORT (flac, ogg, ape) for the sort order of the ARTIST field. These aren't even listed on the mapping help page.

With a user definable mapping system, you can maintain the current mappings, easily add new ones, and end users never have to touch them to have the same functionality that they currently enjoy in Mp3tag. But for people who know/need new tags, they'd then be able to define them and map them across different file types.


About mapping:
For some codecs and file-formats it's standard that the ttag-categoy (e.g. ALBUMSORTORDER) is written out and not shortened to a 4-letters string.
This is as far as I know for the files that support APE-tags and Vorbis Comments, so most codecs that are freeware (FLAC, Ogg, APE etc.).

And you can't avoid the incompatability, as there are many programs and players out there, who don't even understand the standards like ID3, so you can't think of the fact that they support open tagging-specifications. :wink:

But the idea with the two files for the specification sounds interesting.