AW: [ogg-dev] packets and OGG pages

Mathias Kunter mathiaskunter at
Thu Mar 15 07:10:54 PDT 2007

Ralph, thanks for your help.

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

I will of course use the ogg pages and their lacing values to exactly determine where the packets start and end. It just wasn't clear to me that the lacing values signal the borders of the packets in such a clean way (this actually isn't very easy to read out from the specs for a person which is new to ogg).

I thought padding of the first packet in an ogg stream is forbidden: says
end-of-packet condition during decoding the first or third header
packet renders the stream undecodable."
Or does the end-of-packet condition only refers to packets which actually should be greater than the lacing values indicate (in other words, truncated and therefore corrupted packets, at least when speaking about the header packets)?

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

Thanks, I already found out in the meantime that it must be this way, just because the comment header can be so big (well, a 2^64 byte comment header actually would be so big that it can't be stored on any currently existing hardware anyway ;)

>Ouch. This is incorrect. It should read "It uses two additional header 
>packets per logical bitstream."

I thought it must be this way.

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

Yes, but in case of vorbis it's clear since I know that the first three packets are the headers.

>Yow. Ralph, Silvia, should we consider creating an updated Ogg
>Internet-Draft and fixing / clarifying this and any other recent

I would really appreciate that, at least for the vorbis comments. I think most vorbis interested developers mainly care about the comments because of tagging purposes.
The specs at are nice, but not sufficient to actually implement an ogg vorbis comment reader / writer. There should be a single document like it exists for the ID3 standard which completely covers all relevant things to do when somebody wants to deal with vorbis comments. There also should be an "official recommendation" that the comment header is written with sufficient padding when a file has to be rewritten anyway so that future tagging of that file can be done fastly.

As soon as I've finished implementing a working vorbis comments .NET library (which I want to do until the end of March), I can offer to write such specs. Maybe thats a good idea since I can write these specs from the "developer without ogg knowledge view". You could (and should) check the specs for correctitude afterwards, of course. Let me know if you're interested in.


Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail:

More information about the ogg-dev mailing list