[ogg-dev] OggPCM format description, rev 3

[Erik de Castro Lopo]

jkoleszar at on2.com wrote:

> I expected this, it just seemed like a good starting point to get more
> than 7 formats on the table. Specifically I wanted to the logarithmic
> coding formats in there to make it clear this wasn't just for the integer
> ones.

A-law and u-law fit into the scheme of OggPCM without bending OggPCM
out of shape so I'm all for having them included. Adding any of the
ADPCM formats will require a bunch of formats specific hacks which
is a good reason to leave them out.

All cool.

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

I don't know if it was you or someone else, but there are currently
three endian-nesses; big, little and machine. Machine should be culled
because its not portable. If you record a machine endian-ness on an
x86 machine and try an play it back on a PowerPC you will get garbage.

So lets only keep _LE_ and _BE_. However, there are a bunch of good
reason to define a machine endian-ness that is an alias for one of
the other two. So, on x86 machine endian-ness would be an alias for
_LE_ while on PowerPC, machine endian-ness would be an alias for
_BE_. This lets an application specify machine endian-ness which is
optimal for that architecture, but the codec still creates the correct
_LE_ or _BE_ file.

> As long
> as it does 16 bit signed little endian interleaved, I'll be happy.

Thats difficult John, but I think we can do it :-).

> > 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 imagining the case of writing a command line filter chain, for instance:
>  $ snd_capture | deinterlace | denoise | normalize | interlace | compress
> (yes, we'll ignore the fact that you can't normalize in one pass...)

Thats some pretty good points that I hadn't thought of, thanks. 
The only addition requirement I would make is that regardless of 
whether the data is interleaved or chunked, a single packet must 
contain all samples for all channels for that given time period 
represented by the packet and that no other packet may contain 
samples defined for this time period.

I'd say we should allow chunked data. It might finally force me
to implement an interleaver/-dis-interleaver inside libsndfile :-).

Cheers,
Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
"Java, the best argument for Smalltalk since C++." -- Frank Winkler