[ogg-dev] OggPCM (uncompressed Ogg audio)
arc at Xiph.org
Wed Nov 9 05:33:37 PST 2005
Thanks Silvia for your response :-) It's good to get constructive discussion on
this, and I've been hoping to have exactly this kind of criticism re: OggPCM for
On Wed, Nov 09, 2005 at 10:21:04PM +1100, Silvia.Pfeiffer at csiro.au wrote:
> Data pages are identified to be part of a logical bitstream through their
> serial number, so don't need any additional identifiers. Thus, Arc, I don't
> quite understand why you would require another 32 bits at the beginning of
> each data packet, when ogg pages are already covering that information?
This is a suggestion from Monty, amoung others, as a fallback in case a stream
gets broken/etc. Yes, both the page# and bos flag on the page level identify a
header packet, as does a granulepos of 0, but a single 32-bit word at the
beginning of data packets is a small additional overhead compared to the data
payload, and mapped to a 32-bit border, it should be easy to read and discard
I am open to eliminating it, if it can be shown that the act of reading or
skipping this data complicates implementation or makes it less efficient,
however, the decidion to do so should include several people (Monty, Ralph, etc)
who haven't joined this discussion yet.
> As for the information that goes into the bos page, I can see at least an
> endianness indicator missing. I actually think we should ask sombody like the
> author of libsndfile, Erik de Castro Lopo, to give his input on what fields
> should be in the BOS page for such a media mapping. His vast experience on
> parsing different audio formats should provide us with more complete
He sounds like a great person to get involved. There are certainly bits
available (6 padding) for additional data flags to be implemented with.
> As for the last bit required for specifying media mappings: I cannot see a
> specification for what the granule pos means on a ogg pcm stream? My
> suggestion is the total number of PCM samples encoded after all frames
> finished on this ogg page. Whas that the intention?
Yes. It should have been specified on the wiki-draft.
> By the way, I think it would be advantageous to specify the bos page mapping
> in a bit pattern as is common within the IETF. This will help identify if any
> fields cross byte boundaries and would therefore be hard to parse (which I
> haven't seen in the ogg pcm spec, but this format is still a nicer
It can be done. I haven't done it because simply listing the bit lengths, and
adding them up, allows me to int32-align fields. More than welcome for someone
else to add this, it /is/ on a wiki after all :-)
The recognition of individual possibility,
to allow each to be what she and he can be,
rests inherently upon the availability of knowledge;
The perpetuation of ignorance is the beginning of slavery.
from "Die Gedanken Sind Frei": Free Software and the Struggle for Free Thought
by Eben Moglen, General council of the Free Software Foundation
More information about the ogg-dev