[ogg-dev] OggPCM format description, rev 3

[Erik de Castro Lopo]

Hi John,

jkoleszar at on2.com wrote:

> Hi all,
> 
> I updated the wiki with another rev of this format. Updates include
> support for 43 formats in 14 coding schemes, as derived from the ALSA API.
> This seemed like a good way to get a list of what the formats in common
> use out there are, so it should be fairly comprehensive.

Unfortunately the ALSA API defines a number of formats which are
in practice extremely rare. In particular, any unsigned int format
larger than 8 bits. For instance, the only unsigned int type that
libsndfile supports is unsigned 8 bit.

I would also stringly advise against supporting **any** APDCM 
format. These things are a PITA to support and some cannot be 
supported without extending the header. For instance, microsoft's 
ADPCM  requires that a set of 8 coefficients require dor decoding 
be sent in the header. Most of the other ADPCM have blocks sizes
that need to be sent. All in all this is a huge PITA. In comparison
to FLAC, Speex and Vorbis, APDCM formats have little to offer.

> Modifications to the "rev 2" format:
> 1. Expanded the 'id' field to support more than 7 formats. Format id is
> now 16 bits, but the lower 6 bits are reserved to describe the storage
> packing.

I still think that assigning meaning to bits within the format field
is a mistake. Specifying bits like this could only be useful if
you expect the decoder to generate code on the fly when it gets
asked to decode say 16 bit, unsigned, little endian. Auto generated
code that automagically supports all of these formats is significantly
harder to write and debug than the equivalent set of single purpose
decoders so I would suggest that this auto-magic stuff is a bad idea.
Ergo, assigning meaning to the bits is a bad idea as well.

> New since "rev 2":
> 1. Added the notion of chunked vs interleaved storage.

Again, I strongly recommend against allowing non-interleaved data.
It simply complicates everything far more than it needs to be.

> For discussion:
> 1. How useful is the 6 reserved bits in the format id? I'm a little

Reserved for what? I can't possibly think what it could be used for.

> uncomfortable with it, since it's only 70% (45/64) efficient,

This is a file header. Even under the most bloated scheme we could
think of, its unlikely to be more than 100 bytes and it will be
followed by hundreds of kilobytes at least of audio data. So why
are we trying to conserve a couple of bits in the header?

> 2. Does supporting both chunked and interleaved storage place too much of
> a burden on the applications?

I believe it does.

Cheers,
Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
"That being done, all you have to do next is call free() slightly 
less often than malloc(). You may want to examine the Solaris 
system libraries for a particularly ambitious implementation of 
this technique."
-- Eric O'Dell (comp.lang.dylan)