> Yes. Channel map type tells us what the primary interpretation of the > stored signals is. Channel definitions are there to tell which stored > channel corresponds to which abstract channel in the type. Channel > conversions define downmixes to secondary formats, as they do in MLP, > and might end up being ignored unlike the channel map.I think the channel conversion will not be used "most of the times", but it's probably going to be useful for at least a couple apps. The fact that it's optional means that it doesn't hurt anyway and those who don't understand it will probably ignore it instead of putting wrong data in it.> In theory the channel conversion header suffices for compatibility > coding, but in practice I'm not quite sure that the primary target of > such codings -- legacy players -- will implement the feature. In that > case the compatibility might prove illusory.It's not that much about "legacy players". It can be useful for any player. Say you have a 5.1 PCM OggPCM stream. If that file has a conversion header, it means that xmms (or any other player) will be able to play it in stereo without doing anything stupid.> I'm also not entirely sure that the coding chosen for the channel > definitions is the best one. Typically we'd expect each type of channel > map to contain all and nothing but the channel definitions typically > used with that map type, in some order. For example L, C, R, Ls, Rs and > LFE for 5.1. If so, all we're really trying to encode is the > interleaving order. After that we have to ask whether that option is > really necessary (fixed channel orders are a real possibility, > especially since we're not encapsulating an existing format but defining > a new streamable one which will necessitate some copying around in any > case, and because some unnecessary options were already dropped for > simplicity; plus of course the channel conversion headers enable channel > permutations as well) and whether this is the best encoding for it > (permutations can be coded with less redundancy and room for error). If > the idea is to enable subsetting (e.g. 5.1 with a missing LFE equals > 5.0) then something like WAVE's channel mask seems a better alternative. > The format also doesn't stop us from defining two left channels for > stereo, while it does seem to be trying to limit possibilities of error > by defining the channel types separately for each map (e.g. no > OGG_CHANNEL_AMBISONIC_W inside a stereo channel map). Unfortunately, in > the process it could end up with combinatorial explosion in the channel > type enumerations (i.e. we might end up redefining L, R, C, etc. for > each multichannel map type, of which there are a lot).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? Jean-Marc
Jean-Marc Valin wrote:>>I'm also not entirely sure that the coding chosen for the channel >>definitions is the best one. Typically we'd expect each type of channel >>map to contain all and nothing but the channel definitions typically >>used with that map type, in some order. For example L, C, R, Ls, Rs and >>LFE for 5.1. If so, all we're really trying to encode is the >>interleaving order. >>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] = 2 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: Stream 1: channel_type = OGG_CHANNEL_MAP_5_1 channel_map [OGG_CHANNEL_FRONT_LEFT] = 1 channel_map [OGG_CHANNEL_FRONT_CENTER] = 2 channel_map [OGG_CHANNEL_FRONT_RIGHT] = 3 channel_map [OGG_CHANNEL_FRONT_LEFT_SURROUND] = 0 channel_map [OGG_CHANNEL_FRONT_RIGHT_SURROUND] = 0 channel_map [OGG_CHANNEL_FRONT_LFE] = 0 Stream 2: channel_map [OGG_CHANNEL_FRONT_LEFT] = 0 channel_map [OGG_CHANNEL_FRONT_CENTER] = 0 channel_map [OGG_CHANNEL_FRONT_RIGHT] = 0 channel_map [OGG_CHANNEL_FRONT_LEFT_SURROUND] = 1 channel_map [OGG_CHANNEL_FRONT_RIGHT_SURROUND] = 2 channel_map [OGG_CHANNEL_FRONT_LFE] = 3 I think the major difference between Sampo's suggestion and what we defined is that I think we intended only one "channel map" header and many conversion headers. If you allow many "maps", a player that doesn't implement a mixer just has to read packets until it finds a known channel map. Players that do implement mixers only have to read until they hit the first stereo "conversion header." As long as the mapping packets appear in "preferred" order, the player should always produce the best representation it can. With the packets as defined on the wiki, applications have to implement a mixer to play anything but their native format, which may not be desirable, since many formats can be remixed by just selecting the proper channels. Stream 1 above, for example, might define another map: channel_type = OGG_CHANNEL_MAP_STEREO channel_map [OGG_CHANNEL_FRONT_LEFT] = 1 channel_map [OGG_CHANNEL_FRONT_RIGHT] = 3 I think Sampo's notion of calling them both packet types maps is a little cleaner, since both try to do the same thing, but wanted to be consistent with the terms we've been using. His "complex map" is the same as the conversion header as far as I can tell, so it looks like the pair ordering in the channel map is the only thing we disagree on. Overall, I think his solution is pretty slick.>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. John
> 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