[ogg-dev] packets and OGG pages

[Ralph Giles]

On Wed, Mar 14, 2007 at 03:20:19AM +0000, Mathias Kunter wrote:

> my name is Mathias, I'd like to ask about some details of the OGG format because I'm quite new to it. I'd like to write a native .NET library for reading and writing Vorbis comments. It's going to be open-sourced as soon as it's finished.

cool.

> 1) When packing (Vorbis) packets to OGG pages, does a new packet always begin on a fresh OGG page? Within the specs I could only find the info that a packet can be split over several pages.

No, a page can begin with the continuation of a packet from a previous 
page. More than one packet can be packed into a page, a single packet 
can span multiple pages, and these two behaviours can be mixed.

> 2) http://xiph.org/ogg/doc/oggstream.html stats:
> "A physical bitstream consists of
> multiple logical bitstreams multiplexed at the page level and may
> include a 'meta-header' at the beginning of the multiplexed logical
> stream that serves as identification magic."
> What is meant by this "meta-header", I couldn't find any detailed specs about it? Does this simply refer to the "begin of stream" (bos) page where the codec identification header is stored?

See http://wiki.xiph.org/OggSkeleton for what that speculative phrase 
ended up referring to.

> 3) When new information is added to the comment header, it has to be expanded, of course. Is there a way to use some kind of "padding" like ID3v2 does so that rewriting the entire file can be avoided? I thought it must be possible by simply creating an ogg page with a size which is greater than the space required by the comment header, and filling up the remaining bytes with 0's for "clarification". Unless I don't exceed the maximum page size of nearly 64K there should be no problem. Even if I would exceed the 64K limit I think it should be possible by adding a new ogg page, although this would cause to re-number the other ogg pages. Am I right about these assumptions?

You can pad the end of the comment packet, since it contains internal 
length fields. However, you can't rely on it, so it's just an 
optimization. In general you have to rewrite the file.

Hope that helps,
 -r