[ID3 Dev] tagsize calcultaion

[Robert Manson]

> According to spec the size value in the ID3v2 header should include
the size
> of the padding bytes.
> and then the extended header should include the padding size as well.
Why
> include the padding size into
> 2 places?

Presumably the padding size info in the extended header could be used to
calculate the total size of the frames in the tag.  In some cases it
could also be used to quickly determine if a frame could be appended to
the tag without necessitating a rewrite (ie there is enough padding the
tag for the frame).

>In the spirit of "Be liberal in what you accept, and conservative in
>what you send" (from the late great Jon Postel) I would generate an
>extended header but write the parser to stop looking for tags when it
>hits the first frame name that is all nul bytes.

Many ID3 can only parse a subset of the actual ID3v2 specification (some
don't support compression/decompression, un-synchronization, etc) and
just ignore the entire tag if they see something they don't like.
Therefore I would recommend not appending the extended header by default
and instead let it be enabled as a user-configurable option.

-----Original Message-----
From: Ben Bennett [mailto:fiji at ayup.limey.net] 
Sent: Monday, April 11, 2005 10:35 AM
To: id3v2 at id3.org
Subject: Re: [ID3 Dev] tagsize calcultaion

On Sun, Apr 10, 2005 at 01:28:52PM +0800, Christophe Kualasoft wrote:
> Hi,

As a warning, this list seems very quiet.  I posted a question about
the iTunes frame size not being syncsafe in 2.4 (which looks like an
error to me) and got no reply.
 
I have been working on the Perl ID3v2 parser (to give int 2.4 support
and implement support for all 2.3 and 2.4 frame) but I have no insight
other than what I have read in the two specs.

> My questions:
> 
> According to spec the size value in the ID3v2 header should include
the size
> of the padding bytes.
> and then the extended header should include the padding size as well.
Why
> include the padding size into
> 2 places?

In 2.3 that is the case.  It is obviously needed in the main header
since it tells programs where to read the tag (or how far to skip if
they don't care).  I can only guess that it is in the extended header
to tell an ID3 parser how much memory it needs to allocate to hold the
unparsed frame in memory.  However, I can't find anything in the spec
that actually requires the extended header if padding is present.  If
you write an extended header it must contain the padding size.

In the spirit of "Be liberal in what you accept, and conservative in
what you send" (from the late great Jon Postel) I would generate an
extended header but write the parser to stop looking for tags when it
hits the first frame name that is all nul bytes.

In 2.4 the extended header does not contain the padding size.

> BTW, the improved vdHeide will be available as open source on
sourceforge.

Cool.  And my library will be available on CPAN as MPEG::ID3v2Tag
(assuming the current author accepts my diffs).

		      -ben

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org




---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org