Multiple tag types and surprising behavior of mp3tag

Support
1

Today I've come across an album which had id3v1, id3v2 and APE tags, all with different contents. It is displayed like this in kid3. (I do think it mangled/misdetected the id3v1 tags but you get my point)

grafik
grafik396Ă—908 12.2 KB

And dbpoweramp Edit ID-Tag displays it like this:
grafik
Having set up mp3tag like this, my expectation was that all tags are read by mp3tag and identical tags of a "better" tag format supersede the same field of more restrictive tag types, adhering to the hierarchy id3v1 < id3v2 < APE.
grafik

But this is not the case.
grafik

Only the few APE tags are displayed in mp3tag, even in the Extended Tags. While it indicates which tags it is showing if you read the title bar carefully "Tags - APEv2 (ID3v1 ID3v2.3 APEv2)" I still find it confusing that the documentation for Extended Tags states this:

The extended tags dialog available via View → Extended Tags... Alt+T allows for viewing and editing all supported tag fields and cover art for individual files and multiple files at once.

Correct would be that it displays all supported tag fields of the "best" detected tag type, ignoring all other tags present in the file.

My further expectation was that using "Remove tag" would delete ID3v1, ID3v2 and APE tags and upon reverting that action, write back all previously read out tags in the type(s) selected under "Write" (in my case ID3v2.3 UTF-16).

That is also not the case. Mp3tag successfully deletes all 3 tag types and then writes back only the detected APE tags as new ID3v2.3 tags, discarding all ID3v1 and ID3v3.2 tags.

I mean I could deselect "Read" for id3v1 and APE, then always delete all tags and write back the contents of the idv3v2 tags to ensure no residual tags remain, but in my opinion it would be much better if mp3tag reads all selected tag types, resolves identical tag conflicts via a hierarchy and then saves all detected tags in the tag format(s) chosen under "Write".
Or Mp3tag should at least show all detected tags grouped by tag type in the extended tags so the user can copy over the contents of desired tags of one type to another type manually.

In the currect state mp3tag turns a blind eye to all but the "best" tag type while merrily deleting the other types without ever having displayed their contents. That's confusing and for most people probably unwanted behavior.
I've used mp3tag for years without noticing it as luckily most of the files I encounter have ID3v1 and ID3v2 tags, in which case only the ID3v2 tags are displayed. But I'd still like to be able to see the contents of the ID3v1 tags as well. Preferably without changing an option in mp3tag and reloading the files.

2

The behaviour is described in the documentation:

and has been around for years - and user irritation also:

3

Maybe it's time for a change if it still leads to irritation/confusion 17 years later.
I don't understand the rationale behind only displaying one type of tag in the extended tags dialog which is supposed to display all tags.
kid3 manages to display the different tag types clearly separated and dbpoweramp displays them mixed together without declaring the type (which I find worse).
But both solutions beat only displaying a portion of the tags or changing the configuration like this to see all tags, one type at a time:

  1. Read ID3v1, deselect ID3v2 and APE, reload files
  2. Read ID3v2, deselect APE, reload files
  3. Read APE, reload files
4

MP3tag does not evaluate what

could be.
As other file formats may have only 1 tag type (e.g. mp4 or FLAC) the avialable information has to be gathered in one internal container - you see %artist% but not vorbis comment artist or TPE1 or @art and so on. So a decision has to be made which information it should be. And this decision is something that you, the user has to and can make.
And looking at the settings in the screenshots, a decision has been made to modify the default settings.

5

Doesn't it? When I select for it to read all available tag types and all are present, it only displays APE, if I only select ID3v2 and ID3v1, only ID3v2 is displayed and if I only select ID3v1 and APE, only APE is displayed. That is an evaluation in my book.

Hence my proposal for a hierarchy. If the same field, %artist% is present as vorbis comment artist, TPE1 and @art, Mp3tag could either choose to automatically prefer one tag type over another (for example ID3v1 < ID3v2 < APE) or it could display all 3 types in the extended tags and let the user decide which to keep by for example highlighting conflicts (this would be harder to implement).
And when there is only one version of an internal field present in the file (only TPE1 for example), it should not pose a problem at all.
The mappings should already be there, otherwise setting to read one tag type and saving in another would not work.

The decision I intended to make was to display all tags, which I now learned (in part thanks to you) is currently impossible in mp3tag. Which makes me wonder why, when other programs manage to work with different tag types at the same time in the same files.

6

I suspect that the reason is simply a lack of interest, both by Mp3tag users and by the developer. Such a request hardly ever comes up in the Mp3tag forums. And years ago the developer had this to say: ID3 v1&2 suggestion

7

That's a pity. I usually prefer having all available information at my disposal before deciding what to keep and what to delete.

In the case of my example album if I decide not to display the APE tags (which is the default behavior I think), the information that the album was treated with mp3gain (which is a lossy normalization step) is not available to me, unless I either change the tag settings in mp3tag and reload the files or open the files in another program first (kid3 and dbpoweramp Edit ID-tag for example).

And if I do set it to read the APE tags, the ID3 tags aren't displayed if any APE tag is present. Since I've had the settings like they are now for quite a while I have the suspicion that quite a few albums that seemingly had no standard tags at all simply hat at least one APE tag, thusly preventing mp3tag from showing me the ID3 tags.

Now that I know I can check suspicious files like that in kid3, which is a hassle but manageable. Still leaves a sour taste in my mouth that mp3tag doesn't display all tags, no matter what settings I choose.

8

There is nothing lossy with mp3gain.

9

Really? I've never used it myself but what I read about it was that it changes the audio part to normalize. However if the tags remain intact, that step is supposed to be reversible.
Which makes it irreversible and kind of lossy if the tags are lost. That's what I meant.

10

Very useful explanation from @poster:

11

With mp3gain you can decide whether the information about the orginal volume level is stored in tags or not. Even without this tag information, you could restore the original state if you have noted it down elsewhere.
Anyway there is nothing lossy in the way of lossy audio-formats like mp3.

12

Thanks for linking the detailed explanation. I guess deleting the mp3gain tags is only insofar "lossy" as the original volume level of the songs is lost.

Which is something that can easily happen in mp3tag if it's set up like this:
grafik
Performing Remove tag followed by undoing the action in this config deletes the APE tags without ever having displayed them. I still find this problematic.

13

I would now follow a modular way. If MP3tag finds files for you with various tag versions and you do not want to re-read them to find out to what extent previous editing steps and uses of other programs let the tags get out of sync, then you could probably easily drag&drop them to one of the other programs that show the tag contents in the way that you like.

14

I wouldn't either. I just pointed out how inconvenient it would be if the goal of seeing all tags was to be achieved within mp3tag.

That's what I'll do until mp3tag hopefully one day will be able to work with all available tags, not just one type at a time.