OggPCM
This page was created as an alternative to the original OggPCM_Draft1. After a heated debate most developers are now working on this version of the spec.
Draft format 2 for OggPCM
The following is an draft format for OggPCM. This is a work in progress and not a final proposal. In particular, there is no agreement yet on the channel mapping extra headers.
OggPCM is an encapsulation of PCM audio data into an Ogg logical bitstream. An OggPCM bistream may be concurrently multiplexed with other Ogg logical bitstreams such as OggUVS video or CMML metadata,
Note that unless otherwise noted, all multi-byte fields use the network byte order (big endian). The first packet in a stream MUST be the main header packet. The second packet MUST be the comment packet. Some extra header packets MAY be included after the comment header, provided this is identified in the main header. The packets that follow MUST all be data packets.
Main Header Packet
Multibyte fields in the header packets are packed in big endian order, to be consistent with network byte order. A header packet contains the following fields:
64 "PCM " Codec identifier 16 0x00 Version Major (breaks backwards compatibility to increment) 16 0x00 Version Minor (backwards compatible, ie, more supported format id's) 32 [uint] PCM format 32 [uint] Sampling rate [Hz] 8 [uint] Number of significant bits 8 [uint] Number of Channels (< 256) 16 [uint] Maximum number of frames per packet 32 [uint] Number of extra header packets
A PCM "frame" is composed of samples for all channels at a given time.
The "Codec identifier" is 64 bit long since most other Ogg codecs specify their identifier within the first 64 bits rather than the first 32 bits, so this allows applications to match on all 64 bits consistently.
The "Maximum number of frames per packet" field is meant to notify an application reading the file that no data packet will contain more than a certain number of frames. This not only makes implementation easier, but also provides information on how much needs to be buffered when streaming PCM files. A value of 0 means a maximum of 65536 frames. Implementations SHOULD make this field such that packets do not get split into multiple pages.
The "Number of significant bits" field specifies how many bits are actually used. The other bits MUST be zero. This can be used to support audio with any resolution. For example, 12-bit PCM can be supported as "16 bit PCM" for the format and 12 for the number of significant bits.
For streams where the number of significant bits is the same as the bit width specified by the format, the significant bits field may be set to zero.
For streams where the number of significant bits is less than that specified by the bit width, the data shall be justified to fill the most significant bits. For 12 bit PCM in a 16 bit format, the 12 valid bits will occupy the 12 most significant bits of the 16 bit word and the least significant 4 bits shall be zero.
Since the main header packet and the comment packet are mandatory, the "extra header packets" field counts any additional header packets (aside from these two) that can be provided before the start of the data packets.
Supported PCM Formats
Format ID Short Name Description -- Integer coding 0x00000000 OGGPCM_FMT_S8 Signed integer 8 bit 0x00000001 OGGPCM_FMT_U8 Unsigned integer 8 bit 0x00000002 OGGPCM_FMT_S16_LE Signed integer 16 bit little endian 0x00000003 OGGPCM_FMT_S16_BE Signed integer 16 bit big endian 0x00000004 OGGPCM_FMT_S24_LE Signed integer 24 bit little endian 0x00000005 OGGPCM_FMT_S24_BE Signed integer 24 bit big endian 0x00000006 OGGPCM_FMT_S32_LE Signed integer 32 bit little endian 0x00000007 OGGPCM_FMT_S32_BE Signed integer 32 bit big endian -- -- Compressed PCM 0x00000010 OGGPCM_FMT_ULAW G.711 u-law encoding (8 bit) 0x00000011 OGGPCM_FMT_ALAW G.711 A-law encoding (8 bit) -- -- IEEE Floating point coding 0x00000020 OGGPCM_FMT_FLT32_LE IEEE Float [-1,1] 32 bit little endian 0x00000021 OGGPCM_FMT_FLT32_BE IEEE Float [-1,1] 32 bit big endian 0x00000022 OGGPCM_FMT_FLT64_LE IEEE Float [-1,1] 64 bit little endian 0x00000023 OGGPCM_FMT_FLT64_BE IEEE Float [-1,1] 64 bit big endian
Format IDs below 0x80000000 are reserved for use by Xiph and all the ones above are allowed for application-specific formats.
Comment packet
The codec header is followed by a "vorbis comment" packet and by optional extra headers, if any. The format used is the same as for Vorbis with the exception that there is no packet identifier (so the packet is exactly like it is for Speex).
Data Packets
Data packets contain the raw PCM audio in interleaved format (complete frames are encoded sequentially) with the following definitions/restrictions:
- A PCM "frame" is composed of samples for all channels at a given time.
- Any OggPCM packet MUST only contain complete frames (ie samples for all channels at a given sampling instance). Partial frames are forbidden. It is RECOMMENDED that decoders that come across an invalid packet containing a partial frame to drop the partial frame (at the end) and issue an error.
- There is no padding allowed in a frame except when some bits (<8) are needed to complete a byte. This means that packet size has a direct relationship to the number of frames in the packet (for purposes of seeking).
- Recommended packet size is smaller than 4k since interleaving and seeking in Ogg bitstreams is done on the resolution of packets and thus larger packet sizes create suboptimal bitstreams.
Extra Headers (optional)
Extra header packets contain additional information about the OggPCM stream, and must come after the Comment Packet and before the first Data Packet. Each extra header is defined as:
32 [uint] Header ID ... Header data
The first optional headers to be defined handle mappings from physically stored channels to logical channels, such as speaker feeds and ambisonics signals.
Channel Mapping, draft 1
Channel Mapping Header
The channel mapping header is defined as:
32 0x00000000 Header ID 16 [uint] Major version 16 [uint] Minor version 32 [uint] Channel type 32x2N [uint]Channel map (channel-target pairs)
All channel_types less than 0x80000000 are reserved for use by Xiph; 0x80000000 and above are allowed for application specific extensions.
This scheme allows for 2^31 -1 Xiph defined channel map types and 2^32 distinct channel names.
Exampe values for channel types might be:
OGG_CHANNEL_MAP_MONO = 0 OGG_CHANNEL_MAP_STEREO = 1 OGG_CHANNEL_MAP_MS_WAVE = 2 OGG_CHANNEL_MAP_QUADROPHONIC = 3
and defined channels might be:
OGG_CHANNEL_FRONT_CENTER = 0 OGG_CHANNEL_FRONT_LEFT = 1 OGG_CHANNEL_FRONT_RIGHT = 2 OGG_CHANNEL_SURROUND_LEFT = 3 OGG_CHANNEL_SURROUND_RIGHT = 4 OGG_CHANNEL_SURROUND_REAR = 5 OGG_CHANNEL_REAR_LEFT = 6 OGG_CHANNEL_REAR_RIGHT = 7 OGG_CHANNEL_LFE_CENTER = 8 OGG_CHANNEL_LFE_LEFT = 9 OGG_CHANNEL_LFE_RIGHT = 10
A stereo file could thus be defined as:
channel_type = OGG_CHANNEL_MAP_STEREO channel_map [0] = OGG_CHANNEL_FRONT_LEFT channel_map [1] = OGG_CHANNEL_FRONT_RIGHT
The channel map in this case is: "0 1 1 2".
Channel Mapping Defaults
(ideas by JMV, not yet approved by anyone else. Should be merged in respective header definition above if approved)
In order to simplify implementations when it comes to channel mappings, several defaults are defined when no extra header is present.
- Files containing one channel are assumed to be plain mono files with:
channel_type = OGG_CHANNEL_MAP_MONO channel_map [0] = OGG_CHANNEL_FRONT_CENTER
- Files containing two channels are assumed to be stereo files with:
channel_type = OGG_CHANNEL_MAP_STEREO channel_map [0] = OGG_CHANNEL_FRONT_LEFT channel_map [1] = OGG_CHANNEL_FRONT_RIGHT
- Files containing four channels are assumed to be B-format ambisonic files with:
channel_type = OGG_CHANNEL_MAP_B_FORMAT channel_map [0] = OGG_CHANNEL_W channel_map [1] = OGG_CHANNEL_X channel_map [2] = OGG_CHANNEL_Y channel_map [3] = OGG_CHANNEL_Z
Channel Conversion Header
Any number of channel conversion headers can be specified. This header specifies how to down-mix the data to another format.
32 0x00000001 Remixing Header Id 16 [uint] Major version 16 [uint] Minor version 32 [uint] Target Channel type 32xMxN [sint] Target Channel (M) x Src Channel (N) Gain array
The ordering of the mixing matrix is such that source channel gains are consecutive. The gain (note: *signed* integer) has the 16 MSBs for the integer part (including sign) and 16 bits for the fracional part of the gain. Note: the gain can be negative.
Channel Conversion Defaults
- Stereo files SHOULD be converted to mono files by averaging the left channel and the right channel
- Ambisonic files SHOULD be converted to stereo files basic ambisonic dematrixing W and X.
Channel Mapping, proposed draft 2
This proposal has not yet gained the support of the Xiph community. It should be considered EXPERIMENTAL.
Channel mappings are used to convey the meaning of the PCM signals stored in an OggPCM2 stream. They have been designed so that commonly used transmission formats like stereo, 5.1 and Ambisonics can be accurately tagged and distinguished from each other. Rudimentary downmixing from multichannel formats to stereo and mono and interoperability with compatibility formats like Dolby Surround and Ambisonics UHJ are also supported.
A channel mapping can be given in two forms, using one of two headers. The Channel Mapping header tags any subset of the transmitted channels with its intended playback semantics. The Channel Conversion Header additionally provides a mixing matrix which can be applied to the channels before interpretation as a target, logical channel type.
An arbitrary number of mapping and conversion headers can be present, including none at all. The header types can be mixed and they can appear in any order. When neither header is present, the defaults spelled out in the section below on defaulting apply. When more than one header is present, they describe alternative mappings in a decreasing preferential order, and the first supported one SHOULD be used. If an error is encountered in one of the headers, the header SHOULD be discarded and parsing SHOULD continue with the next header. If mapping headers are present but they are all erroneous, defaulting MUST NOT be applied.
The channel mapping header lists physical channels and their associated logical channels, identified by a channel_type value. It is defined as:
32 0x00000000 Channel Mapping Header ID 16 0x0000 Version Major (breaks backwards compatibility to increment) 16 0x0000 Version Minor (backwards compatible, e.g. more supported format id's) 32x2N [uint] Channel number - channel_type pairs
The channel conversion header adds a mixing coefficient to each physical-logical routing, and explicitly allows many-to-many mappings between the two sets of channels. It is defined as:
32 0x00000001 Channel Conversion Header Id 16 0x0000 Version Major (breaks backwards compatibility to increment) 16 0x0000 Version Minor (backwards compatible, e.g. more supported format id's) 32x3N 2*[uint]+[sint] Channel number - channel_type - mixing coefficient triplets
Channel numbers refer to the physical channels transmitted in the OggPCM2 stream. They start at zero, denoting the first channel transmitted in a frame, and range to the number of channels indicated in the main header packet minus one. References to absent channels SHOULD be treated as an error. If a physical channel is not referenced in any of the channel maps and defaulting is not being used, its semantics are unknown. Such channels SHOULD NOT be played without user intervention, and SHOULD NOT be routed to audio outputs which are currently in use.
Channel_types refer to logical channels with a clear interpretation on how the sound data routed to them is to be reproduced. All channel_types less than 0x80000000 are reserved for use by Xiph; 0x80000000 and above are allowed for application specific extensions. This scheme allows for 2^31 -1 Xiph defined channel map types and 2^32 distinct channel names. If a channel_type is encountered which is not defined for the given version of the mapping header, this SHOULD be considered an error and parsing SHOULD continue with the next header. If a channel_type is encountered which is defined but is not supported by the player, parsing SHOULD also continue with the next header. If a channel_type is encountered which is both valid and supported by the player, but cannot be rendered accurately, parsing SHOULD continue with the next header. Furthermore, writers SHOULD include appropriate Channel Conversion Headers at least into stereo and mono, if possible. Finally, if no header is found which leads to an accurate rendering but at least one valid, supported header is present, approximate conversion MAY be attempted, as outlined in the section on compatibility below.
The mapping rows SHOULD be written sorted first by channel number, then by channel_type, and then by mixing coefficient. If a channel number is present more than once in a Channel Mapping Header, only the first associated channel_type SHOULD be used. If a channel_type is present more than once in a Channel Mapping Header, only the first associated channel number SHOULD be used. If a channel number - channel_type pair is present more than once in a Channel Conversion Header, only the first mixing coefficient for the pair SHOULD be used. Readers SHOULD still accept the header without treating it as an error, but SHOULD warn the user.
The mixing coefficients are 32 bit signed, fixed point numbers. The 16 most significant bits are the integer part (including sign), and 16 least significant parts are the fraction. Note that the gain can be negative.
For major version 0, minor version 0 of the Channel Mapping and Channel Conversion headers, the following channel_type values are defined:
OGG_CHANNEL_FRONT_CENTER = 0 (ear level, straight ahead) OGG_CHANNEL_STEREO_LEFT = 1 (30 degrees left) OGG_CHANNEL_STEREO_RIGHT = 2 (30 degrees right) OGG_CHANNEL_FRONT_CENTER_LEFT = 3 (22.5 degrees left) OGG_CHANNEL_FRONT_CENTER_RIGHT = 4 (22.5 degrees right) OGG_CHANNEL_QUAD_FRONT_LEFT = 5 (45 degrees left) OGG_CHANNEL_QUAD_FRONT_RIGHT = 6 (45 degrees right) OGG_CHANNEL_QUAD_BACK_LEFT = 7 (back, 45 degrees left) OGG_CHANNEL_QUAD_BACK_RIGHT = 8 (back, 45 degrees right) OGG_CHANNEL_HEX_FRONT_LEFT = 9 (60 degrees left) OGG_CHANNEL_HEX_FRONT_RIGHT = 10 (60 degrees right) OGG_CHANNEL_HEX_BACK_LEFT = 11 (back, 60 degrees left) OGG_CHANNEL_HEX_BACK_RIGHT = 12 (back, 60 degrees right) OGG_CHANNEL_ITU_BACK_LEFT = 13 (back, 70 degrees left) OGG_CHANNEL_ITU_BACK_RIGHT = 14 (back, 70 degrees right) OGG_CHANNEL_FRONT_TOP_CENTER = 15 (45 degrees elevated) OGG_CHANNEL_FRONT_TOP_LEFT = 16 (45 degrees elevated, 45 degrees left) OGG_CHANNEL_FRONT_TOP_RIGHT = 17 (45 degrees elevated, 45 degrees left) OGG_CHANNEL_FRONT_BOTTOM_CENTER = 18 (45 degrees lowered) OGG_CHANNEL_FRONT_BOTTOM_LEFT = 19 (45 degrees lowered, 45 degrees left) OGG_CHANNEL_FRONT_BOTTOM_RIGHT = 20 (45 degrees lowered, 45 degrees left) OGG_CHANNEL_SIDE_TOP_LEFT = 21 (45 degrees elevated, 90 degrees left) OGG_CHANNEL_SIDE_TOP = 22 (90 degrees elevated) OGG_CHANNEL_SIDE_TOP_RIGHT = 23 (45 degrees elevated, 90 degrees left) OGG_CHANNEL_SIDE_LEFT = 24 (90 degrees left, also used for lfe left) OGG_CHANNEL_SIDE_RIGHT = 25 (90 degrees right, also used for lfe right) OGG_CHANNEL_SIDE_BOTTOM_LEFT = 26 (45 degrees lowered, 90 degrees left) OGG_CHANNEL_SIDE_BOTTOM = 27 (90 degrees lowered) OGG_CHANNEL_SIDE_BOTTOM_RIGHT = 28 (45 degrees lowered, 90 degrees left) OGG_CHANNEL_BACK_TOP_CENTER = 29 (back, 45 degrees elevated) OGG_CHANNEL_BACK_TOP_LEFT = 30 (back, 45 degrees elevated, 45 degrees left) OGG_CHANNEL_BACK_TOP_RIGHT = 31 (back, 45 degrees elevated, 45 degrees right) OGG_CHANNEL_BACK_BOTTOM_CENTER = 32 (back, 45 degrees lowered) OGG_CHANNEL_BACK_BOTTOM_LEFT = 33 (back, 45 degrees lowered, 45 degrees left) OGG_CHANNEL_BACK_BOTTOM_RIGHT = 34 (back, 45 degrees lowered, 45 degrees right) OGG_CHANNEL_FRONT_STEREO_DIPOLE_LEFT = 35 (5 degrees left) OGG_CHANNEL_FRONT_STEREO_DIPOLE_RIGHT = 36 (5 degrees right) OGG_CHANNEL_BACK_STEREO_DIPOLE_LEFT = 37 (back, 5 degrees left) OGG_CHANNEL_BACK_STEREO_DIPOLE_RIGHT = 38 (back, 5 degrees right) OGG_CHANNEL_BINAURAL_LEFT = 39 (fed directly into the left ear canal) OGG_CHANNEL_BINAURAL_RIGHT = 40 (fed directly into the right ear canal) OGG_CHANNEL_SURROUND = 41 (mono, omnidirectional, diffuse) OGG_CHANNEL_HEX_BACK_LEFT_SURROUND = 42 (back, 60 degrees left, diffuse) OGG_CHANNEL_HEX_BACK_RIGHT_SURROUND = 43 (back, 60 degrees right, diffuse) OGG_CHANNEL_BACK_CENTER_SURROUND = 44 (straight back, diffuse) OGG_CHANNEL_SIDE_LEFT_SURROUND = 45 (90 degrees left, diffuse) OGG_CHANNEL_SIDE_RIGHT_SURROUND = 46 (90 degrees right, diffuse) OGG_CHANNEL_AMBISONICS_W = 47 (0th order, also used for lfe) OGG_CHANNEL_AMBISONICS_X = 48 (1st order, also used for mid/side side) OGG_CHANNEL_AMBISONICS_Y = 49 (1st order) OGG_CHANNEL_AMBISONICS_Z = 50 (1st order) OGG_CHANNEL_AMBISONICS_R = 51 (2nd order) OGG_CHANNEL_AMBISONICS_S = 52 (2nd order) OGG_CHANNEL_AMBISONICS_T = 53 (2nd order) OGG_CHANNEL_AMBISONICS_U = 54 (2nd order) OGG_CHANNEL_AMBISONICS_V = 55 (2nd order) OGG_CHANNEL_AMBISONICS_K = 56 (3rd order) OGG_CHANNEL_AMBISONICS_L = 57 (3rd order) OGG_CHANNEL_AMBISONICS_M = 58 (3rd order) OGG_CHANNEL_AMBISONICS_N = 59 (3rd order) OGG_CHANNEL_AMBISONICS_O = 60 (3rd order) OGG_CHANNEL_AMBISONICS_P = 61 (3rd order) OGG_CHANNEL_AMBISONICS_Q = 62 (3rd order) OGG_CHANNEL_UHJ_L = 63 (ambisonics UHJ left) OGG_CHANNEL_UHJ_R = 64 (ambisonics UHJ right) OGG_CHANNEL_UHJ_SIGMA = 65 (ambisonics UHJ mono/sum/mid) OGG_CHANNEL_UHJ_DELTA = 66 (ambisonics UHJ side/difference) OGG_CHANNEL_UHJ_T = 67 (ambisonics UHJ addition for pantophony) OGG_CHANNEL_UHJ_Q = 68 (ambisonics UHJ addition for periphony) OGG_CHANNEL_DOLBY_STEREO_LEFT = 69 (dolby stereo/surround left) OGG_CHANNEL_DOLBY_STEREO_RIGHT = 70 (dolby stereo/surround right) OGG_CHANNEL_MS_MID = 71 (cardioid response straight ahead) OGG_CHANNEL_MS_SIDE = 48 (figure of eight response left to right, also used for ambisonics X) OGG_CHANNEL_XY_X = 72 (cardioid response 45 degrees to the left) OGG_CHANNEL_XY_Y = 73 (cardioid response 45 degrees to the right) OGG_CHANNEL_LFE_LEFT = 24 (90 degrees left, also used for side left) OGG_CHANNEL_LFE_RIGHT = 25 (90 degrees right, also used for side right) OGG_CHANNEL_FRONT_CENTER_LEFT_LFE = 3 (22.5 degrees left) OGG_CHANNEL_FRONT_CENTER_RIGHT_LFE = 4 (22.5 degrees right) OGG_CHANNEL_FRONT_BOTTOM_CENTER_LEFT = 74 (45 degrees lowered, 22.5 degrees left, also used for front left lfe) OGG_CHANNEL_FRONT_BOTTOM_CENTER_RIGHT = 75 (45 degrees lowered, 22.5 degrees right, also used for front right lfe) OGG_CHANNEL_BACK_CENTER = 76 (straight back) OGG_CHANNEL_LFE = 47 (omnidirectional, also used for ambisonics W) OGG_CHANNEL_BACK_STEREO_LEFT = 77 (back, 30 degrees left) OGG_CHANNEL_BACK_STEREO_RIGHT = 78 (back, 30 degrees right)
Unless otherwise indicated, the logical channels are assumed to be speaker feeds, with the speaker lying in the indicated direction. The direction is referenced to either the front center, or where indicated, the back center speaker. By default all of the speakers SHOULD be at the same distance from the listener, or the so called "sweet spot", so that temporally coincident signals give rise to temporally coincident sound at the listening position. Where the channel_type indicates an interpretation other than a speaker feed, temporal coincidence SHOULD still hold.
Some of the base standards used to derive the channel mappings are sensitive to speaker distance in addition to any possible time delay, and some are not. In any case interoperability between the different standards calls for setting the distance. The base standards used to derive the channel map rarely take a stance on that, so for the purposes of this specification the speaker distance, the listening area, and the Ambisonics coding radius are all idealized as being infinite. Hence, the field produced by any speaker near the sweet spot SHOULD approximate a planar wave, and if this cannot be achieved, an effort SHOULD be made to compensate for the difference e.g. electronically.
Defaulting
OggPCM2 streams were originally defined without channel maps, so for compatibility purposes, the simplest cases are defaulted based on the number of physical channels present. The precise Channel Mapping Headers and Channel Conversion headers that are implied can be found below, in the list of standard mappings.
- Files containing precisely one channel and no explicit channel map are assumed to contain plain mono.
- Files containing precisely two channels and no explicit channel map are assumed to contain plain stereo.
- Files containing precisely four channels and no explicit channel map are assumed to contain 1st order Ambisonics.
- Files containing precisely six channels and no explicit channel map are assumed to contain 5.1 surround in the ITU-R BS.775-1 layout.
- Files containing precisely seven channels and no explicit channel map are assumed to contain 6.1 surround in the ITU+EX/ES back channel layout.
- Files containing precisely eight channels and no explicit channel map are assumed to contain 7.1 surround in the Dolby layout.
Standard Mappings
The OggPCM2 channel mapping approach is based on supersetting existing standards, and logical extension where appropriate. Hence a large number of shared channel_types exists, which can make it difficult to find the right set even when encoding to an existing standard. To ease this task, default mappings for several existing standards are set out below. This list is INFORMATIVE.
Default mapping for plain mono:
32 0x00000000 Channel Mapping Header 16 0x0000 Version Major 0 16 0x0000 Version Minor 0 32 0x00000000 Channel 0 32 0x00000000 Channel_type OGG_CHANNEL_FRONT_CENTER
Default mapping for plain stereo:
32 0x00000000 Channel Mapping Header 16 0x0000 Version Major 0 16 0x0000 Version Minor 0 32 0x00000000 Channel 0 32 0x00000001 Channel_type OGG_CHANNEL_STEREO_LEFT 32 0x00000001 Channel 1 32 0x00000002 Channel_type OGG_CHANNEL_STEREO_RIGHT
Default mapping for first order Ambisonics:
32 0x00000000 Channel Mapping Header 16 0x0000 Version Major 0 16 0x0000 Version Minor 0 32 0x00000000 Channel 0 32 0x0000002F Channel_type OGG_CHANNEL_AMBISONICS_W 32 0x00000001 Channel 1 32 0x00000030 Channel_type OGG_CHANNEL_AMBISONICS_X 32 0x00000002 Channel 2 32 0x00000031 Channel_type OGG_CHANNEL_AMBISONICS_Y 32 0x00000003 Channel 3 32 0x00000032 Channel_type OGG_CHANNEL_AMBISONICS_Z
Default mapping for 5.1 surround in the ITU-R BS.775-1 layout:
32 0x00000000 Channel Mapping Header 16 0x0000 Version Major 0 16 0x0000 Version Minor 0 32 0x00000000 Channel 0 32 0x00000001 Channel_type OGG_CHANNEL_STEREO_LEFT 32 0x00000001 Channel 1 32 0x00000002 Channel_type OGG_CHANNEL_STEREO_RIGHT 32 0x00000002 Channel 2 32 0x00000000 Channel_type OGG_CHANNEL_FRONT_CENTER 32 0x00000003 Channel 3 32 0x0000002F Channel_type OGG_CHANNEL_LFE 32 0x00000004 Channel 4 32 0x0000000D Channel_type OGG_CHANNEL_ITU_BACK_LEFT 32 0x00000005 Channel 5 32 0x0000000E Channel_type OGG_CHANNEL_ITU_BACK_RIGHT
Default mapping for 6.1 surround in the ITU+EX/ES back channel layout:
32 0x00000000 Channel Mapping Header 16 0x0000 Version Major 0 16 0x0000 Version Minor 0 32 0x00000000 Channel 0 32 0x00000001 Channel_type OGG_CHANNEL_STEREO_LEFT 32 0x00000001 Channel 1 32 0x00000002 Channel_type OGG_CHANNEL_STEREO_RIGHT 32 0x00000002 Channel 2 32 0x00000000 Channel_type OGG_CHANNEL_FRONT_CENTER 32 0x00000003 Channel 3 32 0x0000002F Channel_type OGG_CHANNEL_LFE 32 0x00000004 Channel 4 32 0x0000000D Channel_type OGG_CHANNEL_ITU_BACK_LEFT 32 0x00000005 Channel 5 32 0x0000000E Channel_type OGG_CHANNEL_ITU_BACK_RIGHT 32 0x00000006 Channel 6 32 0x0000004C Channel_type OGG_CHANNEL_BACK_CENTER
Default mapping for 7.1 surround in the Dolby layout:
32 0x00000000 Channel Mapping Header 16 0x0000 Version Major 0 16 0x0000 Version Minor 0 32 0x00000000 Channel 0 32 0x00000001 Channel_type OGG_CHANNEL_STEREO_LEFT 32 0x00000001 Channel 1 32 0x00000002 Channel_type OGG_CHANNEL_STEREO_RIGHT 32 0x00000002 Channel 2 32 0x00000000 Channel_type OGG_CHANNEL_FRONT_CENTER 32 0x00000003 Channel 3 32 0x0000002F Channel_type OGG_CHANNEL_LFE 32 0x00000004 Channel 4 32 0x00000018 Channel_type OGG_CHANNEL_SIDE_LEFT 32 0x00000005 Channel 5 32 0x00000019 Channel_type OGG_CHANNEL_SIDE_RIGHT 32 0x00000006 Channel 6 32 0x0000004D Channel_type OGG_CHANNEL_BACK_STEREO_LEFT 32 0x00000007 Channel 7 32 0x0000004E Channel_type OGG_CHANNEL_BACK_STEREO_RIGHT
Example Conversions
Even if a player supports a given channel_type, it is not always possible to recreate the precise intention of the coder because of differences and uncertainties in the available speaker layout. The first fallback offered by the OggPCM2 format is the preferential hierarchy of Channel Mapping and Channel Conversion Headers, which allow the coder to both include multiple separate mixes for different layouts, and also support rudimentary downmixing into many different layouts. However, full downmixing information may not always be available, and in any case the speaker layout rarely supports the exact requirements of all of the different channel_types. That is why some common mappings, conversions and adaptations are outlined in this section. The section is purely INFORMATIVE.
Related Links
Short info about AC-3: http://www.mediatwins.com/en/support/kb_topic_11.html
AC-3 spec: http://www.atsc.org/standards/a_52a.pdf
Note: around p34/140 it appears to be how the channel mapping is encoded.
.wav extended headers for multi channel: http://www.microsoft.com/whdc/device/audio/multichaud.mspx
General surround info: http://www.surroundassociates.com/fqmain.html