ogg dev - Nov 2005 - OggPCM (uncompressed Ogg audio)

Hi Arc, illi,

I think it would be advantageous if we take the emotion out of this discussion ,
so let's just argue technically. My experience with xiph is that we are a
very friendly community and trying to help each other and listen, so let's
keep that culture up.

I think we all agree: it is a good idea to have an media mapping for ogg for
uncompressed PCM.

As for what is required in a media mapping, the RFC
(http://www.ietf.org/rfc/rfc3533.txt) and the file that used to be at
http://www.xiph.org/ogg/doc/vorbis-stream.html specify it:
- a bos page (the "header" page) that identifies the codec and sets it
up
- potentially secondary header pages (e.g. for vorbiscomment type stuff)
- and a granule pos scheme.

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?

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.

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?

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

e.g.  the Ogg page header has the following format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| capture_pattern: Magic number for page start "OggS"           | 0-3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version       | header_type   | granule_position              | 4-7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               | 8-11
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               | bitstream_serial_number       | 12-15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               | page_sequence_number          | 16-19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               | CRC_checksum                  | 20-23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |page_segments  | segment_table | 24-27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...                                                           | 28-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Regards,

Silvia.


-----Original Message-----
From:	ogg-dev-bounces@xiph.org on behalf of Arc
Sent:	Wed 11/9/2005 8:10 PM
To:	ogg-dev@Xiph.org
Cc:	
Subject:	[ogg-dev] OggPCM (uncompressed Ogg audio)
Moved off OggYUV thread as this is off-topic for it..

On Wed, Nov 09, 2005 at 04:51:51PM +0800, illiminable
wrote:
> >
> >Um, data packets consist of a 32-bit header followed by PCM data. 
Where
> >did you get the idea that "sync" data was in the packet?
> 
> That's what the first 32 bits of "header" are.
Um, no, the first 32 bits of the header is a packet type ID followed by the 
3-byte codec label.  What part of "\xFFPCM" could possibly be
considered sync
information?  

Seriously, I've gotten the strong impression you're arguing from the hip
without
actually reading any of the draft specs we're talking about.

Here's a link, since you've obviously not read it sufficiently:
 http://wiki.xiph.org/OggPCM

> >KISS - Keep It Simple, Stupid.  This is a raw data format.  It's
value to
> >everyone is primarily how simple it is to implement.
> 
> I don't know whether to laugh or cry. Yes... it's a raw data
format... and
> look at the header you've given it.
Number of channels, bits per sample, samples per second, sample format.. exactly
what in this would you consider extranious?

The data packet header was given because with Ogg codecs you need a one-byte 
identifier to differentiate a data packet from a header packet, and the
"PCM" is
free because otherwise we'd be buffering out to the next 32-byte word
anyway.

Again, I don't know what you've been reading, or if you're seeing
the same spec,
how you could have possibly misunderstood the fairly plain data layout, but this
is the smallest formatted PCM codec I've seen, especially compared to
RIFF/WAVE.

I'm interested in hearing your specific criticisms on this.
 

-- 

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
_______________________________________________
ogg-dev mailing list
ogg-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/ogg-dev

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

On Wed, Nov 09, 2005 at 05:33:37AM -0800, Arc 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?
> 
> 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.
I agree with Silvia here. The initial-octet packet type flagging is nice 
in vorbis and theora because there are a number of headers to 
distinguish, and you have to bit-unpack everything starting at the 
packet boundary anyway. PCM is just PCM, so I think having just the raw 
data in the data packets is better.
> > As for the information that goes into the bos page, I can see at least
an
> > endianness indicator missing.
We should think about float support too.

 -r