[ID3 Dev] Why is footer not included in total size?

[Ray Manning]

> -----Original Message-----
> From: Ben Bennett [mailto:fiji at ayup.limey.net]
> Sent: Tuesday, November 14, 2006 8:37 AM
> To: id3v2 at id3.org
> Subject: Re: [ID3 Dev] Why is footer not included in total size?
>
>
> On Tue, Nov 14, 2006 at 02:56:17AM -0800, Ray Manning wrote:
> >
> > Good point. I was recently wondering the same thing (as well as
> why someone
> > would want to start a tag search from the end of a file in the first
> > place!).
>
> It lets you append a tag which is way easier than moving all file data
> so you can prepend.

Perhaps easier, but if most tools don't know about appended tags,
and there is a general tendency to avoid appended tags, I question
their usefulness. I'd suspect software that adds tags will fail to
search a file backward to see if an appended tag already exists and
still prepend a new tag (obviously v2.3 software won't know about
appended tags and end up prepending a second tag).

<snip>

> >
> > I actually contemplated always outputing a footer in the tags I
> write since
> > it's simple to do and it removes the potential for a false sync signal
> > should the last byte of the tag be 0xFF. I decided against it due to the
> > potential incompatibility problems.
>
> Good choice.  You can get around the sync problem by always including
> padding.  You probably want to include padding anyway so that minor
> tag changes don't need the whole file to be rewritten.  One of the
> notes on the spec site (id3.org) suggests padding out to make the tag
> be a full block (which is filesystem dependent, but a multiple of 512
> or 1024 makes sense).

This comes down to a choice of when to add padding. Do you add more
padding if you use up what's there or do you add padding when there
isn't enough room to complete the task at hand? I really don't see
a reason to add padding if there is enough existing to complete the
task at hand. Like you mention, it's easier not to move the file
especially if the move is only to pad the tag.

>
> > I tried to imagine why you might want to exclude the footer
> from the size
> > but I've come up blank. The closest I've come is that making a
> copy of the
> > tag at the end of the file can be as simple as a literal copy
> of the tag and
> > append the 10 byte footer. That should be sufficient for a tag search
> > starting from the end of the file but it wouldn't be complete
> since, you'd
> > have to whack the header flags to indicate the presence of the footer (I
> > smell the potential for an inconsistency between the header and footer
> > here -- what would it mean to read a footer that doesn't have
> the footer bit
> > set?).
>
> I am not sure what you mean by "footer bit".  Note that a footer has a


Sorry, my inconsistency, I meant the footer _flag_.


> different signature, it has "3DI" at the start of the 10 byte footer.
> The footer is part of the ID3 tag, so you have:
>     [header, tag data, padding, footer]
>     Audio data
>     ID3v1 tag (if any)
>
> Of course a prepended tag with a footer is a bit silly.  An appended
> tag would look like:
>     Audio data
>     [header, tag data, padding, footer]
>     ID3v1 tag (if any)


Hmmm... being new to the ID3 world, I haven't seen ID3v1 tags nor is
there a spec available (that I can find) on www.id3.org so I suspect
it's obsolete? With data (the ID3v1 tag) following the ID3v2.4 appended
tag, it makes it that much harder to find the footer (back to scanning).

Shouldn't the Id3v1 tag be removed when the Id3v4 tag is written? Never
having dealt with the Id3v1 tag, I might be off base here...

>
>
> Please note that you probably don't want to have 2 tags on the
> file... either prepend or append.  Most tools won't know about
> appended tags anyway, so I would just avoid them.

Tools will have to know how to find the appended tag if you are to
avoid 2 tags in one file. pre-id3v2.4 tools don't know about
appended tags so will always prepend a second tag where an
appended tag exists.

>
>
> > Assuming one buys into the idea that the header size should include the
> > footer, is there any real reason to keep the footer flag? As
> far as I can
> > tell, that flag is only present to allow you to "fix" the size
> calculation
> > when skipping the tag. No one is going to be checking that flag
> in order to
> > verify the 10 bytes following the tag are actually a footer.
> The flag does
> > give you one more significant bit for verification when searching for a
> > footer, but skipping to the header from the footer and
> verifying the header
> > should be more than sufficient.
>
> I really don't understand what you are getting at here.  If you
> produce a footer, you should produce a flag in order to conform to the
> spec.  If you are just reading the tag, then it is always helpful to
> avoid having to scan to find the mpeg data.

What I'm getting at here is that I believe the footer flag to be redundant.

The usefulness of the footer is for scanning backward. The backward scanner
doesn't care about the flag because he's going to skip footer->tagSize
backward
once he identifies the footer.  The scanner doesn't need the footer flag.
It already knows the footer exists.

The only other tools interested in the footer will be tools that modify
the tag or need to skip past it. With the footer size included in the
tag size, the skipping becomes trivial (with no knowledge of the footer).

The tools that modify a tag will be interested in the footer because
they will need to update the size in the footer should they change the
tag size. They would need to change the tag size if they were consuming
padding in the tag. When consuming padding one can easily calculate the
padding available by testing for the existence of a footer in the last 10
bytes of the tag (just as a backward scanner would find it).

Note, none of these scenarios require the use of the footer flag making
it redundant.


- Ray


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