[ogg-dev] OggPCM2: channel map

[Sampo Syreeni]

On 2005-11-19, Jean-Marc Valin wrote:

> Not sure this is a good idea. Remember that channel_map is just an 
> array (unless you want to make it a map?). So if you had a 
> OGG_CHANNEL_SPECIAL with an id of 1000, it would force 1000 entries in 
> the array.

True, but remember that the channel map type implied the number of 
entries in the table, and also that in this organization you'll always 
number the logical channels consequtively since each logical channel 
indeed corresponds to an index into the array. If the channel map type 
says it's a map for 5.1, there will only be 6 slots in the table no 
matter how many channels are actually stored. So you would have to 
define a map type with 1000 separate logical channels before the 
situation you worry about could come about. If we forget fancy research 
stuff like high WFS (upto 192 channels, the last I heard; OTOH this 
means 255 channels might not be enough for everything) the broadest 
types I've heard of are Tomlinson Holman's 10.2 (12 channels) and third 
order periphonic ambisonic (16 channels), so I don't think this will 
present an issue any time soon.

Similarly, it is an easily detectable encoding fault if any of the 
indices stored in the table exceed the number of channels in a frame, 
stored in the preceding codec setup header, so we won't be bumping into 
trouble from this side either.

> While it makes it impossible to do something stupid like mapping two 
> channels to the same target, it makes it easier to not map a channel 
> at all.

True, but why would this be a bad thing? First, if we want to be able to 
emulate RIFF WAVE, we have to be able to not map channels, anyway. (WAVE 
explicitly supports channels without associated channel mask bits, so 
that pure multichannel stream transport between e.g. mixing desks where 
the channels do not and cannot have a fixed interpretation is possible.) 
Doing it this way avoids the need for an explicitly undefined, or 
opaque, channel type.

Second, OggPCM will be used as a raw format within the Ogg framework to 
pass unpacked PCM data around. The format could also prove useful as a 
simple wrapper to existing raw sample files (say, for a synth or an 
acoustic simulation), which may very well fail to possess a fixed 
interpretation in terms of speaker feeds or any other common delivery 
format. In these cases you might not want to include a channel map at 
all. Such cases might also constitute the first concrete case against 
defaulting the channel interpretation.

>> I think this is a good idea, but it may be wise to stop at stereo and
>> not provide a preference for any of the 4+ channel formats.
>
> I think a default mapping would be needed just to help for the
> conversion header.

I'm not sure I understand this part.
-- 
Sampo Syreeni, aka decoy - mailto:decoy at iki.fi, tel:+358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2