OggPCM: Difference between revisions

From XiphWiki
Jump to navigation Jump to search
Line 460: Line 460:
===== Further Suggestions for Conversion and Rendering =====
===== 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. This section outlines some strategies which MAY be used to render an OggPCM stream when this primary mechanism proves insufficient.
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. This section outlines some strategies which MAY be used in approximate rendering.


== See Also ==
== See Also ==

Revision as of 13:40, 14 November 2007

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. This section outlines some strategies which MAY be used in approximate rendering.

See Also

External Links