[ogg-dev] OggPCM (uncompressed Ogg audio)
Arc
arc at Xiph.org
Wed Nov 9 10:21:57 PST 2005
On Wed, Nov 09, 2005 at 09:31:29AM -0800, Ralph Giles wrote:
> >
> > 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.
Note that the data begins on an int barrier, as the header was made exactly 32
bits long, so it should be trivial to copy the data from the packet to a buffer
starting at 4 bytes in vs 0 bytes in.
We really do need a "chunk" for the bitpacker, to grab as much continuous memory
as possible, vs 32 bit pieces per function call. Will make handling Speex much
easier, too.
> > > 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.
We have float support, I believe it's sufficient.. basically the same as
RIFF/WAVE supports in it's header:
[...]
2 [variable] Data Type: 0=signed int, 1=unsigned int, 2=float, 3=extended
6 [null] Padding to byte/int - may be used for "extended" data type
--
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
mailing list