Include toolame-dab as library

author: Matthias P. Braendli <matthias.braendli@mpb.li> 2016-02-15 02:44:20 +0100
committer: Matthias P. Braendli <matthias.braendli@mpb.li> 2016-02-15 02:44:20 +0100
commit: 22f1fce330059ef8a383cf327a023d6a9da5ad3e (patch)
tree: 6893f158dcaaaa1b9f1317923c32a841ba31f768 /libtoolame-dab/html/vbr.html
parent: 891bb2592944aa2be2d81e1583e73e632e70537f (diff)
download: fdk-aac-22f1fce330059ef8a383cf327a023d6a9da5ad3e.tar.gz
fdk-aac-22f1fce330059ef8a383cf327a023d6a9da5ad3e.tar.bz2
fdk-aac-22f1fce330059ef8a383cf327a023d6a9da5ad3e.zip
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>
author	Matthias P. Braendli <matthias.braendli@mpb.li>	2016-02-15 02:44:20 +0100
committer	Matthias P. Braendli <matthias.braendli@mpb.li>	2016-02-15 02:44:20 +0100
commit	22f1fce330059ef8a383cf327a023d6a9da5ad3e (patch)
tree	6893f158dcaaaa1b9f1317923c32a841ba31f768 /libtoolame-dab/html/vbr.html
parent	891bb2592944aa2be2d81e1583e73e632e70537f (diff)
download	fdk-aac-22f1fce330059ef8a383cf327a023d6a9da5ad3e.tar.gz fdk-aac-22f1fce330059ef8a383cf327a023d6a9da5ad3e.tar.bz2 fdk-aac-22f1fce330059ef8a383cf327a023d6a9da5ad3e.zip