ID3v2: Extra characters read

[DoomMaster]

You can have an example of real ID3v2 tag generated by EAC V0.9 prebeta 11 here:

http://evselyev.chat*****RealTag.bin

When Winamp reads the tag, it shows an extra character 'T' after the end of song name.

I tweaked the tag a bit and got something even worse:

http://evselyev.chat*****TweakedTag.bin

Characters 'TPE1' appear after the end of name.

IMHO, Winamp doesn't like characters 0xFF, 0x00, especially at the end of ID3v2 field.

Note, 0xFF is a Russian character in Windows. :) And, of course, all those funny characters in my tags look like Cyrillic to me.

[Sawg]

Hmm...only have heard about missing caracters. Anyways if EAC uses Unicode that migh be the problem, winamp doesn't support Unicode characters in ID3 tags (though it should)

[DoomMaster]

:( Look at the tags supplied, please. No Unicode, 8-bit characters only.

[Wish]

Is this an ID3V2 2.3 tag or a 2.4 tag? Winamp doesn't support 2.4 tags currently.

[DoomMaster]

I know. It is version 2.3.

I guess there whould be less questions if you'd look at the tags I posted. They are only 256 bytes long each and what you have to do with them is just view them as hex.

More comments for those who are lazy. ;) No offense, I am lazy myself. :)

May be, I should have said that the bug affects only few of MP3's I create. Most are read correctly so no Unicode or version 2.4 problems! But I happened to notice that the affected ones have a certain Russian character (0xFF) at the end of song name. Furthermore, EAC puts an additional zero-byte after the last character of the name resulting in an ASCIIZ string. The whole string is treated as a field of tag. When Winamp creates tags it acts differently. It doesn't store an unnecessary zero-byte relying on field's length property. IMHO, both variants are correct, but Winamp doesn't read ASCIIZ variant correctly in some cases, see above.

I don't know the standards about ID3v2. I just examined the tags in hex viewer and the format seems clear to me.