XiphWiki - User contributions [en]

People

2015-05-09T08:37:10Z

Erikd: Add myself

This page is meant to help with nickname-to-person lookup.
''Nickname'' can be a mail alias, an IRC nick, or a Subversion user — in most cases several of these.

Please help to fill this table. Keeping your own entry up to date is a good start.

{| border="1" cellspacing="1" cellpadding="4" width="100%"
!colspan="3"| Who Is Who
|-
! Nickname
! Real name
! Keywords
|-
| arkadini
| Arek Korbik
| Quicktime, XiphQT
|-
| basilgohar
| Basil Mohamed Gohar
| opus, legal
|-
| ben
| Benjamin Gérard
| libao
|-
| BjornW
| Björn Wijers
| [[Spread Open Media]], [[XSPF]]
|-
| [[User:Conrad|conrad]]
| [http://blog.kfish.org/ Conrad Parker]
| see ''[[#nick_kfish|kfish]]''
|-
| derf
| [http://people.xiph.org/~tterribe/ Timothy B. Terriberry]
| theora, CELT, video, daala
|-
| dllmain
| Sebastian Pipping
| see ''[[#nick_sping|sping]]'', nick not used anymore
|-
| dm8tbr
| Thomas B. Rücker
| icecast
|-
| doublec
| Chris Double
| firefox, theora, Mozilla
|-
| drac667
| Cristian Adam
| DirectShow, oggcodecs, Windows
|-
| ds
| David Schleef
| theora, dirac, gstreamer
|-
| erikd
| Erik de Castro Lopo
| FLAC maintainer
|-
| [[User:GChriss|gchriss]]
| George Chriss
| gstreamer, Elphel, event videography
|-
| giles
| [http://people.xiph.org/~giles/ Ralph Giles]
| see ''[[#nick_rillian|rillian]]''
|-
| gmaxwell
| Gregory Maxwell
| Wikimedia, CELT, theora, daala
|-
| gnafu
| Gideon Mayhak
| community, testing
|-
| [[User:Silvia|ginger]]
| Silvia Pfeiffer
| see ''[[#nick_nessy|nessy]]''
|-
| [[User:Imalone|imalone]]
| Ian Malone
| metadata
|-
| illiminable
| Zentaro Kavanagh
| DirectShow, dsfilters, Microsoft
|-
| [[User:Saoshyant|ivo]]
| Ivo Emanuel Gonçalves
| advocacy, [[Spread Open Media]], [[XSPF]], wiki mod, vorbis-tools
|-
| jack
| Jack Moffitt
| libao, treasurer, Icecast
|-
| jcoalson
| Josh Coalson
| FLAC author
|-
| j, j^
| Jan Gerber
| v2v, ffmpeg2theora, sysadmin
|-
| [[User:jmspeex|jmspeex]]
| [http://jmvalin.ca/ Jean-Marc Valin]
| Opus (CELT), Daala, Speex
|-
| jmworx
| Jean-Marc Valin
| see ''[[#nick_jmspeex|jmspeex]]''
|-
| JoeyBorn
| Joe Born
| neuros
|-
| karl
| Karl Heyes
| Icecast
|-
| [[User:Conrad|kfish]]
| [http://www.kfish.org/ Conrad Parker]
| annodex, fishsound, hogg, oggz, vorbis-tools
|-
| laser13
| Marcin Lubonski
| annodex, oggplay, win32
|-
| lgonze
| Lucas Gonze
| [[XSPF]]
|-
| lu_zero
| Luca Barbato
| RTP Vorbis, RTP Theora, Gentoo
|-
| maikmerten
| Maik Merten
| theora, java, macos
|-
| MikeS
| Michael Smith
| fluendo, gstreamer, sysadmin, IceS
|-
| Monty
| Christopher Montgomery
| see ''[[#nick_xiphmont|xiphmont]]''
|-
| msmith
| Michael Smith
| see ''[[#nick_mikes|MikeS]]''
|-
| nessy
| Silvia Pfeiffer
| annodex, vquence, sysadmin, CMML
|-
| ozone
| André Pang
| annodex, macos
|-
| pjones
| Peter Jones
| cdparanoia, redhat
|-
| rillian
| [http://people.xiph.org/~giles/ Ralph Giles]
| metadata, video, theora, MNG, sysadmin
|-
| ribamar
| Ribamar Santarosa
| etheora
|-
| Saoshyant
| Ivo Emanuel Gonçalves
| see ''[[#nick_ivo|ivo]]''
|-
| segher
| Segher Boessenkool
| vorbis, audio
|-
| shans
| Shane Stephens
| annodex, oggplay
|-
| silvia
| Silvia Pfeiffer
| see ''[[#nick_nessy|nessy]]''
|-
| smarter
| Guillaume Martres
| libvpx
|-
| [[User:sping|sping]]
| Sebastian Pipping
| [[XSPF]], [http://libspiff.sourceforge.net/ libSpiff], [http://validator.xspf.org/ XSPF Validator]
|-
| TD-Linux
| [http://thomasdaede.com/ Thomas Daede]
| Daala hardware
|-
| tmatth
| Tristan Matthews
| VLC, speex
|-
| tterribe
| [http://people.xiph.org/~tterribe/ Timothy B. Terriberry]
| See ''[[#nick_derf|derf]]''
|-
| thomasvs
| Thomas Vander Stichele
| fluendo, flumotion, gstreamer
|-
| unlord
| Nathan Egge
| daala
|-
| volsung
| Stan Seibert
| libao
|-
| xiphmont
| Christopher Montgomery
| vorbis, ghost, audio, Ogg, cdparanoia, daala
|-
| zen
| Zentaro Kavanagh
| see ''[[#nick_illi|illi]]''
|-
|}

[[Category:Developers stuff]]

OggPCM

2005-11-16T11:18:33Z

Erikd: /* Channel Mapping Header */

'''This page was created as an alternative to the original [[OggPCM]]. The matter is currently a topic of [http://lists.xiph.org/pipermail/ogg-dev/2005-November/thread.html heated debate] and is now being voted on'''

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

64 "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] Sampling rate [Hz]
8 [uint] 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 "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.

=== 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 header packets contain additional information about the OggPCM stream. Each extra header is defined as:

32 [uint] Header ID
... Header data

Two examples for such optional extra header packets are the channel mapping and the channel conversion header packets.

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

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 map type might be:

OGG_CHANNEL_MAP_STEREO = 1
OGG_CHANNEL_MAP_MS_WAVE = 2
OGG_CHANNEL_MAP_QUADROPHONIC = 3

and defined channels might be:

OGG_CHANNEL_FRONT_LEFT = 1
OGG_CHANNEL_FRONT_RIGHT = 2
OGG_CHANNEL_REAR_LEFT = 3
OGG_CHANNEL_REAR_RIGHT = 4

This leaves two ways to define a stereo file:

channel_type = OGG_CHANNEL_MAP_STEREO
channel_map [0] = OGG_CHANNEL_FRONT_LEFT
channel_map [1] = OGG_CHANNEL_FRONT_RIGHT

or as:

channel_type = OGG_CHANNEL_MAP_STEREO
channel_map [0] = OGG_CHANNEL_FRONT_RIGHT
channel_map [1] = OGG_CHANNEL_FRONT_LEFT

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

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

== Related Links ==
Short info about AC-3: http://www.mediatwins.com/en/support/kb_topic_11.html

AC-3 spec: http://www.atsc.org/standards/a_52a.pdf 
Note: around p34/140 it appears to be how the channel mapping is encoded.

.wav extended headers for multi channel: http://www.microsoft.com/whdc/device/audio/multichaud.mspx

General surround info: http://www.surroundassociates.com/fqmain.html

OggPCM

2005-11-16T11:11:23Z

Erikd: Clarify Channel Mapping Header

'''This page was created as an alternative to the original [[OggPCM]]. The matter is currently a topic of [http://lists.xiph.org/pipermail/ogg-dev/2005-November/thread.html heated debate] and is now being voted on'''

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

64 "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] Sampling rate [Hz]
8 [uint] 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 "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.

=== 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 header packets contain additional information about the OggPCM stream. Each extra header is defined as:

32 [uint] Header ID
... Header data

Two examples for such optional extra header packets are the channel mapping and the channel conversion header packets.

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

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 then each of these can have 2^32 channel names.

Exampe values for channel map type might be:

OGG_CHANNEL_MAP_STEREO = 1
OGG_CHANNEL_MAP_MS_WAVE = 2
OGG_CHANNEL_MAP_QUADROPHONIC = 3

and defined channels might be:

OGG_CHANNEL_FRONT_LEFT = 1
OGG_CHANNEL_FRONT_RIGHT = 2
OGG_CHANNEL_REAR_LEFT = 3
OGG_CHANNEL_REAR_RIGHT = 4

This leaves two ways to define a stereo file:

channel_type = OGG_CHANNEL_MAP_STEREO
channel_map [0] = OGG_CHANNEL_FRONT_LEFT
channel_map [1] = OGG_CHANNEL_FRONT_RIGHT

or as:

channel_type = OGG_CHANNEL_MAP_STEREO
channel_map [0] = OGG_CHANNEL_FRONT_RIGHT
channel_map [1] = OGG_CHANNEL_FRONT_LEFT

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

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

== Related Links ==
Short info about AC-3: http://www.mediatwins.com/en/support/kb_topic_11.html

AC-3 spec: http://www.atsc.org/standards/a_52a.pdf 
Note: around p34/140 it appears to be how the channel mapping is encoded.

.wav extended headers for multi channel: http://www.microsoft.com/whdc/device/audio/multichaud.mspx

General surround info: http://www.surroundassociates.com/fqmain.html

OggPCM

2005-11-16T10:53:18Z

Erikd: Channel Mapping Header : minor update

'''This page was created as an alternative to the original [[OggPCM]]. The matter is currently a topic of [http://lists.xiph.org/pipermail/ogg-dev/2005-November/thread.html heated debate] and is now being voted on'''

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

64 "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] Sampling rate [Hz]
8 [uint] 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 "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.

=== 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 header packets contain additional information about the OggPCM stream. Each extra header is defined as:

32 [uint] Header ID
... Header data

Two examples for such optional extra header packets are the channel mapping and the channel conversion header packets.

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

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 then each of these can have 2^32 channel names.

As a simple 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

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

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

== Related Links ==
Short info about AC-3: http://www.mediatwins.com/en/support/kb_topic_11.html

AC-3 spec: http://www.atsc.org/standards/a_52a.pdf 
Note: around p34/140 it appears to be how the channel mapping is encoded.

.wav extended headers for multi channel: http://www.microsoft.com/whdc/device/audio/multichaud.mspx

General surround info: http://www.surroundassociates.com/fqmain.html

Main Page

2005-11-16T10:08:30Z

Erikd: Another PCM format -> OggPCM2

= Projects/Formats =

In an effort to bring open-source ideals to the world of multimedia The Xiph.org Foundation ([[XiphOrg]]) develops a multitude of amazing products.

== Container Formats ==

* [[Ogg]]: Media container. This is our native format and the recommeded container for Xiph codecs.
* [[OggSkeleton]]: Skeleton information on all logical content bitstreams in Ogg

* [[SpeexRTP]]: RTP payload format for voice
* [[VorbisRTP]]: RTP payload format for general audio
* [[TheoraRTP]]: RTP payload format for video
* [[XSPF]]: XML playlist format

== Codecs ==
* '''Compressed Codecs:'''
** [[Vorbis]]: Audio codec with a [[Tremor|fixed point decoder]]
** [[Theora]]: Video codec
** [[FLAC]]: Free Lossless Audio Codec
** [[Speex]]: Speech codec
** [[OggMNG]]: A mapping for encapsulating the MNG animation format in Ogg
* '''[[RawCodecs|Uncompressed Codecs]]:'''
** Audio:
*** [[OggPCM]]: Uncompressed PCM audio, primarily as an interchange codec
*** [[OggPCM2]]: An Alternative Uncompressed PCM audio, under active development
*** [[OggPCM3|Humorous PCM format]]: Uncompressed PCM audio - and a lot more!
** Video:
*** [[OggRGB]]: Uncompressed RGB video, primarily as an interchange codec, under active development
*** [[OggYUV]]: Uncompressed YUV video, primarily as an interchange codec, under active development
*** [[OggUVS]]: Uncompressed RGB and YUV video, under active development as an alternative to OggRGB and OggYUV.
** Text & Hyperlinking:
*** [[OggWrit]]: Text phrase codec (e.g. subtitles)
*** [http://annodex.net/TR/draft-pfeiffer-cmml-02.txt CMML]: Continuous Media Markup Language, used for [http://www.annodex.net/ Annodex] and subtitles (xine, vlc, gstreamer, and DirectShow support)
* '''Metadata Codecs:'''
** [[Metadata]]: Arbitrary metadata stream format (vapourware so far)

== Software for distributing media ==

* [[Icecast]]: Streaming server
* [[Ices]]: Source client for Icecast servers
* [[IceShare]]: P2P content distribution

== Other software ==

* [[OggComponent/VorbisComponent]]: Wrappers to integrate Ogg-Vorbis into MacOsX

= Demonstrations =

Want to hear Xiph in action? These projects are using our codecs, formats, or libraries.

* [[VorbisStreams]]: Stations streaming with the Vorbis codec
* [[Games that use Vorbis]]: Games using the Vorbis codec for music or sound effects
* [[VorbisHardware]]: Hardware players using the Vorbis codec
* [http://www.tversity.com TVersity Media Server]: A UPNP/AV compliant media server that uses the Ogg Vorbis libraries to transcode audio files to the Ogg Vorbis format.

= Project management =

* [[MonthlyMeeting]]
* [[MailingLists]]
* [[Bounties]]
* [[HyperFish]]

= Wiki internal =
* [[Sandbox]]: Testbed for testing editing skills.
* [[Translations]]: What about some translation work

OggPCM

2005-11-16T09:52:36Z

Erikd: Channel Mapping Header : Fix boundary conditions re 0x80000000.

'''This page was created as an alternative to the original [[OggPCM]]. The matter is currently a topic of [http://lists.xiph.org/pipermail/ogg-dev/2005-November/thread.html heated debate] and is now being voted on'''

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

64 "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] Sampling rate [Hz]
8 [uint] 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 "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.

=== 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 header packets contain additional information about the OggPCM stream. Each extra header is defined as:

32 [uint] Header ID
... Header data

Two examples for such optional extra header packets are the channel mapping and the channel conversion header packets.

==== 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; 0x80000000 and 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 MUST 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).
* 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.

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

== Related Links ==
Short info about AC-3: http://www.mediatwins.com/en/support/kb_topic_11.html

AC-3 spec: http://www.atsc.org/standards/a_52a.pdf 
Note: around p34/140 it appears to be how the channel mapping is encoded.

.wav extended headers for multi channel: http://www.microsoft.com/whdc/device/audio/multichaud.mspx

General surround info: http://www.surroundassociates.com/fqmain.html

OggPCM

2005-11-14T16:23:48Z

Erikd: Tweak justified bits explanation.

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

OggPCM

2005-11-14T16:03:21Z

Erikd: Justify to most significant bits.

== 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 the bit width, the signifcant bits shall be justified to fill the most significant bits.

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

OggPCM

2005-11-14T15:58:42Z

Erikd: Significant bits == 0 means all bits significant.

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

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

Talk:OggPCM Draft1

2005-11-10T08:08:48Z

Erikd: /* Do we want/need the 32-bit data packet header? */

=== 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.
--[[User:Arc|Arc]]

* 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)

* I see no reason to support any unsigned PCM format other than 8 bit. For instance, I know of no container format which supports unsigned 16 bit.
--[[User:Erikd|Erikd]]

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

* Some codecs (Vorbis) use floating point samples natively. Others only support int. Support for int/float data flag is thus important.
--[[User:Arc|Arc]]

* Please don't make determination of the data format depend on multiple fields. Instead use an enumeration so that something like little endian 16 bit PCM can be specifed as OGG_PCM_LE_PCM_16 and big endian 16 bit doubles can be specified as OGG_PCM_BE_FLOAT_64. This scheme is far more transparent and self documenting. If the format field is 8 bits, this scheme supports 256 formats; if its 16 bit it will support 65536 formats.

I also suggest leaving the format associated with a value of zero as an invalid format.
--[[Erikd|Erikd]]

=== Do we need to offer endian data flag? If not, which is used? ===

* LSB/MSB can be changed losslessly, one should probobally be settled on for the data and stick with it. It's a fairly 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''.
--[[User:Arc|Arc]]

* 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)

* I agree that we should use little endian as standard, however, I'm questioning if big endian should be supported as well... after all, it'd be trivial for a plugin to convert from one to another.
--[[User:Arc|Arc]] 13:11, 9 Nov 2005 (PST)

* Big and little endian data formats should both be supported with equal status. There should not even be a default; the endian-ness should be explicit.
--[[User:Erikd|Erikd]]

=== 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.
--[[User:Arc|Arc]]

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

* I'm uncertain exactly what this question is. Hopefully the submitter can clarify?
--[[User:Arc|Arc]] 13:11, 9 Nov 2005 (PST)

* Many file formats (WAV, AIFF, AU and others) support 64 bit float data. WAV stores floats as little endian data and AIFF stores if as big endian data. OggPCM should support both 32 and 64 bit floats of both endian-nesses (is that a word?). I don't know of any other floating point format that needs consideration.
--[[Erikd|Erikd]]

=== 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 MSB's of the next larger byte boundary, round toward zero, on a per channel basis. This should allow software that knows how to handle 16 bit audio but not 10 bit to operate on the data.
--[[User:Jkoleszar|Jkoleszar]] 11:48, 9 Nov 2005 (PST)

* The occurrence of N bit PCM where N is not a multiple of 8 bits is so rare that it should probably be ignored. In addition, there really isn't any reason to treat 10 bit data packed into the 10 most significant bits of a 16 bit int any different from a real 16 bit value. So why make any distinction?
--[[Erikd|Erikd]]

== 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. --[[User:Arc|Arc]]

* 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)

* I believe that 64-bit platforms still use 32-bit memory space (I may be wrong!). Yes, libogg2 buffers should always begin on a 32-bit word boundary, so the beginning of the data should also be on a boundary. This was done intentionally, as was the choice to use a three letter codec identifier for raw codecs (since the packet ID + codec ID = 32bits this way), after an extended IRC discussion on the subject. If ending on a 64-bit boundary is something we're really worried about, we could always add 4 bytes, but I really don't think it should be necessary.
--[[User:Arc|Arc]] 13:11, 9 Nov 2005 (PST)

* On UltraSparc and Alpha CPUs (both 64 bit) accessing a 64 bit double at an address that is not 8 byte aligned causes a segmentation fault. However, accessing unaligned doubles on x86 (ie 32 bit) is slower than accessing aligned doubles. You might want to consider this.
--[[Erikd|Erikd]]

User:Erikd

2005-11-10T02:59:03Z

Erikd:

I'm the main author and maintainer of libsndfile [[http://www.mega-nerd.com/libsndfile/]].

I'm hoping to help out on the specification of [[OggPCM]].

Talk:OggPCM Draft1

2005-11-10T02:55:44Z

Erikd: /* Are samples padded to some round number of bits? */

Talk:OggPCM Draft1

2005-11-10T02:34:44Z

Erikd: /* How does one interpret a file where the Bits per Sample is neither 32 nor 64 and the Data Type is float? */

=== 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.
--[[User:Arc|Arc]]

* 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)

* I see no reason to support any unsigned PCM format other than 8 bit. For instance, I know of no container format which supports unsigned 16 bit.
--[[User:Erikd|Erikd]]

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

* Some codecs (Vorbis) use floating point samples natively. Others only support int. Support for int/float data flag is thus important.
--[[User:Arc|Arc]]

* Please don't make determination of the data format depend on multiple fields. Instead use an enumeration so that something like little endian 16 bit PCM can be specifed as OGG_PCM_LE_PCM_16 and big endian 16 bit doubles can be specified as OGG_PCM_BE_FLOAT_64. This scheme is far more transparent and self documenting. If the format field is 8 bits, this scheme supports 256 formats; if its 16 bit it will support 65536 formats.

I also suggest leaving the format associated with a value of zero as an invalid format.
--[[Erikd|Erikd]]

=== Do we need to offer endian data flag? If not, which is used? ===

* LSB/MSB can be changed losslessly, one should probobally be settled on for the data and stick with it. It's a fairly 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''.
--[[User:Arc|Arc]]

* 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)

* I agree that we should use little endian as standard, however, I'm questioning if big endian should be supported as well... after all, it'd be trivial for a plugin to convert from one to another.
--[[User:Arc|Arc]] 13:11, 9 Nov 2005 (PST)

* Big and little endian data formats should both be supported with equal status. There should not even be a default; the endian-ness should be explicit.
--[[User:Erikd|Erikd]]

=== 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.
--[[User:Arc|Arc]]

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

* I'm uncertain exactly what this question is. Hopefully the submitter can clarify?
--[[User:Arc|Arc]] 13:11, 9 Nov 2005 (PST)

* Many file formats (WAV, AIFF, AU and others) support 64 bit float data. WAV stores floats as little endian data and AIFF stores if as big endian data. OggPCM should support both 32 and 64 bit floats of both endian-nesses (is that a word?). I don't know of any other floating point format that needs consideration.
--[[Erikd|Erikd]]

=== 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 MSB's of the next larger byte boundary, round toward zero, on a per channel basis. This should allow software that knows how to handle 16 bit audio but not 10 bit to operate on the data.
--[[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. --[[User:Arc|Arc]]

* 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)

* I believe that 64-bit platforms still use 32-bit memory space (I may be wrong!). Yes, libogg2 buffers should always begin on a 32-bit word boundary, so the beginning of the data should also be on a boundary. This was done intentionally, as was the choice to use a three letter codec identifier for raw codecs (since the packet ID + codec ID = 32bits this way), after an extended IRC discussion on the subject. If ending on a 64-bit boundary is something we're really worried about, we could always add 4 bytes, but I really don't think it should be necessary.
--[[User:Arc|Arc]] 13:11, 9 Nov 2005 (PST)

Talk:OggPCM Draft1

2005-11-10T01:24:58Z

Erikd: /* Do we need to record int/float data flag? */

=== 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.
--[[User:Arc|Arc]]

* 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)

* I see no reason to support any unsigned PCM format other than 8 bit. For instance, I know of no container format which supports unsigned 16 bit.
--[[User:Erikd|Erikd]]

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

* Some codecs (Vorbis) use floating point samples natively. Others only support int. Support for int/float data flag is thus important.
--[[User:Arc|Arc]]

* Please don't make determination of the data format depend on multiple fields. Instead use an enumeration so that something like little endian 16 bit PCM can be specifed as OGG_PCM_LE_PCM_16 and big endian 16 bit doubles can be specified as OGG_PCM_BE_FLOAT_64. This scheme is far more transparent and self documenting. If the format field is 8 bits, this scheme supports 256 formats; if its 16 bit it will support 65536 formats.

I also suggest leaving the format associated with a value of zero as an invalid format.
--[[Erikd|Erikd]]

=== Do we need to offer endian data flag? If not, which is used? ===

* LSB/MSB can be changed losslessly, one should probobally be settled on for the data and stick with it. It's a fairly 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''.
--[[User:Arc|Arc]]

* 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)

* I agree that we should use little endian as standard, however, I'm questioning if big endian should be supported as well... after all, it'd be trivial for a plugin to convert from one to another.
--[[User:Arc|Arc]] 13:11, 9 Nov 2005 (PST)

* Big and little endian data formats should both be supported with equal status. There should not even be a default; the endian-ness should be explicit.
--[[User:Erikd|Erikd]]

=== 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.
--[[User:Arc|Arc]]

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

* I'm uncertain exactly what this question is. Hopefully the submitter can clarify?
--[[User:Arc|Arc]] 13:11, 9 Nov 2005 (PST)

* Many file formats (WAV, AIFF, AU and others) support 64 bit float data. WAV stores floats as little endian data and AIFF stores if as big endian data. OggPCM should support both.
--[[Erikd|Erikd]]

=== 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 MSB's of the next larger byte boundary, round toward zero, on a per channel basis. This should allow software that knows how to handle 16 bit audio but not 10 bit to operate on the data.
--[[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. --[[User:Arc|Arc]]

* 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)

* I believe that 64-bit platforms still use 32-bit memory space (I may be wrong!). Yes, libogg2 buffers should always begin on a 32-bit word boundary, so the beginning of the data should also be on a boundary. This was done intentionally, as was the choice to use a three letter codec identifier for raw codecs (since the packet ID + codec ID = 32bits this way), after an extended IRC discussion on the subject. If ending on a 64-bit boundary is something we're really worried about, we could always add 4 bytes, but I really don't think it should be necessary.
--[[User:Arc|Arc]] 13:11, 9 Nov 2005 (PST)

Talk:OggPCM Draft1

2005-11-10T00:59:23Z

Erikd: /* How does one interpret a file where the Bits per Sample is neither 32 nor 64 and the Data Type is float? */

=== 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.
--[[User:Arc|Arc]]

* 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)

* I see no reason to support any unsigned PCM format other than 8 bit. For instance, I know of no container format which supports unsigned 16 bit.
--[[User:Erikd|Erikd]]

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

* Some codecs (Vorbis) use floating point samples natively. Others only support int. Support for int/float data flag is thus important.
--[[User:Arc|Arc]]

=== Do we need to offer endian data flag? If not, which is used? ===

* LSB/MSB can be changed losslessly, one should probobally be settled on for the data and stick with it. It's a fairly 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''.
--[[User:Arc|Arc]]

* 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)

* I agree that we should use little endian as standard, however, I'm questioning if big endian should be supported as well... after all, it'd be trivial for a plugin to convert from one to another.
--[[User:Arc|Arc]] 13:11, 9 Nov 2005 (PST)

* Big and little endian data formats should both be supported with equal status. There should not even be a default; the endian-ness should be explicit.
--[[User:Erikd|Erikd]]

=== 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.
--[[User:Arc|Arc]]

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

* I'm uncertain exactly what this question is. Hopefully the submitter can clarify?
--[[User:Arc|Arc]] 13:11, 9 Nov 2005 (PST)

* Many file formats (WAV, AIFF, AU and others) support 64 bit float data. WAV stores floats as little endian data and AIFF stores if as big endian data. OggPCM should support both.
--[[Erikd|Erikd]]

=== 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 MSB's of the next larger byte boundary, round toward zero, on a per channel basis. This should allow software that knows how to handle 16 bit audio but not 10 bit to operate on the data.
--[[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. --[[User:Arc|Arc]]

* 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)

* I believe that 64-bit platforms still use 32-bit memory space (I may be wrong!). Yes, libogg2 buffers should always begin on a 32-bit word boundary, so the beginning of the data should also be on a boundary. This was done intentionally, as was the choice to use a three letter codec identifier for raw codecs (since the packet ID + codec ID = 32bits this way), after an extended IRC discussion on the subject. If ending on a 64-bit boundary is something we're really worried about, we could always add 4 bytes, but I really don't think it should be necessary.
--[[User:Arc|Arc]] 13:11, 9 Nov 2005 (PST)

Talk:OggPCM Draft1

2005-11-10T00:57:26Z

Erikd: /* Do we need to offer endian data flag? If not, which is used? */

=== 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.
--[[User:Arc|Arc]]

* 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)

* I see no reason to support any unsigned PCM format other than 8 bit. For instance, I know of no container format which supports unsigned 16 bit.
--[[User:Erikd|Erikd]]

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

* Some codecs (Vorbis) use floating point samples natively. Others only support int. Support for int/float data flag is thus important.
--[[User:Arc|Arc]]

=== Do we need to offer endian data flag? If not, which is used? ===

* LSB/MSB can be changed losslessly, one should probobally be settled on for the data and stick with it. It's a fairly 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''.
--[[User:Arc|Arc]]

* 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)

* I agree that we should use little endian as standard, however, I'm questioning if big endian should be supported as well... after all, it'd be trivial for a plugin to convert from one to another.
--[[User:Arc|Arc]] 13:11, 9 Nov 2005 (PST)

* Big and little endian data formats should both be supported with equal status. There should not even be a default; the endian-ness should be explicit.
--[[User:Erikd|Erikd]]

=== 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.
--[[User:Arc|Arc]]

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

* I'm uncertain exactly what this question is. Hopefully the submitter can clarify?
--[[User:Arc|Arc]] 13:11, 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 MSB's of the next larger byte boundary, round toward zero, on a per channel basis. This should allow software that knows how to handle 16 bit audio but not 10 bit to operate on the data.
--[[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. --[[User:Arc|Arc]]

* 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)

* I believe that 64-bit platforms still use 32-bit memory space (I may be wrong!). Yes, libogg2 buffers should always begin on a 32-bit word boundary, so the beginning of the data should also be on a boundary. This was done intentionally, as was the choice to use a three letter codec identifier for raw codecs (since the packet ID + codec ID = 32bits this way), after an extended IRC discussion on the subject. If ending on a 64-bit boundary is something we're really worried about, we could always add 4 bytes, but I really don't think it should be necessary.
--[[User:Arc|Arc]] 13:11, 9 Nov 2005 (PST)

Talk:OggPCM Draft1

2005-11-10T00:55:35Z

Erikd: /* Do we need signed/unsigned data flag? */

=== 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.
--[[User:Arc|Arc]]

* 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)

* I see no reason to support any unsigned PCM format other than 8 bit. For instance, I know of no container format which supports unsigned 16 bit.
--[[User:Erikd|Erikd]]

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

* Some codecs (Vorbis) use floating point samples natively. Others only support int. Support for int/float data flag is thus important.
--[[User:Arc|Arc]]

=== Do we need to offer endian data flag? If not, which is used? ===

* LSB/MSB can be changed losslessly, one should probobally be settled on for the data and stick with it. It's a fairly 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''.
--[[User:Arc|Arc]]

* 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)

* I agree that we should use little endian as standard, however, I'm questioning if big endian should be supported as well... after all, it'd be trivial for a plugin to convert from one to another.
--[[User:Arc|Arc]] 13:11, 9 Nov 2005 (PST)

=== 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.
--[[User:Arc|Arc]]

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

* I'm uncertain exactly what this question is. Hopefully the submitter can clarify?
--[[User:Arc|Arc]] 13:11, 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 MSB's of the next larger byte boundary, round toward zero, on a per channel basis. This should allow software that knows how to handle 16 bit audio but not 10 bit to operate on the data.
--[[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. --[[User:Arc|Arc]]

* 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)

* I believe that 64-bit platforms still use 32-bit memory space (I may be wrong!). Yes, libogg2 buffers should always begin on a 32-bit word boundary, so the beginning of the data should also be on a boundary. This was done intentionally, as was the choice to use a three letter codec identifier for raw codecs (since the packet ID + codec ID = 32bits this way), after an extended IRC discussion on the subject. If ending on a 64-bit boundary is something we're really worried about, we could always add 4 bytes, but I really don't think it should be necessary.
--[[User:Arc|Arc]] 13:11, 9 Nov 2005 (PST)