ID3v2 tag size
-
Hi, I'm trying do determine an ID3v2 tag size. Acording to the ID3 site it's stored in the first 10 bytes of the tag, acctually there the last 4 of those 10. This is how they explain it.
The ID3v2 tag size is encoded with four bytes where the most significant bit (bit 7)
is set to zero in every byte, making a total of 28 bits. The zeroed bits are ignored,
so a 257 bytes long tag is represented as $00 00 02 01.
An ID3v2 tag can be detected with the following pattern:$49 44 33 yy yy xx zz zz zz zz
Where yy is less than $FF, xx is the 'flags' byte and zz is less than $80
I think $00 00 02 01 is a hexadecimal represantation of the bytes. I understand that 1 byte = 01111111 maximum (bit7 =0), so 1 byte can represent 127 bytes (in tag size) maximum. In the example zz is less then $80, so it's less then 128. If so, I come to 4 * 127 * 127 = 64516 bytes in tag size. That's not 256 MB as they claim on the ID3 site. I'm probably doing something wrong here. Can anyone explain to me how 257 bytes (tag size) are represented by $00 00 02 01 in hexadecimal?
If you want to know The Truth, STOP lying.
-
Hi, I'm trying do determine an ID3v2 tag size. Acording to the ID3 site it's stored in the first 10 bytes of the tag, acctually there the last 4 of those 10. This is how they explain it.
The ID3v2 tag size is encoded with four bytes where the most significant bit (bit 7)
is set to zero in every byte, making a total of 28 bits. The zeroed bits are ignored,
so a 257 bytes long tag is represented as $00 00 02 01.
An ID3v2 tag can be detected with the following pattern:$49 44 33 yy yy xx zz zz zz zz
Where yy is less than $FF, xx is the 'flags' byte and zz is less than $80
I think $00 00 02 01 is a hexadecimal represantation of the bytes. I understand that 1 byte = 01111111 maximum (bit7 =0), so 1 byte can represent 127 bytes (in tag size) maximum. In the example zz is less then $80, so it's less then 128. If so, I come to 4 * 127 * 127 = 64516 bytes in tag size. That's not 256 MB as they claim on the ID3 site. I'm probably doing something wrong here. Can anyone explain to me how 257 bytes (tag size) are represented by $00 00 02 01 in hexadecimal?
If you want to know The Truth, STOP lying.
Expand the hex string 00 00 02 01 to binary, and you get 00000000 00000000 00000010 00000001. Now, we ignore the most significant bit (left-hand end of each byte) giving the bit string 0000000 0000000 0000010 0000001, which when read as normal 8-bit bytes and padded to fill the top byte (padding in brackets) is (0000)0000 00000000 00000001 00000001, or hex 00 00 01 01 which is, in decimal, 257. This following is a C function to get the size of the tag (assumes
intis 32 bits andcharis 8 bits.) The first of the four bytes from the ID3 tag is placed in the first position in the array, so for the example input,encodedSize[0] = 0x0, encodedSize[1] = 0x0, encodedSize[2] = 0x2, encodedSize[3] = 0x1.)int getTagSize(char encodedSize[4]) { int retval = 0; retval = encodedSize[0] << 21 | encodedSize[1] << 14 | encodedSize[2] << 7 | encodedSize[3]; return retval; }
Not that this function doesn't do any form of sanity check on the input data, which is a Bad Thing™ in real code you must check that each byte of the encoded size is < 0x80, and do whatever is appropriate in your app when encountering an invalid ID3 tag if the test fails. As for the aside about maximum tag size, the max value with this encoding is $7f 7f 7f 7f, which represents 268435455 bytes, or 256 MB, of ID3v2 tag. I don't see where you're getting 4*127*127 from, but the reason why 127*127*127*127 = 260144641 is wrong is that, while the maximum value for each byte is 127, the total number of values for each byte is 128, and so there are 128*128*128*128 = 268435456 possible values for the tag size (0-268435455) -
Expand the hex string 00 00 02 01 to binary, and you get 00000000 00000000 00000010 00000001. Now, we ignore the most significant bit (left-hand end of each byte) giving the bit string 0000000 0000000 0000010 0000001, which when read as normal 8-bit bytes and padded to fill the top byte (padding in brackets) is (0000)0000 00000000 00000001 00000001, or hex 00 00 01 01 which is, in decimal, 257. This following is a C function to get the size of the tag (assumes
intis 32 bits andcharis 8 bits.) The first of the four bytes from the ID3 tag is placed in the first position in the array, so for the example input,encodedSize[0] = 0x0, encodedSize[1] = 0x0, encodedSize[2] = 0x2, encodedSize[3] = 0x1.)int getTagSize(char encodedSize[4]) { int retval = 0; retval = encodedSize[0] << 21 | encodedSize[1] << 14 | encodedSize[2] << 7 | encodedSize[3]; return retval; }
Not that this function doesn't do any form of sanity check on the input data, which is a Bad Thing™ in real code you must check that each byte of the encoded size is < 0x80, and do whatever is appropriate in your app when encountering an invalid ID3 tag if the test fails. As for the aside about maximum tag size, the max value with this encoding is $7f 7f 7f 7f, which represents 268435455 bytes, or 256 MB, of ID3v2 tag. I don't see where you're getting 4*127*127 from, but the reason why 127*127*127*127 = 260144641 is wrong is that, while the maximum value for each byte is 127, the total number of values for each byte is 128, and so there are 128*128*128*128 = 268435456 possible values for the tag size (0-268435455)There was an error in my reasoning :doh:. I did (127+127+127+127)*127 instead of 127*127*127*127, silly me :->. I get it now. I don't understand C programming, I just got the basics of VB.Net, but I'll learn as I get along. Reading (and eventually writing) mp3-tags seemed easy, as I could see the tag (more or less) when I open the file in notepad. And I love a challenge ;P. Thanks for the help. On to the next problem.;)
If you want to know The Truth, STOP lying.