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

[Ben Bennett]

On Wed, Nov 15, 2006 at 07:02:22AM -0800, Ray Manning wrote:
<snip>
> 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

Ack.  Good luck!  We should start some compatability list with some
test tags.  I have said this before, but haven't done anything about
it.  Mea culpa.

<snip>
> It would be helpful, I think, if this mailing list was archived somewhere

True... I admit I don't actually know who runs the id3.org site and
list.  If I can help get something set up, please step forward and let
me know what you need.

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

It wasn't an issue of absolute tag size, but I haven't really stress
tested it.  I will have to go back and recreate the information to
know for sure, since I can't seem to find my notes at the moment.  I
seem to recall Amarok doing something daft when presented with a v.2.3
tag with some of the frame types.  I think it was something to do with
dates, but I can't remember (perhaps if you had a TYER along with TDAT
it was wonky).

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

You have to remember that a lot of the motivation for ID3v2 was to
allow tags to be embedded in audio streams.  I read "unembedded" as
"not-in-the-middle".

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

Cool.  I think we have similar desires.  I have been playing around
with the Perl libraries, and trying to write a better ID3v2 module
(with the ability to sanity check stuff and conver 2.3 to 2.4).

I have also been trying to work out the best way to write generally
understood tags... but it is a hairy process.  More below.

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

So, when you are decoding an mp3 stream (assuming a reliable
transport) then you look for the mp3 sync information, and from that
you know how big the mp3 frame is.  When you are done reading that
much data, you should either see the mp3 sync bits again, or another
header you know.  So if you see 'TAG' you know you are looking at a v1
tag and should consume 125 more bytes, if looking at 'ID3' then it is
some flavor of v2 and you have to look at the fixed size header for
the frame length, etc.  I realize you can just set your code to skip
if you see '3DI', but it seems easier to know if you are looking at a
2.4 tag and to skip the extra 10 footer bytes.

You really want to avoid doing search to resync when looking for your
next mp3 data since it is slow, and there is a chance that you can get
a bad sync and throw non-mp3 data at your decoder.  (Since the sync is
relatively small it is not uncommon in binary data).

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

I have advocated for a v2.4.1 version that clarifies some of the
questions about 2.4.0.  Not really as a major restructuring of the
spec, but more as a chance to say, if you claim it is a 2.4.1 tag then
it damn well better address these issues.  iTunes, for instance, gets
the frame lengths wrong since it doesn't apply unsynchronization to
the length.  So if they are big, it reads too much, and misses
subsequent data.  I think it also messes up the frame flags in 2.4,
but that may have been only when it was converting a 2.3 tag to 2.4.

Anyway, if you are serious about this we should set up a wiki
somewhere (I can host it I suppose) and make some sample frames that
we can use for conformance testing.  Then maintain a compatability
matrix of the various programs with respect to the sample frames.

We should also open the 2.4 spec up for comments, but restrict it
solely to clarifications.

I want to make a separate document that updates the programming
guidelines and discusses how to write "safe" tags.

Comments?  Who is with me?

	   -ben

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