It appears that id3v2 has a bug when writing tags that results in a null
byte being prepended to most of the tag fields.

From my testing, it appears that the fields affected are TRCK, TYER, TIT2,
TCON, TPE1, TALB, and possibly others.

For instance when calling "id3v2 --year 1990 file.mp3", the encoded field
that ends up in the file has a tag length of 0x05, and the contents are
"^@1990".  The verbatim contents (seen through less) is:
"TYER^@^@^@^E^@^@^@1990"

Please let me know if you need any additional information.

Evan

This is not actually a bug, the '\0' byte in front of the string
specifies the encoding, where 0 is iso-8859-1.

See http://www.id3.org/id3v2.4.0-structure.txt, section 4.

Closing as not-a-bug, confirming the analysis already given in this
report by Tobias Diedrich in 2005.

The leading 0x00 byte is not a spurious null prepended by id3v2: it is
the mandatory text-encoding byte that begins every ID3v2 text
information frame. A value of 0x00 denotes ISO-8859-1, which is the
default and correct encoding for plain ASCII/Latin-1 text. This is
required by the ID3v2 specification (text frame structure: a one-byte
text-encoding descriptor followed by the string).

In the reported example, TYER 00 00 00 05 00 00 00 1990 decomposes as
the frame ID TYER, the 4-byte size field (00 00 00 05 = 5 bytes), the
2-byte flags field (00 00), and then the frame body: the text-encoding
byte 00 (ISO-8859-1) followed by 1990. id3v2 is therefore writing
well-formed, specification-compliant frames, and the output is read
correctly by conformant taggers. No change is warranted.

Martin