[vorbis-dev] clarifications on comments spec

[Beni Cherniavsky]

Ralph Giles wrote on 2003-06-30:

> > If it was required, as is true with the Vorbis identification
> > header, that future implementations put the comment in an Ogg
> > stream page by itself this could solve the above issues.  It would
> > then be possible to deduce the total size of the comment from the
> > Ogg page header.  Though I haven't tried it yet, I also presume
> > that empty space at the end of an Ogg page would simply be
> > ignored, thus providing a mechanism for padding.
>
> s/page/packet/ here. It usually takes a while to grok the two levels.
>
> The spec doesn't say either way about extra data in the header
> packet, but presumedly a good decoder would handle that.

Oops, so I was wrong when claiming that decoders that don't ignore the
tail of a comment packt are broken.  Too bad.  Re-reading the spec__,
what's the point of the "framing bit"?

http://www.xiph.org/ogg/vorbis/doc/v-comment.html

> The reason we won't put it on a page by itself is that limits the
> length to 64k. Is that enough for everyone? That will also be a
> significant fraction of a low-bitrate file if you always use the
> full length for padding.
>
Padding can be adaptive.  Allow it in the spec and let different
encoders/comment editors try different strategies (as with the
codebooks concept but on smaller scale ;).

> We have considered ideas of this sort in the past, particularly when
> we wrote our own example tag editor. So you're not the first to have
> to deal with this stuff. Generally our conclusion has been that it's
> not worth adjusting the spec for the convenience of only that
> application.
>
The adjustment is very small: allow garbage at the end of the comment
packet.  It's certainly worth the trouble if the spec was designed
now, the only problem is that the Vorbis I spec is frozen.  Why I
certainly respect your decision to not touch it, I can't understand
why can't Xiph publish some "best-practices" guidelines for
implementors enocuraging implementations that will also work with
probable changes in future specs.  This is thesecond such issue that I
remember:

1. Vorbis I decoders are strongly encouraged to silently ignore all
   other multiplexed streams, even though legal Vorbis I streams can't
   be multiplexed.  This is trivial to implement (drop pages with
   other stream numbers) and will be needed in the future anyway.

2. Vorbis I decoders should ignore all content of the comments packet
   after the last comment (according to the number of comments
   appearing in the packet, after the vendor string).

Anything else?  I think it really makes sense to publish any such
guidelines along with the spec (marking them as non-normative, at
least for this version of the spec).


-- 
Beni Cherniavsky <cben at tx.technion.ac.il>

"Reading the documentation I felt like a kid in a toy shop."
 -- Phil Thompson on Python's standard library
--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.