OggUVS

2005-11-14T21:17:06Z

Jkoleszar: /* Main Header Packet */

OggUVS

2005-11-14T18:09:21Z

Jkoleszar:

OggUVS

2005-11-14T18:01:19Z

Jkoleszar:

OggPCM

2005-11-14T16:38:40Z

Jkoleszar: Add related links

== Alternate format for OggPCM ==

The following is an alternate format for OggPCM. This is a work in progress and not a final proposal.

Note that unless otherwise noted, all multi-byte fields use the network byte order (big endian). The first packed 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:

32 "PCM " Codec identifier
16 0x00 Version Major (breaks backwards compatability to increment)
16 0x00 Version Minor (backwards compatable, ie, more supported format id's)
32 [uint] PCM format
32 [uint] Significant bits
32 [uint] Sampling rate
32 [uint] Number of Channels (< 256)
16 [uint] Maximum number of frames per packet
16 [uint] Number of extra headers

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

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

=== Extra Headers (optional) ===

Extra headers contain additional information about the OggPCM stream. Each extra header is defined as:

32 [uint] Header ID
... Header data

==== 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
32xN [uint] Channel map (one for each channel)

As an example, stereo might be encoded as:

channel_type = OGG_CHANNEL_MAP_STEREO
channel_map [0] = OGG_CHANNEL_STEREO_LEFT
channel_map [1] = OGG_CHANNEL_STEREO_RIGHT

or as:

channel_type = OGG_CHANNEL_MAP_STEREO
channel_map [0] = OGG_CHANNEL_STEREO_RIGHT
channel_map [1] = OGG_CHANNEL_STEREO_LEFT

All channel_types less than 0x80000000 are reserved for use by Xiph and all the ones above are allowed for application specific extensions.

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

=== 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 should only contain complete frames (ie samples for all channels at a given sampling instance). Partial frames are forbidden.
* 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).

=== 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
0x00000008 OGGPCM_FMT_ULAW G.711 u-law encoding (8 bit)
0x00000009 OGGPCM_FMT_ALAW G.711 A-law encoding (8 bit)
0x0000000A OGGPCM_FMT_ULAW12 Wideband u-law encoding (12 bit)
0x0000000B OGGPCM_FMT_ALAW12 Wideband A-law encoding (12 bit)
--
-- IEEE Floating point coding
0x00000010 OGGPCM_FMT_FLT32_LE IEEE Float [-1,1] 32 bit little endian
0x00000011 OGGPCM_FMT_FLT32_BE IEEE Float [-1,1] 32 bit big endian
0x00000012 OGGPCM_FMT_FLT64_LE IEEE Float [-1,1] 64 bit little endian
0x00000013 OGGPCM_FMT_FLT64_BE IEEE Float [-1,1] 64 bit big endian

== 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 <br>
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

OggPCM Draft1

2005-11-13T22:54:39Z

Jkoleszar: /* Header Packet */

'''Warning: OggPCM is currently a topic of [http://lists.xiph.org/pipermail/ogg-dev/2005-November/thread.html heated debate]. The following is *not* the final spec.'''

== What is it ==

'''OggPCM''' is a pulse-code modulation (PCM) audio codec for Ogg. Similar to Microsoft's .wav or Apple's .aiff formats, it's a simple way to store and transfer uncompressed audio within an Ogg container. For the purposes of this document, the term PCM is used to describe a digital representation of an audio signal, where volume samples are taken at regular uniform intervals and then quantized into a digital (usually binary) code. A more complete definition of PCM and related terminology can be found at [[Wikipedia:Pulse-code_modulation|Wikipedia]].

== Why is it ==
The intention for this format is as an interchange format, for example for use with [[OggStream]]. It is also useful for storing time-synced decoded audio/video, as opposed to using RIFF/WAV (.wav) and YUV4MPEG (.yuv) in separate files as was done during [[Theora]] development. It is intended to be less complex to use than either RIFF or AIFF.

