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

[Ben Bennett]

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.

> The footer does seem like it may, in some situation, for someone,
> solve a problem but IMO, it shouldn't foist knowledge of itself into the
> interpretation of the size field. To interpret the size field, you now have
> to understand the flags as well as choose the proper calculation in order to
> determine how many bytes are included in the tag. Overly complex, and as you
> mention a breaking change. I see no reason why it couldn't have been made
> part of the size field and have a fixed position at the last 10 bytes of the
> header.

The footer needs to be at the end in order to allow you to find the
tag start when scanning backwards from the end of the file.

I can't comment on why the size doesn't contain the footer.

> 
> 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).

> 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
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)
 

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.


> 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.

		-ben

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