Missage tag info, Empty v2 tags override v1 tags Options

[Dragonne]

I installed Mp3Tag to give it a try. I have over 10,000 mp3 files and found that 2 or 3 thousand apparently have both v1 and v2 tags - but the v2 tags are empty. In that case they empty tags overwrite the non-empty v1 tags and so the data is not "read". Since I don't before hand which tags are empty (it might not be all of them), I can't just turn off reading v2 tags.

This is not necessarily an Mp3Tag "bug", but does affect its usability. Probably the bug is in the various programs that produced empty v2 tags. But I would think that it needs to be handled.

[DetlevD]

I installed Mp3Tag to give it a try. ... apparently have both v1 and v2 tags - but the v2 tags are empty. ...

Possibly no bug but misunderstanding how Mp3tag works.

In dialog "Mp3tag/Tools/Options/Mpeg" what tag types are set to be read?
What tag-types will be written?

Do a systematically investigation. What tag type carries what data?

At first disable reading of APE tag-type and you will see ID3v2 tag-type fields and values.
Then disable reading of ID3v2 tag-type and you will see ID3v1 tag-type fields and values.

DD.20120708.1404.CEST

[Dragonne]

Possibly no bug but misunderstanding how Mp3tag works.

In dialog "Mp3tag/Tools/Options/Mpeg" what tag types are set to be read?
What tag-types will be written?

Do a systematically investigation. What tag type carries what data?

At first disable reading of APE tag-type and you will see ID3v2 tag-type fields and values.
Then disable reading of ID3v2 tag-type and you will see ID3v1 tag-type fields and values.

DD.20120708.1404.CEST

I did all that. But, I did it again with a selected file. Specifically for a selected test file, when I choose only APE there is no meta-meta. When I choose only ID3V2 the only meta-data is for Artist. When I choose ID3V1 all of the meta-data is there (although the title is truncated due to its length exceeding the ID3V1 length limit). When I examine the file in hex I see the ID3V1 tags at the end. At the beginning I see ID3V2 tags. Some with data and some that are empty. Of particular interest the Genre tag has data but it does not show up. There is other ID3V2 data present.

So, I belive that my conclusion is correct. Empty ID3V2 tags should not overrite non-empty ID3V1 tags. Seeing the data in the Genre ID3V2 tag there is possibly some other issue. The file was written by RealPlayer which was used to rip the track. I tried attaching this particular file so that it can be examined in more detail by someone who understands the binary format better but it is too large. Apparently there is a 200k file size limit. Most .mp3 files are larger than that. This one is 5M.

Note that Windows Explorer, RealPlayer and Zune do not have a problem with the tags. Mp3Tag and FooBar2000 both are unable to read the tags correctly.

[Dragonne]

I did all that. But, I did it again with a selected file. Specifically for a selected test file, when I choose only APE there is no meta-meta. When I choose only ID3V2 the only meta-data is for Artist. When I choose ID3V1 all of the meta-data is there (although the title is truncated due to its length exceeding the ID3V1 length limit). When I examine the file in hex I see the ID3V1 tags at the end. At the beginning I see ID3V2 tags. Some with data and some that are empty. Of particular interest the Genre tag has data but it does not show up. There is other ID3V2 data present.

So, I belive that my conclusion is correct. Empty ID3V2 tags should not overrite non-empty ID3V1 tags. Seeing the data in the Genre ID3V2 tag there is possibly some other issue. The file was written by RealPlayer which was used to rip the track. I tried attaching this particular file so that it can be examined in more detail by someone who understands the binary format better but it is too large. Apparently there is a 200k file size limit. Most .mp3 files are larger than that. This one is 5M.

Note that Windows Explorer, RealPlayer and Zune do not have a problem with the tags. Mp3Tag and FooBar2000 both are unable to read the tags correctly.

Also, both MP3Checker and MP3Utility give the file a clean bill of health. MP3Utility displays both the ID3V1 and ID3V2 tags which match what I said above. I also didn't mention that when I select both ID3V1 and ID3V2 tags only the ID3V2 tags are showing up (which is the problem). Note that different failing files may have different ID3V2 tag data present. Most have none at all.

