[ogg-dev] finalizing oggpcm channel maps

[Sampo Syreeni]

In November 2005 the discussion on OggPCM2 died down before we got 
around to finalizing the channel map. I thought it would be a good time 
to resurrect the topic. The previous threads are at 
http://lists.xiph.org/pipermail/ogg-dev/2005-November/000097.html and 
http://lists.xiph.org/pipermail/ogg-dev/2005-November/000168.html .

In draft 2 of the spec, there are two types of channel maps: a mapping 
header for the primary semantics of the channels, and a conversion 
header which e.g. allows multichannel files to be mixed down into 
stereo. The mapping header contains a channel type, for example 
"stereo", and physical-logical channel pairs, for instance "1st channel 
is interpreted as the left stereo channel". The logical channel 
names/constants are shared across channel types, which makes the channel 
type largely redundant. The conversion header is similar, except it 
contains a full physical times logical channels mixing matrix in 
addition to the channel type field.

Earlier I suggested it would make sense to rephrase the document, so 
that the two map types would be interpreted simply as a simple and a 
complex version of a single header, and to allow an arbitrary number of 
each kind of header in decreasing preferential order, so that 
compatibility codings (like Dolby MP and Ambisonic UHJ) could be made to 
work. I also think there shouldn't be redundancy in the headers, which 
implies that the physical-logical pairs perhaps should be simplified 
into a list which gives the channel semantics either 1) per physical 
channel or 2) per logical channel. I suggested the latter because IMO it 
leaves the least room for nonsensical mappings, it makes it easy not to 
map a given physical channel, and it also uniquely fixes the sizes of 
the lists/matrices stored in the headers per map type. It doesn't allow 
mixed system operation (like B-format plus a stereo pair), though.

Also, the channel type probably ought to be normalized, either by 
dropping it and keeping with a common list of logical channel types 
(which would include channel types from all of the supported systems, 
like Dolby, Ambisonic, discrete multichannel and so on), or 
alternatively by defining the channel names by channel map type (i.e. 
only ambisonic logical channels would be defined for an ambisonic 
channel map). I suggested the latter, but again the former organization 
also has its merits for mixed system operation in the absence of Ogg 
multiplexing.

Finally, one open point about the spec is whether the channel semantics 
ought to be defaulted in the absence of mapping headers. Defaulting 
would allow current, headerless OggPCM2 streams to be interpreted as 
mono, stereo and Ambisonic B-format, depending on the number of channels 
stored. After last time's discussion, I've come to think defaulting 
isn't such a good idea. If/when OggPCM2 is used e.g. inside the Ogg 
framework to carry sound data which doesn't possess an interpretation in 
terms of any of the common transfer formats, it should be possible to 
unambiguously say so. Also, formats like RIFF WAVE allow for generic, 
unmapped channels, so emulating their functionality calls for unmapped 
channels which would conflict with the defaults. So, if defaulting is 
used, I think the channel type list should include an undefined channel 
type for this purpose.

The above are meant as discussion points. If we can develop a consensus 
this time, I'm willing to edit the document, dig up a representative 
list of channel types for the enumerations, put in some context about 
the different choices we've made, and so on.
-- 
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