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

[Jim]

Some ID3v1 tag information can be found here:  http://www.id3.org/id3v1.html

While it is has some limitations in size and what information it can
contain, it is a much simpler to use tag than ID3v2 so I'm not sure it is
quite obsolete.  Some files can contain both.  I think most tag apps give
the user the option of writing both or removing one or the other.  (I could
be wrong about that.)

It is true that tools that don't support or know how to check for appended
2.4 tags will probably end up writing a 2nd prepended tag.  That might be a
good reason to avoid appended tags for now but hopefully most tools will
eventually support and recognize appended tags.

And I still think that the footer flag is useful.  Sure you can check the
last 10 bytes of the tag data to see if it is a footer, but isn't it easier
to check one flag bit instead of comparing 10 bytes for the header/footer
format?  (This method may not confirm that the footer is valid as written,
but it does tell you to expect it to be there.)  If I'm parsing a tag that
contains a footer, I can just subtract 10 bytes from the expected size of
the tag data/padding and deal with the footer later, if I need to.  (If it
is a prepended tag and I do not change the overall size of the tag or the
flag byte, I can skip over dealing with the footer entirely.)

----- Original Message ----- 
From: "Ray Manning" <ray at homeautomationdev.com>
To: <id3v2 at id3.org>
Sent: Tuesday, November 14, 2006 12:36 PM
Subject: RE: [ID3 Dev] Why is footer not included in total size?


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



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