Interestingly, in looking through the hex I see some of the missing tag information in the ID3V2 area. Since I don't know the binary format, I don't know if this is "garbage" data in unused areas or if the ID3V2 tags are mal-formed, an older version or what, although both very old and very new versions of Real JukeBox / RealPlayer all read the data ok. That makes me think that an older version of the standard was used writing the files. This particular file appears to have been ripped by RealJ ukebox (I have been ripping mp3 files for a long time). I spot checked other files ripped by Real JukeBox and they have bot ID3V1 and ID3V2 tags and everything is correct so I may be incorrect about an older version of the standard being used.

Since I can't upload the entire file, I have removed everything except the first 2048 bytes and the last 128 bytes and attached that. That appears to cover all of the tag data.

If I loaded each file using ID3V1 tags only and saved using ID3V1 tags only that would strip off all of the ID3V2 tags. That would work except that it would remove the ID3V2 tags that are present. In some cases ID3V2 tags are needed because of field length limits. Since these are scattered amount a very large collection this would also be a very tedious process.

Attached File(s)

 test.mp3 ( 2.13K ) Number of downloads: 40

 

[DetlevD]

... when I select both ID3V1 and ID3V2 tags only the ID3V2 tags are showing up (which is the problem). Note that different failing files may have different ID3V2 tag data present. ... If I loaded each file using ID3V1 tags only and saved using ID3V1 tags only that would strip off all of the ID3V2 tags. ...

Do understand that Mp3tag has a priority view to the possible embedded tag-types when reading data: APE > ID3v2 > ID3v1
You can set the Mpeg options for all tag-types to be read, but the existing tag-type with the higher priority wins.
That leads often to problems, especially when mp3 files have got an APE tag-type accidentally by misuse of the Mp3Gain utility. The APE tag-type with the ReplayGain informations hides all the other tag-type's data.

In your case the problem seems to be that the file has a proper filled tag-type ID3v1, but the ID3v2 tag-type carries less or different data.
Note: In ID3v1 the genre is stored into one byte as a genre catalog number
(... go on reading Wikipedia articles about ID3v1 and ID3v2).

Beside that, the ID3v2 tag-type seems to have any data, otherwise the data from the ID3v1 tag-type would be shown by fallback, when both tag-types are set to be read.

Note: The dialog "Extended tags..." will always show all tag-fields, which are supported by Mp3tag (depending on the set of Mpeg options).

There is a tricky way to pull or lift up data from a lower levelled tag-type to a higher tag-type.

Lift up data from ID3v1 to ID3v2
Set tag-type APE completely to off.
Set ID3v1 to write off, read on.
Set ID3v2 to write on, read off.
Refresh view.
Dialog "Extended Tags..." will show only ID3v1 tag-fields.
Use the action "Format value" to create user defined tag-fields (you can create a group of actions to handle all ID3v1 tag-fields at once).
Example ...
Action: Format value
Field: ID3V1_ARTIST
Value: %ARTIST%
(... and so on for all ID3v1 tag-fields).
Perform the actiongroup.

Then switch the Mpeg options for ID3v2 to read on and write on.
Set all other tag-type's access methods to off.

Refresh view.
In the column "TagRead (TagTypes)" you see the current tag-type status for each file.
Dialog "Extended Tags..." will show all tag-fields from the ID3v2 tag-type.
There will be shown all the fields you have created in the prior step ...
ID3V1_ARTIST (... and so on), even ID3V1_GENRE, now with textual description.

From now on do work only with the ID3v2 tag-type.
If you further need the tag-type ID3v1 too (for old players), then set Mpeg options to read and write the tag-type ID3v1 too.

It can help to set up additional columns for the helper tag-fields.
This offers a better overview about the current values in the related tag-fields, for example ARTIST and ID3V1_ARTIST.

