ID3: Incorrect padding length at end of tag data

[GoogleCodeExporter]

when writing out an id3 tag too much padding is added to the end of the tag
data. looks like it's adding and extra 10 '0x00's which are accounted for
as the id3 header length. this becomes particularly noticeable when
importing files into iTunes. iTunes ends up munging the vbr header of the
file which breaks any idea of gapless playback. attached is a patch that
should address this. note, the patch either adds 10 to the "outsize"
variable when tags are read from a file because the rest of the code
expects that size to be +10 for the header and then removes it both when
adding the padding and inserting bytes. i also changed what value is passed
to "BitPaddedInt" from "outsize" to "len(framedata)" since the latter is
more specifically what value we want in the id3 header. i used hard-coded
"10" because the header length isn't in a variable i can find anywhere.
anyway, feel free to contact me if you like.

Original issue reported on code.google.com by motiva...@gmail.com on 11 Feb 2010 at 6:55

Attachments:

• id3.py.patch

[GoogleCodeExporter]

I don't think there is a bug in Mutagen.

http://id3.org/id3v2.4.0-structure:

   The ID3v2 tag size is stored as a 32 bit synchsafe integer (section
   6.2), making a total of 28 effective bits (representing up to 256MB).

   The ID3v2 tag size is the sum of the byte length of the extended
   header, the padding and the frames after unsynchronisation. If a
   footer is present this equals to ('total size' - 20) bytes, otherwise
   ('total size' - 10) bytes.

The "ten extra bytes" you are seeing is because the size present in the ID3 
header
does not include the header itself, as per the spec.

Original comment by joe.wreschnig@gmail.com on 13 Feb 2010 at 11:58

• Changed title: ID3: Incorrect padding length at end of tag data
• Changed state: Invalid