[X] Trailing nulls in ID3v2 comments

[gino0631]

It looks like the application is incorrectly null-terminating ID3v2 comments; see https://github.com/JamesHeinrich/getID3/issues/121 for details.

[ohrenkino]

see the release notes for V2.81:
http://www.mp3tag.de/en/changelog.html
[2016-12-05] FIX: improved ID3v2 specification compliance by adding terminating 00 for text

               strings.

So, I would say that this is intentional.

[gino0631]

In the specification there are no nulls specified at the end of a comment text, so it is not clear why this change can be considered as an improvement.

[Florian]

OK, let me jump in there.

In the past there were different reports from users that had issues with programs that were expecting all strings terminated with 00 (or 00 00 in case of UTF-16), which led to me changing the way Mp3tag writes strings in ID3v2.

After reading the specification again (not sure how many times I did this), it's clear to me that it makes a implicit differentiation between "text strings" and "terminated text strings". However, at one crucial point in the ID3v2.4 spec §4 it describes the structure of text strings (highlights in bold are added by me):

If nothing else is said, strings, including numeric strings and URLs
[URL], are represented as ISO-8859-1 [ISO-8859-1] characters in the
range $20 - $FF. Such strings are represented in frame descriptions
as , or if newlines are allowed. If
nothing else is said newline character is forbidden. In ISO-8859-1 a
newline is represented, when allowed, with $0A only.

Frames that allow different types of text encoding contains a text
encoding description byte. Possible encodings:

 $00   ISO-8859-1 [ISO-8859-1]. <b>Terminated with $00.</b>
 $01   UTF-16 [UTF-16] encoded Unicode [UNICODE] with BOM. All
       strings in the same frame SHALL have the same byteorder.
       <b>Terminated with $00 00.</b>
 $02   UTF-16BE [UTF-16] encoded Unicode [UNICODE] without BOM.
       Terminated with $00 00.
 $03   UTF-8 [UTF-8] encoded Unicode [UNICODE]. <b>Terminated with $00.</b>

Strings dependent on encoding are represented in frame descriptions
as , or if newlines are allowed. Any empty strings of
type $01 which are NULL-terminated may have the Unicode BOM followed
by a Unicode NULL ($FF FE 00 00 or $FE FF 00 00).

This can give the impression that all strings are terminated. In fact, some developers implemented in exactly this way (e.g., Apple iTunes or foobar2000), whereas others are not terminating the strings (e.g., Windows Media Player).

I'd prefer to keep this more compatible implementation. Maybe James could relax his implementation a little?

Kind regards
– Florian

[gino0631]

Thank you for the very detailed explanation, I'll inform James.