OggPCM
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 Ambisonic signals.
Channel Mapping, option 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_QUADRAPHONIC = 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 three 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
- 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 a mono file by averaging the left channel and the right channel
- Ambisonic files SHOULD be converted to a mono file using Mono = W*sqrt(2).
- Ambisonic files SHOULD be converted to stereo files by dematrixing W, X and Y.
Channel Mapping, proposed option 2
This proposed version of Channel Mapping has not yet gained the support of the Xiph.Org Foundation. However, it is likely the more mature proposal between the two. Still needs a bit more of polish, though.
Channel mappings are used to convey the meaning of the PCM signals stored in an OggPCM 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.
A header is considered to be present once its header ID has been read successfully. If a field or structure is prematurely terminated after reading the ID, the header is considered erroneous. If an error is encountered in a header, it MUST 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 OggPCM 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 MUST 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, but they MUST NOT be considered an error.
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 which has not been defined is encountered, this MUST be considered an error. If a channel_type is encountered which is defined only for a newer version of the header than indicated, this MAY be considered an error, in which case parsing SHOULD continue with the next header. If a channel_type is encountered which is defined but is not supported by the decoder, parsing SHOULD also continue with the next header. If a channel_type is encountered which is both valid and supported by the decoder, 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, the first associated channel_type MUST be used. If a channel_type is present more than once in a Channel Mapping Header, the first associated channel number MUST be used. If a channel number - channel_type pair is present more than once in a Channel Conversion Header, the first mixing coefficient for the pair MUST be used. If channel mapping data is neglected because of these rules, readers SHOULD still accept the header without treating it as an error, but MAY warn the user.
The mixing coefficients are 32 bit signed, two's complement, fixed point numbers. The 16 most significant bits contain the integer part (including sign), and the 16 least significant bits 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. They are divided into groups corresponding to the closest mapping into the set of channels used in CAF, RIFF WAVE and USB channel masks:
// front left/right OGG_CHANNEL_STEREO_LEFT = 0 = 0x00000000 (30 degrees left) OGG_CHANNEL_STEREO_RIGHT = 1 = 0x00000001 (30 degrees right) OGG_CHANNEL_QUAD_FRONT_LEFT = 2 = 0x00000002 (45 degrees left) OGG_CHANNEL_QUAD_FRONT_RIGHT = 3 = 0x00000003 (45 degrees right) OGG_CHANNEL_BLUMLEIN_LEFT = 4 = 0x00000004 (figure of eight response 45 degrees to the left) OGG_CHANNEL_BLUMLEIN_RIGHT = 5 = 0x00000005 (figure of eight response 45 degrees to the right) OGG_CHANNEL_WALL_FRONT_LEFT = 6 = 0x00000006 (55 degrees left) OGG_CHANNEL_WALL_FRONT_RIGHT = 7 = 0x00000007 (55 degrees right) OGG_CHANNEL_HEX_FRONT_LEFT = 8 = 0x00000008 (60 degrees left) OGG_CHANNEL_HEX_FRONT_RIGHT = 9 = 0x00000009 (60 degrees right) OGG_CHANNEL_PENTAGONAL_FRONT_LEFT = 10 = 0x0000000A (72 degrees left) OGG_CHANNEL_PENTAGONAL_FRONT_RIGHT = 11 = 0x0000000B (72 degrees right) OGG_CHANNEL_BINAURAL_LEFT = 12 = 0x0000000C (fed directly into the left ear canal, or front stereo dipole with crosstalk cancellation) OGG_CHANNEL_BINAURAL_RIGHT = 13 = 0x0000000D (fed directly into the right ear canal, or front stereo dipole with crosstalk cancellation) OGG_CHANNEL_FRONT_STEREO_DIPOLE_LEFT = 14 = 0x0000000E (5 degrees left) OGG_CHANNEL_FRONT_STEREO_DIPOLE_RIGHT = 15 = 0x0000000F (5 degrees right) OGG_CHANNEL_UHJ_L = 16 = 0x00000010 (ambisonics UHJ left) OGG_CHANNEL_UHJ_R = 17 = 0x00000011 (ambisonics UHJ right) OGG_CHANNEL_DOLBY_STEREO_LEFT = 18 = 0x00000012 (dolby stereo/surround left total) OGG_CHANNEL_DOLBY_STEREO_RIGHT = 19 = 0x00000013 (dolby stereo/surround right total) OGG_CHANNEL_XY_LEFT = 20 = 0x00000014 (cardioid response 45 degrees to the left) OGG_CHANNEL_XY_RIGHT = 21 = 0x00000015 (cardioid response 45 degrees to the right)
// front center/mono OGG_CHANNEL_FRONT_CENTER = 256 = 0x00000100 (ear level, straight ahead) OGG_CHANNEL_MS_MID = 257 = 0x00000101 (cardioid response, straight ahead)
// lfe OGG_CHANNEL_LFE = 512 = 0x00000200 (omnidirectional, bandlimited to 120Hz, 10dB louder than the reference level) OGG_CHANNEL_LFE_SIDE_LEFT = 513 = 0x00000201 (90 degrees left, bandlimited to 120Hz, 10dB louder than the reference level) OGG_CHANNEL_LFE_SIDE_RIGHT = 514 = 0x00000202 (90 degrees right, bandlimited to 120Hz, 10dB louder than the reference level) OGG_CHANNEL_LFE_FRONT_CENTER_LEFT = 515 = 0x00000203 (22.5 degrees left, bandlimited to 120Hz, 10dB louder than the reference level) OGG_CHANNEL_LFE_FRONT_CENTER_RIGHT = 516 = 0x00000204 (22.5 degrees right, bandlimited to 120Hz, 10dB louder than the reference level) OGG_CHANNEL_LFE_FRONT_BOTTOM_CENTER_LEFT = 517 = 0x00000205 (45 degrees lowered, 22.5 degrees left, bandlimited to 120Hz, 10dB louder than the reference level) OGG_CHANNEL_LFE_FRONT_BOTTOM_CENTER_RIGHT = 518 = 0x00000206 (45 degrees lowered, 22.5 degrees right, bandlimited to 120Hz, 10dB louder than the reference level)
// back left/right OGG_CHANNEL_ITU_BACK_LEFT = 768 = 0x00000300 (back, 70 degrees left) OGG_CHANNEL_ITU_BACK_RIGHT = 769 = 0x00000301 (back, 70 degrees right) OGG_CHANNEL_ITU_BACK_LEFT_SURROUND = 770 = 0x00000302 (back, 70 degrees left) OGG_CHANNEL_ITU_BACK_RIGHT_SURROUND = 771 = 0x00000303 (back, 70 degrees right) OGG_CHANNEL_HEX_BACK_LEFT = 772 = 0x00000304 (back, 60 degrees left) OGG_CHANNEL_HEX_BACK_RIGHT = 773 = 0x00000305 (back, 60 degrees right) OGG_CHANNEL_QUAD_BACK_LEFT = 774 = 0x00000306 (back, 45 degrees left) OGG_CHANNEL_QUAD_BACK_RIGHT = 775 = 0x00000307 (back, 45 degrees right) OGG_CHANNEL_PENTAGONAL_BACK_LEFT = 776 = 0x00000308 (back, 36 degrees left) OGG_CHANNEL_PENTAGONAL_BACK_RIGHT = 777 = 0x00000309 (back, 36 degrees right) OGG_CHANNEL_BACK_STEREO_LEFT = 778 = 0x0000030A (back, 30 degrees left) OGG_CHANNEL_BACK_STEREO_RIGHT = 779 = 0x0000030B (back, 30 degrees right) OGG_CHANNEL_BACK_STEREO_DIPOLE_LEFT = 780 = 0x0000030C (back, 5 degrees left) OGG_CHANNEL_BACK_STEREO_DIPOLE_RIGHT = 781 = 0x0000020E (back, 5 degrees right)
// front center left/right OGG_CHANNEL_FRONT_CENTER_LEFT = 1024 = 0x00000400 (22.5 degrees left) OGG_CHANNEL_FRONT_CENTER_RIGHT = 1025 = 0x00000401 (22.5 degrees right)
// back center OGG_CHANNEL_BACK_CENTER = 1280 = 0x00000500 (straight back) OGG_CHANNEL_BACK_CENTER_SURROUND = 1281 = 0x00000501 (straight back, diffuse) OGG_CHANNEL_SURROUND = 1282 = 0x00000502 (back and sides, diffuse)
// side left/right OGG_CHANNEL_SIDE_LEFT = 1536 = 0x00000600 (90 degrees left) OGG_CHANNEL_SIDE_RIGHT = 1537 = 0x00000601 (90 degrees right) OGG_CHANNEL_SIDE_LEFT_SURROUND = 1538 = 0x00000602 (90 degrees left, diffuse) OGG_CHANNEL_SIDE_RIGHT_SURROUND = 1539 = 0x00000603 (90 degrees right, diffuse)
// rest of the wav/usb/caf mask types OGG_CHANNEL_TOP_CENTER = 1792 = 0x00000700 (90 degrees elevated) OGG_CHANNEL_FRONT_TOP_LEFT = 1793 = 0x00000701 (45 degrees elevated, 45 degrees left) OGG_CHANNEL_FRONT_TOP_CENTER = 1794 = 0x00000702 (45 degrees elevated) OGG_CHANNEL_FRONT_TOP_RIGHT = 1795 = 0x00000703 (45 degrees elevated, 45 degrees left) OGG_CHANNEL_BACK_TOP_LEFT = 1796 = 0x00000704 (back, 45 degrees elevated, 45 degrees left) OGG_CHANNEL_BACK_TOP_CENTER = 1797 = 0x00000705 (back, 45 degrees elevated) OGG_CHANNEL_BACK_TOP_RIGHT = 1798 = 0x00000706 (back, 45 degrees elevated, 45 degrees right)
// rest of the cube OGG_CHANNEL_SIDE_TOP_LEFT = 2048 = 0x00000800 (45 degrees elevated, 90 degrees left) OGG_CHANNEL_SIDE_TOP_RIGHT = 2049 = 0x00000801 (45 degrees elevated, 90 degrees right) OGG_CHANNEL_FRONT_BOTTOM_LEFT = 2050 = 0x00000802 (45 degrees lowered, 45 degrees left) OGG_CHANNEL_FRONT_BOTTOM_CENTER = 2051 = 0x00000803 (45 degrees lowered) OGG_CHANNEL_FRONT_BOTTOM_RIGHT = 2052 = 0x00000804 (45 degrees lowered, 45 degrees right) OGG_CHANNEL_SIDE_BOTTOM_LEFT = 2053 = 0x00000805 (45 degrees lowered, 90 degrees left) OGG_CHANNEL_BOTTOM_CENTER = 2054 = 0x00000806 (90 degrees lowered) OGG_CHANNEL_SIDE_BOTTOM_RIGHT = 2055 = 0x00000807 (45 degrees lowered, 90 degrees left) OGG_CHANNEL_BACK_BOTTOM_CENTER = 2056 = 0x00000808 (back, 45 degrees lowered) OGG_CHANNEL_BACK_BOTTOM_LEFT = 2057 = 0x00000809 (back, 45 degrees lowered, 45 degrees left) OGG_CHANNEL_BACK_BOTTOM_RIGHT = 2058 = 0x0000080A (back, 45 degrees lowered, 45 degrees right)
// ambisonics OGG_CHANNEL_AMBISONICS_W = 2304 = 0x00000900 (0th order) OGG_CHANNEL_AMBISONICS_X = 2305 = 0x00000901 (1st order) OGG_CHANNEL_AMBISONICS_Y = 2306 = 0x00000902 (1st order, also used for mid/side side) OGG_CHANNEL_AMBISONICS_Z = 2307 = 0x00000903 (1st order) OGG_CHANNEL_AMBISONICS_R = 2308 = 0x00000904 (2nd order) OGG_CHANNEL_AMBISONICS_S = 2309 = 0x00000905 (2nd order) OGG_CHANNEL_AMBISONICS_T = 2310 = 0x00000906 (2nd order) OGG_CHANNEL_AMBISONICS_U = 2311 = 0x00000907 (2nd order) OGG_CHANNEL_AMBISONICS_V = 2312 = 0x00000908 (2nd order) OGG_CHANNEL_AMBISONICS_K = 2313 = 0x00000909 (3rd order) OGG_CHANNEL_AMBISONICS_L = 2314 = 0x0000090A (3rd order) OGG_CHANNEL_AMBISONICS_M = 2315 = 0x0000090B (3rd order) OGG_CHANNEL_AMBISONICS_N = 2316 = 0x0000090C (3rd order) OGG_CHANNEL_AMBISONICS_O = 2317 = 0x0000090D (3rd order) OGG_CHANNEL_AMBISONICS_P = 2318 = 0x0000090E (3rd order) OGG_CHANNEL_AMBISONICS_Q = 2319 = 0x0000090F (3rd order)
// passive matrix additions OGG_CHANNEL_MS_SIDE = 2306 = 0x00000902 (figure of eight response left to right, same as Ambisonics Y) OGG_CHANNEL_UHJ_T = 2561 = 0x00000A01 (ambisonics UHJ addition for pantophony) OGG_CHANNEL_UHJ_Q = 2562 = 0x00000A02 (ambisonics UHJ addition for periphony)
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.
Unless otherwise indicated, each channel should give rise to the same sound pressure level at the listener. The channel mapping metadata does not impose an absolute reference level for the channel data. The relative levels for ambisonic channels are given by the Furse-Malham convention.
Unless otherwise indicated, channel_types marked as being "diffuse" are intended to be reproduced with an average cardioid response emanating from the stated direction. They MAY instead be reproduced using dipole speakers aligned so that direct arrival of sound to the sweet spot is minimized, or they MAY be reproduced by multiple speakers placed slightly above the listener in and around the stated direction. They SHOULD retain flat average spectral response as measured from the sweet spot, in average they MUST be temporally aligned with the rest of the channels at the sweet spot, at each frequency they SHOULD be reproduced with maximal spatial dispersion consistent with the above, and each pair of diffuse channels SHOULD be temporally decorrelated to the maximum degree that is consistent with the above.
Defaulting and Standard Mappings
OggPCM 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 are specified below. Further INFORMATIVE mappings for various channel layouts can be found in a companion document.
- 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 three channels and no explicit channel map are assumed to contain 1st order pantophonic Ambisonics (W, X and Y).
- Files containing precisely four channels and no explicit channel map are assumed to contain 1st order periphonic Ambisonics (W, X, Y and Z).
- Files containing precisely six channels and no explicit channel map are assumed to contain 5.1 in the ITU-R BS.775-1 layout.
- Files containing precisely seven channels and no explicit channel map are assumed to contain 6.1 in the ITU+back channel layout.
- Files containing precisely eight channels and no explicit channel map are assumed to contain 7.1 in the Dolby/DTS discrete layout.
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 0x00000100 Channel_type OGG_CHANNEL_FRONT_CENTER
32 0x00000001 Channel Conversion Header 16 0x0000 Version Major 0 16 0x0000 Version Minor 0 32 0x00000000 Channel 0, containing OGG_CHANNEL_FRONT_CENTER 32 0x00000000 Channel_type OGG_CHANNEL_STEREO_LEFT 32 0x0000B504 Mixing coefficient 1/sqrt(2) 32 0x00000000 Channel 0, containing OGG_CHANNEL_FRONT_CENTER 32 0x00000001 Channel_type OGG_CHANNEL_STEREO_RIGHT 32 0x0000B504 Mixing coefficient 1/sqrt(2)
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 0x00000000 Channel_type OGG_CHANNEL_STEREO_LEFT 32 0x00000001 Channel 1 32 0x00000001 Channel_type OGG_CHANNEL_STEREO_RIGHT
32 0x00000001 Channel Conversion Header 16 0x0000 Version Major 0 16 0x0000 Version Minor 0 32 0x00000000 Channel 0, containing OGG_CHANNEL_STEREO_LEFT 32 0x00000100 Channel_type OGG_CHANNEL_FRONT_CENTER 32 0x0000B504 Mixing coefficient 1/sqrt(2) 32 0x00000001 Channel 1, containing OGG_CHANNEL_STEREO_RIGHT 32 0x00000100 Channel_type OGG_CHANNEL_FRONT_CENTER 32 0x0000B504 Mixing coefficient 1/sqrt(2)
Default mapping for first order pantophonic Ambisonics:
32 0x00000000 Channel Mapping Header 16 0x0000 Version Major 0 16 0x0000 Version Minor 0 32 0x00000000 Channel 0 32 0x00000900 Channel_type OGG_CHANNEL_AMBISONICS_W 32 0x00000001 Channel 1 32 0x00000901 Channel_type OGG_CHANNEL_AMBISONICS_X 32 0x00000002 Channel 2 32 0x00000902 Channel_type OGG_CHANNEL_AMBISONICS_Y
Default mapping for first order periphonic Ambisonics:
32 0x00000000 Channel Mapping Header 16 0x0000 Version Major 0 16 0x0000 Version Minor 0 32 0x00000000 Channel 0 32 0x00000900 Channel_type OGG_CHANNEL_AMBISONICS_W 32 0x00000001 Channel 1 32 0x00000901 Channel_type OGG_CHANNEL_AMBISONICS_X 32 0x00000002 Channel 2 32 0x00000902 Channel_type OGG_CHANNEL_AMBISONICS_Y 32 0x00000003 Channel 3 32 0x00000903 Channel_type OGG_CHANNEL_AMBISONICS_Z
Default mapping for 5.1 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 0x00000000 Channel_type OGG_CHANNEL_STEREO_LEFT 32 0x00000001 Channel 1 32 0x00000001 Channel_type OGG_CHANNEL_STEREO_RIGHT 32 0x00000002 Channel 2 32 0x00000100 Channel_type OGG_CHANNEL_FRONT_CENTER 32 0x00000003 Channel 3 32 0x00000200 Channel_type OGG_CHANNEL_LFE 32 0x00000004 Channel 4 32 0x00000300 Channel_type OGG_CHANNEL_ITU_BACK_LEFT 32 0x00000005 Channel 5 32 0x00000301 Channel_type OGG_CHANNEL_ITU_BACK_RIGHT
Default mapping for 6.1 in the ITU+back channel layout:
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_STEREO_LEFT 32 0x00000001 Channel 1 32 0x00000001 Channel_type OGG_CHANNEL_STEREO_RIGHT 32 0x00000002 Channel 2 32 0x00000100 Channel_type OGG_CHANNEL_FRONT_CENTER 32 0x00000003 Channel 3 32 0x00000200 Channel_type OGG_CHANNEL_LFE 32 0x00000004 Channel 4 32 0x00000300 Channel_type OGG_CHANNEL_ITU_BACK_LEFT 32 0x00000005 Channel 5 32 0x00000301 Channel_type OGG_CHANNEL_ITU_BACK_RIGHT 32 0x00000006 Channel 6 32 0x00000500 Channel_type OGG_CHANNEL_BACK_CENTER
Default mapping for 7.1 in the Dolby/DTS discrete layout:
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_STEREO_LEFT 32 0x00000001 Channel 1 32 0x00000001 Channel_type OGG_CHANNEL_STEREO_RIGHT 32 0x00000002 Channel 2 32 0x00000100 Channel_type OGG_CHANNEL_FRONT_CENTER 32 0x00000003 Channel 3 32 0x00000200 Channel_type OGG_CHANNEL_LFE 32 0x00000004 Channel 4 32 0x0000030A Channel_type OGG_CHANNEL_BACK_STEREO_LEFT 32 0x00000005 Channel 5 32 0x0000030B Channel_type OGG_CHANNEL_BACK_STEREO_RIGHT 32 0x00000006 Channel 6 32 0x00000600 Channel_type OGG_CHANNEL_SIDE_LEFT 32 0x00000007 Channel 7 32 0x00000601 Channel_type OGG_CHANNEL_SIDE_RIGHT
Further Suggestions for Conversion and Rendering
Even if a decoder 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 OggPCM 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 to support rudimentary downmixing into many different layouts. In the following a set of Channel Conversion Headers are provided which MAY be applied by default.
If this is done, these headers should be considered as having lower priority than any header explicitly provided by the OggPCM stream. That is, if they are incorporated by the decoder, they MUST be added after the last header provided by the OggPCM stream itself.
If they are instead incorporated by the OggPCM encoder, they MUST be fully controllable by the user. Furthermore, the mixing functionality of Channel Conversion Headers MUST NOT be used to override the semantics of defined channel_types.
Even when extensive downmixing information is present, it might not cover the precise speaker layout or hardware capabilities needed for precise playback. That is why this INFORMATIVE section gives some extra tips on channel mapping which cannot be expressed using Channel Conversion Headers.
See Also
External Links
- Short info about AC-3
- AC-3 spec. Note: around p34/140 it appears to be how the channel mapping is encoded.
- .wav extended headers (WAVE-EX) for multi channel
- Ambisonics on Wikipedia
- General surround info