[ID3 Dev] Padding

Tue Aug 23 14:00:26 PDT 2005

Pyt please help me, i don't know if i understand good:

If i use padding to add a new frame: let's say that i have a tag with TIT1 and TIT2: 

<tag header>
<TIT1 header><TIT1 contents>
<TIT2 header><TIT2 contents>
<end of the tag, no padding>
<mp3 audio data>
<tag footer>
<ID3v1 tag>

if i add a new frame (TALB) using padding tag will look like this?:

<tag header>
<TALB header only>
<TIT1 header><TIT1 contents>
<TIT2 header><TIT2 contents>
<end of the tag, start of the padding>
<TALB contents (or TALB enlargement, if padding is used to enlarge a frame)>
<mp3 audio data>
<no footer>
<ID3v1 tag>

if frame TALB already exists in the tag:

<tag header>
<TALB header><TALB contents>

<TIT1 header><TIT1 contents>
<TIT2 header><TIT2 contents>
<end of the tag, no padding>
<mp3 audio data>
<tag footer>
<ID3v1 tag>

and i extend it using padding:

<tag header>
<TALB header><TALB contents>

<TIT1 header><TIT1 contents>
<TIT2 header><TIT2 contents>
<end of the tag, start of the padding>
<TALB aditional content (or TALB enlargement)>
<mp3 audio data>
<no footer>
<ID3v1 tag>

But how to detect when padding starts? just before last frame, but how to detect when is last frame?

if i have two frame, with its enlargmens in padding:

<tag header>
<TALB header><TALB contents>

<TIT1 header><TIT1 contents>
<TIT2 header><TIT2 contents>
<end of the tag, start of the padding>
<$00 00 00 00 (start of padding?) TALB aditional content>
<$00 00 00 00 TIT1 aditional content>

<mp3 audio data>
<no footer>
<ID3v1 tag>

in both cases if i use padding to enlarge or add new frames information in padding is just bytes, no headers or flags, before data content?

Thanks, very mach! and help me please :(

Pyt <py.thoulon at gmail.com> wrote:

>Tag size included on tag header, dont include padding? 

The tag size in the tag header includes the size of : (1) the extended header, (2) the actual frames, (3) the padding. See id3v2.4.0-structure.txt, section 3.1.

 >If padding is used to add aditional frames, where is the frame ID since ID is four null chars? or if padding is used to enlarge existing frames how to know what frame are enlarged?

Let's say you have a tag with padding so that the total size of header+extended header+frames+padding = 4K (a typical case); the size in the tag header would be 4086 (4096 - size of header, which is ten bytes). Let's also say the actual frames use up only 2000 of those 4086 bytes. That leaves 2086 bytes of padding. 
Now, if you want to add a new frame to the tag, you can stick it right after the last of the existing frames, overwriting the padding bytes with the new frame contents. You would make no other change to your tag: the size remains the same, only the relative sizes of frames vs. padding have changed; if you new frame is say 50 bytes long, the tag size still indicates 4086, the total frame size is now 2050, and the padding size only 2036. 
The advantage of this is that if you have enough padding, you can play with the frames without having to rewrite the whole MP3 file (which is generally a lengthy exercise, given the sizes of these beast).

Enlarging a frame means a bit more extensive work because frames have to remain in one piece. Let's say you have a tag with TIT1, TALB, TIPL, TIT2 frames in this order, followed by padding. If you want to enlarge TIPL for example, you will need to rewrite your whole tag (or at least the end of it, starting with TIPL) over the original one, eating up into the padding. 

>And if footer is writting to end of file, is'n possible to write an ID3v1 Tag, right? since ID3v1 tag is located from 0 to 128 bytes at end of file.
Yes, you can. The ID3v2 footer should be located just before the ID3v1 tag. A good parsing algorithm looking for an ID3v2 footer should be able to skip the v1 tag.

Regards,
Pyt.

Pyt <py.thoulon at gmail.com> wrote:>Tag size included on tag header, dont include padding? 

The tag size in the tag header includes the size of : (1) the extended header, (2) the actual frames, (3) the padding. See id3v2.4.0-structure.txt, section 3.1.

 >If padding is used to add aditional frames, where is the frame ID since ID is four null chars? or if padding is used to enlarge existing frames how to know what frame are enlarged?

Let's say you have a tag with padding so that the total size of header+extended header+frames+padding = 4K (a typical case); the size in the tag header would be 4086 (4096 - size of header, which is ten bytes). Let's also say the actual frames use up only 2000 of those 4086 bytes. That leaves 2086 bytes of padding. 
Now, if you want to add a new frame to the tag, you can stick it right after the last of the existing frames, overwriting the padding bytes with the new frame contents. You would make no other change to your tag: the size remains the same, only the relative sizes of frames vs. padding have changed; if you new frame is say 50 bytes long, the tag size still indicates 4086, the total frame size is now 2050, and the padding size only 2036. 
The advantage of this is that if you have enough padding, you can play with the frames without having to rewrite the whole MP3 file (which is generally a lengthy exercise, given the sizes of these beast).

Enlarging a frame means a bit more extensive work because frames have to remain in one piece. Let's say you have a tag with TIT1, TALB, TIPL, TIT2 frames in this order, followed by padding. If you want to enlarge TIPL for example, you will need to rewrite your whole tag (or at least the end of it, starting with TIPL) over the original one, eating up into the padding. 

>And if footer is writting to end of file, is'n possible to write an ID3v1 Tag, right? since ID3v1 tag is located from 0 to 128 bytes at end of file.
Yes, you can. The ID3v2 footer should be located just before the ID3v1 tag. A good parsing algorithm looking for an ID3v2 footer should be able to skip the v1 tag.

Regards,
Pyt.

---------------------------------
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20050823/f5764127/attachment.html>