== Stream Description ==
A stream is composed of a header packet, zero or more comment packets, and one or more data packets. Data packets may be of variable length, including zero. The only valid use of a zero length data packet is to mark the end of stream. Data packets must contain samples for all channels. That is to say, the length of a data packet must be a multiple of the number of channels times the storage size of a single sample. For instance, for a stream containing 6 channels at 2 byte per channel, the length of the data packet must be a multiple of 12 bytes.

The degenerate stream is a single header packet followed by the raw data packets. While this degenerate stream is not incredibly useful for long term storage or as a general purpose container, it is useful for applications where other data describing the stream is available out of band, for instance amongst cooperating applications in an inter-process communication scheme. Streams providing the extra defined comment packets are intended to be useful for long term storage and communication amongst diverse applications.

== Packet Format ==
Header and comment packets are processed as per the value of their first byte. Packets of unknown ID should be silently ignored, providing a convient way to add future expandability which does not break the data format. An example of how this can be useful is the proposed ReplayGain extension to .wav format: http://replaygain.hydrogenaudio.org/file_format_wav.html

The header packet contains a field indicating the number of comment packets preceding the raw data. Applications must either parse or skip exactly this many packets, in addition to the header packet, before treating the stream as raw data.

=== 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:

Packet 0, BOS, 16 bytes
8 0x00 Stream Header Packet ID
24 "PCM" Codec identifier
-
8 0x01 Version Major (breaks backwards compatability to increment)
8 0x00 Version Minor (backwards compatable, ie, more supported format id's)
8 [uint] Number of comment packets preceding data
8 [uint] Number of Channels, 0 = 256
-
16 [flag] Flags
16 [enum] PCM Format ID
-
32 [uint] Sample Rate

The flags field is defined as follows:
Bit Description
15 (MSB) Interleaved/Chunked - If set, data in the packets is "chunked" by channel. In a data
packet containing 3 channels and 2 samples/channel, the chunked storage order would be
001122. For the interleaved storage format (default), the order would be 012012.
others Reserved

Applications conforming to version 1.0 of this spec MUST:<ul>
<li>set all reserved flags to false (zero) when creating these streams.</li>
<li>preserve all values of all reserved flags when reading or modifying these streams, unless the application sets the minor version field to zero, in which case the reserved flags must be set to false as well.</li>
</ul>

=== Comment Packets ===
At this time, there is only one defined comment packet.
Comment Header Packet
8 0x03 Comment Header Packet ID
24 "PCM" Codec Identifier
-- Continues as [[http://www.xiph.org/vorbis/doc/Vorbis_I_spec.html#vorbis-spec-comment|Vorbis's Comment Header]]

=== Data Packets ===
Data packets have no header word. This is done to preserve the alignment of the data payload. The contents of the data packets are specified by a combination of the 'PCM Format ID' field and the 'Flags' field. The length of the data packet must be a multiple of the number of channels specified in the header, and the storage size of a single sample, as specified by the 'PCM Format ID' field.

=== Supported PCM Formats ===
Formats are identified within a header packet by a 16 bit "format type" field. While
most applications will treat this as an opaque type, it is possible to discern some
information about the format from the value of this field itself. Specifically, the
format's storage size, in bytes, and its byte ordering, can be discerned by parsing
the lower 6 bits of the value. These values are exposed so that it is possible to
extract individual samples without necessarily understanding the coding scheme involved.
While for pratical purposes, due to performance concerns, most applications will
choose to operate on a buffer directly, it is nonetheless possible to work a sample
at a time.

Binary Value Meaning
..xxxx00 N/A, or data not accurately described by this scheme.
..xxxx01 Least significant byte first. Bytes are MS bit first.
..xxxx10 Most significant byte first. Bytes are MS bit first.
..xxxx11 Data is machine endian
..0000xx Data can not be described by this bytepacking scheme.
..0001xx Samples are stored using one byte per sample
..0010xx Samples are stored using two bytes per sample
..0011xx Samples are stored using three bytes per sample
..0100xx Samples are stored using four bytes per sample
..1000xx Samples are stored using eight bytes per sample

The remaining 10 bits describe the coding scheme used to convert the digital value
to an audio signal. The following formats are defined for version 1.0 of this
format. For purposes of attribution, it should be noted that these formats are the
PCM formats supported by the Advanced Linux Sound Architecture (ALSA) project, and
should be fairly comprehensive.

Format ID Short Name Description
-- Signed integer coding (0)
0x0004 OGGPCM_FMT_S8 Signed integer 8 bit
0x0009 OGGPCM_FMT_S16_LE Signed integer 16 bit little endian
0x000A OGGPCM_FMT_S16_BE Signed integer 16 bit big endian
0x000B OGGPCM_FMT_S16 Signed integer 16 bit machine endian
0x000D OGGPCM_FMT_S24_3LE Signed integer 24 bit little endian
0x000E OGGPCM_FMT_S24_3BE Signed integer 24 bit big endian
0x0011 OGGPCM_FMT_S32_LE Signed integer 32 bit little endian
0x0012 OGGPCM_FMT_S32_BE Signed integer 32 bit big endian
0x0013 OGGPCM_FMT_S32 Signed integer 32 bit machine endian
--
-- Unsigned integer coding (1)
0x0044 OGGPCM_FMT_U8 Unsigned integer 8 bit
0x0049 OGGPCM_FMT_U16_LE Unsigned integer 16 bit little endian
0x004A OGGPCM_FMT_U16_BE Unsigned integer 16 bit big endian
0x004B OGGPCM_FMT_U16 Unsigned integer 16 bit machine endian
0x004D OGGPCM_FMT_U24_3LE Unsigned integer 24 bit little endian
0x004E OGGPCM_FMT_U24_3BE Unsigned integer 24 bit big endian
0x0051 OGGPCM_FMT_U32_LE Unsigned integer 32 bit little endian
0x0052 OGGPCM_FMT_U32_BE Unsigned integer 32 bit big endian
0x0053 OGGPCM_FMT_U32 Unsigned integer 32 bit machine endian
--
-- IEEE Floating point coding (2)
0x0091 OGGPCM_FMT_FLT_LE IEEE Float (-1,1) 32 bit little endian
0x0092 OGGPCM_FMT_FLT_BE IEEE Float (-1,1) 32 bit big endian
0x0093 OGGPCM_FMT_FLT IEEE Float (-1,1) 32 bit machine endian
0x00A1 OGGPCM_FMT_FLT64_LE IEEE Float (-1,1) 64 bit little endian
0x00A2 OGGPCM_FMT_FLT64_BE IEEE Float (-1,1) 64 bit big endian
0x00A3 OGGPCM_FMT_FLT64 IEEE Float (-1,1) 64 bit machine endian
--
-- IEC958 coding (?) (3)
0x00CD OGGPCM_FMT_IEC958_3LE IEC958 Subframe, 24 bit little endian
0x00CE OGGPCM_FMT_IEC958_3BE IEC958 Subframe, 24 bit big endian
0x00D1 OGGPCM_FMT_IEC958_LE IEC958 Subframe, 32 bit little endian
0x00D2 OGGPCM_FMT_IEC958_BE IEC958 Subframe, 32 bit big endian
0x00D3 OGGPCM_FMT_IEC958 IEC965 Subframe, 32 bit machine endian
--
-- Mu-Law coding (4)
0x0104 OGGPCM_FMT_MU_LAW Mu-Law
--
-- A-Law coding (5)
0x0144 OGGPCM_FMT_A_LAW A-Law
--
-- ADPCM coding (6)
0x0180 OGGPCM_FMT_ADPCM Ima-ADPCM
--
-- GSM coding (7)
0x01C0 OGGPCM_FMT_GSM GSM
--
-- 24 bit signed integer in 32 bit storage (8)
0x0211 OGGPCM_FMT_S24_LE Signed integer 24 bit little endian
0x0212 OGGPCM_FMT_S24_BE Signed integer 24 bit big endian
0x0213 OGGPCM_FMT_S24 Signed integer 24 bit machine endian
--
-- 24 bit unsigned integer in 32 bit storage (9)
0x0251 OGGPCM_FMT_U24_LE Unsigned integer 24 bit little endian
0x0252 OGGPCM_FMT_U24_BE Unsigned integer 24 bit big endian
0x0253 OGGPCM_FMT_U24 Unsigned integer 24 bit machine endian
--
-- 20 bit signed integer in 24 bit storage (10)
0x028D OGGPCM_FMT_S20_3LE Signed integer 20 bit little endian
0x028E OGGPCM_FMT_S20_3BE Signed integer 20 bit big endian
--
-- 20 bit unsigned integer in 24 bit storage (11)
0x02CD OGGPCM_FMT_U20_3LE Unsigned integer 20 bit little endian
0x02CE OGGPCM_FMT_U20_3BE Unsigned integer 20 bit big endian
--
-- 18 bit signed integer in 24 bit storage (12)
0x030D OGGPCM_FMT_S18_3LE Signed integer 18 bit little endian
0x030E OGGPCM_FMT_S18_3BE Signed integer 18 bit big endian
--
-- 18 bit unsigned integer in 24 bit storage (13)
0x034D OGGPCM_FMT_U18_3LE Unsigned integer 18 bit little endian
0x034E OGGPCM_FMT_U18_3BE Unsigned integer 18 bit big endian
--
Other coding schemes supported by ALSA but not specified here:
MPEG
--
TODO: ADPCM and GSM need further specification (or elimination) since these aren't really
byte packed like the other formats here are.

== Encapsulation in Ogg ==
Following standard terminology for uncompressed audio, an audio frame is the collection of samples for all channels for a single sampling period. For example, an audio frame for a stereo signal is a pair of sample values for the left and right channels.

The granulepos of an Ogg page indicates the presentation time of the last presentable element in the last complete packet within that page; for '''OggPCM''', a granule is an audio frame. The granule position specified is the total audio frames in the stream including the last complete packet in a page. Audio frames must not be split across packets. The rationale here is that the position specified in the frame header of the last page tells how long the data coded by the bitstream is in samples as well as provides the current stream position to seeking routines. A truncated stream will still return the proper number of audio frames that can be decoded fully.

OggPCM Draft1

2005-11-13T22:42:24Z

Jkoleszar: Minor updates to just about everything

'''Warning: OggPCM is currently a topic of [http://lists.xiph.org/pipermail/ogg-dev/2005-November/thread.html heated debate]. The following is *not* the final spec.'''

== What is it ==

'''OggPCM''' is a pulse-code modulation (PCM) audio codec for Ogg. Similar to Microsoft's .wav or Apple's .aiff formats, it's a simple way to store and transfer uncompressed audio within an Ogg container. For the purposes of this document, the term PCM is used to describe a digital representation of an audio signal, where volume samples are taken at regular uniform intervals and then quantized into a digital (usually binary) code. A more complete definition of PCM and related terminology can be found at [[Wikipedia:Pulse-code_modulation|Wikipedia]].

== Why is it ==
The intention for this format is as an interchange format, for example for use with [[OggStream]]. It is also useful for storing time-synced decoded audio/video, as opposed to using RIFF/WAV (.wav) and YUV4MPEG (.yuv) in separate files as was done during [[Theora]] development. It is intended to be less complex to use than either RIFF or AIFF.

== Stream Description ==
A stream is composed of a header packet, zero or more comment packets, and one or more data packets. Data packets may be of variable length, including zero. The only valid use of a zero length data packet is to mark the end of stream. Data packets must contain samples for all channels. That is to say, the length of a data packet must be a multiple of the number of channels times the storage size of a single sample. For instance, for a stream containing 6 channels at 2 byte per channel, the length of the data packet must be a multiple of 12 bytes.

The degenerate stream is a single header packet followed by the raw data packets. While this degenerate stream is not incredibly useful for long term storage or as a general purpose container, it is useful for applications where other data describing the stream is available out of band, for instance amongst cooperating applications in an inter-process communication scheme. Streams providing the extra defined comment packets are intended to be useful for long term storage and communication amongst diverse applications.

== Packet Format ==
Header and comment packets are processed as per the value of their first byte. Packets of unknown ID should be silently ignored, providing a convient way to add future expandability which does not break the data format. An example of how this can be useful is the proposed ReplayGain extension to .wav format: http://replaygain.hydrogenaudio.org/file_format_wav.html

The header packet contains a field indicating the number of comment packets preceding the raw data. Applications must either parse or skip exactly this many packets, in addition to the header packet, before treating the stream as raw data.

=== 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:

Packet 0, BOS, 16 bytes
8 0x00 Stream Header Packet ID
24 "PCM" Codec identifier
-
8 0x01 Version Major (breaks backwards compatability to increment)
8 0x00 Version Minor (backwards compatable, ie, more supported format id's)
8 [uint] Number of comment packets preceding data
8 [uint] Number of Channels, 0 = 256
-
16 [flag] Flags
16 [enum] PCM Format ID
-
32 [uint] Sample Rate

The flags field is defined as follows:
Bit Description
0 (LSB) Interleaved/Chunked - If set, data in the packets is "chunked" by channel. In a data
packet containing 3 channels and 2 samples/channel, the chunked storage order would be
001122. For the interleaved storage format (default), the order would be 012012.
others Reserved

Applications conforming to version 1.0 of this spec MUST:<ul>
<li>set all reserved flags to false (zero) when creating these streams.</li>
<li>preserve all values of all reserved flags when reading or modifying these streams, unless the application sets the minor version field to zero, in which case the reserved flags must be set to false as well.</li>
</ul>

=== Comment Packets ===
At this time, there is only one defined comment packet.
Comment Header Packet
8 0x03 Comment Header Packet ID
24 "PCM" Codec Identifier
-- Continues as [[http://www.xiph.org/vorbis/doc/Vorbis_I_spec.html#vorbis-spec-comment|Vorbis's Comment Header]]

=== Data Packets ===
Data packets have no header word. This is done to preserve the alignment of the data payload. The contents of the data packets are specified by a combination of the 'PCM Format ID' field and the 'Flags' field. The length of the data packet must be a multiple of the number of channels specified in the header, and the storage size of a single sample, as specified by the 'PCM Format ID' field.

=== Supported PCM Formats ===
Formats are identified within a header packet by a 16 bit "format type" field. While
most applications will treat this as an opaque type, it is possible to discern some
information about the format from the value of this field itself. Specifically, the
format's storage size, in bytes, and its byte ordering, can be discerned by parsing
the lower 6 bits of the value. These values are exposed so that it is possible to
extract individual samples without necessarily understanding the coding scheme involved.
While for pratical purposes, due to performance concerns, most applications will
choose to operate on a buffer directly, it is nonetheless possible to work a sample
at a time.

Binary Value Meaning
..xxxx00 N/A, or data not accurately described by this scheme.
..xxxx01 Least significant byte first. Bytes are MS bit first.
..xxxx10 Most significant byte first. Bytes are MS bit first.
..xxxx11 Data is machine endian
..0000xx Data can not be described by this bytepacking scheme.
..0001xx Samples are stored using one byte per sample
..0010xx Samples are stored using two bytes per sample
..0011xx Samples are stored using three bytes per sample
..0100xx Samples are stored using four bytes per sample
..1000xx Samples are stored using eight bytes per sample

The remaining 10 bits describe the coding scheme used to convert the digital value
to an audio signal. The following formats are defined for version 1.0 of this
format. For purposes of attribution, it should be noted that these formats are the
PCM formats supported by the Advanced Linux Sound Architecture (ALSA) project, and
should be fairly comprehensive.

Format ID Short Name Description
-- Signed integer coding (0)
0x0004 OGGPCM_FMT_S8 Signed integer 8 bit
0x0009 OGGPCM_FMT_S16_LE Signed integer 16 bit little endian
0x000A OGGPCM_FMT_S16_BE Signed integer 16 bit big endian
0x000B OGGPCM_FMT_S16 Signed integer 16 bit machine endian
0x000D OGGPCM_FMT_S24_3LE Signed integer 24 bit little endian
0x000E OGGPCM_FMT_S24_3BE Signed integer 24 bit big endian
0x0011 OGGPCM_FMT_S32_LE Signed integer 32 bit little endian
0x0012 OGGPCM_FMT_S32_BE Signed integer 32 bit big endian
0x0013 OGGPCM_FMT_S32 Signed integer 32 bit machine endian
--
-- Unsigned integer coding (1)
0x0044 OGGPCM_FMT_U8 Unsigned integer 8 bit
0x0049 OGGPCM_FMT_U16_LE Unsigned integer 16 bit little endian
0x004A OGGPCM_FMT_U16_BE Unsigned integer 16 bit big endian
0x004B OGGPCM_FMT_U16 Unsigned integer 16 bit machine endian
0x004D OGGPCM_FMT_U24_3LE Unsigned integer 24 bit little endian
0x004E OGGPCM_FMT_U24_3BE Unsigned integer 24 bit big endian
0x0051 OGGPCM_FMT_U32_LE Unsigned integer 32 bit little endian
0x0052 OGGPCM_FMT_U32_BE Unsigned integer 32 bit big endian
0x0053 OGGPCM_FMT_U32 Unsigned integer 32 bit machine endian
--
-- IEEE Floating point coding (2)
0x0091 OGGPCM_FMT_FLT_LE IEEE Float (-1,1) 32 bit little endian
0x0092 OGGPCM_FMT_FLT_BE IEEE Float (-1,1) 32 bit big endian
0x0093 OGGPCM_FMT_FLT IEEE Float (-1,1) 32 bit machine endian
0x00A1 OGGPCM_FMT_FLT64_LE IEEE Float (-1,1) 64 bit little endian
0x00A2 OGGPCM_FMT_FLT64_BE IEEE Float (-1,1) 64 bit big endian
0x00A3 OGGPCM_FMT_FLT64 IEEE Float (-1,1) 64 bit machine endian
--
-- IEC958 coding (?) (3)
0x00CD OGGPCM_FMT_IEC958_3LE IEC958 Subframe, 24 bit little endian
0x00CE OGGPCM_FMT_IEC958_3BE IEC958 Subframe, 24 bit big endian
0x00D1 OGGPCM_FMT_IEC958_LE IEC958 Subframe, 32 bit little endian
0x00D2 OGGPCM_FMT_IEC958_BE IEC958 Subframe, 32 bit big endian
0x00D3 OGGPCM_FMT_IEC958 IEC965 Subframe, 32 bit machine endian
--
-- Mu-Law coding (4)
0x0104 OGGPCM_FMT_MU_LAW Mu-Law
--
-- A-Law coding (5)
0x0144 OGGPCM_FMT_A_LAW A-Law
--
-- ADPCM coding (6)
0x0180 OGGPCM_FMT_ADPCM Ima-ADPCM
--
-- GSM coding (7)
0x01C0 OGGPCM_FMT_GSM GSM
--
-- 24 bit signed integer in 32 bit storage (8)
0x0211 OGGPCM_FMT_S24_LE Signed integer 24 bit little endian
0x0212 OGGPCM_FMT_S24_BE Signed integer 24 bit big endian
0x0213 OGGPCM_FMT_S24 Signed integer 24 bit machine endian
--
-- 24 bit unsigned integer in 32 bit storage (9)
0x0251 OGGPCM_FMT_U24_LE Unsigned integer 24 bit little endian
0x0252 OGGPCM_FMT_U24_BE Unsigned integer 24 bit big endian
0x0253 OGGPCM_FMT_U24 Unsigned integer 24 bit machine endian
--
-- 20 bit signed integer in 24 bit storage (10)
0x028D OGGPCM_FMT_S20_3LE Signed integer 20 bit little endian
0x028E OGGPCM_FMT_S20_3BE Signed integer 20 bit big endian
--
-- 20 bit unsigned integer in 24 bit storage (11)
0x02CD OGGPCM_FMT_U20_3LE Unsigned integer 20 bit little endian
0x02CE OGGPCM_FMT_U20_3BE Unsigned integer 20 bit big endian
--
-- 18 bit signed integer in 24 bit storage (12)
0x030D OGGPCM_FMT_S18_3LE Signed integer 18 bit little endian
0x030E OGGPCM_FMT_S18_3BE Signed integer 18 bit big endian
--
-- 18 bit unsigned integer in 24 bit storage (13)
0x034D OGGPCM_FMT_U18_3LE Unsigned integer 18 bit little endian
0x034E OGGPCM_FMT_U18_3BE Unsigned integer 18 bit big endian
--
Other coding schemes supported by ALSA but not specified here:
MPEG
--
TODO: ADPCM and GSM need further specification (or elimination) since these aren't really
byte packed like the other formats here are.

== Encapsulation in Ogg ==
Following standard terminology for uncompressed audio, an audio frame is the collection of samples for all channels for a single sampling period. For example, an audio frame for a stereo signal is a pair of sample values for the left and right channels.

The granulepos of an Ogg page indicates the presentation time of the last presentable element in the last complete packet within that page; for '''OggPCM''', a granule is an audio frame. The granule position specified is the total audio frames in the stream including the last complete packet in a page. Audio frames must not be split across packets. The rationale here is that the position specified in the frame header of the last page tells how long the data coded by the bitstream is in samples as well as provides the current stream position to seeking routines. A truncated stream will still return the proper number of audio frames that can be decoded fully.

2005-11-09T19:48:27Z

Jkoleszar: Thoughts on the topic

'''Do we need signed/unsigned data flag?'''

Not really. The data can be easily changed to signed as default losslessly. Unsigned 8-bit data (where 128 is the median) is easily changed to signed, and changed back if being saved as RIFF/WAV (which only supports unsigned 8-bit).

However, it wouldn't hurt to support it. Applications can be built to support one or multiple formats, thus requesting conversion if not supported by the codec.
* I don't agree with that. It just puts more conditional code into packages that would normally have only one native format and it gives them more opportunity to fail to support variants of the format. If it's fixed then a few packages will always have to modify the data, and most will never get it wrong. If it's variable then every package will have to do something sometimes, or fail occasionally. --[[User:Gumboot|Gumboot]] 01:28, 8 Nov 2005 (PST)

'''Do we need to record int/float data flag?'''

Some codecs (Vorbis) use floating point samples nativly. Others only support int. Support for int/float data flag is thus important.

'''Do we need to offer endian data flag?'''

LSB/MSB can be changed losslessly, one should probobally be settled on for the data and stick with it. It's a fainly low-CPU process to change the endian on the application side in any event, and if the application uses the bitpacker, this isn't even an issue.

Supporting both is possible, too, but adds complexity to a format intended to be ''simple''.
* We should just standardize on little endian ordering for the data. It's commonly used and well supported in hardware and software. Any cross architecture application that can deal WAV's will already know how to support it.
--[[User:Jkoleszar|Jkoleszar]] 11:48, 9 Nov 2005 (PST)

'''Which endian is it?'''

'''Is it worth supporting a vorbiscomment header?'''

It'd be useful to be able to carry information like what was decoded, or CDDB IDs, or replaygain information. Besides, if you don't put it in then five other people will do it five different ways.

'''How does one interpret a file where the Bits per Sample is neither 32 nor 64 and the Data Type is float?'''
* One doesn't. Standardize on IEEE floats and be done with it. Simple, remember? :)
--[[User:Jkoleszar|Jkoleszar]] 11:48, 9 Nov 2005 (PST)

'''Are samples padded to some round number of bits?'''
* I don't know of any PCM formats for non-octet based samples, but if you want to specify something, I'd say pack them into the LSB's of the next larger byte boundary, with sign extention, on a per channel basis.
--[[User:Jkoleszar|Jkoleszar]] 11:48, 9 Nov 2005 (PST)

== Do we want/need the 32-bit data packet header? ==

The issue was raised on the ogg-dev mailing list of wether this is necessary. With only a single header packet, it could be considered an unneeded complication, however, additional header packets (current or future) will make this a requirement.
* I can definitely see people wanting to use comment pages, so I'd say leave the header on the data pages as well. On the other hand, if ogg provides guarantees about the alignment of packet data from packetout, I could see getting rid of it since there are benefits to working on buffers aligned to larger boundaries on some architectures. As far as I can tell, either no guarantees are made, or you'll get a buffer aligned to a word boundary, in which case having the header has no penalty.
--[[User:Jkoleszar|Jkoleszar]] 11:48, 9 Nov 2005 (PST)