[ogg-dev] OggPCM2: channel map

[Jean-Marc Valin]

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

Not quite, let's say the six first logical channels are the ones used
for surround (left, right, back, ...) and you have an ambisonic file
(left and right have no meaning) or something like that. You still have
a much larger table than you need.

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

Unless I've missed someone, doesn't all this add to the size of the map
even for mappings you don't use? Is seems like the whole thing would be
a bit hard to extend, no? Anybody else here has thoughts on this?

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

Doesn't really matter if there's a default. The mapping header always
overrides the default and if there's no mapping header, the default is
still better than nothing (not knowing how to play the file at all).

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

I mean that if we want to describe how to convert from 5.1 to stereo,
then you don't want to define the conversion for both [left,right]
stereo and for [right,left] stereo. If you have a default, then the
conversion is always defined for the default and if you want something
else, you can easily swap channels.

	Jean-Marc