[ogg-dev] OggPCM2: channel map

[Jean-Marc Valin]

> Yes. Channel map type tells us what the primary interpretation of the 
> stored signals is. Channel definitions are there to tell which stored 
> channel corresponds to which abstract channel in the type. Channel 
> conversions define downmixes to secondary formats, as they do in MLP, 
> and might end up being ignored unlike the channel map.

I think the channel conversion will not be used "most of the times", but
it's probably going to be useful for at least a couple apps. The fact
that it's optional means that it doesn't hurt anyway and those who don't
understand it will probably ignore it instead of putting wrong data in
it.

> In theory the channel conversion header suffices for compatibility 
> coding, but in practice I'm not quite sure that the primary target of 
> such codings -- legacy players -- will implement the feature. In that 
> case the compatibility might prove illusory.

It's not that much about "legacy players". It can be useful for any
player. Say you have a 5.1 PCM OggPCM stream. If that file has a
conversion header, it means that xmms (or any other player) will be able
to play it in stereo without doing anything stupid.

> I'm also not entirely sure that the coding chosen for the channel 
> definitions is the best one. Typically we'd expect each type of channel 
> map to contain all and nothing but the channel definitions typically 
> used with that map type, in some order. For example L, C, R, Ls, Rs and 
> LFE for 5.1. If so, all we're really trying to encode is the 
> interleaving order. After that we have to ask whether that option is 
> really necessary (fixed channel orders are a real possibility, 
> especially since we're not encapsulating an existing format but defining 
> a new streamable one which will necessitate some copying around in any 
> case, and because some unnecessary options were already dropped for 
> simplicity; plus of course the channel conversion headers enable channel 
> permutations as well) and whether this is the best encoding for it 
> (permutations can be coded with less redundancy and room for error). If 
> the idea is to enable subsetting (e.g. 5.1 with a missing LFE equals 
> 5.0) then something like WAVE's channel mask seems a better alternative. 
> The format also doesn't stop us from defining two left channels for 
> stereo, while it does seem to be trying to limit possibilities of error 
> by defining the channel types separately for each map (e.g. no 
> OGG_CHANNEL_AMBISONIC_W inside a stereo channel map). Unfortunately, in 
> the process it could end up with combinatorial explosion in the channel 
> type enumerations (i.e. we might end up redefining L, R, C, etc. for 
> each multichannel map type, of which there are a lot).

One idea I had for this is that there should be a default mapping for
all channel mappings and a default channel mapping for the most used
number of channels. For example, we would say that unless you include a
mapping header, then a 2-channel file is stereo with left channel
interleaved before right. I've added the idea at the bottom of
http://wiki.xiph.org/index.php/OggPCM2 . Any thoughts on this?

	Jean-Marc