libvorbis-1.1.2.tar.gz

Vorbis I specification

Xiph.org Foundation

Table of Contents

1. Introduction and Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Decoder Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3. High-level Decode Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Bitpacking Convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.2. Header decode and decode setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.3. Audio packet decode and synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5. comment field and header specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.2. Comment encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6. Floor type 0 setup and decode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.2. Floor 0 format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7. Floor type 1 setup and decode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

8.5. residue 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

8.6. Residue decode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

9. Helper equations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

9.2. Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

10. Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

10.1. floor1_inverse_dB_table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

A. Embedding Vorbis into an Ogg stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

A.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

A.1.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

specification

1. Introduction and Description

$Id: 01-introduction.xml 7186 2004-07-20 07:19:25Z xiphmont $

1.1. Overview

This document provides a high level description of the Vorbis codec’s construction. A bit-by-bit specification

appears beginning in Section 4, “Codec Setup and Packet Decode”. The later sections assume a high-level

understanding of the Vorbis decode process, which is provided here.

1.1.1. Application

Vorbis is a general purpose perceptual audio CODEC intended to allow maximum encoder flexibility, thus allowing

it to scale competitively over an exceptionally wide range of bitrates. At the high quality/bitrate end of the scale

Vorbis I is a forward-adaptive monolithic transform CODEC based on the Modified Discrete Cosine Transform.

The codec is structured to allow addition of a hybrid wavelet filterbank in Vorbis II to offer better transient response

and reproduction using a transform better suited to localized time events.

1.1.3. Assumptions

The Vorbis CODEC design assumes a complex, psychoacoustically-aware encoder and simple, low-complexity

decoder. Vorbis decode is computationally simpler than mp3, although it does require more working memory as

Vorbis has no static probability model; the vector codebooks used in the first stage of decoding from the bitstream

are packed in their entirety into the Vorbis bitstream headers. In packed form, these codebooks occupy only a few

kilobytes; the extent to which they are pre-decoded into a cache is the dominant factor in decoder memory usage.

Vorbis provides none of its own framing, synchronization or protection against errors; it is solely a method of

a packet may be any size, or end before or after packet decode expects.

Vorbis packets are thus intended to be used with a transport mechanism that provides free-form framing, sync,

positioning and error correction in accordance with these design assumptions, such as Ogg (for file transport) or

RTP (for network multicast). For purposes of a few examples in this document, we will assume that Vorbis is to

be embedded in an Ogg stream specifically, although this is by no means a requirement or fundamental assumption

in the Vorbis design.

The specification for embedding Vorbis into an Ogg transport stream is in Appendix A, Embedding Vorbis into an

Ogg stream.

1.1.4. Codec Setup and Probability Model

Vorbis’ heritage is as a research CODEC and its current design reflects a desire to allow multiple decades of

specification

begin decode at any frame in the stream without having previously fetched the codec setup header.

Thus, Vorbis headers are both required for decode to begin and relatively large as bitstream headers go. The

header size is unbounded, although for streaming a rule-of-thumb of 4kB or less is recommended (and Xiph.Org’s

Vorbis encoder follows this suggestion).

Our own design work indicates the primary liability of the required header is in mindshare; it is an unusual design

and thus causes some amount of complaint among engineers as this runs against current design trends (and also

points out limitations in some existing software/interface designs, such as Windows’ ACM codec framework).

1.1.6. Hardware Profile

Although Vorbis decode is computationally simple, it may still run into specific limitations of an embedded design.

For this reason, embedded designs are allowed to deviate in limited ways from the ’full’ decode specification yet

still be certified compliant. These optional omissions are labelled in the spec where relevant.

1.2. Decoder Configuration

Decoder setup consists of configuration of multiple, self-contained component abstractions that perform specific

functions in the decode pipeline. Each different component instance of a specific type is semantically

interchangeable; decoder configuration consists both of internal component configuration, as well as arrangement

of specific instances into a decode pipeline. Componentry arrangement is roughly as follows:

3

specification

The mode mechanism is used to encode a frame according to one of multiple possible methods with the intention

of choosing a method best suited to that frame. Different modes are, e.g. how frame size is changed from frame

to frame. The mode number of a frame serves as a top level configuration switch for all other specific aspects of

frame decode.

A ’mode’ configuration consists of a frame size setting, window type (always 0, the Vorbis window, in Vorbis I),

transform type (always type 0, the MDCT, in Vorbis I) and a mapping number. The mapping number specifies

which mapping configuration instance to use for low-level packet decode and synthesis.

1.2.3. Mapping

A mapping contains a channel coupling description and a list of ’submaps’ that bundle sets of channel vectors

together for grouped encoding and decoding. These submaps are not references to external components; the

As an example:

Assume a Vorbis stream that contains six channels in the standard 5.1 format. The sixth channel, as is normal in

5.1, is bass only. Therefore it would be wasteful to encode a full-spectrum version of it as with the other channels.

The submapping mechanism can be used to apply a full range floor and residue encoding to channels 0 through

4, and a bass-only representation to the bass channel, thus saving space. In this example, channels 0-4 belong to

submap 0 (which indicates use of a full-range floor) and channel 5 belongs to submap 1, which uses a bass-only

representation.

1.2.4. Floor

Vorbis encodes a spectral ’floor’ vector for each PCM channel. This vector is a low-resolution representation

of the audio spectrum for the given channel in the current frame, generally used akin to a whitening filter. It

specification

5