Your message dated Sat, 20 Jun 2026 09:44:03 +0200
with message-id <[email protected]>
and subject line Re: Bug#266081: id3v2 bug prepending null byte to most tag
fields when writing tags
has caused the Debian Bug report #266081,
regarding id3v2 bug prepending null byte to most tag fields when writing tags
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
266081: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=266081
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: id3v2
Version: 0.1.9-2
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
--- End Message ---
--- Begin Message ---
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
On Mon, Aug 16, 2004 at 11:50:31 -0500, Evan Harris wrote:
> Package: id3v2
> Version: 0.1.9-2
>
> 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
--- End Message ---
