
Chris@1: % -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*-
Chris@1: %!TEX root = Vorbis_I_spec.tex
Chris@1: % $Id$
Chris@1: \section{Introduction and Description} \label{vorbis:spec:intro}
Chris@1: 
Chris@1: \subsection{Overview}
Chris@1: 
Chris@1: This document provides a high level description of the Vorbis codec's
Chris@1: construction.  A bit-by-bit specification appears beginning in
Chris@1: \xref{vorbis:spec:codec}.
Chris@1: The later sections assume a high-level
Chris@1: understanding of the Vorbis decode process, which is
Chris@1: provided here.
Chris@1: 
Chris@1: \subsubsection{Application}
Chris@1: Vorbis is a general purpose perceptual audio CODEC intended to allow
Chris@1: maximum encoder flexibility, thus allowing it to scale competitively
Chris@1: over an exceptionally wide range of bitrates.  At the high
Chris@1: quality/bitrate end of the scale (CD or DAT rate stereo, 16/24 bits)
Chris@1: it is in the same league as MPEG-2 and MPC.  Similarly, the 1.0
Chris@1: encoder can encode high-quality CD and DAT rate stereo at below 48kbps
Chris@1: without resampling to a lower rate.  Vorbis is also intended for
Chris@1: lower and higher sample rates (from 8kHz telephony to 192kHz digital
Chris@1: masters) and a range of channel representations (monaural,
Chris@1: polyphonic, stereo, quadraphonic, 5.1, ambisonic, or up to 255
Chris@1: discrete channels).
Chris@1: 
Chris@1: 
Chris@1: \subsubsection{Classification}
Chris@1: Vorbis I is a forward-adaptive monolithic transform CODEC based on the
Chris@1: Modified Discrete Cosine Transform.  The codec is structured to allow
Chris@1: addition of a hybrid wavelet filterbank in Vorbis II to offer better
Chris@1: transient response and reproduction using a transform better suited to
Chris@1: localized time events.
Chris@1: 
Chris@1: 
Chris@1: \subsubsection{Assumptions}
Chris@1: 
Chris@1: The Vorbis CODEC design assumes a complex, psychoacoustically-aware
Chris@1: encoder and simple, low-complexity decoder. Vorbis decode is
Chris@1: computationally simpler than mp3, although it does require more
Chris@1: working memory as Vorbis has no static probability model; the vector
Chris@1: codebooks used in the first stage of decoding from the bitstream are
Chris@1: packed in their entirety into the Vorbis bitstream headers. In
Chris@1: packed form, these codebooks occupy only a few kilobytes; the extent
Chris@1: to which they are pre-decoded into a cache is the dominant factor in
Chris@1: decoder memory usage.
Chris@1: 
Chris@1: 
Chris@1: Vorbis provides none of its own framing, synchronization or protection
Chris@1: against errors; it is solely a method of accepting input audio,
Chris@1: dividing it into individual frames and compressing these frames into
Chris@1: raw, unformatted 'packets'. The decoder then accepts these raw
Chris@1: packets in sequence, decodes them, synthesizes audio frames from
Chris@1: them, and reassembles the frames into a facsimile of the original
Chris@1: audio stream. Vorbis is a free-form variable bit rate (VBR) codec and packets have no
Chris@1: minimum size, maximum size, or fixed/expected size.  Packets
Chris@1: are designed that they may be truncated (or padded) and remain
Chris@1: decodable; this is not to be considered an error condition and is used
Chris@1: extensively in bitrate management in peeling.  Both the transport
Chris@1: mechanism and decoder must allow that a packet may be any size, or
Chris@1: end before or after packet decode expects.
Chris@1: 
Chris@1: Vorbis packets are thus intended to be used with a transport mechanism
Chris@1: that provides free-form framing, sync, positioning and error correction
Chris@1: in accordance with these design assumptions, such as Ogg (for file
Chris@1: transport) or RTP (for network multicast).  For purposes of a few
Chris@1: examples in this document, we will assume that Vorbis is to be
Chris@1: embedded in an Ogg stream specifically, although this is by no means a
Chris@1: requirement or fundamental assumption in the Vorbis design.
Chris@1: 
Chris@1: The specification for embedding Vorbis into
Chris@1: an Ogg transport stream is in \xref{vorbis:over:ogg}.
Chris@1: 
Chris@1: 
Chris@1: 
Chris@1: \subsubsection{Codec Setup and Probability Model}
Chris@1: 
Chris@1: Vorbis' heritage is as a research CODEC and its current design
Chris@1: reflects a desire to allow multiple decades of continuous encoder
Chris@1: improvement before running out of room within the codec specification.
Chris@1: For these reasons, configurable aspects of codec setup intentionally
Chris@1: lean toward the extreme of forward adaptive.
Chris@1: 
Chris@1: The single most controversial design decision in Vorbis (and the most
Chris@1: unusual for a Vorbis developer to keep in mind) is that the entire
Chris@1: probability model of the codec, the Huffman and VQ codebooks, is
Chris@1: packed into the bitstream header along with extensive CODEC setup
Chris@1: parameters (often several hundred fields).  This makes it impossible,
Chris@1: as it would be with MPEG audio layers, to embed a simple frame type
Chris@1: flag in each audio packet, or begin decode at any frame in the stream
Chris@1: without having previously fetched the codec setup header.
Chris@1: 
Chris@1: 
Chris@1: \begin{note}
Chris@1: Vorbis \emph{can} initiate decode at any arbitrary packet within a
Chris@1: bitstream so long as the codec has been initialized/setup with the
Chris@1: setup headers.
Chris@1: \end{note}
Chris@1: 
Chris@1: Thus, Vorbis headers are both required for decode to begin and
Chris@1: relatively large as bitstream headers go.  The header size is
Chris@1: unbounded, although for streaming a rule-of-thumb of 4kB or less is
Chris@1: recommended (and Xiph.Org's Vorbis encoder follows this suggestion).
Chris@1: 
Chris@1: Our own design work indicates the primary liability of the
Chris@1: required header is in mindshare; it is an unusual design and thus
Chris@1: causes some amount of complaint among engineers as this runs against
Chris@1: current design trends (and also points out limitations in some
Chris@1: existing software/interface designs, such as Windows' ACM codec
Chris@1: framework).  However, we find that it does not fundamentally limit
Chris@1: Vorbis' suitable application space.
Chris@1: 
Chris@1: 
Chris@1: \subsubsection{Format Specification}
Chris@1: The Vorbis format is well-defined by its decode specification; any
Chris@1: encoder that produces packets that are correctly decoded by the
Chris@1: reference Vorbis decoder described below may be considered a proper
Chris@1: Vorbis encoder.  A decoder must faithfully and completely implement
Chris@1: the specification defined below (except where noted) to be considered
Chris@1: a proper Vorbis decoder.
Chris@1: 
Chris@1: \subsubsection{Hardware Profile}
Chris@1: Although Vorbis decode is computationally simple, it may still run
Chris@1: into specific limitations of an embedded design.  For this reason,
Chris@1: embedded designs are allowed to deviate in limited ways from the
Chris@1: `full' decode specification yet still be certified compliant.  These
Chris@1: optional omissions are labelled in the spec where relevant.
Chris@1: 
Chris@1: 
Chris@1: \subsection{Decoder Configuration}
Chris@1: 
Chris@1: Decoder setup consists of configuration of multiple, self-contained
Chris@1: component abstractions that perform specific functions in the decode
Chris@1: pipeline.  Each different component instance of a specific type is
Chris@1: semantically interchangeable; decoder configuration consists both of
Chris@1: internal component configuration, as well as arrangement of specific
Chris@1: instances into a decode pipeline.  Componentry arrangement is roughly
Chris@1: as follows:
Chris@1: 
Chris@1: \begin{center}
Chris@1: \includegraphics[width=\textwidth]{components}
Chris@1: \captionof{figure}{decoder pipeline configuration}
Chris@1: \end{center}
Chris@1: 
Chris@1: \subsubsection{Global Config}
Chris@1: Global codec configuration consists of a few audio related fields
Chris@1: (sample rate, channels), Vorbis version (always '0' in Vorbis I),
Chris@1: bitrate hints, and the lists of component instances.  All other
Chris@1: configuration is in the context of specific components.
Chris@1: 
Chris@1: \subsubsection{Mode}
Chris@1: 
Chris@1: Each Vorbis frame is coded according to a master 'mode'.  A bitstream
Chris@1: may use one or many modes.
Chris@1: 
Chris@1: The mode mechanism is used to encode a frame according to one of
Chris@1: multiple possible methods with the intention of choosing a method best
Chris@1: suited to that frame.  Different modes are, e.g. how frame size
Chris@1: is changed from frame to frame. The mode number of a frame serves as a
Chris@1: top level configuration switch for all other specific aspects of frame
Chris@1: decode.
Chris@1: 
Chris@1: A 'mode' configuration consists of a frame size setting, window type
Chris@1: (always 0, the Vorbis window, in Vorbis I), transform type (always
Chris@1: type 0, the MDCT, in Vorbis I) and a mapping number.  The mapping
Chris@1: number specifies which mapping configuration instance to use for
Chris@1: low-level packet decode and synthesis.
Chris@1: 
Chris@1: 
Chris@1: \subsubsection{Mapping}
Chris@1: 
Chris@1: A mapping contains a channel coupling description and a list of
Chris@1: 'submaps' that bundle sets of channel vectors together for grouped
Chris@1: encoding and decoding. These submaps are not references to external
Chris@1: components; the submap list is internal and specific to a mapping.
Chris@1: 
Chris@1: A 'submap' is a configuration/grouping that applies to a subset of
Chris@1: floor and residue vectors within a mapping.  The submap functions as a
Chris@1: last layer of indirection such that specific special floor or residue
Chris@1: settings can be applied not only to all the vectors in a given mode,
Chris@1: but also specific vectors in a specific mode.  Each submap specifies
Chris@1: the proper floor and residue instance number to use for decoding that
Chris@1: submap's spectral floor and spectral residue vectors.
Chris@1: 
Chris@1: As an example:
Chris@1: 
Chris@1: Assume a Vorbis stream that contains six channels in the standard 5.1
Chris@1: format.  The sixth channel, as is normal in 5.1, is bass only.
Chris@1: Therefore it would be wasteful to encode a full-spectrum version of it
Chris@1: as with the other channels.  The submapping mechanism can be used to
Chris@1: apply a full range floor and residue encoding to channels 0 through 4,
Chris@1: and a bass-only representation to the bass channel, thus saving space.
Chris@1: In this example, channels 0-4 belong to submap 0 (which indicates use
Chris@1: of a full-range floor) and channel 5 belongs to submap 1, which uses a
Chris@1: bass-only representation.
Chris@1: 
Chris@1: 
Chris@1: \subsubsection{Floor}
Chris@1: 
Chris@1: Vorbis encodes a spectral 'floor' vector for each PCM channel.  This
Chris@1: vector is a low-resolution representation of the audio spectrum for
Chris@1: the given channel in the current frame, generally used akin to a
Chris@1: whitening filter.  It is named a 'floor' because the Xiph.Org
Chris@1: reference encoder has historically used it as a unit-baseline for
Chris@1: spectral resolution.
Chris@1: 
Chris@1: A floor encoding may be of two types.  Floor 0 uses a packed LSP
Chris@1: representation on a dB amplitude scale and Bark frequency scale.
Chris@1: Floor 1 represents the curve as a piecewise linear interpolated
Chris@1: representation on a dB amplitude scale and linear frequency scale.
Chris@1: The two floors are semantically interchangeable in
Chris@1: encoding/decoding. However, floor type 1 provides more stable
Chris@1: inter-frame behavior, and so is the preferred choice in all
Chris@1: coupled-stereo and high bitrate modes.  Floor 1 is also considerably
Chris@1: less expensive to decode than floor 0.
Chris@1: 
Chris@1: Floor 0 is not to be considered deprecated, but it is of limited
Chris@1: modern use.  No known Vorbis encoder past Xiph.Org's own beta 4 makes
Chris@1: use of floor 0.
Chris@1: 
Chris@1: The values coded/decoded by a floor are both compactly formatted and
Chris@1: make use of entropy coding to save space.  For this reason, a floor
Chris@1: configuration generally refers to multiple codebooks in the codebook
Chris@1: component list.  Entropy coding is thus provided as an abstraction,
Chris@1: and each floor instance may choose from any and all available
Chris@1: codebooks when coding/decoding.
Chris@1: 
Chris@1: 
Chris@1: \subsubsection{Residue}
Chris@1: The spectral residue is the fine structure of the audio spectrum
Chris@1: once the floor curve has been subtracted out.  In simplest terms, it
Chris@1: is coded in the bitstream using cascaded (multi-pass) vector
Chris@1: quantization according to one of three specific packing/coding
Chris@1: algorithms numbered 0 through 2.  The packing algorithm details are
Chris@1: configured by residue instance.  As with the floor components, the
Chris@1: final VQ/entropy encoding is provided by external codebook instances
Chris@1: and each residue instance may choose from any and all available
Chris@1: codebooks.
Chris@1: 
Chris@1: \subsubsection{Codebooks}
Chris@1: 
Chris@1: Codebooks are a self-contained abstraction that perform entropy
Chris@1: decoding and, optionally, use the entropy-decoded integer value as an
Chris@1: offset into an index of output value vectors, returning the indicated
Chris@1: vector of values.
Chris@1: 
Chris@1: The entropy coding in a Vorbis I codebook is provided by a standard
Chris@1: Huffman binary tree representation.  This tree is tightly packed using
Chris@1: one of several methods, depending on whether codeword lengths are
Chris@1: ordered or unordered, or the tree is sparse.
Chris@1: 
Chris@1: The codebook vector index is similarly packed according to index
Chris@1: characteristic.  Most commonly, the vector index is encoded as a
Chris@1: single list of values of possible values that are then permuted into
Chris@1: a list of n-dimensional rows (lattice VQ).
Chris@1: 
Chris@1: 
Chris@1: 
Chris@1: \subsection{High-level Decode Process}
Chris@1: 
Chris@1: \subsubsection{Decode Setup}
Chris@1: 
Chris@1: Before decoding can begin, a decoder must initialize using the
Chris@1: bitstream headers matching the stream to be decoded.  Vorbis uses
Chris@1: three header packets; all are required, in-order, by this
Chris@1: specification. Once set up, decode may begin at any audio packet
Chris@1: belonging to the Vorbis stream. In Vorbis I, all packets after the
Chris@1: three initial headers are audio packets.
Chris@1: 
Chris@1: The header packets are, in order, the identification
Chris@1: header, the comments header, and the setup header.
Chris@1: 
Chris@1: \paragraph{Identification Header}
Chris@1: The identification header identifies the bitstream as Vorbis, Vorbis
Chris@1: version, and the simple audio characteristics of the stream such as
Chris@1: sample rate and number of channels.
Chris@1: 
Chris@1: \paragraph{Comment Header}
Chris@1: The comment header includes user text comments (``tags'') and a vendor
Chris@1: string for the application/library that produced the bitstream.  The
Chris@1: encoding and proper use of the comment header is described in \xref{vorbis:spec:comment}.
Chris@1: 
Chris@1: \paragraph{Setup Header}
Chris@1: The setup header includes extensive CODEC setup information as well as
Chris@1: the complete VQ and Huffman codebooks needed for decode.
Chris@1: 
Chris@1: 
Chris@1: \subsubsection{Decode Procedure}
Chris@1: 
Chris@1: The decoding and synthesis procedure for all audio packets is
Chris@1: fundamentally the same.
Chris@1: \begin{enumerate}
Chris@1: \item decode packet type flag
Chris@1: \item decode mode number
Chris@1: \item decode window shape (long windows only)
Chris@1: \item decode floor
Chris@1: \item decode residue into residue vectors
Chris@1: \item inverse channel coupling of residue vectors
Chris@1: \item generate floor curve from decoded floor data
Chris@1: \item compute dot product of floor and residue, producing audio spectrum vector
Chris@1: \item inverse monolithic transform of audio spectrum vector, always an MDCT in Vorbis I
Chris@1: \item overlap/add left-hand output of transform with right-hand output of previous frame
Chris@1: \item store right hand-data from transform of current frame for future lapping
Chris@1: \item if not first frame, return results of overlap/add as audio result of current frame
Chris@1: \end{enumerate}
Chris@1: 
Chris@1: Note that clever rearrangement of the synthesis arithmetic is
Chris@1: possible; as an example, one can take advantage of symmetries in the
Chris@1: MDCT to store the right-hand transform data of a partial MDCT for a
Chris@1: 50\% inter-frame buffer space savings, and then complete the transform
Chris@1: later before overlap/add with the next frame.  This optimization
Chris@1: produces entirely equivalent output and is naturally perfectly legal.
Chris@1: The decoder must be \emph{entirely mathematically equivalent} to the
Chris@1: specification, it need not be a literal semantic implementation.
Chris@1: 
Chris@1: \paragraph{Packet type decode}
Chris@1: 
Chris@1: Vorbis I uses four packet types. The first three packet types mark each
Chris@1: of the three Vorbis headers described above. The fourth packet type
Chris@1: marks an audio packet. All other packet types are reserved; packets
Chris@1: marked with a reserved type should be ignored.
Chris@1: 
Chris@1: Following the three header packets, all packets in a Vorbis I stream
Chris@1: are audio.  The first step of audio packet decode is to read and
Chris@1: verify the packet type; \emph{a non-audio packet when audio is expected
Chris@1: indicates stream corruption or a non-compliant stream. The decoder
Chris@1: must ignore the packet and not attempt decoding it to
Chris@1: audio}.
Chris@1: 
Chris@1: 
Chris@1: 
Chris@1: 
Chris@1: \paragraph{Mode decode}
Chris@1: Vorbis allows an encoder to set up multiple, numbered packet 'modes',
Chris@1: as described earlier, all of which may be used in a given Vorbis
Chris@1: stream. The mode is encoded as an integer used as a direct offset into
Chris@1: the mode instance index.
Chris@1: 
Chris@1: 
Chris@1: \paragraph{Window shape decode (long windows only)} \label{vorbis:spec:window}
Chris@1: 
Chris@1: Vorbis frames may be one of two PCM sample sizes specified during
Chris@1: codec setup.  In Vorbis I, legal frame sizes are powers of two from 64
Chris@1: to 8192 samples.  Aside from coupling, Vorbis handles channels as
Chris@1: independent vectors and these frame sizes are in samples per channel.
Chris@1: 
Chris@1: Vorbis uses an overlapping transform, namely the MDCT, to blend one
Chris@1: frame into the next, avoiding most inter-frame block boundary
Chris@1: artifacts.  The MDCT output of one frame is windowed according to MDCT
Chris@1: requirements, overlapped 50\% with the output of the previous frame and
Chris@1: added.  The window shape assures seamless reconstruction.
Chris@1: 
Chris@1: This is easy to visualize in the case of equal sized-windows:
Chris@1: 
Chris@1: \begin{center}
Chris@1: \includegraphics[width=\textwidth]{window1}
Chris@1: \captionof{figure}{overlap of two equal-sized windows}
Chris@1: \end{center}
Chris@1: 
Chris@1: And slightly more complex in the case of overlapping unequal sized
Chris@1: windows:
Chris@1: 
Chris@1: \begin{center}
Chris@1: \includegraphics[width=\textwidth]{window2}
Chris@1: \captionof{figure}{overlap of a long and a short window}
Chris@1: \end{center}
Chris@1: 
Chris@1: In the unequal-sized window case, the window shape of the long window
Chris@1: must be modified for seamless lapping as above.  It is possible to
Chris@1: correctly infer window shape to be applied to the current window from
Chris@1: knowing the sizes of the current, previous and next window.  It is
Chris@1: legal for a decoder to use this method. However, in the case of a long
Chris@1: window (short windows require no modification), Vorbis also codes two
Chris@1: flag bits to specify pre- and post- window shape.  Although not
Chris@1: strictly necessary for function, this minor redundancy allows a packet
Chris@1: to be fully decoded to the point of lapping entirely independently of
Chris@1: any other packet, allowing easier abstraction of decode layers as well
Chris@1: as allowing a greater level of easy parallelism in encode and
Chris@1: decode.
Chris@1: 
Chris@1: A description of valid window functions for use with an inverse MDCT
Chris@1: can be found in \cite{Sporer/Brandenburg/Edler}.  Vorbis windows
Chris@1: all use the slope function
Chris@1: \[ y = \sin(.5*\pi \, \sin^2((x+.5)/n*\pi)) . \]
Chris@1: 
Chris@1: 
Chris@1: 
Chris@1: \paragraph{floor decode}
Chris@1: Each floor is encoded/decoded in channel order, however each floor
Chris@1: belongs to a 'submap' that specifies which floor configuration to
Chris@1: use.  All floors are decoded before residue decode begins.
Chris@1: 
Chris@1: 
Chris@1: \paragraph{residue decode}
Chris@1: 
Chris@1: Although the number of residue vectors equals the number of channels,
Chris@1: channel coupling may mean that the raw residue vectors extracted
Chris@1: during decode do not map directly to specific channels.  When channel
Chris@1: coupling is in use, some vectors will correspond to coupled magnitude
Chris@1: or angle.  The coupling relationships are described in the codec setup
Chris@1: and may differ from frame to frame, due to different mode numbers.
Chris@1: 
Chris@1: Vorbis codes residue vectors in groups by submap; the coding is done
Chris@1: in submap order from submap 0 through n-1.  This differs from floors
Chris@1: which are coded using a configuration provided by submap number, but
Chris@1: are coded individually in channel order.
Chris@1: 
Chris@1: 
Chris@1: 
Chris@1: \paragraph{inverse channel coupling}
Chris@1: 
Chris@1: A detailed discussion of stereo in the Vorbis codec can be found in
Chris@1: the document \href{stereo.html}{Stereo Channel Coupling in the
Chris@1: Vorbis CODEC}.  Vorbis is not limited to only stereo coupling, but
Chris@1: the stereo document also gives a good overview of the generic coupling
Chris@1: mechanism.
Chris@1: 
Chris@1: Vorbis coupling applies to pairs of residue vectors at a time;
Chris@1: decoupling is done in-place a pair at a time in the order and using
Chris@1: the vectors specified in the current mapping configuration.  The
Chris@1: decoupling operation is the same for all pairs, converting square
Chris@1: polar representation (where one vector is magnitude and the second
Chris@1: angle) back to Cartesian representation.
Chris@1: 
Chris@1: After decoupling, in order, each pair of vectors on the coupling list,
Chris@1: the resulting residue vectors represent the fine spectral detail
Chris@1: of each output channel.
Chris@1: 
Chris@1: 
Chris@1: 
Chris@1: \paragraph{generate floor curve}
Chris@1: 
Chris@1: The decoder may choose to generate the floor curve at any appropriate
Chris@1: time.  It is reasonable to generate the output curve when the floor
Chris@1: data is decoded from the raw packet, or it can be generated after
Chris@1: inverse coupling and applied to the spectral residue directly,
Chris@1: combining generation and the dot product into one step and eliminating
Chris@1: some working space.
Chris@1: 
Chris@1: Both floor 0 and floor 1 generate a linear-range, linear-domain output
Chris@1: vector to be multiplied (dot product) by the linear-range,
Chris@1: linear-domain spectral residue.
Chris@1: 
Chris@1: 
Chris@1: 
Chris@1: \paragraph{compute floor/residue dot product}
Chris@1: 
Chris@1: This step is straightforward; for each output channel, the decoder
Chris@1: multiplies the floor curve and residue vectors element by element,
Chris@1: producing the finished audio spectrum of each channel.
Chris@1: 
Chris@1: % TODO/FIXME: The following two paragraphs have identical twins
Chris@1: %   in section 4 (under "dot product")
Chris@1: One point is worth mentioning about this dot product; a common mistake
Chris@1: in a fixed point implementation might be to assume that a 32 bit
Chris@1: fixed-point representation for floor and residue and direct
Chris@1: multiplication of the vectors is sufficient for acceptable spectral
Chris@1: depth in all cases because it happens to mostly work with the current
Chris@1: Xiph.Org reference encoder.
Chris@1: 
Chris@1: However, floor vector values can span \~{}140dB (\~{}24 bits unsigned), and
Chris@1: the audio spectrum vector should represent a minimum of 120dB (\~{}21
Chris@1: bits with sign), even when output is to a 16 bit PCM device.  For the
Chris@1: residue vector to represent full scale if the floor is nailed to
Chris@1: $-140$dB, it must be able to span 0 to $+140$dB.  For the residue vector
Chris@1: to reach full scale if the floor is nailed at 0dB, it must be able to
Chris@1: represent $-140$dB to $+0$dB.  Thus, in order to handle full range
Chris@1: dynamics, a residue vector may span $-140$dB to $+140$dB entirely within
Chris@1: spec.  A 280dB range is approximately 48 bits with sign; thus the
Chris@1: residue vector must be able to represent a 48 bit range and the dot
Chris@1: product must be able to handle an effective 48 bit times 24 bit
Chris@1: multiplication.  This range may be achieved using large (64 bit or
Chris@1: larger) integers, or implementing a movable binary point
Chris@1: representation.
Chris@1: 
Chris@1: 
Chris@1: 
Chris@1: \paragraph{inverse monolithic transform (MDCT)}
Chris@1: 
Chris@1: The audio spectrum is converted back into time domain PCM audio via an
Chris@1: inverse Modified Discrete Cosine Transform (MDCT).  A detailed
Chris@1: description of the MDCT is available in \cite{Sporer/Brandenburg/Edler}.
Chris@1: 
Chris@1: Note that the PCM produced directly from the MDCT is not yet finished
Chris@1: audio; it must be lapped with surrounding frames using an appropriate
Chris@1: window (such as the Vorbis window) before the MDCT can be considered
Chris@1: orthogonal.
Chris@1: 
Chris@1: 
Chris@1: 
Chris@1: \paragraph{overlap/add data}
Chris@1: Windowed MDCT output is overlapped and added with the right hand data
Chris@1: of the previous window such that the 3/4 point of the previous window
Chris@1: is aligned with the 1/4 point of the current window (as illustrated in
Chris@1: the window overlap diagram). At this point, the audio data between the
Chris@1: center of the previous frame and the center of the current frame is
Chris@1: now finished and ready to be returned.
Chris@1: 
Chris@1: 
Chris@1: \paragraph{cache right hand data}
Chris@1: The decoder must cache the right hand portion of the current frame to
Chris@1: be lapped with the left hand portion of the next frame.
Chris@1: 
Chris@1: 
Chris@1: 
Chris@1: \paragraph{return finished audio data}
Chris@1: 
Chris@1: The overlapped portion produced from overlapping the previous and
Chris@1: current frame data is finished data to be returned by the decoder.
Chris@1: This data spans from the center of the previous window to the center
Chris@1: of the current window.  In the case of same-sized windows, the amount
Chris@1: of data to return is one-half block consisting of and only of the
Chris@1: overlapped portions. When overlapping a short and long window, much of
Chris@1: the returned range is not actually overlap.  This does not damage
Chris@1: transform orthogonality.  Pay attention however to returning the
Chris@1: correct data range; the amount of data to be returned is:
Chris@1: 
Chris@1: \begin{Verbatim}[commandchars=\\\{\}]
Chris@1: window\_blocksize(previous\_window)/4+window\_blocksize(current\_window)/4
Chris@1: \end{Verbatim}
Chris@1: 
Chris@1: from the center of the previous window to the center of the current
Chris@1: window.
Chris@1: 
Chris@1: Data is not returned from the first frame; it must be used to 'prime'
Chris@1: the decode engine.  The encoder accounts for this priming when
Chris@1: calculating PCM offsets; after the first frame, the proper PCM output
Chris@1: offset is '0' (as no data has been returned yet).




