Read ID3v1, IDv2, APE priority?

[Cookie_Monster]

MP3Tag is a great tool, but frankly I'm disappointed about how it deals with audio files that have more than one tag.

I wonder what's the read priority when I have all tag formats checked in "Options->Tags->->Read"? The thing is that it happened more than once (I have all tag formats checked in Tags->->Read) that I have lost meta data when doing my tag conversion routine (Ctrl-S, Ctrl-R), because the tag with the most accurate or most extensive meta data had a lower read-out priority over the one with only few meta data. "Tags->->Save" has the tag I want, and "Tags->->Remove" has the tags I don't want checked.

How can I assure that Mp3Tag always reads out the tag with the "best" meta informations, without having to manually check every tag by changing the read settings in the options menu?

I think Mp3Tag needs an easy access to all tags in the main GUI: Buttons. You press the ID3v1 button and then you get the meta data in the ID3v1 tag, when you then do file actions all meta data used is based on the info in that tag. Press the APEv2 button and Mp3Tag switches to the APEv2 tag and bases all its actions on the information it finds in the APEv2 tag.

For merging what you think is the best meta info of two or more tags, you would use Ctrl-C, switch tag and then Ctrl-V.

Well, I doubt this will be implemented (that's why I haven't posted in the Feature Request forum) because Florian already declined to change the current way of selecting the preferred tags (i.e. moving it out of the options).

So, I just want to know what others think about this or whether some of you even had similar bad experience of this kind. I use to change the tag type of many hundreds of files at once, and really I can't check which tag holds the best meta data for every single one of them! So this is kind of a petition in case there are many other Mp3Tag users who'd like this to be improved.

[Sebastian_Mares]

The priority is APEv2 > ID3v2 > ID3v1. Even if an APEv2 tag is present but empty, it will be prefered over an ID3v2 tag.

[Cookie_Monster]

The priority is APEv2 > ID3v2 > ID3v1.

Ah yep, now I remember. I guess I never really noticed it since I use APEv2 by default, and therefore had no trouble that the changes I make are not displayed: like you first really noticed something when it is missing.

Even if an APEv2 tag is present but empty, it will be prefered over an ID3v2 tag.

Yes exactly. Unfortunately that's causing some trouble when you mass-migrate from various inter-mixed tag systems to a consistent one. It would be more convenient to have them displayed all at one glance (which would require some major GUI changes) or have an option to switch the Read settings instantly from the main window (or more precisely change the tag that is being displayed in case all tags were loaded from the files into memory and not only the one displayed).

[Cookie_Monster]

The priority is APEv2 > ID3v2 > ID3v1. Even if an APEv2 tag is present but empty, it will be prefered over an ID3v2 tag.

I recently encountered a quite serious problem which is caused by Mp3Tags prioritization. If the MP3s have MP3Gain undo data, which is saved in APEv2, then the actual metadata related to the music isn't shown.

So I have to disable APEv2 reading in order to see and manipulate the "real" metadata.

Maybe this will change Florian's mind to look into this matter...?

[eyebex]

I also wished tag reading prioritization would be a little more generic.

For example, in the options under Tags -> Mpeg -> Read (and also for the other file formats), instead of checkboxes there could be a listview listing all supported tag formats for that file format, along with a checkbox next to each listview item, and up / down button next to the listview control. The checkboxes inside the listview would be used toggle reading of that tag, just as the checkboxes do now. The up / down buttons would be used to reorder items in the listview: The top-most tag format entry gets read first, the bottom-most last. All fields from all enabled tag formats would then be read into a common "tag field database" in order. Tag fields should get merged (and not overwritten) in that database.

As an example, let's assume the user defined the order of the tags to read to match Mp3tag's current behavior (APEv2 > ID3v2 > ID3v1). Then all tag fields present in the APEv2 tag would be read into the common tag database. Next, all tags fields that are present in the ID3v2 but do not yet have an (semantically equal) entry in the common tag database get merged into the tag database. Next the same is done for ID3v1. So in the common tag database you now have union of all tag fields from all user selected tag formats, and each tag field should also know which tag format it originally came from. This would be displayed nicely in the GUI tag panel by writing next to each field which tag the information came from (or by displaying nice icons instead of text next to the fields).

