> I that this is handled pretty nicely by the "simple map" that Sampo > suggested. This is basically the same thing as the "channel map" > described on the wiki, but with the (physical,logical) channel pair > swapped. So, using the syntax from the wiki: > channel_type = OGG_CHANNEL_MAP_STEREO > channel_map [OGG_CHANNEL_FRONT_LEFT] = 1 > channel_map [OGG_CHANNEL_FRONT_RIGHT] = 2Not 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.> This is nice because it makes it impossible for somebody to do something > stupid like define two channels as carrying FRONT_LEFT. A player can't > handle that situation sanely, but handling both FRONT_LEFT and > FRONT_RIGHT mapping to channel 0 is easy. Like Sampo said, this does > mean having to define (and assign an order to) what channels are in each > channel type, but I don't look at that as a bad thing. The other case we > were trying to support, of multiple logical streams at different > bitrates is still easy: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.> >One idea I had for this is that there should be a default mapping for > >all channel mappings and a default channel mapping for the most used > >number of channels. For example, we would say that unless you include a > >mapping header, then a 2-channel file is stereo with left channel > >interleaved before right. I've added the idea at the bottom of > >http://wiki.xiph.org/index.php/OggPCM2 . Any thoughts on this? > > > > > > > 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. Jean-Marc
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@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
> 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