165 lines
7.1 KiB
HTML
165 lines
7.1 KiB
HTML
<HTML><HEAD><TITLE>xiph.org: Ogg Vorbis documentation</TITLE>
|
|
<BODY bgcolor="#ffffff" text="#202020" link="#006666" vlink="#000000">
|
|
<nobr><img src="white-ogg.png"><img src="vorbisword2.png"></nobr><p>
|
|
|
|
<h1><font color=#000070>
|
|
Ogg Vorbis I format specification: embedding Vorbis into an Ogg stream
|
|
</font></h1>
|
|
|
|
<em>Last update to this document: July 14, 2002</em><br>
|
|
|
|
<h1>Overview</h1>
|
|
|
|
This document describes using Ogg logical and physical transport
|
|
streams to encapsulate Vorbis compressed audio packet data into file
|
|
form.<p>
|
|
|
|
_<a href="vorbis-spec-intro.html">Ogg Vorbis I format specification:
|
|
high-level description</a>_ provides an overview of the construction
|
|
of Vorbis audio packets.<p> The _<a href="oggstream.html">Ogg
|
|
bitstream overview</a>_ and <a href="framing.html">Ogg logical
|
|
bitstream and framing spec</a>_ provide detailed descriptions of Ogg
|
|
transport streams. This specification document assumes a working
|
|
knowledge of the concepts covered in these named backround
|
|
documents. Please read them first.<p>
|
|
|
|
|
|
<h2>Restrictions</h2>
|
|
|
|
The Ogg/Vorbis I specification currently dictates that Ogg/Vorbis
|
|
streams use Ogg transport streams in degenerate, unmultiplexed
|
|
form only. That is:
|
|
|
|
<ul>
|
|
<li>A meta-headerless Ogg file encapsulates the Vorbis I packets
|
|
<li>The Ogg stream may be chained, i.e. contain multiple, contigous logical streams (links).
|
|
<li>The Ogg stream must be unmultiplexed (only one stream, a Vorbis audio stream, per link)
|
|
</ul>
|
|
|
|
This is not to say that it is not currently possible to multiplex
|
|
Vorbis with other media types into a multi-stream Ogg file. At the
|
|
time this document was written, Ogg was becoming a popular container
|
|
for low-bitrate movies consisting of DiVX video and Vorbis audio.
|
|
However, a 'Vorbis I audio file' is taken to imply Vorbis audio
|
|
existing alone within a degenerate Ogg stream. A compliant 'Vorbis
|
|
audio player' is not required to implement Ogg support beyond the
|
|
specific support of Vorbis within a degenrate ogg stream (naturally,
|
|
application authors are encouraged to support full multiplexed Ogg
|
|
handling).
|
|
<p>
|
|
|
|
<h2>MIME type</h2>
|
|
|
|
The correct MIME type of any Ogg file is <tt>application/x-ogg</tt>.
|
|
However, if a file is a Vorbis I audio file (which implies a
|
|
degenerate Ogg stream including only unmultiplexed Vorbis audio), the
|
|
mime type <tt>audio/x-vorbis</tt> is also allowed.
|
|
|
|
<h1>Encapsulation</h1>
|
|
|
|
Ogg encapsulation of a Vorbis packet stream is straightforward.<p>
|
|
|
|
<ul>
|
|
<li>The first Vorbis packet [the indentification header], which
|
|
uniquely identifies a stream as Vorbis audio, is placed alone in the
|
|
first page of the logical Ogg stream. This results in a first Ogg
|
|
page of exactly 58 bytes at the very beginning of the logical stream.<p>
|
|
|
|
<li>This first page is marked 'beginning of stream' in the page flags.<p>
|
|
|
|
<li>The second and third vorbis packets [comment and setup
|
|
headers] may span one or more pages beginning on the second page of
|
|
the logical stream. However many pages they span, the third header
|
|
packet finishes the page on which it ends. The next [first audio] packet
|
|
must begin on a fresh page.<p>
|
|
|
|
<li>The granule position of these first pages containing only headers is
|
|
zero.<p>
|
|
|
|
<li>The first audio packet of the logical stream begins a fresh Ogg page.<p>
|
|
|
|
<li>Packets are placed into ogg pages in order until the end of stream.<p>
|
|
|
|
<li>The last page is marked 'end of stream' in the page flags.<p>
|
|
|
|
<li>Vorbis packets may span page boundaries. <p>
|
|
|
|
<li>The granule position of pages contining Vorbis audio is in units
|
|
of PCM audio samples (per channel; a stereo stream's granule position
|
|
does no increment at twice the speed of a mono stream).<p>
|
|
|
|
<li>The granule position of a page represents the end PCM sample
|
|
position of the last packet <em>completed</em> on that page. A page
|
|
that is entirely spanned by a single packet (that completes on a
|
|
subsequent page) has no granule position, and the granule position is
|
|
set to '-1'.<p>
|
|
|
|
<li>The granule (PCM) position of the first page need not indicate
|
|
that the stream started at position zero. Although the granule
|
|
position belongs to the last completed packet on the page and a
|
|
valid granule position must be positive, by
|
|
inference it may indicate that the PCM position of the beginning
|
|
of audio is positive or negative.<p>
|
|
|
|
<ul>
|
|
<li>A positive starting value simply indicates that this stream begins at
|
|
some positive time offset, potentially within a larger
|
|
program. This is a common case when connecting to the middle
|
|
of broadcast stream.<p> <li>A negative value indicates that
|
|
output samples preceeding time zero should be discarded during
|
|
decoding; this technique is used to allow sample-granularity
|
|
editing of the stream start time of already-encoded Vorbis
|
|
streams. The number of samples to be discarded must not exceed
|
|
the overlap-add span of the first two audio packets.<p>
|
|
</uL>
|
|
In both of these cases in which the initial audio PCM starting
|
|
offset is nonzero, the second finished audio packet must flush the
|
|
page on which it appears and the third packet begin a fresh page.
|
|
This allows the decoder to always be able to perform PCM position
|
|
adjustments before needing to return any PCM data from synthesis,
|
|
resulting in correct positioning information without any aditional
|
|
seeking logic.<p>
|
|
|
|
(Note however that failure to do so should, at worst, cause a
|
|
decoder implementation to return incorrect positioning information
|
|
for seeking operations at the very beginning of the stream.)<p>
|
|
|
|
<li> A granule position on the final page in a stream that indicates
|
|
less audio data than the final packet would normally return is used to
|
|
end the stream on other than even frame boundaries. The difference
|
|
between the actual available data returned and the declared amount
|
|
indicates how many trailing samples to discard from the decoding
|
|
process.<p>
|
|
</ul>
|
|
<hr>
|
|
<a href="http://www.xiph.org/">
|
|
<img src="white-xifish.png" align=left border=0>
|
|
</a>
|
|
<font size=-2 color=#505050>
|
|
|
|
Ogg is a <a href="http://www.xiph.org">Xiph.org Foundation</a> effort
|
|
to protect essential tenets of Internet multimedia from corporate
|
|
hostage-taking; Open Source is the net's greatest tool to keep
|
|
everyone honest. See <a href="http://www.xiph.org/about.html">About
|
|
the Xiph.org Foundation</a> for details.
|
|
<p>
|
|
|
|
Ogg Vorbis is the first Ogg audio CODEC. Anyone may freely use and
|
|
distribute the Ogg and Vorbis specification, whether in a private,
|
|
public or corporate capacity. However, the Xiph.org Foundation and
|
|
the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis
|
|
specification and certify specification compliance.<p>
|
|
|
|
Xiph.org's Vorbis software CODEC implementation is distributed under a
|
|
BSD-like license. This does not restrict third parties from
|
|
distributing independent implementations of Vorbis software under
|
|
other licenses.<p>
|
|
|
|
Ogg, Vorbis, Xiph.org Foundation and their logos are trademarks (tm)
|
|
of the <a href="http://www.xiph.org/">Xiph.org Foundation</a>. These
|
|
pages are copyright (C) 1994-2002 Xiph.org Foundation. All rights
|
|
reserved.<p>
|
|
|
|
</body>
|
|
|