Saved ID3v2 tag not compatible with WinAmp 2.95

[avengerx]

I'm not sure what's going on. If I download a music, I get id3v1 but no id3v2 tag in WinAmp 2.95 (yes, that's that old one).

Then if I use squell's id3 tool, I see:

$ id3 -2v filename.mp3
#file   filename.mp3
#tag    ID3v2 3.0
{TSSE}
        Lavf58.27.102
(...)

If I just replace the ID3v2 in-place:

id3 --duplicate I_Dont_Want_to_Miss_a_Thing.mp3 -2 I_Dont_Want_to_Miss_a_Thing.mp3

Then voila, WinAmp shows its id3v2.

By Inspecting the tag again I see the same ID3v2 3.0, no difference in the dump value at all. So there's something kinda hideous going on. I've found a discussion somewhere else about somebody having a problem with ID3 tags due to its text encoding. Like, it was saving as UTF-16 but UTF-8 or Latin1 (ISO-8859-1) worked for them... Could this be the cause?

[avengerx]

It definitively is the character encoding in the ID3v2 tag.

"Broken" sample:

Fixed one:

Well, and most likely an issue with WinAmp not supporting that charset. Maybe it'd be useful to use UTF-8/Unicode by default as it's capable of showing more characters, like Cyrillic and more accent options, supporting a broader number of Youtube links that have comments/etc in languages other than English.

Well, there are further differences in those headers around 0x11 and 0x14 (0F, 03 in broken, 0E, 00 in working, respectively). The 0x11 byte seems to tell where to jump to get the first tag (jump 16 or 15 bytes, resp, which effectively "shifts back" the tag position by 1 position in the working one) but I'm not super versed in ID3 tag structure to tell that's the reason.