OggPCM Draft1: Difference between revisions
(→Format) |
|||
| Line 8: | Line 8: | ||
You're probobally thinking, this is pretty redundant, eh? Well, yes, it is. We have FLAC and, of course, there's .wav and .aiff files when you don't want to go through the hassle of losslessly compressing it. | You're probobally thinking, this is pretty redundant, eh? Well, yes, it is. We have FLAC and, of course, there's .wav and .aiff files when you don't want to go through the hassle of losslessly compressing 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. | 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. | 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 == | == Format == | ||
Revision as of 21:31, 7 December 2004
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
You're probobally thinking, this is pretty redundant, eh? Well, yes, it is. We have FLAC and, of course, there's .wav and .aiff files when you don't want to go through the hassle of losslessly compressing 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.
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