[vorbis-dev] clarifications on comments spec

[Beni Cherniavsky]

Michael Smith wrote on 2003-07-01:

> > *) There seems to be no provision for "padding" (to use the ID3v2 word).
> > Since the comment is very near to the beginning of a Vorbis stream,
> > assuming a file based implementation, the overwhelming majority of the
> > file's contents will have to be moved when the comment size changes.  Is
> > this correct?
>
> Yes, this lastt bit is correct, but padding is certainly possible. Just use a
> packet which is larger than the contents of the packet - with the rest
> probably zero-filled, though it doesn't really matter.
>
http://www.xiph.org/ogg/vorbis/doc/v-comment.html is not entirely
explicit on this.  It only says you must have one "framing bit" equal
to 1 after the comments - what for?  The natural way to read it would
be that if you do have the framing bit, everything after it should be
ignored -- but it doesn't take too much squinting at it to decide to
do anything else (like complaining) when the packet doesn't end there.
If the intent is that such padding is legal, could this be written
there explicitly?

> > *) Rerendering the full Ogg page(s) seems to be a requirement of the
> > current scheme.  This isn't particularly difficult, but could be
> > simplified.
>
> Depends. This is a matter of how much complexity you want. The only case where
> (assuming a correct input file) you need to re-'render' every ogg page is if
> the total length of the comment header increases to more than
> (current_number_of_ogg_pages_for_comment_header * max_page_length), where
> max_page_length is just under 64 kB. That's pretty rare.
>
If you want to strain it, you could always keep lengthening following
pages until you catch up with the page number of the original file, so
that the rest can be trivially bit-copied.  This is not necessarily a
good idea since long pages require bigger buffers (=> higher latency)
at the decoder and reduce the fault-tolerance and seek effeciency(?).

Besides, all such tricks require deeper tying of the comment-handling
to the Ogg framing implementation than if you just take the Ogg
packets abstraction as opaque to your needs.  And the later will
be easier to adapt to parsing comments from Ogg-less RTP streams, if
these are relevant to your TagLib.

In any case, I don't think re-paginating the file makes much
difference if you are rwriting it completely anyway.  If you normally
avoid this by padding, you also avoid re-pagination.

> You could just choose not to support that case - 64 kB of text
> comments is quite a lot. Doing so would solve your issues, I think.
>
You can do so on writing but you must be prepared to read files that
do split the comment header to multiple pages.


-- 
Beni Cherniavsky <cben at tx.technion.ac.il>
--- >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.