search for: ogg_channel_front_center

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

> 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

> 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

...nnel 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 = O...