Finally, to solve Cookie_Monster's issue, there should be a second checkbox for each tag format entry in the listview saying something like "Allow override of empty tag fields", which means that in case a tag field is present but empty, the first tag format listed below that entry that also has that tag field present is allowed to override that entry with its own data.

What do you think?

[eyebex]

Florian, any comments regarding my suggestion?

[PappaSde]

No new arguments, but I also would like to see another handling. An easy way to toggle which tags are read/displayed would be nice.

[freekey]

So I guess this is the problem..

I support 100% for Cookie's suggestion for the tag read priority.

Thanks

[freekey]

I also wished tag reading prioritization would be a little more generic.

For example, in the options under Tags -> Mpeg -> Read (and also for the other file formats), instead of checkboxes there could be a listview listing all supported tag formats for that file format, along with a checkbox next to each listview item, and up / down button next to the listview control. The checkboxes inside the listview would be used toggle reading of that tag, just as the checkboxes do now. The up / down buttons would be used to reorder items in the listview: The top-most tag format entry gets read first, the bottom-most last. All fields from all enabled tag formats would then be read into a common "tag field database" in order. Tag fields should get merged (and not overwritten) in that database.

As an example, let's assume the user defined the order of the tags to read to match Mp3tag's current behavior (APEv2 > ID3v2 > ID3v1). Then all tag fields present in the APEv2 tag would be read into the common tag database. Next, all tags fields that are present in the ID3v2 but do not yet have an (semantically equal) entry in the common tag database get merged into the tag database. Next the same is done for ID3v1. So in the common tag database you now have union of all tag fields from all user selected tag formats, and each tag field should also know which tag format it originally came from. This would be displayed nicely in the GUI tag panel by writing next to each field which tag the information came from (or by displaying nice icons instead of text next to the fields).

Finally, to solve Cookie_Monster's issue, there should be a second checkbox for each tag format entry in the listview saying something like "Allow override of empty tag fields", which means that in case a tag field is present but empty, the first tag format listed below that entry that also has that tag field present is allowed to override that entry with its own data.

What do you think?

I have the same thought with you!!!

[freekey]

Set mp3tag to read only id3v1 and write to both id3v1 and id3v2 would not help since...

It would overwrite all the precious info in id3v2 if it's already exists!!

Or is there any tricks to overcome this?

Thank you.

[freekey]

I have a proof that this could be done...

As can be seen.. there's no basic info inside the id3v2 (it is in id3v1), but the program could read both info at the same time.

So, why can't mp3tag?

Thank you.

[freekey]

By the way, it seems that the program also prioritize id3v2 higher than the id3v1 since the Comment field in the id3v1 is not 'test'.

Thank you.

[Florian]

Sure, it can be done but I don't plan to support this with Mp3tag.

[freekey]

Ermm..

But could you justify why is that so?

Coz I don't see any big issue with this..

The only thing needed is just to read the id3v1 value if the id3v2 is null. That's all.

Thank you.

[Florian]

Coz I don't see any big issue with this..

The only thing needed is just to read the id3v1 value if the id3v2 is null. That's all.

Yes, from that point of view I also don't see the big issue there. However, merging different tag versions into one consolidated view results in a situation where particular parts of that information cannot be traced back to a tag version (ID3v1, ID3v2 or even APEv2) anymore. This would most likely result in a new support nightmare with lots of posts describing the fact that Mp3tag shows information that is not displayed in player X or program Y.

Of course, there is also the possibility do create dedicated views for the different tag versions -- but this is also something I don't want to realize in Mp3tag because it'll unnecessarily bloat the user interface.

I simply suggest to decide for one consistent tagging strategy, be it ID3v1 or ID3v2 or both, and fix the tags accordingly.