summaryrefslogtreecommitdiffstats
path: root/libtoolame-dab/html/vbr.html
diff options
context:
space:
mode:
Diffstat (limited to 'libtoolame-dab/html/vbr.html')
-rw-r--r--libtoolame-dab/html/vbr.html239
1 files changed, 239 insertions, 0 deletions
diff --git a/libtoolame-dab/html/vbr.html b/libtoolame-dab/html/vbr.html
new file mode 100644
index 0000000..5f7ae38
--- /dev/null
+++ b/libtoolame-dab/html/vbr.html
@@ -0,0 +1,239 @@
+<html>
+<head>
+<title>tooLAME: MPEG Audio Layer II VBR</title>
+<style>
+<!-- BODY { BACKGROUND: #FFFFFF; COLOR: #000000; FONT-SIZE: 10pt; FONT-FAMILY: verdana, sans-serif }
+ A { COLOR: #111177; TEXT-DECORATION: none }
+ TD { font-size: medium; font-weight:normal }
+--!>
+</STYLE>
+</head>
+<body>
+
+<table border = 0 width="75%" align="center"><tr><td>
+<h1> tooLAME: MPEG Audio Layer II VBR </h1>
+
+<h2>Contents</h2>
+<Ul>
+<LI>Introduction
+<LI>Usage
+<LI>Bitrate Ranges for various Sampling frequencies
+<LI>Why can't the bitrate vary from 32kbps to 384kbps for every file?
+<UL>
+ <LI>Short Answer
+ <LI>Long Answer
+</UL>
+<LI> Tech Stuff
+</UL>
+
+<h2>Introduction</h2>
+VBR mode works by selecting a different bitrate for each frame. Frames
+which are harder to encode will be allocated more bits i.e. a higher bitrate.</p>
+
+LayerII VBR is a complete hack - the ISO standard actually says that decoders are not
+required to support it. As a hack, its implementation is a pain to try and understand.
+If you're mega-keen to get full range VBR working, either (a) send me money (b) grab the
+ISO standard and a C compiler and email me.</p>
+
+<h2>Usage</h2>
+<pre>
+ toolame -v [level] inputfile outputfile.
+</pre>
+A level of 5 works very well for me.</p>
+
+The level value can is a measurement of quality - the higher
+the level the higher the average bitrate of the resultant file.
+[See TECH STUFF for a better explanation of what the value does]</p>
+
+The confusing part of my implementation of LayerII VBR is that it's different from MP3 VBR.
+<UL>
+<LI>The range of bitrates used is controlled by the input sampling frequency. (See below "Bitrate ranges")
+<LI>The tendency to use higher bitrates is governed by the <level>.
+</ul>
+
+E.g. Say you have a 44.1kHz Stereo file. In VBR mode, the bitrate can range from 192 to 384 kbps.
+Using "-v -5" will force the encoder to favour the lower bitrate.
+Using "-v 5" will force the encoder to favour the upper bitrate.
+The value can actually be *any* int. -27, 233, 47. The larger the number, the greater
+the bitrate bias.</p>
+
+<h2>Bitrate Ranges</h2>
+
+When making a VBR stream, the bitrate is only allowed to vary within
+set limits</p>
+
+<pre>
+48kHz
+Stereo: 112-384kbps Mono: 56-192kbps
+
+44.1kHz & 32kHz
+Stereo: 192-384kbps Mono: 96-192kbps
+
+24kHz, 22.05kHz & 16kHz
+Stereo/Mono: 8-160kbps
+</pre>
+
+<h2>Why doesn't the VBR mode work the same as MP3VBR? The Short Answer</h2>
+<b>Why can't the bitrate vary from 32kbps to 384kbps for every file?</b></p>
+According to the standard (ISO/IEC 11172-3:1993) Section 2.4.2.3
+<pre>
+ "In order to provide the smallest possible delay and complexity, the
+ decoder is not required to support a continuously variable bitrate when
+ in layer I or II. Layer III supports variable bitrate by switching the
+ bitrate index."
+
+ and
+
+ "For Layer II, not all combinations of total bitrate and mode are allowed."
+</pre>
+
+Hence, most LayerII coders would not have been written with VBR in mind, and
+LayerII VBR is a hack. It works for limited cases. Getting it to work to
+the same extent as MP3-style VBR will be a major hack.</p>
+
+(If you *really* want better bitrate ranges, read "The Long Answer" and submit your mega-patch.)</p>
+
+<h2>Why doesn't the VBR mode work the same as MP3VBR? The Long Answer</h2>
+<b>Why can't the bitrate vary from 32kbps to 384kbps for every file?</b>
+
+<h3>Reason 1: The standard limits the range</h3>
+
+As quoted above from the standard for 48/44.1/32kHz:
+<pre>
+ "For Layer II, not all combinations of total bitrate and mode are allowed. See
+ the following table."
+
+Bitrate Allowed Modes
+(kbps)
+32 mono only
+48 mono only
+56 mono only
+64 all modes
+80 mono only
+96 all modes
+112 all modes
+128 all modes
+160 all modes
+192 all modes
+224 stereo only
+256 stereo only
+320 stereo only
+384 stereo only
+</pre>
+
+So based upon this table alone, you *could* have VBR stereo encoding which varies
+smoothly from 96 to 384kbps. Or you could have have VBR mono encoding which varies from
+32 to 192kbps. But since the top and bottom bitrates don't apply to all modes, it would
+be impossible to have a stereo file encoded from 32 to 384 kbps.</p>
+
+But this isn't what is really limiting the allowable bitrate range - the bit allocation
+tables are the major hurdle.</p>
+
+<h3>Reason 2: The bit allocation tables don't allow it</h3>
+
+From the standard, Section 2.4.3.3.1 "Bit allocation decoding"</p>
+<pre>
+ "For different combinations of bitrate and sampling frequency, different bit
+ allocation tables exist.
+</pre>
+These bit allocation tables are pre-determined tables (in Annex B of the standard) which
+indicate
+<UL>
+ <LI>how many bits to read for the initial data (2,3 or 4)
+ <LI>these bits are then used as an index back into the table to
+ find the number of quantize levels for the samples in this subband
+</ul>
+But the table used (and hence the number of bits and the calculated index) are different
+for different combinations of bitrate and sampling frequency.</p>
+
+I will use TableB.2a as an example.</p>
+
+Table B.2a Applies for the following combinations.
+<pre>
+Sampling Freq Bitrates in (kbps/channel) [emphasis: this is a PER CHANNEL bitrate]
+48 56, 64, 80, 96, 112, 128, 160, 192
+44.1 56, 64, 80
+32 56, 64, 80
+</pre>
+If we have a STEREO 48kHz input file, and we use this table, then the bitrates
+we could calculate from this would be 112, 128, 160, 192, 224, 256, 320 and 384 kbps.</p>
+
+This table contains no information on how to encode stuff at bitrates less than 112kbps
+(for a stereo file). You would have to load allocation table B.2c to encode stereo at
+64kbps and 128kbps.</p>
+
+Since it would be a MAJOR piece of hacking to get the different tables shifted in and out
+during the encoding process, once an allocation table is loaded *IT IS NOT CHANGED*.</p>
+
+Hence, the best table is picked at the start of the encoding process, and the encoder
+is stuck with it for the rest of the encode. </p>
+
+For toolame-02j, I have picked the table it loads for different
+sampling frequencies in order to optimize the range of bitrates possible.
+<pre>
+48 kHz - Table B.2a
+ Stereo Bitrate Range: 112 - 384
+ Mono Bitrate Range : 56 - 192
+
+44.1/32 kHz - Table B.2b
+ Stereo Bitrate Range: 192 - 384
+ Mono Bitrate Range: 96 - 192
+
+24/22.05/16 kHz - LSF Table (Standard ISO/IEC 13818.3:1995 Annex B, Table B.1)
+ There is only 1 table for the Lower Sampling Frequencies
+ All modes (mono and stereo) are allowable at all bitrates
+ So at the Lower Sampling Frequencies you *can* have a completely variable
+ bitrate over the entire range.
+</pre>
+<h2>Tech Stuff</h2>
+
+The VBR mode is mainly centered around the main_bit_allocation() and
+a_bit_allocation() routines in encode.c.</p>
+
+The limited range of VBR is due to my particular implementation which restricts
+ranges to within one alloc table (see tables B.2a, B.2b, B.2c and B.2d in ISO 11172).
+The VBR range for 32/44.1khz lies within B.2b, and the 48khz VBR lies within table B.2a.</p>
+
+I'm not sure whether it is worth extending these ranges down to lower bitrates.
+The work required to switch alloc tables *during* the encoding is major.</p>
+
+In the case of silence, it might be worth doing a quick check for very low signals
+and writing a pre-calculated *blank* 32kpbs frame. [probably also a lot of work].</p>
+
+<h3>How CBR works</h3>
+<UL>
+<LI> Use the psycho model to determine the MNRs for each subband
+ [MNR = the ratio of "masking" to "noise"]
+ (From an encoding perspective, a bigger MNR in a subband means that
+ it sounds better since the noise is more masked))
+<LI> calculate the available data bits (adb) for this bitrate.
+<LI> Based upon the MNR (Masking:Noise Ratio) values, allocate bits to each
+ subband
+<LI> Keep increasing the bits to whichever subband currently has the min MNR
+ value until we have no bits left.
+<LI> This mode does not guarentee that all the subbands are without noise
+ ie there may still be subbands with MNR less than 0.0 (noisy!)
+</ul>
+
+<h3>How VBR works</h3>
+<UL>
+<LI> pretend we have lots of bits to spare, and work out the bits which would
+ raise the MNR in each subband to the level given by the argument on the
+ command line "-v [int]"
+<LI> Pick the bitrate which has more bits than the required_bits we just calculated
+<LI> calculate a_bit_allocation()
+<LI> VBR "guarantees" that all subbands have MNR > VBRLEVEL or that we have
+ reached the maximum bitrate.
+</ul>
+
+<h2>FUTURE</h2>
+<UL>
+<LI> with this VBR mode, we know the bits aren't going to run out, so we can
+ just assign them "greedily".
+<LI> VBR_a_bit_allocation() is yet to be written :)
+</ul>
+
+
+</tr></td>
+</body>
+</html>