[ogg-dev] packets and OGG pages

[Ralph Giles]

On Wed, Mar 14, 2007 at 12:23:47PM +0000, Mathias Kunter wrote:

> OK, since I only want to read / write the Vorbis comments, I can limit it to the Vorbis header packets.
> http://xiph.org/vorbis/doc/Vorbis_I_spec.html stats that the comment header always begins on the second ogg page. Since the length of the precedent identification header is fixed, this even is a fixed offset into the logical ogg stream.

This will work for all the vorbis-only files I've seen (because no one 
pads the first packet). You should really implement a proper ogg parser,
but by all means get a hack working first.

> The spec now further stats that the comment and setup headers can together span >= 1 pages. So does this also mean that the comment header itself can be split over different pages?

Absolutely. The vorbis spec allows the comment packet to be up to 
18446744078004518921 bytes long. Of course it would be silly to
use all of that, but if someone stuffs liner notes or cover art in 
there, it could easily be over the normal 4k page size.

> In contrast to that, http://www.ietf.org/rfc/rfc3533.txt stats the following:
> "Ogg Vorbis provides the name and revision of the Vorbis codec,
> the audio rate and the audio quality on the Ogg Vorbis bos page.
> It also uses TWO additional header pages per logical bitstream."Sounds like ogg would ALWAYS use a total of three header PAGES for its three header PACKAGES. Is this actually the case?

Ouch. This is incorrect. It should read "It uses two additional header 
packets per logical bitstream." You have to know the codec embedding (or 
use a skeleton "meta-header" stream) to find the boundary between the 
headers and the data, if any.

> That's a pity. It could have been very easy included in the specs by just defining that the comment header always uses an ogg page alone which has a size greater than the actual content (for example 32K). Re-tagging a music file is common and it's not efficient to rewrite the entire file....

Yes, everyone writing a tag editor complains about this. Just like 
everyone who writes streaming code complains about id3 tags being
at the end of the files. :)

> So this means I can ALWAYS expect the first ogg page to be on offset 0 of a physical stream (an ogg file), right?

Assuming no file corruption, yes.

 -r