OggPCM Draft1: Difference between revisions

From XiphWiki
Jump to navigation Jump to search
(→‎Why is it: removing narrative intro)
m (Specified byte ordering)
Line 13: Line 13:
== Format ==
== Format ==


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.
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. Multibyte fields in the header packet are packed in big endian order. Multibyte fields in the data packet are packed in little endian order.


An example of how this can be useful is the proposed ReplayGain extension to .wav format: http://replaygain.hydrogenaudio.org/file_format_wav.html
An example of how this can be useful is the proposed ReplayGain extension to .wav format: http://replaygain.hydrogenaudio.org/file_format_wav.html

Revision as of 11:59, 9 November 2005

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.


Why is it

The intention for this format is as an interchange format, especially for use with OggStream. It is also useful for storing time-synced decoded audio/video for development, vs RIFF/WAV (.wav) and YUV4MPEG (.yuv) in seperate files as we did with Theora.

It is also less complex than either .wav (RIFF) or .aiff (AIFF), both of these formats being designed for generic multimedia (audio, video, etc). Full compatability with these formats includes support for non-PCM data.

Using raw PCM data, on the other hand, doesn't give us that all-important header which carries information about the number of channels, sample width, and sample frequency. So what we need is a header followed by raw PCM data - nothing more complicated.

Format

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. Multibyte fields in the header packet are packed in big endian order. Multibyte fields in the data packet are packed in little endian order.

An example of how this can be useful is the proposed ReplayGain extension to .wav format: http://replaygain.hydrogenaudio.org/file_format_wav.html

Note that no such extension is planned, nor is the need for a future format forseen, but history has shown that even the most basic formats eventually become obsolete.

Packet 0, BOS, 12 bytes
 8  0x00       Header Packet ID
24  "PCM"      Codec identifier 
 8  0x01       Version Major (breaks backwards compatability to increment)
 8  0x00       Version Minor (backwards compatable, ie, via extended header)
 8  [variable] Number of Channels
 8  [variable] Bits per Sample
24  [variable] Samples per Second
 2  [variable] Data Type: 0=signed int, 1=unsigned int, 2=float, 3=extended
 6  [null]     Padding to byte/int - may be used for "extended" data type
Data Packet
 8  0xFF       Data Packet ID
24  "PCM"      Codec identifier, pads data to 32-bits
..  [data]     variable length pcm data