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