Then format the tag-field ARTIST (... and so on) with the data from the helper tag-field ID3V1_ARTIST (... and so on).
Action: Format value
Field: ARTIST
Value: $if2(%ARTIST%,%ID3V1_ARTIST%)
... or ...
Value: %ID3V1_ARTIST%
(... and so on for all helper tag-fields).

If all went good, then remove the helper tag-fields.
Action: Remove fields
Fields: ID3V1_ARTIST;ID3V1_TITLE (... and so on)

Good luck!

Oooohhhh, ......... monday morning!

How could I forget this?
http://forums.mp3tag.de/index.php?showtopic=11736

DD.20120709.1000.CEST


Would it be possible to implement such program code to make this copy method available for the Mp3tag user?

This would eliminate struggling with the export and import of language specific special characters by detour of external text file.

This would be suitable to concentrate the copy process between different tag-types into only one dialog window.

DD.20120710.1010.CEST

This post has been edited by DetlevD: Jul 13 2012, 07:01

[dano]

That does not work Detlev.
You will lose every Id3v2 tag field except unsupported frames.

You have to export the ID3v1 data to a text file and then import it to the ID3v2 tag.

Dragonne in your file the only properly stored data in the ID3v2 tag is the artist tag. The rest of the information is saved in one tag frame that can have any kind of (binary) data. And the data structure is only known by the program that wrote it.
So all this additional info (also the longer title tag) is only readable by the Realplayer application.
Maybe you can get the program to write a proper Id3v2 tag?

This post has been edited by dano: Jul 9 2012, 11:00

[Dragonne]

That does not work Detlev.
You will lose every Id3v2 tag field except unsupported frames.

You have to export the ID3v1 data to a text file and then import it to the ID3v2 tag.

Dragonne in your file the only properly stored data in the ID3v2 tag is the artist tag. The rest of the information is saved in one tag frame that can have any kind of (binary) data. And the data structure is only known by the program that wrote it.
So all this additional info (also the longer title tag) is only readable by the Realplayer application.
Maybe you can get the program to write a proper Id3v2 tag?

In some files only Artist shows up as ID3V2, others have Artist and Genre and others none at all. Possibly using a newer version of the program I could open each file and make an edit and save it. However, that is pretty tedious for several thousand files (but still only about 10% of the total, and randomly dispersed). It could take months do what you suggest manually.

If the only tag which is correctly saved is Artist and the remaining fields are in a generic format making the data unavailable then the other tags DO NOT EXIST as ID3V2 tags for all practical purposes. In that case, the ID3V1 tags should always be used. If you display an ID3V2 tag and it is blank and you have an ID3V1 tag which is NOT blank then the ID3V1 tag should be used.

The hierarchy should not be all APE tags first and only, all ID3V2 tags next and only and all ID3V1 tags last, it should be APE, non-blank first, ID3V2 non-blank next and ID3V1 last. And the hierarchy should be traversed for each individual tag.

Maybe I'm crazy but it seems simple enough to me. No file changes are needed, because all of the data is still there - it is just being ignored because of blank fields.

P.S. The "Extended" dialog does NOT show all tags in the file when both ID3V2 and ID3V1 tags are selected, it only shows the ID3V2 tags.

[Dragonne]

I am assuming that the existing pseudo code is something like this...

...tags <= new Map<String,String>
...for each tagBlock order by "APE', 'ID3V2", "ID3V1"
......for each tag in tagBlock
.........tags.add(tagName, value)
......break

And that it should be modified as follows...

...tags <- new Map<String,String>
...for each tagBlock order by "APE', 'ID3V2", "ID3V1"
......for each tag in tagBlock
.........if value.Trim() != "" and not tags.contains(tagName)
............tags.add(tagName, value)

Sorry for the leading dots, but the post destroys indentation.

This is very simple, robust and allows all possible tag data to be retrieved. If a file contains a higher level tag type which contains all of the possible tag names then there is no difference. If a lower level tag block contains tag names not present in a higher level tag block then this change is far preferrable because it picks up more tag data. And is certainly the expected behaviour regardless of the amount of effort.