MP3 tags from other MP3 apps are not recognized

Support
1

I have been a long-time user of mp3tag, even though the problem mentioned in the subject line has actually existed for many years and is annoying.

The problem is that virtually all common systems and apps on the market, whether they are apps on the PC that read MP3 tags (foobar, MixedInKeys, Windows Media Player, Virtual DJ, and a lot of other MP3 tools and players), apps on smartphones, TVs, or even in cars, can read virtually all tags created by other apps—only mp3tag seems to do its own thing. For example, if I tag something in MixedInKeys, practically no tags appear in mp3tag, especially not basic ones like artist or title. Let's not even get started on integrated covers or special tags like Key, even though I defined them correctly in mp3tag (it worked for a short time, then suddenly stopped). I know how to create the KEY tag correctly; I've managed to do it in foobar. If I download an MP3 from somewhere (without knowing how and with which app the tag was created), it is still recognized by practically all apps, but very often not by mp3tag.

This means that if I want to use mp3tag, I have to laboriously recreate all the tags for almost every MP3 file, even though they are already contained in the file. I also have to search for and insert the cover image again, even though it was already contained in the MP3 file.

Now the question for me is why practically all apps can read the tags correctly from all other apps, but mp3tag can't? Of course, all other apps can read tags created with mp3tag, so why doesn't it work the other way around?

The tag options in mp3tag are for reading ID3v1, ID3v2, and APE, and for writing ID3v1, ID3v2, APEv2, and ID3v2.3 UTF-16. Does anyone know how to solve this problem? I would actually like to stick with mp3tag, but it's gradually becoming too annoying for me.

2

What happens if you switch off the option to read APE tags?

3

Oh man, thanks, a lot better now… I didn’t know that this APE tag option enabled causes so much trouble, I saw it just as an further option to read this APE tag, just in case a MP3 has it although I even had no idea what that's good for :wink:

4

From the documentation about Options -> Tags -> Mpeg

These configuration options are affecting audio formats which are using ID3v2 tags (currently MP3 and TTA).

Read

The order below, is the order in which Mp3tag reads different tag formats (that means that displaying APEv2 tags is prioritized over displaying ID3v1 tags). Mp3tag only displays the contents of one tag format at a time. The read tag format is denoted in the Tag column of the File List.

ID3v1 If enabled, Mp3tag reads an existing ID3v1 tag.

ID3v2 If enabled, Mp3tag reads an existing ID3v2 tag.

APE If enabled, Mp3tag reads an existing APEv1 or APEv2 tag.

5

then maybe the default reading order should be changed from the most common tags to the least common if all is enabled? Probably ID3v2 is the most common and should be prioritized when all options enabled?

6

Actually, when it is set to be APE first by default it tends to call out that they exist in the first place, and you can choose what to do with them. In my experience almost all files in the wild with APE tags typically have Replaygain values only. You can choose to keep these and write them back to id3 format or delete them. Leaving them unmanaged in the background can have adverse effects in other programs where you won’t have the same ability as mp3tag to find and handle them.

Once the APE values have been eliminated then the complete set of ID3 values will appear (after a refresh).