[ogg-dev] OggPCM (uncompressed Ogg audio)

[Arc]

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

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

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

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

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