[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 12:22 PM
> To: id3v2 at id3.org
> Subject: Re: [ID3 Dev] Why is footer not included in total size?
>
>
> > 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.

I guess I'll be asking more questions here along my ID3 tag journey then.
Having just recently started looking at the specs, I assumed 2.4 would
be the place to start. From what I'm learning from this discussion and
and reading the 2.3 and 2.4 specs, I now see my assumption was invalid.

It would be helpful, I think, if this mailing list was archived somewhere
so new comers like me might gain better insight into the state of things.
I tend to believe that the more senior members of this list have seen
many repeated topics/issues. Something as simple as forwarding this
mailing list to a nntp server and having Google do the archive would
be helpful.

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

Thanks for the tip. That helps focus my efforts. Can you shed some light
on what problems you've encountered with adding too many tags? I do
realize that not all tags will be interpreted the same way (for example,
I've seen a "Comedy" track that listed the comedian as the composer).
Is this the main issue or have you expreienced problems with the raw
size of the tag?

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

I didn't realize appended tags were an "advanced" feature.

If you are talking about the suggestions for scanning in section
"5. Tag location", then yes I did see that. The word "unembedded"
gave my stomach a flip. What is an embedded frame? I'm guessing
it's embedded in an audio stream in order for players to pick
up frames from a stream?

The tool I'm working on is for managing a large music database and
importing music into it. I need to be able to read tags from multiple
sources and file formats as well as write tags that can be widely
understood.

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

I don't understand what you're saying here. How would the
player receiving a stream, know a tag follows without seeing the
tag header first? I'd assume a player would be looking for a
header and not a footer. I'm also thinking this is where the
SEEK frame might be useful.


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

Agreed. That doesn't mean it can't be improved upon the next version.
It almost sounds to me like 2.4 is reluctantly being accepted due
to some of the issues it introduces. I certainly don't get the
impression people are in a hurry to move to 2.4 which is somewhat
surprising to me given a 6 year old standard and the increased
exposure of mp3 in that same period.

- Ray

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