I discovered the following bug in mp3tag: It appears that mp3tag writes 0-terminated strings in id3v2 text frames where according to the specs there should be no 0-termination. This problem remains mainly unnoticed, but iTunes 7.1 chokes on the extra 0 in UTF-8 encoded v2.4 tags.
iTunes itself writes 0-termination on every frame!
And it's no problem for iTunes on other encodings, just utf-8 is a problem for it. Only Apple knows why. It's an iTunes bug!
iTunes also has more ID3v2.4 bugs that can make it problematic to use ID3v2.4 with itunes.
You are right, iTunes writes the 0-termination, but it doesn't write UTF-8. So, only Apple knows why it does that, but why does Mp3tag do it? I mean, it is still against the specs.
I've changed the ID3v2 writer with the current Development Build, so that frames are written without 0-termination.
It wasn't a bug, but it's probably more compatible without the 0-termination.
So, according to the ID3 specs, is it optional or forbidden
to write terminated text strings ? I was under the impression that
it is optional (i.e. it is not against the specs to do so) ?
And besides, while increasing iTunes "compatibility", are there
any risks that this change might lead to compatibility issues on
other fronts (with other software / other devices) ?
According to the specs of Ver. 2.4 there has to be such a termination.
See also http://www.id3.org/id3v2.4.0-structure .
Well, the specs isn't very clear regarding the termination. The termination sequences for the different character encodings are relevant for all frames holding several strings, they are separated by the termination sequences (noted as $00 (00) in the specs). But I really don't see any point in terminating single strings. So, I don't know...
Well, I am confused too. From my reading it seems optional, but
the way the spec is written indicates that termination might be the preferred way.
If it is not clear from the specification, I think Mp3tag should do what is common practice
and what most other tag writers do and have done for years. If, for example Winamp, Foobar,
Windows Media Player, and Taglib (Linux) all use termination (I don't know if they do) that
would be what I mean by "common practice".
I think it would not be a good Idea to change the behavior (from termination to no termination)
more or less just because of a bug in iTunes, when it is (I don't know if it is) common practice
to terminate strings. Maybe this would cause problems with some other programs, who knows ?
Anyway, I'm not enough into the specifications and intricacies of ID3v2 to know what's best,
but I just wanted to provide some "food for thought" that maybe it could be not a good idea to
change something that fundamental just because of iTunes...
To me it's pretty clear that this additional termination is wrong, but is also does not do much harm.
The big majority of programs use no termination.
The ID3v2 reference library id3lib doesn't do it.
When you read also the frame definitions of the ID3v2 standard http://www.id3.org/id3v2.4.0-frames and not only the chapter that Radagast showed, you should understand that this chapter only shows how you have to terminate a string but not when.
Compare for example chapter 4.2 with 4.2.6 from id3v2.4.0-frames
In addition to that, ID3v2.4 uses the terminating 0 to separate multiple strings in one frame. So a terminating 0 after the last string in a text frame could be interpreted as an additional string with zero length. Sounds a little bit hypothetical, but it could be interpreted like that.
Personally I think the section Radagast referred to is clear enough.
However, since some still find this disputable, would it be an idea to have the option to enable 0 terminating? Right now I'm tempted to stick to the latest beta which still had 0 termination but this would leave me with possible bugs and the lack of new features like TAK support.
No, this section only refers to strings which need to be terminated (which are referenced as 'terminated string' in the ID3v2.4 spec).
Can you point me to the application which requires the terminating 0 after each string?
I have a problem since version 2.38.
My walkman now cuts the last character of my song titles and artist names !
I had a look in the release notes and saw this probable cause :
[2007-04-29] REL: VERSION 2.38 (for Windows 2000/XP/2003/Vista) [2007-03-17] CHG: ID3v2 text frames are written without terminating 0 now.
Then I found this thread, hopefully !
Previously, my walkman (A-Data MF1), was cutting the last characters of ID3v2.4 (UTF-8) tags only.
When I used ID3v2.3 (UTF-16) tags, it was OK and displayed the full field contents.
Since mp3tag v2.38, the last character is cut, whatever the ID3v2 version…
It would be nice (at least for me) that I would be able to put this "0" back at the end of fields
Who cares about iTunes anyway?
…so it's a dead end?
Yes, I won't change the behaviour again and I don't think that it's good to add options for all this weird software and hardware out there.
Sorry for that!
Well, if IT IS THE STANDARD, it's OK with me…
I'll try to make them write a new firmware.
To my mind, having a superfluous #0 makes less harm (if it does), than not having 0-termination at all. Anyway, yes, you're right, it's not needed, but seems that many players (soft and hard) are confused. Don't know, if my one will show me correct values, but I agree with this change.
Thanks for mp3tag.
I wonder what other people think…
My walkman's manufacturer doesn't reply my request and has never issued any firmware update.
Thank you for giving your opinion too Kreator.
I'd like that zero back myself too.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.