[ogg-dev] OggPCM2: channel map
decoy at iki.fi
Sat Nov 19 02:19:27 PST 2005
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
More information about the ogg-dev