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

[Ben Bennett]

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

Yes.  The spec is stale with respect to usage.  If you stray too far
from 2.3 then you get in trouble.

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

Obviously.  (Save for the case where you need a byte of padding to
avoid sync issues).  Did you read the http://www.id3.org/id3guide.htm
guide?  Specifically the padding section.


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

ID3v1 is on almost every mp3 file have ever seen that has been tagged
in any way.  It is a very simple tag format that is a fixed 128 bytes
at the end of the file.

There is some info at http://www.id3.org/intro.html Specifically:
http://www.id3.org/id3v1.html but the other links are interesting too.

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

Depends on what compatability level you want with players.  Everything
understands ID3v1.  Some things understand v2.3 and a few things
understand v2.4.  And some even implement them correctly.  Getting
things to play well together is hell.  For instance if you want iTunes
to work correctly with large frames (e.g. images) you need to use 2.3
since they messed up reading the size in 2.4. But if you want to use
Amarok too... then they partially support 2.3 and support 2.4 much
better.

If you want to write something that almost everything can read, then
write a ID3v2.3 tag on the front (the only choice) and a ID3v1 tag on
the end (again, the only choice).  Also only a subset of tags are
reliably supported.  Populating too much can get you in trouble with
some tools too...

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

Yes.  I fully understand that.  You are the one talking about advanced
features of 2.4.  (Note there is a guide for scanning for tags in the
2.4 spec).  I am not sure what you are trying to do, is this a tool
for your personal use?  Are you trying to make widely-readable tags?  Etc.

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

You forget about the case where a file is streamed, the player
receiveing the stream wants to know that there may be a tag following.

Anyway, it may be silly, but it is already out there in the spec.

	       -ben

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