OggPCM Draft1: Difference between revisions
(→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