[ogg-dev] OggPCM format description, rev 3

[Jean-Marc Valin]

> > 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.
> 
> No objection here. I'd like to see someone other than myself go through
> and cull the list of formats into whatever a practical subset is. As long
> as it does 16 bit signed little endian interleaved, I'll be happy.

In my opinion, the only formats that *could* be worth including in
OggPCM are the ones that support do not incur a loss when tandeming
(decode+reencode). All the PCM formats are fine with that DPCM should be
OK (though probably not useful enough to support), but with ADPCM, you
can't just play with the file, decode, re-encode and still have the same
result unless you don't change anything anywhere in the file.

> > Again, I strongly recommend against allowing non-interleaved data.
> > It simply complicates everything far more than it needs to be.
> 
> This is probably the only point we may disagree on. Having the data
> chunked opens the door for a whole host of SIMD optimized filters and it
> definitely could be a useful internal representation along a filter chain.
> As long as you're only dealing with byte aligned data, I don't think the
> storage and retrieval is that difficult. I agree, it's probably not very
> useful in the general case, but there are some cases where it is, so it
> may be worth defining it.

I'm not completely against non-interleaved, but I don't see a good
reason for it yet (to justify the increased complexity). Even for SIMD
processing I think it doesn't cost that much (compared to the IO to just
read the file) for an application to just copy to non-interleaved
internally. Even then, I would say there's probably a lot of processing
that can be done more efficiently with SIMD by processing interleaved
data (e.g. FIR/IIR filtering). 

	Jean-Marc