> 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
>> 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.I think I understand the confusion here, but correct me if I'm wrong. What we're proposing is to define the channel map for each supported channel group type. The array syntax I used in my last post probably added to the confusion - look at it again but without using the assigned values to the OGG_CHANNEL_* text. A couple examples: Packet 1: channel_type = OGG_CHANNEL_MAP_5_1 channel_map [0 = OGG_CHANNEL_FRONT_LEFT] = 1 channel_map [1 = OGG_CHANNEL_FRONT_CENTER] = 2 channel_map [2 = OGG_CHANNEL_FRONT_RIGHT] = 3 Packet 2: channel_type = OGG_CHANNEL_MAP_STEREO channel_map [0 = OGG_CHANNEL_FRONT_LEFT] = 1 channel_map [1 = OGG_CHANNEL_FRONT_RIGHT] = 2 Packet 3: channel_type = OGG_CHANNEL_MAP_UHJ channel_map [0 = OGG_CHANNEL_UHJ_SIGMA] = 1 channel_map [1 = OGG_CHANNEL_UHJ_DELTA] = 2>From the first two examples, we see that a channel can appear at differentindexes in the mapping array. The order of channels within the array is defined by the channel_type. Under this scheme, the channel id either has no numerical value, or has a value defined for each different channel_type. To make this more clear, the channels above should be renamed: OGG_CHANNEL_STEREO_LEFT = 0 OGG_CHANNEL_STEREO_RIGHT = 1 OGG_CHANNEL_5_1_FRONT_LEFT = 0 OGG_CHANNEL_5_1_FRONT_CENTER = 1 OGG_CHANNEL_5_1_FRONT_RIGHT = 2 OGG_CHANNEL_UHJ_SIGMA = 0 OGG_CHANNEL_UHJ_DELTA = 1 So the number of channels in the map is always equal to the number of channels in the group type, not the number of channels in the stream. You're right, if the channel id's had a globally unique value (as is currently defined), then you'd have to include blank slots for all the unused channels as you mentioned, and this wouldn't work. Applications should search based on group types, not channel id's - ie, an application supports CHANNEL_MAP_STEREO, not CHANNEL_FRONT_LEFT and CHANNEL_FRONT_RIGHT. So I don't think defining the channel id's within the scope of a group type is too bad.> 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.The conversion maps define conversions to logical channels, not physical ones. To use a crude example, if you're going from 5.1 to stereo by just extracting the FL and FR channels, you'd define a conversion map that says stereo left is on channel 0, stereo right is on channel 2. Then if your app wants to make (r,l) out of it instead of (l,r) it's free to do so. So you would create a stream with Packet 1 above, and Packet 4: Packet 4: channel_type = OGG_CHANNEL_MAP_STEREO channel_map [0 = OGG_CHANNEL_FRONT_LEFT] = 1 channel_map [1 = OGG_CHANNEL_FRONT_RIGHT] = 3 Does that help at all, or have I added to the confusion? John
OK, I hadn't understood that you'd also get rid of the global channel definitions. In that case, you shouldn't use OGG_CHANNEL_FRONT_LEFT like you were using, but OGG_CHANNEL_STEREO_FRONT_LEFT, OGG_CHANNEL_QUAD_FRONT_LEFT, OGG_CHANNEL_5_1_FRONT_LEFT, ... I think that would be a mess, but then again I won't be the primary user of OggPCM. I suggest everyone interested gives his opinion about this so we can see where the majority is and/or whether there's a compromise possible. Jean-Marc Le samedi 19 novembre 2005 ? 07:46 -0500, jkoleszar@on2.com a ?crit :> >> 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. > > I think I understand the confusion here, but correct me if I'm wrong. What > we're proposing is to define the channel map for each supported channel > group type. The array syntax I used in my last post probably added to the > confusion - look at it again but without using the assigned values to the > OGG_CHANNEL_* text. A couple examples: > > Packet 1: > channel_type = OGG_CHANNEL_MAP_5_1 > channel_map [0 = OGG_CHANNEL_FRONT_LEFT] = 1 > channel_map [1 = OGG_CHANNEL_FRONT_CENTER] = 2 > channel_map [2 = OGG_CHANNEL_FRONT_RIGHT] = 3 > > Packet 2: > channel_type = OGG_CHANNEL_MAP_STEREO > channel_map [0 = OGG_CHANNEL_FRONT_LEFT] = 1 > channel_map [1 = OGG_CHANNEL_FRONT_RIGHT] = 2 > > Packet 3: > channel_type = OGG_CHANNEL_MAP_UHJ > channel_map [0 = OGG_CHANNEL_UHJ_SIGMA] = 1 > channel_map [1 = OGG_CHANNEL_UHJ_DELTA] = 2 > > From the first two examples, we see that a channel can appear at different > indexes in the mapping array. The order of channels within the array is > defined by the channel_type. Under this scheme, the channel id either has > no numerical value, or has a value defined for each different > channel_type. To make this more clear, the channels above should be > renamed: > OGG_CHANNEL_STEREO_LEFT = 0 > OGG_CHANNEL_STEREO_RIGHT = 1 > OGG_CHANNEL_5_1_FRONT_LEFT = 0 > OGG_CHANNEL_5_1_FRONT_CENTER = 1 > OGG_CHANNEL_5_1_FRONT_RIGHT = 2 > OGG_CHANNEL_UHJ_SIGMA = 0 > OGG_CHANNEL_UHJ_DELTA = 1 > > So the number of channels in the map is always equal to the number of > channels in the group type, not the number of channels in the stream. > You're right, if the channel id's had a globally unique value (as is > currently defined), then you'd have to include blank slots for all the > unused channels as you mentioned, and this wouldn't work. > > Applications should search based on group types, not channel id's - ie, an > application supports CHANNEL_MAP_STEREO, not CHANNEL_FRONT_LEFT and > CHANNEL_FRONT_RIGHT. So I don't think defining the channel id's within the > scope of a group type is too bad. > > > > 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. > > The conversion maps define conversions to logical channels, not physical > ones. To use a crude example, if you're going from 5.1 to stereo by just > extracting the FL and FR channels, you'd define a conversion map that says > stereo left is on channel 0, stereo right is on channel 2. Then if your > app wants to make (r,l) out of it instead of (l,r) it's free to do so. So > you would create a stream with Packet 1 above, and Packet 4: > Packet 4: > channel_type = OGG_CHANNEL_MAP_STEREO > channel_map [0 = OGG_CHANNEL_FRONT_LEFT] = 1 > channel_map [1 = OGG_CHANNEL_FRONT_RIGHT] = 3 > > Does that help at all, or have I added to the confusion? > > John > > > > >