jamosdev
/
rhubarb-lip-sync
mirror of https://github.com/DanielSWolf/rhubarb-lip-sync.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add libvorbis

This commit is contained in:
Daniel Wolf 2018-07-13 22:44:37 +02:00
parent b4a2a295d1
commit d077aae74c
412 changed files with 112884 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
LICENSE.md
View File

@ -232,6 +232,22 @@ The [utf8proc](https://github.com/JuliaLang/utf8proc) library is released under
> >
> Unicode and the Unicode logo are trademarks of Unicode, Inc., and may be registered in some jurisdictions. All other trademarks and registered trademarks mentioned herein are the property of their respective owners. > Unicode and the Unicode logo are trademarks of Unicode, Inc., and may be registered in some jurisdictions. All other trademarks and registered trademarks mentioned herein are the property of their respective owners.
### `[vorbis]` libvorbis
libvorbis is released under the **3-clause BSD license**.
> Copyright (c) 2002-2018 Xiph.org Foundation
>
> Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
>
> - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
>
> - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
>
> - Neither the name of the Xiph.org Foundation nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
>
> THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
### `[webrtc]` WebRTC ### `[webrtc]` WebRTC
The [WebRTC](https://chromium.googlesource.com/external/webrtc) library is released under the **3-clause BSD License**. The [WebRTC](https://chromium.googlesource.com/external/webrtc) library is released under the **3-clause BSD License**.

30
rhubarb/CMakeLists.txt
View File

@ -242,6 +242,36 @@ target_include_directories(ogg SYSTEM PUBLIC "lib/ogg-1.3.3/include")
target_compile_options(ogg PRIVATE ${disableWarningsFlags}) target_compile_options(ogg PRIVATE ${disableWarningsFlags})
set_target_properties(ogg PROPERTIES FOLDER lib) set_target_properties(ogg PROPERTIES FOLDER lib)
# ... Vorbis
add_library(vorbis
lib/vorbis-1.3.6/include/vorbis/vorbisfile.h
lib/vorbis-1.3.6/lib/bitrate.c
lib/vorbis-1.3.6/lib/block.c
lib/vorbis-1.3.6/lib/codebook.c
lib/vorbis-1.3.6/lib/envelope.c
lib/vorbis-1.3.6/lib/floor0.c
lib/vorbis-1.3.6/lib/floor1.c
lib/vorbis-1.3.6/lib/info.c
lib/vorbis-1.3.6/lib/lpc.c
lib/vorbis-1.3.6/lib/lsp.c
lib/vorbis-1.3.6/lib/mapping0.c
lib/vorbis-1.3.6/lib/mdct.c
lib/vorbis-1.3.6/lib/psy.c
lib/vorbis-1.3.6/lib/registry.c
lib/vorbis-1.3.6/lib/res0.c
lib/vorbis-1.3.6/lib/sharedbook.c
lib/vorbis-1.3.6/lib/smallft.c
lib/vorbis-1.3.6/lib/synthesis.c
lib/vorbis-1.3.6/lib/vorbisfile.c
lib/vorbis-1.3.6/lib/window.c
)
target_include_directories(vorbis SYSTEM PUBLIC "lib/vorbis-1.3.6/include")
target_link_libraries(vorbis
ogg
)
target_compile_options(vorbis PRIVATE ${disableWarningsFlags})
set_target_properties(vorbis PROPERTIES FOLDER lib)
# Define Rhubarb libraries # Define Rhubarb libraries
include_directories("src") include_directories("src")

40
rhubarb/lib/vorbis-1.3.6/.gitignore vendored Normal file
View File

@ -0,0 +1,40 @@
*.o
*.lo
*.la
.libs
.deps
aclocal.m4
configure
Makefile
Makefile.in
autom4te.cache
compile
config.guess
config.h
config.h.in
config.h.in~
config.log
config.status
config.sub
depcomp
install-sh
libtool
ltmain.sh
missing
stamp-h1
m4/libtool.m4
m4/ltoptions.m4
m4/ltsugar.m4
m4/ltversion.m4
m4/lt~obsolete.m4
libvorbis.spec
vorbis-uninstalled.pc
vorbis.pc
vorbisenc-uninstalled.pc
vorbisenc.pc
vorbisfile-uninstalled.pc
vorbisfile.pc
doc/Doxyfile
doc/doxygen-build.stamp
lib/test_sharedbook
test/test

24
rhubarb/lib/vorbis-1.3.6/.travis.yml Normal file
View File

@ -0,0 +1,24 @@
language: c
compiler:
- gcc
- clang
env:
- BUILD_SYSTEM=AUTOTOOLS
- BUILD_SYSTEM=CMAKE
addons:
apt:
packages:
- libogg-dev
script:
- if [[ "$BUILD_SYSTEM" == "AUTOTOOLS" ]] ; then ./autogen.sh ; fi
- if [[ "$BUILD_SYSTEM" == "AUTOTOOLS" ]] ; then ./configure ; fi
- if [[ "$BUILD_SYSTEM" == "AUTOTOOLS" ]] ; then make -j2 V=1 distcheck ; fi
- if [[ "$BUILD_SYSTEM" == "CMAKE" ]] ; then mkdir build ; fi
- if [[ "$BUILD_SYSTEM" == "CMAKE" ]] ; then pushd build ; fi
- if [[ "$BUILD_SYSTEM" == "CMAKE" ]] ; then cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Release .. ; fi
- if [[ "$BUILD_SYSTEM" == "CMAKE" ]] ; then cmake --build . ; fi
- if [[ "$BUILD_SYSTEM" == "CMAKE" ]] ; then popd ; fi

8
rhubarb/lib/vorbis-1.3.6/.ycm_extra_conf.py Normal file
View File

@ -0,0 +1,8 @@
def FlagsForFile(filename, **kwargs):
return {
'flags': [
'-x', 'c',
'-g', '-Wall', '-Wextra',
'-D_REENTRANT', '-D__NO_MATH_INLINES', '-fsigned-char'
],
}

3
rhubarb/lib/vorbis-1.3.6/AUTHORS Normal file
View File

@ -0,0 +1,3 @@
Monty <monty@xiph.org>
and the rest of the Xiph.org Foundation.

165
rhubarb/lib/vorbis-1.3.6/CHANGES Normal file
View File

@ -0,0 +1,165 @@
libvorbis 1.3.6 (2018-03-16) -- "Xiph.Org libVorbis I 20180316 (Now 100% fewer shells)"
* Fix CVE-2018-5146 - out-of-bounds write on codebook decoding.
* Fix CVE-2017-14632 - free() on unitialized data
* Fix CVE-2017-14633 - out-of-bounds read
* Fix bitrate metadata parsing.
* Fix out-of-bounds read in codebook parsing.
* Fix residue vector size in Vorbis I spec.
* Appveyor support
* Travis CI support
* Add secondary CMake build system.
* Build system fixes
libvorbis 1.3.5 (2015-03-03) -- "Xiph.Org libVorbis I 20150105 (⛄⛄⛄⛄)"
* Tolerate single-entry codebooks.
* Fix decoder crash with invalid input.
* Fix encoder crash with non-positive sample rates.
# Fix issues in vorbisfile's seek bisection code.
* Spec errata.
* Reject multiple headers of the same type.
* Various build fixes and code cleanup.
libvorbis 1.3.4 (2014-01-22) -- "Xiph.Org libVorbis I 20140122 (Turpakäräjiin)"
* Reduce codebook footprint in library code.
* Various build and documentation fixes.
libvorbis 1.3.3 (2012-02-03) -- "Xiph.Org libVorbis I 20120203 (Omnipresent)"
* vorbis: additional proofing against invalid/malicious
streams in decode (see SVN for details).
* vorbis: fix a memory leak in vorbis_commentheader_out().
* updates, corrections and clarifications in the Vorbis I specification
document
* win32: fixed project configuration which referenced two CRT versions
in output binaries.
* build warning fixes
libvorbis 1.3.2 (2010-11-01) -- "Xiph.Org libVorbis I 20101101 (Schaufenugget)"
* vorbis: additional proofing against invalid/malicious
streams in floor, residue, and bos/eos packet trimming
code (see SVN for details).
* vorbis: Added programming documentation tree for the
low-level calls
* vorbisfile: Correct handling of serial numbers array
element [0] on non-seekable streams
* vorbisenc: Back out an [old] AoTuV HF weighting that was
first enabled in 1.3.0; there are a few samples where I
really don't like the effect it causes.
* vorbis: return correct timestamp for granule positions
with high bit set.
* vorbisfile: the [undocumented] half-rate decode api made no
attempt to keep the pcm offset tracking consistent in seeks.
Fix and add a testing mode to seeking_example.c to torture
test seeking in halfrate mode. Also remove requirement that
halfrate mode only work with seekable files.
* vorbisfile: Fix a chaining bug in raw_seeks where seeking
out of the current link would fail due to not
reinitializing the decode machinery.
* vorbisfile: improve seeking strategy. Reduces the
necessary number of seek callbacks in an open or seek
operation by well over 2/3.
libvorbis 1.3.1 (2010-02-26) -- "Xiph.Org libVorbis I 20100325 (Everywhere)"
* tweak + minor arithmetic fix in floor1 fit
* revert noise norm to conservative 1.2.3 behavior pending
more listening testing
libvorbis 1.3.0 (2010-02-25) -- unreleased staging snapshot
* Optimized surround support for 5.1 encoding at 44.1/48kHz
* Added encoder control call to disable channel coupling
* Correct an overflow bug in very low-bitrate encoding on 32 bit
machines that caused inflated bitrates
* Numerous API hardening, leak and build fixes
* Correct bug in 22kHz compand setup that could cause a crash
* Correct bug in 16kHz codebooks that could cause unstable pure
tones at high bitrates
libvorbis 1.2.3 (2009-07-09) -- "Xiph.Org libVorbis I 20090709"
* correct a vorbisfile bug that prevented proper playback of
Vorbis files where all audio in a logical stream is in a
single page
* Additional decode setup hardening against malicious streams
* Add 'OV_EXCLUDE_STATIC_CALLBACKS' define for developers who
wish to avoid unused symbol warnings from the static callbacks
defined in vorbisfile.h
libvorbis 1.2.2 (2009-06-24) -- "Xiph.Org libVorbis I 20090624"
* define VENDOR and ENCODER strings
* seek correctly in files bigger than 2 GB (Windows)
* fix regression from CVE-2008-1420; 1.0b1 files work again
* mark all tables as constant to reduce memory occupation
* additional decoder hardening against malicious streams
* substantially reduce amount of seeking performed by Vorbisfile
* Multichannel decode bugfix
* build system updates
* minor specification clarifications/fixes
libvorbis 1.2.1 (unreleased) -- "Xiph.Org libVorbis I 20080501"
* Improved robustness with corrupt streams.
* New ov_read_filter() vorbisfile call allows filtering decoded
audio as floats before converting to integer samples.
* Fix an encoder bug with multichannel streams.
* Replaced RTP payload format draft with RFC 5215.
* Bare bones self test under 'make check'.
* Fix a problem encoding some streams between 14 and 28 kHz.
* Fix a numerical instability in the edge extrapolation filter.
* Build system improvements.
* Specification correction.
libvorbis 1.2.0 (2007-07-25) -- "Xiph.Org libVorbis I 20070622"
* new ov_fopen() convenience call that avoids the common
stdio conflicts with ov_open() and MSVC runtimes.
* libvorbisfile now handles multiplexed streams
* improve robustness to corrupt input streams
* fix a minor encoder bug
* updated RTP draft
* build system updates
* minor corrections to the specification
libvorbis 1.1.2 (2005-11-27) -- "Xiph.Org libVorbis I 20050304"
* fix a serious encoder bug with gcc 4 optimized builds
* documentation and spec fixes
* updated VS2003 and XCode builds
* new draft RTP encapsulation spec
libvorbis 1.1.1 (2005-06-27) -- "Xiph.Org libVorbis I 20050304"
* bug fix to the bitrate management encoder interface
* bug fix to properly set packetno field in the encoder
* new draft RTP encapsulation spec
* library API documentation improvements
libvorbis 1.1.0 (2004-09-22) -- "Xiph.Org libVorbis I 20040629"
* merges tuning improvements from Aoyumi's aoTuV with fixups
* new managed bitrate (CBR) mode support
* new vorbis_encoder_ctl() interface
* extensive documentation updates
* application/ogg mimetype is now official
* autotools cleanup from Thomas Vander Stichele
* SymbianOS build support from Colin Ward at CSIRO
* various bugfixes
* various packaging improvements
libvorbis 1.0.1 (2003-11-17) -- "Xiph.Org libVorbis I 20030909"
* numerous bug fixes
* specification corrections
* new crosslap and halfrate APIs for game use
* packaging and build updates
libvorbis 1.0.0 (2002-07-19) -- "Xiph.Org libVorbis I 20020717"
* first stable release

81
rhubarb/lib/vorbis-1.3.6/CMakeLists.txt Normal file
View File

@ -0,0 +1,81 @@
cmake_minimum_required(VERSION 2.8.7)
project(vorbis)
# Required modules
include(GNUInstallDirs)
include(CheckIncludeFiles)
# Build options
option(BUILD_SHARED_LIBS "Build shared library" OFF)
if(APPLE)
option(BUILD_FRAMEWORK "Build Framework bundle for OSX" OFF)
endif()
if(BUILD_FRAMEWORK)
set(BUILD_SHARED_LIBS TRUE)
endif()
# Extract project version from configure.ac
file(READ configure.ac CONFIGURE_AC_CONTENTS)
string(REGEX MATCH "AC_INIT\\(\\[libvorbis\\],\\[([0-9]*).([0-9]*).([0-9]*)" DUMMY ${CONFIGURE_AC_CONTENTS})
set(PROJECT_VERSION_MAJOR ${CMAKE_MATCH_1})
set(PROJECT_VERSION_MINOR ${CMAKE_MATCH_2})
set(PROJECT_VERSION_PATCH ${CMAKE_MATCH_3})
set(PROJECT_VERSION ${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}.${PROJECT_VERSION_PATCH})
# Helper function to get version-info
function(get_version_info result current_var_name age_var_name revision_var_name)
string(REGEX MATCH "${current_var_name}=([0-9]*)" DUMMY ${CONFIGURE_AC_CONTENTS})
set(VERSION_INFO_CURRENT ${CMAKE_MATCH_1})
string(REGEX MATCH "${age_var_name}=([0-9]*)" DUMMY ${CONFIGURE_AC_CONTENTS})
set(VERSION_INFO_AGE ${CMAKE_MATCH_1})
string(REGEX MATCH "${revision_var_name}=([0-9]*)" DUMMY ${CONFIGURE_AC_CONTENTS})
set(VERSION_INFO_REVISION ${CMAKE_MATCH_1})
math(EXPR VERSION_INFO_CURRENT_MINUS_AGE "${VERSION_INFO_CURRENT} - ${VERSION_INFO_AGE}")
set(${result} "${VERSION_INFO_CURRENT_MINUS_AGE}.${VERSION_INFO_AGE}.${VERSION_INFO_REVISION}" PARENT_SCOPE)
endfunction()
# Helper function to configure pkg-config files
function(configure_pkg_config_file pkg_config_file_in)
set(prefix ${CMAKE_INSTALL_PREFIX})
set(exec_prefix ${CMAKE_INSTALL_FULL_BINDIR})
set(libdir ${CMAKE_INSTALL_FULL_LIBDIR})
set(includedir ${CMAKE_INSTALL_FULL_INCLUDEDIR})
set(VERSION ${PROJECT_VERSION})
string(REPLACE ".in" "" pkg_config_file ${pkg_config_file_in})
configure_file(${pkg_config_file_in} ${pkg_config_file} @ONLY)
endfunction()
message(STATUS "Configuring ${PROJECT_NAME} ${PROJECT_VERSION}")
# Find ogg dependency
if(NOT OGG_ROOT)
find_package(PkgConfig QUIET)
pkg_check_modules(PC_OGG QUIET ogg)
find_path(OGG_INCLUDE_DIRS NAMES ogg/ogg.h HINTS ${PC_OGG_INCLUDE_DIRS} PATH_SUFFIXES ogg)
find_library(OGG_LIBRARIES NAMES ogg HINTS ${PC_OGG_LIBRARY_DIRS})
else()
find_path(OGG_INCLUDE_DIRS NAMES ogg/ogg.h HINTS ${OGG_ROOT}/include PATH_SUFFIXES ogg)
find_library(OGG_LIBRARIES NAMES ogg HINTS ${OGG_ROOT}/lib ${OGG_ROOT}/lib64)
endif()
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(OGG DEFAULT_MSG OGG_INCLUDE_DIRS OGG_LIBRARIES)
add_subdirectory(lib)
configure_pkg_config_file(vorbis.pc.in)
configure_pkg_config_file(vorbisenc.pc.in)
configure_pkg_config_file(vorbisfile.pc.in)
install(
FILES
${CMAKE_CURRENT_BINARY_DIR}/vorbis.pc
${CMAKE_CURRENT_BINARY_DIR}/vorbisenc.pc
${CMAKE_CURRENT_BINARY_DIR}/vorbisfile.pc
DESTINATION
${CMAKE_INSTALL_LIBDIR}/pkgconfig
)

28
rhubarb/lib/vorbis-1.3.6/COPYING Normal file
View File

@ -0,0 +1,28 @@
Copyright (c) 2002-2018 Xiph.org Foundation
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
- Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
- Neither the name of the Xiph.org Foundation nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION
OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

47
rhubarb/lib/vorbis-1.3.6/Makefile.am Normal file
View File

@ -0,0 +1,47 @@
## Process this file with automake to produce Makefile.in
AUTOMAKE_OPTIONS = foreign 1.11 dist-zip dist-xz
ACLOCAL_AMFLAGS = -I m4
SUBDIRS = m4 include vq lib test doc
if BUILD_EXAMPLES
SUBDIRS += examples
endif
m4datadir = $(datadir)/aclocal
m4data_DATA = vorbis.m4
pkgconfigdir = $(libdir)/pkgconfig
pkgconfig_DATA = vorbis.pc vorbisenc.pc vorbisfile.pc
EXTRA_DIST = \
CHANGES COPYING \
autogen.sh \
libvorbis.spec libvorbis.spec.in \
vorbis.m4 \
vorbis.pc.in vorbisenc.pc.in vorbisfile.pc.in \
vorbis-uninstalled.pc.in \
vorbisenc-uninstalled.pc.in \
vorbisfile-uninstalled.pc.in \
symbian \
macosx win32
DISTCHECK_CONFIGURE_FLAGS = --enable-docs
dist-hook:
for item in $(EXTRA_DIST); do \
if test -d $$item; then \
echo -n "cleaning $$item dir for distribution..."; \
rm -rf `find $(distdir)/$$item -name .svn`; \
echo "OK"; \
fi; \
done
debug:
$(MAKE) all CFLAGS="@DEBUG@"
profile:
$(MAKE) all CFLAGS="@PROFILE@"

149
rhubarb/lib/vorbis-1.3.6/README.md Normal file
View File

@ -0,0 +1,149 @@
# Vorbis
[![Travis Build Status](https://travis-ci.org/xiph/vorbis.svg?branch=master)](https://travis-ci.org/xiph/vorbis)
[![Jenkins Build Status](https://mf4.xiph.org/jenkins/job/libvorbis/badge/icon)](https://mf4.xiph.org/jenkins/job/libvorbis/)
[![AppVeyor Build status](https://ci.appveyor.com/api/projects/status/github/xiph/vorbis?branch=master&svg=true)](https://ci.appveyor.com/project/rillian/vorbis)
Vorbis is a general purpose audio and music encoding format
contemporary to MPEG-4's AAC and TwinVQ, the next generation beyond
MPEG audio layer 3. Unlike the MPEG sponsored formats (and other
proprietary formats such as RealAudio G2 and Windows' flavor of the
month), the Vorbis CODEC specification belongs to the public domain.
All the technical details are published and documented, and any
software entity may make full use of the format without license
fee, royalty or patent concerns.
This package contains:
- libvorbis, a BSD-style license software implementation of
the Vorbis specification by the Xiph.Org Foundation
(https://www.xiph.org/)
- libvorbisfile, a BSD-style license convenience library
built on Vorbis designed to simplify common uses
- libvorbisenc, a BSD-style license library that provides a simple,
programmatic encoding setup interface
- example code making use of libogg, libvorbis, libvorbisfile and
libvorbisenc
## What's here ##
This source distribution includes libvorbis and an example
encoder/player to demonstrate use of libvorbis as well as
documentation on the Ogg Vorbis audio coding format.
You'll need libogg (distributed separately) to compile this library.
A more comprehensive set of utilities is available in the vorbis-tools
package.
Directory:
- `lib` The source for the libraries, a BSD-license implementation of the public domain Ogg Vorbis audio encoding format.
- `include` Library API headers
- `debian` Rules/spec files for building Debian .deb packages
- `doc` Vorbis documentation
- `examples` Example code illustrating programmatic use of libvorbis, libvorbisfile and libvorbisenc
- `macosx` Project files for MacOS X.
- `win32` Win32 projects files and build automation
- `vq` Internal utilities for training/building new LSP/residue and auxiliary codebooks.
## Contact ##
The Ogg homepage is located at 'https://www.xiph.org/ogg/'.
Vorbis's homepage is located at 'https://www.xiph.org/vorbis/'.
Up to date technical documents, contact information, source code and
pre-built utilities may be found there.
The user website for Ogg Vorbis software and audio is http://vorbis.com/
## Building ##
#### Building from master ####
Development source is under git revision control at
https://git.xiph.org/vorbis.git. You will also need the
newest versions of autoconf, automake, libtool and pkg-config in
order to compile Vorbis from development source. A configure script
is provided for you in the source tarball distributions.
./autogen.sh
./configure
make
and as root if desired:
make install
This will install the Vorbis libraries (static and shared) into
/usr/local/lib, includes into /usr/local/include and API manpages
(once we write some) into /usr/local/man.
Documentation building requires xsltproc and pdfxmltex.
#### Building from tarball distributions ####
./configure
make
and optionally (as root):
make install
#### Building RPM packages ####
after normal configuring:
make dist
rpm -ta libvorbis-<version>.tar.gz
## Building with CMake ##
Ogg supports building using [CMake](http://www.cmake.org/). CMake is a meta build system that generates native projects for each platform.
To generate projects just run cmake replacing `YOUR-PROJECT-GENERATOR` with a proper generator from a list [here](http://www.cmake.org/cmake/help/v3.2/manual/cmake-generators.7.html):
cmake -G YOUR-PROJECT-GENERATOR .
Note that by default cmake generates projects that will build static libraries.
To generate projects that will build dynamic library use `BUILD_SHARED_LIBS` option like this:
cmake -G YOUR-PROJECT-GENERATOR -DBUILD_SHARED_LIBS=1 .
After projects are generated use them as usual
#### Building on Windows ####
Use proper generator for your Visual Studio version like:
cmake -G "Visual Studio 12 2013" .
#### Building on Mac OS X ####
Use Xcode generator. To build framework run:
cmake -G Xcode -DBUILD_FRAMEWORK=1 .
#### Building on Linux ####
Use Makefile generator which is default one.
cmake .
make
## License ##
THIS FILE IS PART OF THE OggVorbis SOFTWARE CODEC SOURCE CODE.
USE, DISTRIBUTION AND REPRODUCTION OF THIS LIBRARY SOURCE IS
GOVERNED BY A BSD-STYLE SOURCE LICENSE INCLUDED WITH THIS SOURCE
IN 'COPYING'. PLEASE READ THESE TERMS BEFORE DISTRIBUTING.
THE OggVorbis SOURCE CODE IS COPYRIGHT (C) 1994-2018
by the Xiph.Org Foundation https://www.xiph.org/

32
rhubarb/lib/vorbis-1.3.6/appveyor.yml Normal file
View File

@ -0,0 +1,32 @@
image: Visual Studio 2015
configuration:
- Debug
platform:
- Win32
environment:
matrix:
- BUILD_SYSTEM: MSVC
- BUILD_SYSTEM: CMAKE
install:
- git clone -q https://github.com/xiph/ogg.git %APPVEYOR_BUILD_FOLDER%\..\libogg
- if "%BUILD_SYSTEM%"=="MSVC" msbuild "%APPVEYOR_BUILD_FOLDER%\..\libogg\win32\VS2015\libogg_static.sln" /m /v:minimal /logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll" /property:Configuration=%CONFIGURATION%;Platform=%PLATFORM%
- if "%BUILD_SYSTEM%"=="CMAKE" mkdir "%APPVEYOR_BUILD_FOLDER%\..\libogg\build"
- if "%BUILD_SYSTEM%"=="CMAKE" pushd "%APPVEYOR_BUILD_FOLDER%\..\libogg\build"
- if "%BUILD_SYSTEM%"=="CMAKE" cmake -A "%PLATFORM%" -G "Visual Studio 14 2015" -DCMAKE_INSTALL_PREFIX="%APPVEYOR_BUILD_FOLDER%\..\libogg\install" ..
- if "%BUILD_SYSTEM%"=="CMAKE" cmake --build . --config "%CONFIGURATION%" --target install -- /logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"
- if "%BUILD_SYSTEM%"=="CMAKE" popd
before_build:
- if "%BUILD_SYSTEM%" == "CMAKE" mkdir "%APPVEYOR_BUILD_FOLDER%\build"
- if "%BUILD_SYSTEM%" == "CMAKE" pushd "%APPVEYOR_BUILD_FOLDER%\build"
- if "%BUILD_SYSTEM%" == "CMAKE" cmake -A "%PLATFORM%" -G "Visual Studio 14 2015" -DOGG_ROOT=%APPVEYOR_BUILD_FOLDER%\..\libogg\install ..
- if "%BUILD_SYSTEM%" == "CMAKE" popd
build_script:
- if "%BUILD_SYSTEM%"=="MSVC" msbuild "%APPVEYOR_BUILD_FOLDER%\win32\VS2010\vorbis_dynamic.sln" /m /v:minimal /logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll" /property:Configuration=%CONFIGURATION%;Platform=%PLATFORM%
- if "%BUILD_SYSTEM%" == "CMAKE" pushd "%APPVEYOR_BUILD_FOLDER%\build"
- if "%BUILD_SYSTEM%" == "CMAKE" cmake --build . --config "%CONFIGURATION%" -- /logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"
- if "%BUILD_SYSTEM%" == "CMAKE" popd

12
rhubarb/lib/vorbis-1.3.6/autogen.sh Normal file
View File

@ -0,0 +1,12 @@
#!/bin/sh
# Run this to set up the build system: configure, makefiles, etc.
set -e
package="vorbis"
srcdir=`dirname $0`
test -n "$srcdir" && cd "$srcdir"
echo "Updating build configuration files for $package, please wait...."
autoreconf -if

304
rhubarb/lib/vorbis-1.3.6/configure.ac Normal file
View File

@ -0,0 +1,304 @@
dnl Process this file with autoconf to produce a configure script
dnl ------------------------------------------------
dnl Initialization and Versioning
dnl ------------------------------------------------
AC_INIT([libvorbis],[1.3.6],[vorbis-dev@xiph.org])
AC_CONFIG_MACRO_DIR([m4])
AC_CONFIG_SRCDIR([lib/mdct.c])
AC_CANONICAL_TARGET([])
AM_INIT_AUTOMAKE
AM_MAINTAINER_MODE
dnl Add parameters for aclocal
AC_SUBST(ACLOCAL_AMFLAGS, "-I m4")
dnl enable silent rules on automake 1.11 and later
m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
dnl Library versioning
dnl - library source changed -> increment REVISION
dnl - interfaces added/removed/changed -> increment CURRENT, REVISION = 0
dnl - interfaces added -> increment AGE
dnl - interfaces removed -> AGE = 0
V_LIB_CURRENT=4
V_LIB_REVISION=8
V_LIB_AGE=4
VF_LIB_CURRENT=6
VF_LIB_REVISION=7
VF_LIB_AGE=3
VE_LIB_CURRENT=2
VE_LIB_REVISION=11
VE_LIB_AGE=0
AC_SUBST(V_LIB_CURRENT)
AC_SUBST(V_LIB_REVISION)
AC_SUBST(V_LIB_AGE)
AC_SUBST(VF_LIB_CURRENT)
AC_SUBST(VF_LIB_REVISION)
AC_SUBST(VF_LIB_AGE)
AC_SUBST(VE_LIB_CURRENT)
AC_SUBST(VE_LIB_REVISION)
AC_SUBST(VE_LIB_AGE)
dnl --------------------------------------------------
dnl Check for programs
dnl --------------------------------------------------
dnl save $CFLAGS since AC_PROG_CC likes to insert "-g -O2"
dnl if $CFLAGS is blank
cflags_save="$CFLAGS"
AC_PROG_CC
AC_PROG_CPP
CFLAGS="$cflags_save"
AC_C_INLINE
AC_LIBTOOL_WIN32_DLL
AC_PROG_LIBTOOL
AM_PROG_CC_C_O
dnl Check for doxygen
if test "x$enable_docs" = xyes; then
AC_CHECK_PROG(HAVE_DOXYGEN, doxygen, true, false)
if test $HAVE_DOXYGEN = "false"; then
AC_MSG_WARN([*** doxygen not found, API documentation will not be built])
fi
else
HAVE_DOXYGEN=false
fi
AM_CONDITIONAL(HAVE_DOXYGEN,$HAVE_DOXYGEN)
dnl latex tools for the specification document
AC_ARG_ENABLE(docs,
AC_HELP_STRING([--enable-docs], [build the documentation]))
if test "x$enable_docs" = xyes; then
AC_CHECK_PROGS([PDFLATEX], pdflatex, [/bin/false])
AC_CHECK_PROGS([HTLATEX], htlatex, [/bin/false])
if test "x$PDFLATEX" = x/bin/false || test "x$HTLATEX" = x/bin/false; then
enable_docs=no
AC_MSG_WARN([Documentation will not be built!])
fi
fi
AM_CONDITIONAL(BUILD_DOCS, [test "x$enable_docs" = xyes])
AC_ARG_ENABLE(examples,
AS_HELP_STRING([--enable-examples], [build the examples]))
AM_CONDITIONAL(BUILD_EXAMPLES, [test "x$enable_examples" = xyes])
dnl --------------------------------------------------
dnl Set build flags based on environment
dnl --------------------------------------------------
dnl Set some target options
cflags_save="$CFLAGS"
if test -z "$GCC"; then
case $host in
*-*-irix*)
dnl If we're on IRIX, we wanna use cc even if gcc
dnl is there (unless the user has overriden us)...
if test -z "$CC"; then
CC=cc
fi
DEBUG="-g -signed"
CFLAGS="-O2 -w -signed"
PROFILE="-p -g3 -O2 -signed" ;;
sparc-sun-solaris*)
DEBUG="-v -g"
CFLAGS="-xO4 -fast -w -fsimple -native -xcg92"
PROFILE="-v -xpg -g -xO4 -fast -native -fsimple -xcg92 -Dsuncc" ;;
*)
DEBUG="-g"
CFLAGS="-O"
PROFILE="-g -p" ;;
esac
else
AC_MSG_CHECKING([GCC version])
GCC_VERSION=`$CC -dumpversion`
AC_MSG_RESULT([$GCC_VERSION])
case $host in
*86-*-linux*)
DEBUG="-g -Wall -Wextra -D_REENTRANT -D__NO_MATH_INLINES -fsigned-char"
CFLAGS="-O3 -Wall -Wextra -ffast-math -mno-ieee-fp -D_REENTRANT -fsigned-char"
# PROFILE="-Wall -Wextra -pg -g -O3 -ffast-math -D_REENTRANT -fsigned-char -fno-inline -static"
PROFILE="-Wall -Wextra -pg -g -O3 -ffast-math -mno-ieee-fp -D_REENTRANT -fsigned-char -fno-inline"
# glibc < 2.1.3 has a serious FP bug in the math inline header
# that will cripple Vorbis. Look to see if the magic FP stack
# clobber is missing in the mathinline header, thus indicating
# the buggy version
AC_EGREP_CPP(log10.*fldlg2.*fxch,[
#define __LIBC_INTERNAL_MATH_INLINES 1
#define __OPTIMIZE__
#include <math.h>
],bad=maybe,bad=no)
if test ${bad} = "maybe" ;then
AC_EGREP_CPP(log10.*fldlg2.*fxch.*st\([[0123456789]]*\),
[
#define __LIBC_INTERNAL_MATH_INLINES 1
#define __OPTIMIZE__
#include <math.h>
],bad=no,bad=yes)
fi
if test ${bad} = "yes" ;then
AC_MSG_WARN([ ])
AC_MSG_WARN([********************************************************])
AC_MSG_WARN([* The glibc headers on this machine have a serious bug *])
AC_MSG_WARN([* in /usr/include/bits/mathinline.h This bug affects *])
AC_MSG_WARN([* all floating point code, not just Ogg, built on this *])
AC_MSG_WARN([* machine. Upgrading to glibc 2.1.3 is strongly urged *])
AC_MSG_WARN([* to correct the problem. Note that upgrading glibc *])
AC_MSG_WARN([* will not fix any previously built programs; this is *])
AC_MSG_WARN([* a compile-time bug. *])
AC_MSG_WARN([* To work around the problem for this build of Ogg, *])
AC_MSG_WARN([* autoconf is disabling all math inlining. This will *])
AC_MSG_WARN([* hurt Ogg performace but is necessary for an Ogg that *])
AC_MSG_WARN([* will actually work. Once glibc is upgraded, rerun *])
AC_MSG_WARN([* configure and make to build with inlining. *])
AC_MSG_WARN([********************************************************])
AC_MSG_WARN([ ])
CFLAGS=${OPT}" -D__NO_MATH_INLINES"
PROFILE=${PROFILE}" -D__NO_MATH_INLINES"
fi;;
powerpc-*-linux*spe)
DEBUG="-g -Wall -Wextra -D_REENTRANT -D__NO_MATH_INLINES"
CFLAGS="-O3 -Wall -Wextra -ffast-math -mfused-madd -D_REENTRANT"
PROFILE="-pg -g -O3 -ffast-math -mfused-madd -D_REENTRANT";;
powerpc-*-linux*)
DEBUG="-g -Wall -Wextra -D_REENTRANT -D__NO_MATH_INLINES"
CFLAGS="-O3 -Wall -Wextra -ffast-math -mfused-madd -mcpu=750 -D_REENTRANT"
PROFILE="-pg -g -O3 -ffast-math -mfused-madd -mcpu=750 -D_REENTRANT";;
*-*-linux*)
DEBUG="-g -Wall -Wextra -D_REENTRANT -D__NO_MATH_INLINES -fsigned-char"
CFLAGS="-O3 -Wall -Wextra -ffast-math -D_REENTRANT -fsigned-char"
PROFILE="-pg -g -O3 -ffast-math -D_REENTRANT -fsigned-char";;
sparc-sun-*)
sparc_cpu=""
AC_MSG_CHECKING([if gcc supports -mv8])
old_cflags="$CFLAGS"
CFLAGS="$CFLAGS -mv8"
AC_TRY_COMPILE(, [return 0;], [
AC_MSG_RESULT([yes])
sparc_cpu="-mv8"
])
CFLAGS="$old_cflags"
DEBUG="-g -Wall -Wextra -D__NO_MATH_INLINES -fsigned-char $sparc_cpu"
CFLAGS="-O3 -Wall -Wextra -ffast-math -D__NO_MATH_INLINES -fsigned-char $sparc_cpu"
PROFILE="-pg -g -O3 -D__NO_MATH_INLINES -fsigned-char $sparc_cpu" ;;
*-*-darwin*)
DEBUG="-DDARWIN -fno-common -force_cpusubtype_ALL -Wall -g -O0 -fsigned-char"
CFLAGS="-DDARWIN -fno-common -force_cpusubtype_ALL -Wall -g -O3 -ffast-math -fsigned-char"
PROFILE="-DDARWIN -fno-common -force_cpusubtype_ALL -Wall -g -pg -O3 -ffast-math -fsigned-char";;
*-*-os2*)
# Use -W instead of -Wextra because gcc on OS/2 is an old version.
DEBUG="-g -Wall -W -D_REENTRANT -D__NO_MATH_INLINES -fsigned-char"
CFLAGS="-O3 -Wall -W -ffast-math -D_REENTRANT -fsigned-char"
PROFILE="-pg -g -O3 -ffast-math -D_REENTRANT -fsigned-char";;
*)
DEBUG="-g -Wall -Wextra -D__NO_MATH_INLINES -fsigned-char"
CFLAGS="-O3 -Wall -Wextra -D__NO_MATH_INLINES -fsigned-char"
PROFILE="-O3 -g -pg -D__NO_MATH_INLINES -fsigned-char" ;;
esac
AC_ADD_CFLAGS([-Wdeclaration-after-statement])
fi
CFLAGS="$CFLAGS $cflags_save"
dnl --------------------------------------------------
dnl Check for headers
dnl --------------------------------------------------
AC_CHECK_HEADER(memory.h,CFLAGS="$CFLAGS -DUSE_MEMORY_H",:)
dnl --------------------------------------------------
dnl Check for typedefs, structures, etc
dnl --------------------------------------------------
dnl none
dnl --------------------------------------------------
dnl Check for libraries
dnl --------------------------------------------------
AC_CHECK_LIB(m, cos, VORBIS_LIBS="-lm", VORBIS_LIBS="")
AC_CHECK_LIB(pthread, pthread_create, pthread_lib="-lpthread", :)
PKG_PROG_PKG_CONFIG
HAVE_OGG=no
if test "x$PKG_CONFIG" != "x"
then
PKG_CHECK_MODULES(OGG, ogg >= 1.0, HAVE_OGG=yes, HAVE_OGG=no)
fi
if test "x$HAVE_OGG" = "xno"
then
dnl fall back to the old school test
XIPH_PATH_OGG(, AC_MSG_ERROR(must have Ogg installed!))
libs_save=$LIBS
LIBS="$OGG_LIBS $VORBIS_LIBS"
AC_CHECK_FUNC(oggpack_writealign, , AC_MSG_ERROR(Ogg >= 1.0 required !))
LIBS=$libs_save
fi
dnl --------------------------------------------------
dnl Check for library functions
dnl --------------------------------------------------
AC_FUNC_ALLOCA
AC_FUNC_MEMCMP
dnl --------------------------------------------------
dnl Do substitutions
dnl --------------------------------------------------
AC_SUBST(VORBIS_LIBS)
AC_SUBST(DEBUG)
AC_SUBST(PROFILE)
AC_SUBST(pthread_lib)
dnl The following line causes the libtool distributed with the source
dnl to be replaced if the build system has a more recent version.
AC_SUBST(LIBTOOL_DEPS)
AC_CONFIG_FILES([
Makefile
m4/Makefile
lib/Makefile
lib/modes/Makefile
lib/books/Makefile
lib/books/coupled/Makefile
lib/books/uncoupled/Makefile
lib/books/floor/Makefile
doc/Makefile doc/vorbisfile/Makefile doc/vorbisenc/Makefile doc/libvorbis/Makefile
doc/Doxyfile
include/Makefile include/vorbis/Makefile
examples/Makefile
test/Makefile
vq/Makefile
libvorbis.spec
vorbis.pc
vorbisenc.pc
vorbisfile.pc
vorbis-uninstalled.pc
vorbisenc-uninstalled.pc
vorbisfile-uninstalled.pc
])
AC_CONFIG_HEADERS([config.h])
AC_OUTPUT

208
rhubarb/lib/vorbis-1.3.6/debian/changelog Normal file
View File

@ -0,0 +1,208 @@
libvorbis (1.2.0.dfsg-3.1) unstable; urgency=high
* Non-maintainer upload by the security team
* Fix integer overflows (and possible DoS attacks) via crafted
OGG files (Closes: #482518)
Fixes: CVE-2008-1423, CVE-2008-1420, CVE-2008-1419
-- Steffen Joeris <white@debian.org> Mon, 26 May 2008 12:48:06 +0000
libvorbis (1.2.0.dfsg-3) unstable; urgency=low
* Use dpkg-gensymbols, with symbol files obtained from Mole (stripping
debian revision and .dfsg suffix).
* Install upstream CHANGES file as changelog.gz. (Closes: #302037)
* Bump debian/compat to 5, and Standards-Version to 3.7.3 (no changes
needed).
* Use quilt.make in debian/rules.
-- Adeodato Simó <dato@net.com.org.es> Thu, 27 Dec 2007 14:33:45 +0100
libvorbis (1.2.0.dfsg-2) unstable; urgency=high
* Bump shlibs for libvorbis0a due to new vorbis_synthesis_idheader header.
(Closes: #436083)
-- Adeodato Simó <dato@net.com.org.es> Tue, 14 Aug 2007 20:55:54 +0200
libvorbis (1.2.0.dfsg-1) unstable; urgency=low
[ Adeodato Simó ]
* Use ${binary:Version} instead of ${Source-Version}.
[ Clint Adams ]
* New upstream release.
- Remove upstream_r13198-fix_segfault_in_ov_time_seek.diff .
* Bump shlibs for libvorbisfile3 to >= 1.2.0 due to new ov_fopen
function.
-- Clint Adams <schizo@debian.org> Fri, 27 Jul 2007 02:57:44 -0400
libvorbis (1.1.2.dfsg-2) unstable; urgency=low
* Bump to Standards-Version 3.7.2.
* Add upstream_r13198-fix_segfault_in_ov_time_seek.diff. closes: #281995.
-- Clint Adams <schizo@debian.org> Fri, 29 Jun 2007 09:46:12 -0400
libvorbis (1.1.2.dfsg-1.2) unstable; urgency=high
* Fix shlibs files for libvorbisenc and libvorbisfile, which were broken
by my first NMU to have dependencies for libvorbis0a. Closes: #395048
-- Joey Hess <joeyh@debian.org> Tue, 24 Oct 2006 19:55:19 -0400
libvorbis (1.1.2.dfsg-1.1) unstable; urgency=low
* NMU
* Remove draft RFC files, as they are not under a free license.
Closes: #390660
* Repackage the source package without these files.
* Add README.Source documenting how the upstream source is repackaged.
* Modify dh_makeshlibs call to avoid generating a shlibs file that has
an unncessarily tight versioned dependency on this new pseudo-version
of libvorbis.
-- Joey Hess <joeyh@debian.org> Sun, 15 Oct 2006 17:21:37 -0400
libvorbis (1.1.2-1) unstable; urgency=low
* Switch maintenance to the Debian Xiph.org Maintainers (alioth/pkg-xiph).
* New upstream release packaged. (Closes: #327586)
* Move HTML documentation from /usr/share/doc/libvorbis-dev itself to an
html/ subdirectory of it.
* Update debian/control:
+ drop unnecessary build-dependency on devscripts.
+ drop version restriction on debhelper and libogg-dev build-dependencies,
since they're already satisfied with stable.
* Overhaul debian/rules, and switch to quilt for patch management.
* Add debian/compat file, instead of exporting DH_COMPAT.
* Update download URL in debian/copyright.
* Add debian/watch file.
* Bumped Standards-Version to 3.6.2 (no changes required).
-- Adeodato Simó <dato@net.com.org.es> Thu, 26 Jan 2006 01:35:39 +0100
libvorbis (1.1.0-1) unstable; urgency=low
* New upstream.
-- Christopher L Cheney <ccheney@debian.org> Thu, 17 Mar 2005 21:30:00 -0600
libvorbis (1.0.1-1) unstable; urgency=low
* New upstream.
* Improved descriptions. (Closes: #166649)
* Updated DEB_BUILD_OPTIONS support. (Closes: #188464)
-- Christopher L Cheney <ccheney@debian.org> Tue, 9 Dec 2003 01:00:00 -0600
libvorbis (1.0.0-3) unstable; urgency=low
* Add libvorbis0 conflict to libvorbis0a.
-- Christopher L Cheney <ccheney@debian.org> Wed, 12 Mar 2003 17:00:00 -0600
libvorbis (1.0.0-2) unstable; urgency=low
* Rename libvorbis0 -> libvorbis0a to keep packages from upgrading to it
by mistake. (Closes: #156227, #156365, #161961, #171548, #172466,
#172469, #178756)
* GNU config automated update: config.sub (20020621 to 20030103),
config.guess (20020529 to 20030110)
-- Christopher L Cheney <ccheney@debian.org> Sat, 8 Mar 2003 13:00:00 -0600
libvorbis (1.0.0-1) unstable; urgency=low
* New upstream.
* Split libvorbis package into libvorbis libvorbisenc libvorbisfile due to
shared object major versions going out of sync.
-- Christopher L Cheney <ccheney@debian.org> Fri, 19 Jul 2002 09:00:00 -0500
libvorbis (1.0rc3-1) unstable; urgency=low
* New upstream. (Closes: #121995, #123472)
* added autotools target (config.* updater) to rules
-- Christopher L Cheney <ccheney@debian.org> Mon, 24 Dec 2001 11:00:00 -0600
libvorbis (1.0rc2-1) unstable; urgency=low
* New upstream.
-- Christopher L Cheney <ccheney@debian.org> Sun, 12 Aug 2001 22:00:00 -0500
libvorbis (1.0rc1-1) unstable; urgency=low
* New upstream. (Closes: #84977, #95330)
* Upstream says lame at fault. See bug details. (Closes: #98010)
* Fixed versioned depends.
* Changed clean method to distclean.
-- Christopher L Cheney <ccheney@debian.org> Sun, 17 Jun 2001 20:00:00 -0500
libvorbis (1.0beta4-1) unstable; urgency=low
* New upstream.
* Appears to be fixed, can't reproduce bug (closes: #78848)
-- Christopher L Cheney <ccheney@debian.org> Mon, 26 Feb 2001 08:00:00 -0600
libvorbis (1.0beta3-3) unstable; urgency=low
* Fixed Build-Depends libogg-dev version dependency.
* Fixed Sections.
* Updated to Standards-Version to 3.5.1.0
-- Christopher L Cheney <ccheney@debian.org> Sat, 17 Feb 2001 18:14:53 -0600
libvorbis (1.0beta3-2) unstable; urgency=low
* Added dependency for libogg-dev (closes: #78262)
* Added dependency for libogg-dev (closes: #81432)
* Corrected development library package name (closes: #82464)
-- Christopher L Cheney <ccheney@debian.org> Sat, 3 Feb 2001 13:29:30 -0600
libvorbis (1.0beta3-1) unstable; urgency=low
* New Maintainer.
* Upstream source was reorganized.
* Package split according to the upstream reorganization.
-- Christopher L Cheney <ccheney@debian.org> Tue, 31 Oct 2000 15:08:22 -0600
vorbis (1.0beta2-1) unstable; urgency=low
* New upstream version. Closes: #67326, #68416
* Changed xmms-vorbis to Architechture: any. Closes: #67395
* Added Build-deps. Closes: #66628
* Moved vorbize to vorbis-tools along with oggenc and vorbiscomment
-- Michael Beattie <mjb@debian.org> Wed, 9 Aug 2000 00:30:15 +1200
vorbis (1.0beta1-1) unstable; urgency=low
* First Beta, Ready for debian release.
-- Michael Beattie <mickyb@es.co.nz> Fri, 30 Jun 2000 19:26:59 +1200
vorbis (0.0-1) unstable; urgency=low
* Initial Release.
* Initial package, not placed in archive.
-- Michael Beattie <mickyb@es.co.nz> Mon, 26 Jun 2000 18:59:56 +1200

60
rhubarb/lib/vorbis-1.3.6/debian/control Normal file
View File

@ -0,0 +1,60 @@
Source: libvorbis
Section: libs
Priority: optional
Maintainer: Christopher L Cheney <ccheney@debian.org>
Build-Depends: autotools-dev, debhelper (>> 4.0.18), devscripts, libogg-dev (>> 1.1.0)
Standards-Version: 3.6.1.0
Package: libvorbis0a
Architecture: any
Section: libs
Depends: ${shlibs:Depends}
Conflicts: libvorbis0
Replaces: libvorbis0
Description: The Vorbis General Audio Compression Codec
Ogg Vorbis is a fully open, non-proprietary, patent-and-royalty-free,
general-purpose compressed audio format for audio and music at fixed
and variable bitrates from 16 to 128 kbps/channel.
.
The Vorbis library is the primary Ogg Vorbis library.
Package: libvorbisenc2
Architecture: any
Section: libs
Depends: ${shlibs:Depends}
Conflicts: libvorbis0 (<< 1.0.0)
Replaces: libvorbis0 (<< 1.0.0)
Description: The Vorbis General Audio Compression Codec
Ogg Vorbis is a fully open, non-proprietary, patent-and-royalty-free,
general-purpose compressed audio format for audio and music at fixed
and variable bitrates from 16 to 128 kbps/channel.
.
The Vorbisenc library provides a convenient API for setting up an encoding
environment using libvorbis.
Package: libvorbisfile3
Architecture: any
Section: libs
Depends: ${shlibs:Depends}
Conflicts: libvorbis0 (<< 1.0.0)
Replaces: libvorbis0 (<< 1.0.0)
Description: The Vorbis General Audio Compression Codec
Ogg Vorbis is a fully open, non-proprietary, patent-and-royalty-free,
general-purpose compressed audio format for audio and music at fixed
and variable bitrates from 16 to 128 kbps/channel.
.
The Vorbisfile library provides a convenient high-level API for decoding
and basic manipulation of all Vorbis I audio streams.
Package: libvorbis-dev
Architecture: any
Section: libdevel
Depends: libogg-dev, libvorbis0a (= ${Source-Version}), libvorbisenc2 (= ${Source-Version}), libvorbisfile3 (= ${Source-Version})
Description: The Vorbis General Audio Compression Codec (development files)
Ogg Vorbis is a fully open, non-proprietary, patent-and-royalty-free,
general-purpose compressed audio format for audio and music at fixed
and variable bitrates from 16 to 128 kbps/channel.
.
This package contains the header files and documentation needed to develop
applications with libvorbis.

38
rhubarb/lib/vorbis-1.3.6/debian/copyright Normal file
View File

@ -0,0 +1,38 @@
This package was debianized by Christopher L Cheney <ccheney@debian.org> on
Tue, 31 Oct 2000 15:08:22 -0600.
It was downloaded from http://www.vorbis.com/download_unix.psp
Upstream Author: Monty <monty@xiph.org>
Copyright:
Copyright (c) 2002, Xiph.org Foundation
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
- Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
- Neither the name of the Xiph.org Foundation nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

1
rhubarb/lib/vorbis-1.3.6/debian/libvorbis-dev.docs Normal file
View File

@ -0,0 +1 @@
debian/tmp/usr/share/doc/libvorbis-*/*

2
rhubarb/lib/vorbis-1.3.6/debian/libvorbis-dev.examples Normal file
View File

@ -0,0 +1,2 @@
examples/*.c
examples/*.pl

16
rhubarb/lib/vorbis-1.3.6/debian/libvorbis-dev.install Normal file
View File

@ -0,0 +1,16 @@
debian/tmp/usr/include/vorbis/codec.h
debian/tmp/usr/include/vorbis/vorbisenc.h
debian/tmp/usr/include/vorbis/vorbisfile.h
debian/tmp/usr/lib/libvorbis.a
debian/tmp/usr/lib/libvorbis.la
debian/tmp/usr/lib/libvorbis.so
debian/tmp/usr/lib/libvorbisenc.a
debian/tmp/usr/lib/libvorbisenc.la
debian/tmp/usr/lib/libvorbisenc.so
debian/tmp/usr/lib/libvorbisfile.a
debian/tmp/usr/lib/libvorbisfile.la
debian/tmp/usr/lib/libvorbisfile.so
debian/tmp/usr/lib/pkgconfig/vorbis.pc
debian/tmp/usr/lib/pkgconfig/vorbisenc.pc
debian/tmp/usr/lib/pkgconfig/vorbisfile.pc
debian/tmp/usr/share/aclocal/vorbis.m4

1
rhubarb/lib/vorbis-1.3.6/debian/libvorbis0a.install Normal file
View File

@ -0,0 +1 @@
debian/tmp/usr/lib/libvorbis.so.*

1
rhubarb/lib/vorbis-1.3.6/debian/libvorbisenc2.install Normal file
View File

@ -0,0 +1 @@
debian/tmp/usr/lib/libvorbisenc.so.*

1
rhubarb/lib/vorbis-1.3.6/debian/libvorbisfile3.install Normal file
View File

@ -0,0 +1 @@
debian/tmp/usr/lib/libvorbisfile.so.*

154
rhubarb/lib/vorbis-1.3.6/debian/rules Normal file
View File

@ -0,0 +1,154 @@
#!/usr/bin/make -f
# Sample debian/rules that uses debhelper.
# GNU copyright 1997 to 1999 by Joey Hess.
#
# Modified to make a template file for a multi-binary package with separated
# build-arch and build-indep targets by Bill Allombert 2001
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
# This is the debhelper compatibility version to use.
export DH_COMPAT=4
# This has to be exported to make some magic below work.
export DH_OPTIONS
# These are used for cross-compiling and for saving the configure script
# from having to guess our platform (since we know it already)
DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
objdir = $(CURDIR)/obj-$(DEB_BUILD_GNU_TYPE)
CFLAGS = -Wall -g
ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O0
else
CFLAGS += -O2
endif
ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
INSTALL_PROGRAM += -s
endif
configure: configure-stamp
configure-stamp:
dh_testdir
# make build directory
mkdir $(objdir)
# run configure with build tree $(objdir)
# change ../configure to ../autogen.sh for CVS build
cd $(objdir) && \
../configure --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE) \
--prefix=/usr --enable-static
touch configure-stamp
#Architecture
build: build-arch build-indep
build-arch: build-arch-stamp
build-arch-stamp: configure-stamp
cd $(objdir) && \
$(MAKE)
touch build-arch-stamp
build-indep: build-indep-stamp
build-indep-stamp: configure-stamp
# Add here commands to compile the indep part of the package.
#$(MAKE) doc
touch build-indep-stamp
debian-clean:
dh_testdir
dh_testroot
dh_clean
clean:
dh_testdir
dh_testroot
rm -f build-arch-stamp build-indep-stamp configure-stamp
# Remove build tree
rm -rf $(objdir)
# if Makefile exists run distclean
if test -f Makefile; then \
$(MAKE) distclean; \
fi
#if test -d CVS; then \
$(MAKE) cvs-clean ;\
fi
dh_clean
install: install-indep install-arch
install-indep:
dh_testdir
dh_testroot
# dh_clean -k -i
# dh_installdirs -i
# dh_install -i --list-missing
install-arch:
dh_testdir
dh_testroot
dh_clean -k -s
dh_installdirs -s
cd $(objdir) && \
$(MAKE) install DESTDIR=$(CURDIR)/debian/tmp
dh_install -s --list-missing
# Must not depend on anything. This is to be called by
# binary-arch/binary-indep
# in another 'make' thread.
binary-common:
dh_testdir
dh_testroot
dh_installchangelogs CHANGES
dh_installdocs
dh_installexamples
# dh_installmenu
# dh_installdebconf
# dh_installlogrotate
# dh_installemacsen
# dh_installpam
# dh_installmime
# dh_installinit
# dh_installcron
# dh_installinfo
dh_installman
dh_link
dh_strip
dh_compress
dh_fixperms
# dh_perl
# dh_python
dh_makeshlibs -V
dh_installdeb
dh_shlibdeps -ldebian/libvorbis0a/usr/lib
dh_gencontrol
dh_md5sums
dh_builddeb
# Build architecture independant packages using the common target.
binary-indep: build-indep install-indep
# $(MAKE) -f debian/rules DH_OPTIONS=-i binary-common
# Build architecture dependant packages using the common target.
binary-arch: build-arch install-arch
$(MAKE) -f debian/rules DH_OPTIONS=-a binary-common
binary: binary-arch binary-indep
.PHONY: build clean binary-indep binary-arch binary install install-indep install-arch configure

3
rhubarb/lib/vorbis-1.3.6/debian/watch Normal file
View File

@ -0,0 +1,3 @@
version=2
http://downloads.xiph.org/releases/vorbis/libvorbis-(.*)\.tar\.gz debian uupdate

528
rhubarb/lib/vorbis-1.3.6/doc/01-introduction.tex Normal file
View File

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

246
rhubarb/lib/vorbis-1.3.6/doc/02-bitpacking.tex Normal file
View File

@ -0,0 +1,246 @@
% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*-
%!TEX root = Vorbis_I_spec.tex
\section{Bitpacking Convention} \label{vorbis:spec:bitpacking}
\subsection{Overview}
The Vorbis codec uses relatively unstructured raw packets containing
arbitrary-width binary integer fields. Logically, these packets are a
bitstream in which bits are coded one-by-one by the encoder and then
read one-by-one in the same monotonically increasing order by the
decoder. Most current binary storage arrangements group bits into a
native word size of eight bits (octets), sixteen bits, thirty-two bits
or, less commonly other fixed word sizes. The Vorbis bitpacking
convention specifies the correct mapping of the logical packet
bitstream into an actual representation in fixed-width words.
\subsubsection{octets, bytes and words}
In most contemporary architectures, a 'byte' is synonymous with an
'octet', that is, eight bits. This has not always been the case;
seven, ten, eleven and sixteen bit 'bytes' have been used. For
purposes of the bitpacking convention, a byte implies the native,
smallest integer storage representation offered by a platform. On
modern platforms, this is generally assumed to be eight bits (not
necessarily because of the processor but because of the
filesystem/memory architecture. Modern filesystems invariably offer
bytes as the fundamental atom of storage). A 'word' is an integer
size that is a grouped multiple of this smallest size.
The most ubiquitous architectures today consider a 'byte' to be an
octet (eight bits) and a word to be a group of two, four or eight
bytes (16, 32 or 64 bits). Note however that the Vorbis bitpacking
convention is still well defined for any native byte size; Vorbis uses
the native bit-width of a given storage system. This document assumes
that a byte is one octet for purposes of example.
\subsubsection{bit order}
A byte has a well-defined 'least significant' bit (LSb), which is the
only bit set when the byte is storing the two's complement integer
value +1. A byte's 'most significant' bit (MSb) is at the opposite
end of the byte. Bits in a byte are numbered from zero at the LSb to
$n$ ($n=7$ in an octet) for the
MSb.
\subsubsection{byte order}
Words are native groupings of multiple bytes. Several byte orderings
are possible in a word; the common ones are 3-2-1-0 ('big endian' or
'most significant byte first' in which the highest-valued byte comes
first), 0-1-2-3 ('little endian' or 'least significant byte first' in
which the lowest value byte comes first) and less commonly 3-1-2-0 and
0-2-1-3 ('mixed endian').
The Vorbis bitpacking convention specifies storage and bitstream
manipulation at the byte, not word, level, thus host word ordering is
of a concern only during optimization when writing high performance
code that operates on a word of storage at a time rather than by byte.
Logically, bytes are always coded and decoded in order from byte zero
through byte $n$.
\subsubsection{coding bits into byte sequences}
The Vorbis codec has need to code arbitrary bit-width integers, from
zero to 32 bits wide, into packets. These integer fields are not
aligned to the boundaries of the byte representation; the next field
is written at the bit position at which the previous field ends.
The encoder logically packs integers by writing the LSb of a binary
integer to the logical bitstream first, followed by next least
significant bit, etc, until the requested number of bits have been
coded. When packing the bits into bytes, the encoder begins by
placing the LSb of the integer to be written into the least
significant unused bit position of the destination byte, followed by
the next-least significant bit of the source integer and so on up to
the requested number of bits. When all bits of the destination byte
have been filled, encoding continues by zeroing all bits of the next
byte and writing the next bit into the bit position 0 of that byte.
Decoding follows the same process as encoding, but by reading bits
from the byte stream and reassembling them into integers.
\subsubsection{signedness}
The signedness of a specific number resulting from decode is to be
interpreted by the decoder given decode context. That is, the three
bit binary pattern 'b111' can be taken to represent either 'seven' as
an unsigned integer, or '-1' as a signed, two's complement integer.
The encoder and decoder are responsible for knowing if fields are to
be treated as signed or unsigned.
\subsubsection{coding example}
Code the 4 bit integer value '12' [b1100] into an empty bytestream.
Bytestream result:
\begin{Verbatim}[commandchars=\\\{\}]
|
V
7 6 5 4 3 2 1 0
byte 0 [0 0 0 0 1 1 0 0] <-
byte 1 [ ]
byte 2 [ ]
byte 3 [ ]
...
byte n [ ] bytestream length == 1 byte
\end{Verbatim}
Continue by coding the 3 bit integer value '-1' [b111]:
\begin{Verbatim}[commandchars=\\\{\}]
|
V
7 6 5 4 3 2 1 0
byte 0 [0 1 1 1 1 1 0 0] <-
byte 1 [ ]
byte 2 [ ]
byte 3 [ ]
...
byte n [ ] bytestream length == 1 byte
\end{Verbatim}
Continue by coding the 7 bit integer value '17' [b0010001]:
\begin{Verbatim}[commandchars=\\\{\}]
|
V
7 6 5 4 3 2 1 0
byte 0 [1 1 1 1 1 1 0 0]
byte 1 [0 0 0 0 1 0 0 0] <-
byte 2 [ ]
byte 3 [ ]
...
byte n [ ] bytestream length == 2 bytes
bit cursor == 6
\end{Verbatim}
Continue by coding the 13 bit integer value '6969' [b110 11001110 01]:
\begin{Verbatim}[commandchars=\\\{\}]
|
V
7 6 5 4 3 2 1 0
byte 0 [1 1 1 1 1 1 0 0]
byte 1 [0 1 0 0 1 0 0 0]
byte 2 [1 1 0 0 1 1 1 0]
byte 3 [0 0 0 0 0 1 1 0] <-
...
byte n [ ] bytestream length == 4 bytes
\end{Verbatim}
\subsubsection{decoding example}
Reading from the beginning of the bytestream encoded in the above example:
\begin{Verbatim}[commandchars=\\\{\}]
|
V
7 6 5 4 3 2 1 0
byte 0 [1 1 1 1 1 1 0 0] <-
byte 1 [0 1 0 0 1 0 0 0]
byte 2 [1 1 0 0 1 1 1 0]
byte 3 [0 0 0 0 0 1 1 0] bytestream length == 4 bytes
\end{Verbatim}
We read two, two-bit integer fields, resulting in the returned numbers
'b00' and 'b11'. Two things are worth noting here:
\begin{itemize}
\item Although these four bits were originally written as a single
four-bit integer, reading some other combination of bit-widths from the
bitstream is well defined. There are no artificial alignment
boundaries maintained in the bitstream.
\item The second value is the
two-bit-wide integer 'b11'. This value may be interpreted either as
the unsigned value '3', or the signed value '-1'. Signedness is
dependent on decode context.
\end{itemize}
\subsubsection{end-of-packet alignment}
The typical use of bitpacking is to produce many independent
byte-aligned packets which are embedded into a larger byte-aligned
container structure, such as an Ogg transport bitstream. Externally,
each bytestream (encoded bitstream) must begin and end on a byte
boundary. Often, the encoded bitstream is not an integer number of
bytes, and so there is unused (uncoded) space in the last byte of a
packet.
Unused space in the last byte of a bytestream is always zeroed during
the coding process. Thus, should this unused space be read, it will
return binary zeroes.
Attempting to read past the end of an encoded packet results in an
'end-of-packet' condition. End-of-packet is not to be considered an
error; it is merely a state indicating that there is insufficient
remaining data to fulfill the desired read size. Vorbis uses truncated
packets as a normal mode of operation, and as such, decoders must
handle reading past the end of a packet as a typical mode of
operation. Any further read operations after an 'end-of-packet'
condition shall also return 'end-of-packet'.
\subsubsection{reading zero bits}
Reading a zero-bit-wide integer returns the value '0' and does not
increment the stream cursor. Reading to the end of the packet (but
not past, such that an 'end-of-packet' condition has not triggered)
and then reading a zero bit integer shall succeed, returning 0, and
not trigger an end-of-packet condition. Reading a zero-bit-wide
integer after a previous read sets 'end-of-packet' shall also fail
with 'end-of-packet'.

456
rhubarb/lib/vorbis-1.3.6/doc/03-codebook.tex Normal file
View File

@ -0,0 +1,456 @@
% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*-
%!TEX root = Vorbis_I_spec.tex
\section{Probability Model and Codebooks} \label{vorbis:spec:codebook}
\subsection{Overview}
Unlike practically every other mainstream audio codec, Vorbis has no
statically configured probability model, instead packing all entropy
decoding configuration, VQ and Huffman, into the bitstream itself in
the third header, the codec setup header. This packed configuration
consists of multiple 'codebooks', each containing a specific
Huffman-equivalent representation for decoding compressed codewords as
well as an optional lookup table of output vector values to which a
decoded Huffman value is applied as an offset, generating the final
decoded output corresponding to a given compressed codeword.
\subsubsection{Bitwise operation}
The codebook mechanism is built on top of the vorbis bitpacker. Both
the codebooks themselves and the codewords they decode are unrolled
from a packet as a series of arbitrary-width values read from the
stream according to \xref{vorbis:spec:bitpacking}.
\subsection{Packed codebook format}
For purposes of the examples below, we assume that the storage
system's native byte width is eight bits. This is not universally
true; see \xref{vorbis:spec:bitpacking} for discussion
relating to non-eight-bit bytes.
\subsubsection{codebook decode}
A codebook begins with a 24 bit sync pattern, 0x564342:
\begin{Verbatim}[commandchars=\\\{\}]
byte 0: [ 0 1 0 0 0 0 1 0 ] (0x42)
byte 1: [ 0 1 0 0 0 0 1 1 ] (0x43)
byte 2: [ 0 1 0 1 0 1 1 0 ] (0x56)
\end{Verbatim}
16 bit \varname{[codebook\_dimensions]} and 24 bit \varname{[codebook\_entries]} fields:
\begin{Verbatim}[commandchars=\\\{\}]
byte 3: [ X X X X X X X X ]
byte 4: [ X X X X X X X X ] [codebook\_dimensions] (16 bit unsigned)
byte 5: [ X X X X X X X X ]
byte 6: [ X X X X X X X X ]
byte 7: [ X X X X X X X X ] [codebook\_entries] (24 bit unsigned)
\end{Verbatim}
Next is the \varname{[ordered]} bit flag:
\begin{Verbatim}[commandchars=\\\{\}]
byte 8: [ X ] [ordered] (1 bit)
\end{Verbatim}
Each entry, numbering a
total of \varname{[codebook\_entries]}, is assigned a codeword length.
We now read the list of codeword lengths and store these lengths in
the array \varname{[codebook\_codeword\_lengths]}. Decode of lengths is
according to whether the \varname{[ordered]} flag is set or unset.
\begin{itemize}
\item
If the \varname{[ordered]} flag is unset, the codeword list is not
length ordered and the decoder needs to read each codeword length
one-by-one.
The decoder first reads one additional bit flag, the
\varname{[sparse]} flag. This flag determines whether or not the
codebook contains unused entries that are not to be included in the
codeword decode tree:
\begin{Verbatim}[commandchars=\\\{\}]
byte 8: [ X 1 ] [sparse] flag (1 bit)
\end{Verbatim}
The decoder now performs for each of the \varname{[codebook\_entries]}
codebook entries:
\begin{Verbatim}[commandchars=\\\{\}]
1) if([sparse] is set) \{
2) [flag] = read one bit;
3) if([flag] is set) \{
4) [length] = read a five bit unsigned integer;
5) codeword length for this entry is [length]+1;
\} else \{
6) this entry is unused. mark it as such.
\}
\} else the sparse flag is not set \{
7) [length] = read a five bit unsigned integer;
8) the codeword length for this entry is [length]+1;
\}
\end{Verbatim}
\item
If the \varname{[ordered]} flag is set, the codeword list for this
codebook is encoded in ascending length order. Rather than reading
a length for every codeword, the encoder reads the number of
codewords per length. That is, beginning at entry zero:
\begin{Verbatim}[commandchars=\\\{\}]
1) [current\_entry] = 0;
2) [current\_length] = read a five bit unsigned integer and add 1;
3) [number] = read \link{vorbis:spec:ilog}{ilog}([codebook\_entries] - [current\_entry]) bits as an unsigned integer
4) set the entries [current\_entry] through [current\_entry]+[number]-1, inclusive,
of the [codebook\_codeword\_lengths] array to [current\_length]
5) set [current\_entry] to [number] + [current\_entry]
6) increment [current\_length] by 1
7) if [current\_entry] is greater than [codebook\_entries] ERROR CONDITION;
the decoder will not be able to read this stream.
8) if [current\_entry] is less than [codebook\_entries], repeat process starting at 3)
9) done.
\end{Verbatim}
\end{itemize}
After all codeword lengths have been decoded, the decoder reads the
vector lookup table. Vorbis I supports three lookup types:
\begin{enumerate}
\item
No lookup
\item
Implicitly populated value mapping (lattice VQ)
\item
Explicitly populated value mapping (tessellated or 'foam'
VQ)
\end{enumerate}
The lookup table type is read as a four bit unsigned integer:
\begin{Verbatim}[commandchars=\\\{\}]
1) [codebook\_lookup\_type] = read four bits as an unsigned integer
\end{Verbatim}
Codebook decode precedes according to \varname{[codebook\_lookup\_type]}:
\begin{itemize}
\item
Lookup type zero indicates no lookup to be read. Proceed past
lookup decode.
\item
Lookup types one and two are similar, differing only in the
number of lookup values to be read. Lookup type one reads a list of
values that are permuted in a set pattern to build a list of vectors,
each vector of order \varname{[codebook\_dimensions]} scalars. Lookup
type two builds the same vector list, but reads each scalar for each
vector explicitly, rather than building vectors from a smaller list of
possible scalar values. Lookup decode proceeds as follows:
\begin{Verbatim}[commandchars=\\\{\}]
1) [codebook\_minimum\_value] = \link{vorbis:spec:float32:unpack}{float32\_unpack}( read 32 bits as an unsigned integer)
2) [codebook\_delta\_value] = \link{vorbis:spec:float32:unpack}{float32\_unpack}( read 32 bits as an unsigned integer)
3) [codebook\_value\_bits] = read 4 bits as an unsigned integer and add 1
4) [codebook\_sequence\_p] = read 1 bit as a boolean flag
if ( [codebook\_lookup\_type] is 1 ) \{
5) [codebook\_lookup\_values] = \link{vorbis:spec:lookup1:values}{lookup1\_values}(\varname{[codebook\_entries]}, \varname{[codebook\_dimensions]} )
\} else \{
6) [codebook\_lookup\_values] = \varname{[codebook\_entries]} * \varname{[codebook\_dimensions]}
\}
7) read a total of [codebook\_lookup\_values] unsigned integers of [codebook\_value\_bits] each;
store these in order in the array [codebook\_multiplicands]
\end{Verbatim}
\item
A \varname{[codebook\_lookup\_type]} of greater than two is reserved
and indicates a stream that is not decodable by the specification in this
document.
\end{itemize}
An 'end of packet' during any read operation in the above steps is
considered an error condition rendering the stream undecodable.
\paragraph{Huffman decision tree representation}
The \varname{[codebook\_codeword\_lengths]} array and
\varname{[codebook\_entries]} value uniquely define the Huffman decision
tree used for entropy decoding.
Briefly, each used codebook entry (recall that length-unordered
codebooks support unused codeword entries) is assigned, in order, the
lowest valued unused binary Huffman codeword possible. Assume the
following codeword length list:
\begin{Verbatim}[commandchars=\\\{\}]
entry 0: length 2
entry 1: length 4
entry 2: length 4
entry 3: length 4
entry 4: length 4
entry 5: length 2
entry 6: length 3
entry 7: length 3
\end{Verbatim}
Assigning codewords in order (lowest possible value of the appropriate
length to highest) results in the following codeword list:
\begin{Verbatim}[commandchars=\\\{\}]
entry 0: length 2 codeword 00
entry 1: length 4 codeword 0100
entry 2: length 4 codeword 0101
entry 3: length 4 codeword 0110
entry 4: length 4 codeword 0111
entry 5: length 2 codeword 10
entry 6: length 3 codeword 110
entry 7: length 3 codeword 111
\end{Verbatim}
\begin{note}
Unlike most binary numerical values in this document, we
intend the above codewords to be read and used bit by bit from left to
right, thus the codeword '001' is the bit string 'zero, zero, one'.
When determining 'lowest possible value' in the assignment definition
above, the leftmost bit is the MSb.
\end{note}
It is clear that the codeword length list represents a Huffman
decision tree with the entry numbers equivalent to the leaves numbered
left-to-right:
\begin{center}
\includegraphics[width=10cm]{hufftree}
\captionof{figure}{huffman tree illustration}
\end{center}
As we assign codewords in order, we see that each choice constructs a
new leaf in the leftmost possible position.
Note that it's possible to underspecify or overspecify a Huffman tree
via the length list. In the above example, if codeword seven were
eliminated, it's clear that the tree is unfinished:
\begin{center}
\includegraphics[width=10cm]{hufftree-under}
\captionof{figure}{underspecified huffman tree illustration}
\end{center}
Similarly, in the original codebook, it's clear that the tree is fully
populated and a ninth codeword is impossible. Both underspecified and
overspecified trees are an error condition rendering the stream
undecodable.
Codebook entries marked 'unused' are simply skipped in the assigning
process. They have no codeword and do not appear in the decision
tree, thus it's impossible for any bit pattern read from the stream to
decode to that entry number.
\paragraph{Errata 20150226: Single entry codebooks}
A 'single-entry codebook' is a codebook with one active codeword
entry. A single-entry codebook may be either a fully populated
codebook with only one declared entry, or a sparse codebook with only
one entry marked used. The Vorbis I spec provides no means to specify
a codeword length of zero, and as a result, a single-entry codebook is
inherently malformed because it is underpopulated. The original
specification did not address directly the matter of single-entry
codebooks; they were implicitly illegal as it was not possible to
write such a codebook with a valid tree structure.
In r14811 of the libvorbis reference implementation, Xiph added an
additional check to the codebook implementation to reject
underpopulated Huffman trees. This change led to the discovery of
single-entry books used 'in the wild' when the new, stricter checks
rejected a number of apparently working streams.
In order to minimize breakage of deployed (if technically erroneous)
streams, r16073 of the reference implementation explicitly
special-cased single-entry codebooks to tolerate the single-entry
case. Commit r16073 also added the following to the specification:
\blockquote{\sout{Take special care that a codebook with a single used
entry is handled properly; it consists of a single codework of
zero bits and ’reading’ a value out of such a codebook always
returns the single used value and sinks zero bits.
}}
The intent was to clarify the spec and codify current practice.
However, this addition is erroneously at odds with the intent of preserving
usability of existing streams using single-entry codebooks, disagrees
with the code changes that reinstated decoding, and does not address how
single-entry codebooks should be encoded.
As such, the above addition made in r16037 is struck from the
specification and replaced by the following:
\blockquote{It is possible to declare a Vorbis codebook containing a
single codework entry. A single-entry codebook may be either a
fully populated codebook with \varname{[codebook\_entries]} set to
1, or a sparse codebook marking only one entry used. Note that it
is not possible to also encode a \varname{[codeword\_length]} of
zero for the single used codeword, as the unsigned value written to
the stream is \varname{[codeword\_length]-1}. Instead, encoder
implementations should indicate a \varname{[codeword\_length]} of 1
and 'write' the codeword to a stream during audio encoding by
writing a single zero bit.
Decoder implementations shall reject a codebook if it contains only
one used entry and the encoded \varname{[codeword\_length]} of that
entry is not 1. 'Reading' a value from single-entry codebook always
returns the single used codeword value and sinks one bit. Decoders
should tolerate that the bit read from the stream be '1' instead of
'0'; both values shall return the single used codeword.}
\paragraph{VQ lookup table vector representation}
Unpacking the VQ lookup table vectors relies on the following values:
\begin{programlisting}
the [codebook\_multiplicands] array
[codebook\_minimum\_value]
[codebook\_delta\_value]
[codebook\_sequence\_p]
[codebook\_lookup\_type]
[codebook\_entries]
[codebook\_dimensions]
[codebook\_lookup\_values]
\end{programlisting}
\bigskip
Decoding (unpacking) a specific vector in the vector lookup table
proceeds according to \varname{[codebook\_lookup\_type]}. The unpacked
vector values are what a codebook would return during audio packet
decode in a VQ context.
\paragraph{Vector value decode: Lookup type 1}
Lookup type one specifies a lattice VQ lookup table built
algorithmically from a list of scalar values. Calculate (unpack) the
final values of a codebook entry vector from the entries in
\varname{[codebook\_multiplicands]} as follows (\varname{[value\_vector]}
is the output vector representing the vector of values for entry number
\varname{[lookup\_offset]} in this codebook):
\begin{Verbatim}[commandchars=\\\{\}]
1) [last] = 0;
2) [index\_divisor] = 1;
3) iterate [i] over the range 0 ... [codebook\_dimensions]-1 (once for each scalar value in the value vector) \{
4) [multiplicand\_offset] = ( [lookup\_offset] divided by [index\_divisor] using integer
division ) integer modulo [codebook\_lookup\_values]
5) vector [value\_vector] element [i] =
( [codebook\_multiplicands] array element number [multiplicand\_offset] ) *
[codebook\_delta\_value] + [codebook\_minimum\_value] + [last];
6) if ( [codebook\_sequence\_p] is set ) then set [last] = vector [value\_vector] element [i]
7) [index\_divisor] = [index\_divisor] * [codebook\_lookup\_values]
\}
8) vector calculation completed.
\end{Verbatim}
\paragraph{Vector value decode: Lookup type 2}
Lookup type two specifies a VQ lookup table in which each scalar in
each vector is explicitly set by the \varname{[codebook\_multiplicands]}
array in a one-to-one mapping. Calculate [unpack] the
final values of a codebook entry vector from the entries in
\varname{[codebook\_multiplicands]} as follows (\varname{[value\_vector]}
is the output vector representing the vector of values for entry number
\varname{[lookup\_offset]} in this codebook):
\begin{Verbatim}[commandchars=\\\{\}]
1) [last] = 0;
2) [multiplicand\_offset] = [lookup\_offset] * [codebook\_dimensions]
3) iterate [i] over the range 0 ... [codebook\_dimensions]-1 (once for each scalar value in the value vector) \{
4) vector [value\_vector] element [i] =
( [codebook\_multiplicands] array element number [multiplicand\_offset] ) *
[codebook\_delta\_value] + [codebook\_minimum\_value] + [last];
5) if ( [codebook\_sequence\_p] is set ) then set [last] = vector [value\_vector] element [i]
6) increment [multiplicand\_offset]
\}
7) vector calculation completed.
\end{Verbatim}
\subsection{Use of the codebook abstraction}
The decoder uses the codebook abstraction much as it does the
bit-unpacking convention; a specific codebook reads a
codeword from the bitstream, decoding it into an entry number, and then
returns that entry number to the decoder (when used in a scalar
entropy coding context), or uses that entry number as an offset into
the VQ lookup table, returning a vector of values (when used in a context
desiring a VQ value). Scalar or VQ context is always explicit; any call
to the codebook mechanism requests either a scalar entry number or a
lookup vector.
Note that VQ lookup type zero indicates that there is no lookup table;
requesting decode using a codebook of lookup type 0 in any context
expecting a vector return value (even in a case where a vector of
dimension one) is forbidden. If decoder setup or decode requests such
an action, that is an error condition rendering the packet
undecodable.
Using a codebook to read from the packet bitstream consists first of
reading and decoding the next codeword in the bitstream. The decoder
reads bits until the accumulated bits match a codeword in the
codebook. This process can be though of as logically walking the
Huffman decode tree by reading one bit at a time from the bitstream,
and using the bit as a decision boolean to take the 0 branch (left in
the above examples) or the 1 branch (right in the above examples).
Walking the tree finishes when the decode process hits a leaf in the
decision tree; the result is the entry number corresponding to that
leaf. Reading past the end of a packet propagates the 'end-of-stream'
condition to the decoder.
When used in a scalar context, the resulting codeword entry is the
desired return value.
When used in a VQ context, the codeword entry number is used as an
offset into the VQ lookup table. The value returned to the decoder is
the vector of scalars corresponding to this offset.

660
rhubarb/lib/vorbis-1.3.6/doc/04-codec.tex Normal file
View File

@ -0,0 +1,660 @@
% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*-
%!TEX root = Vorbis_I_spec.tex
\section{Codec Setup and Packet Decode} \label{vorbis:spec:codec}
\subsection{Overview}
This document serves as the top-level reference document for the
bit-by-bit decode specification of Vorbis I. This document assumes a
high-level understanding of the Vorbis decode process, which is
provided in \xref{vorbis:spec:intro}. \xref{vorbis:spec:bitpacking} covers reading and writing bit fields from
and to bitstream packets.
\subsection{Header decode and decode setup}
A Vorbis bitstream begins with three header packets. The header
packets are, in order, the identification header, the comments header,
and the setup header. All are required for decode compliance. An
end-of-packet condition during decoding the first or third header
packet renders the stream undecodable. End-of-packet decoding the
comment header is a non-fatal error condition.
\subsubsection{Common header decode}
Each header packet begins with the same header fields.
\begin{Verbatim}[commandchars=\\\{\}]
1) [packet\_type] : 8 bit value
2) 0x76, 0x6f, 0x72, 0x62, 0x69, 0x73: the characters 'v','o','r','b','i','s' as six octets
\end{Verbatim}
Decode continues according to packet type; the identification header
is type 1, the comment header type 3 and the setup header type 5
(these types are all odd as a packet with a leading single bit of '0'
is an audio packet). The packets must occur in the order of
identification, comment, setup.
\subsubsection{Identification header}
The identification header is a short header of only a few fields used
to declare the stream definitively as Vorbis, and provide a few externally
relevant pieces of information about the audio stream. The
identification header is coded as follows:
\begin{Verbatim}[commandchars=\\\{\}]
1) [vorbis\_version] = read 32 bits as unsigned integer
2) [audio\_channels] = read 8 bit integer as unsigned
3) [audio\_sample\_rate] = read 32 bits as unsigned integer
4) [bitrate\_maximum] = read 32 bits as signed integer
5) [bitrate\_nominal] = read 32 bits as signed integer
6) [bitrate\_minimum] = read 32 bits as signed integer
7) [blocksize\_0] = 2 exponent (read 4 bits as unsigned integer)
8) [blocksize\_1] = 2 exponent (read 4 bits as unsigned integer)
9) [framing\_flag] = read one bit
\end{Verbatim}
\varname{[vorbis\_version]} is to read '0' in order to be compatible
with this document. Both \varname{[audio\_channels]} and
\varname{[audio\_sample\_rate]} must read greater than zero. Allowed final
blocksize values are 64, 128, 256, 512, 1024, 2048, 4096 and 8192 in
Vorbis I. \varname{[blocksize\_0]} must be less than or equal to
\varname{[blocksize\_1]}. The framing bit must be nonzero. Failure to
meet any of these conditions renders a stream undecodable.
The bitrate fields above are used only as hints. The nominal bitrate
field especially may be considerably off in purely VBR streams. The
fields are meaningful only when greater than zero.
\begin{itemize}
\item All three fields set to the same value implies a fixed rate, or tightly bounded, nearly fixed-rate bitstream
\item Only nominal set implies a VBR or ABR stream that averages the nominal bitrate
\item Maximum and or minimum set implies a VBR bitstream that obeys the bitrate limits
\item None set indicates the encoder does not care to speculate.
\end{itemize}
\subsubsection{Comment header}
Comment header decode and data specification is covered in
\xref{vorbis:spec:comment}.
\subsubsection{Setup header}
Vorbis codec setup is configurable to an extreme degree:
\begin{center}
\includegraphics[width=\textwidth]{components}
\captionof{figure}{decoder pipeline configuration}
\end{center}
The setup header contains the bulk of the codec setup information
needed for decode. The setup header contains, in order, the lists of
codebook configurations, time-domain transform configurations
(placeholders in Vorbis I), floor configurations, residue
configurations, channel mapping configurations and mode
configurations. It finishes with a framing bit of '1'. Header decode
proceeds in the following order:
\paragraph{Codebooks}
\begin{enumerate}
\item \varname{[vorbis\_codebook\_count]} = read eight bits as unsigned integer and add one
\item Decode \varname{[vorbis\_codebook\_count]} codebooks in order as defined
in \xref{vorbis:spec:codebook}. Save each configuration, in
order, in an array of
codebook configurations \varname{[vorbis\_codebook\_configurations]}.
\end{enumerate}
\paragraph{Time domain transforms}
These hooks are placeholders in Vorbis I. Nevertheless, the
configuration placeholder values must be read to maintain bitstream
sync.
\begin{enumerate}
\item \varname{[vorbis\_time\_count]} = read 6 bits as unsigned integer and add one
\item read \varname{[vorbis\_time\_count]} 16 bit values; each value should be zero. If any value is nonzero, this is an error condition and the stream is undecodable.
\end{enumerate}
\paragraph{Floors}
Vorbis uses two floor types; header decode is handed to the decode
abstraction of the appropriate type.
\begin{enumerate}
\item \varname{[vorbis\_floor\_count]} = read 6 bits as unsigned integer and add one
\item For each \varname{[i]} of \varname{[vorbis\_floor\_count]} floor numbers:
\begin{enumerate}
\item read the floor type: vector \varname{[vorbis\_floor\_types]} element \varname{[i]} =
read 16 bits as unsigned integer
\item If the floor type is zero, decode the floor
configuration as defined in \xref{vorbis:spec:floor0}; save
this
configuration in slot \varname{[i]} of the floor configuration array \varname{[vorbis\_floor\_configurations]}.
\item If the floor type is one,
decode the floor configuration as defined in \xref{vorbis:spec:floor1}; save this configuration in slot \varname{[i]} of the floor configuration array \varname{[vorbis\_floor\_configurations]}.
\item If the the floor type is greater than one, this stream is undecodable; ERROR CONDITION
\end{enumerate}
\end{enumerate}
\paragraph{Residues}
Vorbis uses three residue types; header decode of each type is identical.
\begin{enumerate}
\item \varname{[vorbis\_residue\_count]} = read 6 bits as unsigned integer and add one
\item For each of \varname{[vorbis\_residue\_count]} residue numbers:
\begin{enumerate}
\item read the residue type; vector \varname{[vorbis\_residue\_types]} element \varname{[i]} = read 16 bits as unsigned integer
\item If the residue type is zero,
one or two, decode the residue configuration as defined in \xref{vorbis:spec:residue}; save this configuration in slot \varname{[i]} of the residue configuration array \varname{[vorbis\_residue\_configurations]}.
\item If the the residue type is greater than two, this stream is undecodable; ERROR CONDITION
\end{enumerate}
\end{enumerate}
\paragraph{Mappings}
Mappings are used to set up specific pipelines for encoding
multichannel audio with varying channel mapping applications. Vorbis I
uses a single mapping type (0), with implicit PCM channel mappings.
% FIXME/TODO: LaTeX cannot nest enumerate that deeply, so I have to use
% itemize at the innermost level. However, it would be much better to
% rewrite this pseudocode using listings or algoritmicx or some other
% package geared towards this.
\begin{enumerate}
\item \varname{[vorbis\_mapping\_count]} = read 6 bits as unsigned integer and add one
\item For each \varname{[i]} of \varname{[vorbis\_mapping\_count]} mapping numbers:
\begin{enumerate}
\item read the mapping type: 16 bits as unsigned integer. There's no reason to save the mapping type in Vorbis I.
\item If the mapping type is nonzero, the stream is undecodable
\item If the mapping type is zero:
\begin{enumerate}
\item read 1 bit as a boolean flag
\begin{enumerate}
\item if set, \varname{[vorbis\_mapping\_submaps]} = read 4 bits as unsigned integer and add one
\item if unset, \varname{[vorbis\_mapping\_submaps]} = 1
\end{enumerate}
\item read 1 bit as a boolean flag
\begin{enumerate}
\item if set, square polar channel mapping is in use:
\begin{itemize}
\item \varname{[vorbis\_mapping\_coupling\_steps]} = read 8 bits as unsigned integer and add one
\item for \varname{[j]} each of \varname{[vorbis\_mapping\_coupling\_steps]} steps:
\begin{itemize}
\item vector \varname{[vorbis\_mapping\_magnitude]} element \varname{[j]}= read \link{vorbis:spec:ilog}{ilog}(\varname{[audio\_channels]} - 1) bits as unsigned integer
\item vector \varname{[vorbis\_mapping\_angle]} element \varname{[j]}= read \link{vorbis:spec:ilog}{ilog}(\varname{[audio\_channels]} - 1) bits as unsigned integer
\item the numbers read in the above two steps are channel numbers representing the channel to treat as magnitude and the channel to treat as angle, respectively. If for any coupling step the angle channel number equals the magnitude channel number, the magnitude channel number is greater than \varname{[audio\_channels]}-1, or the angle channel is greater than \varname{[audio\_channels]}-1, the stream is undecodable.
\end{itemize}
\end{itemize}
\item if unset, \varname{[vorbis\_mapping\_coupling\_steps]} = 0
\end{enumerate}
\item read 2 bits (reserved field); if the value is nonzero, the stream is undecodable
\item if \varname{[vorbis\_mapping\_submaps]} is greater than one, we read channel multiplex settings. For each \varname{[j]} of \varname{[audio\_channels]} channels:
\begin{enumerate}
\item vector \varname{[vorbis\_mapping\_mux]} element \varname{[j]} = read 4 bits as unsigned integer
\item if the value is greater than the highest numbered submap (\varname{[vorbis\_mapping\_submaps]} - 1), this in an error condition rendering the stream undecodable
\end{enumerate}
\item for each submap \varname{[j]} of \varname{[vorbis\_mapping\_submaps]} submaps, read the floor and residue numbers for use in decoding that submap:
\begin{enumerate}
\item read and discard 8 bits (the unused time configuration placeholder)
\item read 8 bits as unsigned integer for the floor number; save in vector \varname{[vorbis\_mapping\_submap\_floor]} element \varname{[j]}
\item verify the floor number is not greater than the highest number floor configured for the bitstream. If it is, the bitstream is undecodable
\item read 8 bits as unsigned integer for the residue number; save in vector \varname{[vorbis\_mapping\_submap\_residue]} element \varname{[j]}
\item verify the residue number is not greater than the highest number residue configured for the bitstream. If it is, the bitstream is undecodable
\end{enumerate}
\item save this mapping configuration in slot \varname{[i]} of the mapping configuration array \varname{[vorbis\_mapping\_configurations]}.
\end{enumerate}
\end{enumerate}
\end{enumerate}
\paragraph{Modes}
\begin{enumerate}
\item \varname{[vorbis\_mode\_count]} = read 6 bits as unsigned integer and add one
\item For each of \varname{[vorbis\_mode\_count]} mode numbers:
\begin{enumerate}
\item \varname{[vorbis\_mode\_blockflag]} = read 1 bit
\item \varname{[vorbis\_mode\_windowtype]} = read 16 bits as unsigned integer
\item \varname{[vorbis\_mode\_transformtype]} = read 16 bits as unsigned integer
\item \varname{[vorbis\_mode\_mapping]} = read 8 bits as unsigned integer
\item verify ranges; zero is the only legal value in Vorbis I for
\varname{[vorbis\_mode\_windowtype]}
and \varname{[vorbis\_mode\_transformtype]}. \varname{[vorbis\_mode\_mapping]} must not be greater than the highest number mapping in use. Any illegal values render the stream undecodable.
\item save this mode configuration in slot \varname{[i]} of the mode configuration array
\varname{[vorbis\_mode\_configurations]}.
\end{enumerate}
\item read 1 bit as a framing flag. If unset, a framing error occurred and the stream is not
decodable.
\end{enumerate}
After reading mode descriptions, setup header decode is complete.
\subsection{Audio packet decode and synthesis}
Following the three header packets, all packets in a Vorbis I stream
are audio. The first step of audio packet decode is to read and
verify the packet type. \emph{A non-audio packet when audio is expected
indicates stream corruption or a non-compliant stream. The decoder
must ignore the packet and not attempt decoding it to audio}.
\subsubsection{packet type, mode and window decode}
\begin{enumerate}
\item read 1 bit \varname{[packet\_type]}; check that packet type is 0 (audio)
\item read \link{vorbis:spec:ilog}{ilog}([vorbis\_mode\_count]-1) bits
\varname{[mode\_number]}
\item decode blocksize \varname{[n]} is equal to \varname{[blocksize\_0]} if
\varname{[vorbis\_mode\_blockflag]} is 0, else \varname{[n]} is equal to \varname{[blocksize\_1]}.
\item perform window selection and setup; this window is used later by the inverse MDCT:
\begin{enumerate}
\item if this is a long window (the \varname{[vorbis\_mode\_blockflag]} flag of this mode is
set):
\begin{enumerate}
\item read 1 bit for \varname{[previous\_window\_flag]}
\item read 1 bit for \varname{[next\_window\_flag]}
\item if \varname{[previous\_window\_flag]} is not set, the left half
of the window will be a hybrid window for lapping with a
short block. See \xref{vorbis:spec:window} for an illustration of overlapping
dissimilar
windows. Else, the left half window will have normal long
shape.
\item if \varname{[next\_window\_flag]} is not set, the right half of
the window will be a hybrid window for lapping with a short
block. See \xref{vorbis:spec:window} for an
illustration of overlapping dissimilar
windows. Else, the left right window will have normal long
shape.
\end{enumerate}
\item if this is a short window, the window is always the same
short-window shape.
\end{enumerate}
\end{enumerate}
Vorbis windows all use the slope function $y=\sin(\frac{\pi}{2} * \sin^2((x+0.5)/n * \pi))$,
where $n$ is window size and $x$ ranges $0 \ldots n-1$, but dissimilar
lapping requirements can affect overall shape. Window generation
proceeds as follows:
\begin{enumerate}
\item \varname{[window\_center]} = \varname{[n]} / 2
\item if (\varname{[vorbis\_mode\_blockflag]} is set and \varname{[previous\_window\_flag]} is
not set) then
\begin{enumerate}
\item \varname{[left\_window\_start]} = \varname{[n]}/4 -
\varname{[blocksize\_0]}/4
\item \varname{[left\_window\_end]} = \varname{[n]}/4 + \varname{[blocksize\_0]}/4
\item \varname{[left\_n]} = \varname{[blocksize\_0]}/2
\end{enumerate}
else
\begin{enumerate}
\item \varname{[left\_window\_start]} = 0
\item \varname{[left\_window\_end]} = \varname{[window\_center]}
\item \varname{[left\_n]} = \varname{[n]}/2
\end{enumerate}
\item if (\varname{[vorbis\_mode\_blockflag]} is set and \varname{[next\_window\_flag]} is not
set) then
\begin{enumerate}
\item \varname{[right\_window\_start]} = \varname{[n]*3}/4 -
\varname{[blocksize\_0]}/4
\item \varname{[right\_window\_end]} = \varname{[n]*3}/4 +
\varname{[blocksize\_0]}/4
\item \varname{[right\_n]} = \varname{[blocksize\_0]}/2
\end{enumerate}
else
\begin{enumerate}
\item \varname{[right\_window\_start]} = \varname{[window\_center]}
\item \varname{[right\_window\_end]} = \varname{[n]}
\item \varname{[right\_n]} = \varname{[n]}/2
\end{enumerate}
\item window from range 0 ... \varname{[left\_window\_start]}-1 inclusive is zero
\item for \varname{[i]} in range \varname{[left\_window\_start]} ...
\varname{[left\_window\_end]}-1, window(\varname{[i]}) = $\sin(\frac{\pi}{2} * \sin^2($ (\varname{[i]}-\varname{[left\_window\_start]}+0.5) / \varname{[left\_n]} $* \frac{\pi}{2})$ )
\item window from range \varname{[left\_window\_end]} ... \varname{[right\_window\_start]}-1
inclusive is one\item for \varname{[i]} in range \varname{[right\_window\_start]} ... \varname{[right\_window\_end]}-1, window(\varname{[i]}) = $\sin(\frac{\pi}{2} * \sin^2($ (\varname{[i]}-\varname{[right\_window\_start]}+0.5) / \varname{[right\_n]} $ * \frac{\pi}{2} + \frac{\pi}{2})$ )
\item window from range \varname{[right\_window\_start]} ... \varname{[n]}-1 is
zero
\end{enumerate}
An end-of-packet condition up to this point should be considered an
error that discards this packet from the stream. An end of packet
condition past this point is to be considered a possible nominal
occurrence.
\subsubsection{floor curve decode}
From this point on, we assume out decode context is using mode number
\varname{[mode\_number]} from configuration array
\varname{[vorbis\_mode\_configurations]} and the map number
\varname{[vorbis\_mode\_mapping]} (specified by the current mode) taken
from the mapping configuration array
\varname{[vorbis\_mapping\_configurations]}.
Floor curves are decoded one-by-one in channel order.
For each floor \varname{[i]} of \varname{[audio\_channels]}
\begin{enumerate}
\item \varname{[submap\_number]} = element \varname{[i]} of vector [vorbis\_mapping\_mux]
\item \varname{[floor\_number]} = element \varname{[submap\_number]} of vector
[vorbis\_submap\_floor]
\item if the floor type of this
floor (vector \varname{[vorbis\_floor\_types]} element
\varname{[floor\_number]}) is zero then decode the floor for
channel \varname{[i]} according to the
\xref{vorbis:spec:floor0-decode}
\item if the type of this floor
is one then decode the floor for channel \varname{[i]} according
to the \xref{vorbis:spec:floor1-decode}
\item save the needed decoded floor information for channel for later synthesis
\item if the decoded floor returned 'unused', set vector \varname{[no\_residue]} element
\varname{[i]} to true, else set vector \varname{[no\_residue]} element \varname{[i]} to
false
\end{enumerate}
An end-of-packet condition during floor decode shall result in packet
decode zeroing all channel output vectors and skipping to the
add/overlap output stage.
\subsubsection{nonzero vector propagate}
A possible result of floor decode is that a specific vector is marked
'unused' which indicates that that final output vector is all-zero
values (and the floor is zero). The residue for that vector is not
coded in the stream, save for one complication. If some vectors are
used and some are not, channel coupling could result in mixing a
zeroed and nonzeroed vector to produce two nonzeroed vectors.
for each \varname{[i]} from 0 ... \varname{[vorbis\_mapping\_coupling\_steps]}-1
\begin{enumerate}
\item if either \varname{[no\_residue]} entry for channel
(\varname{[vorbis\_mapping\_magnitude]} element \varname{[i]})
or channel
(\varname{[vorbis\_mapping\_angle]} element \varname{[i]})
are set to false, then both must be set to false. Note that an 'unused'
floor has no decoded floor information; it is important that this is
remembered at floor curve synthesis time.
\end{enumerate}
\subsubsection{residue decode}
Unlike floors, which are decoded in channel order, the residue vectors
are decoded in submap order.
for each submap \varname{[i]} in order from 0 ... \varname{[vorbis\_mapping\_submaps]}-1
\begin{enumerate}
\item \varname{[ch]} = 0
\item for each channel \varname{[j]} in order from 0 ... \varname{[audio\_channels]} - 1
\begin{enumerate}
\item if channel \varname{[j]} in submap \varname{[i]} (vector \varname{[vorbis\_mapping\_mux]} element \varname{[j]} is equal to \varname{[i]})
\begin{enumerate}
\item if vector \varname{[no\_residue]} element \varname{[j]} is true
\begin{enumerate}
\item vector \varname{[do\_not\_decode\_flag]} element \varname{[ch]} is set
\end{enumerate}
else
\begin{enumerate}
\item vector \varname{[do\_not\_decode\_flag]} element \varname{[ch]} is unset
\end{enumerate}
\item increment \varname{[ch]}
\end{enumerate}
\end{enumerate}
\item \varname{[residue\_number]} = vector \varname{[vorbis\_mapping\_submap\_residue]} element \varname{[i]}
\item \varname{[residue\_type]} = vector \varname{[vorbis\_residue\_types]} element \varname{[residue\_number]}
\item decode \varname{[ch]} vectors using residue \varname{[residue\_number]}, according to type \varname{[residue\_type]}, also passing vector \varname{[do\_not\_decode\_flag]} to indicate which vectors in the bundle should not be decoded. Correct per-vector decode length is \varname{[n]}/2.
\item \varname{[ch]} = 0
\item for each channel \varname{[j]} in order from 0 ... \varname{[audio\_channels]}
\begin{enumerate}
\item if channel \varname{[j]} is in submap \varname{[i]} (vector \varname{[vorbis\_mapping\_mux]} element \varname{[j]} is equal to \varname{[i]})
\begin{enumerate}
\item residue vector for channel \varname{[j]} is set to decoded residue vector \varname{[ch]}
\item increment \varname{[ch]}
\end{enumerate}
\end{enumerate}
\end{enumerate}
\subsubsection{inverse coupling}
for each \varname{[i]} from \varname{[vorbis\_mapping\_coupling\_steps]}-1 descending to 0
\begin{enumerate}
\item \varname{[magnitude\_vector]} = the residue vector for channel
(vector \varname{[vorbis\_mapping\_magnitude]} element \varname{[i]})
\item \varname{[angle\_vector]} = the residue vector for channel (vector
\varname{[vorbis\_mapping\_angle]} element \varname{[i]})
\item for each scalar value \varname{[M]} in vector \varname{[magnitude\_vector]} and the corresponding scalar value \varname{[A]} in vector \varname{[angle\_vector]}:
\begin{enumerate}
\item if (\varname{[M]} is greater than zero)
\begin{enumerate}
\item if (\varname{[A]} is greater than zero)
\begin{enumerate}
\item \varname{[new\_M]} = \varname{[M]}
\item \varname{[new\_A]} = \varname{[M]}-\varname{[A]}
\end{enumerate}
else
\begin{enumerate}
\item \varname{[new\_A]} = \varname{[M]}
\item \varname{[new\_M]} = \varname{[M]}+\varname{[A]}
\end{enumerate}
\end{enumerate}
else
\begin{enumerate}
\item if (\varname{[A]} is greater than zero)
\begin{enumerate}
\item \varname{[new\_M]} = \varname{[M]}
\item \varname{[new\_A]} = \varname{[M]}+\varname{[A]}
\end{enumerate}
else
\begin{enumerate}
\item \varname{[new\_A]} = \varname{[M]}
\item \varname{[new\_M]} = \varname{[M]}-\varname{[A]}
\end{enumerate}
\end{enumerate}
\item set scalar value \varname{[M]} in vector \varname{[magnitude\_vector]} to \varname{[new\_M]}
\item set scalar value \varname{[A]} in vector \varname{[angle\_vector]} to \varname{[new\_A]}
\end{enumerate}
\end{enumerate}
\subsubsection{dot product}
For each channel, synthesize the floor curve from the decoded floor
information, according to packet type. Note that the vector synthesis
length for floor computation is \varname{[n]}/2.
For each channel, multiply each element of the floor curve by each
element of that channel's residue vector. The result is the dot
product of the floor and residue vectors for each channel; the produced
vectors are the length \varname{[n]}/2 audio spectrum for each
channel.
% TODO/FIXME: The following two paragraphs have identical twins
% in section 1 (under "compute floor/residue dot product")
One point is worth mentioning about this dot product; a common mistake
in a fixed point implementation might be to assume that a 32 bit
fixed-point representation for floor and residue and direct
multiplication of the vectors is sufficient for acceptable spectral
depth in all cases because it happens to mostly work with the current
Xiph.Org reference encoder.
However, floor vector values can span \~140dB (\~24 bits unsigned), and
the audio spectrum vector should represent a minimum of 120dB (\~21
bits with sign), even when output is to a 16 bit PCM device. For the
residue vector to represent full scale if the floor is nailed to
$-140$dB, it must be able to span 0 to $+140$dB. For the residue vector
to reach full scale if the floor is nailed at 0dB, it must be able to
represent $-140$dB to $+0$dB. Thus, in order to handle full range
dynamics, a residue vector may span $-140$dB to $+140$dB entirely within
spec. A 280dB range is approximately 48 bits with sign; thus the
residue vector must be able to represent a 48 bit range and the dot
product must be able to handle an effective 48 bit times 24 bit
multiplication. This range may be achieved using large (64 bit or
larger) integers, or implementing a movable binary point
representation.
\subsubsection{inverse MDCT}
Convert the audio spectrum vector of each channel back into time
domain PCM audio via an inverse Modified Discrete Cosine Transform
(MDCT). A detailed description of the MDCT is available in \cite{Sporer/Brandenburg/Edler}. The window
function used for the MDCT is the function described earlier.
\subsubsection{overlap\_add}
Windowed MDCT output is overlapped and added with the right hand data
of the previous window such that the 3/4 point of the previous window
is aligned with the 1/4 point of the current window (as illustrated in
\xref{vorbis:spec:window}). The overlapped portion
produced from overlapping the previous and current frame data is
finished data to be returned by the decoder. This data spans from the
center of the previous window to the center of the current window. In
the case of same-sized windows, the amount of data to return is
one-half block consisting of and only of the overlapped portions. When
overlapping a short and long window, much of the returned range does not
actually overlap. This does not damage transform orthogonality. Pay
attention however to returning the correct data range; the amount of
data to be returned is:
\begin{programlisting}
window_blocksize(previous_window)/4+window_blocksize(current_window)/4
\end{programlisting}
from the center (element windowsize/2) of the previous window to the
center (element windowsize/2-1, inclusive) of the current window.
Data is not returned from the first frame; it must be used to 'prime'
the decode engine. The encoder accounts for this priming when
calculating PCM offsets; after the first frame, the proper PCM output
offset is '0' (as no data has been returned yet).
\subsubsection{output channel order}
Vorbis I specifies only a channel mapping type 0. In mapping type 0,
channel mapping is implicitly defined as follows for standard audio
applications. As of revision 16781 (20100113), the specification adds
defined channel locations for 6.1 and 7.1 surround. Ordering/location
for greater-than-eight channels remains 'left to the implementation'.
These channel orderings refer to order within the encoded stream. It
is naturally possible for a decoder to produce output with channels in
any order. Any such decoder should explicitly document channel
reordering behavior.
\begin{description} %[style=nextline]
\item[one channel]
the stream is monophonic
\item[two channels]
the stream is stereo. channel order: left, right
\item[three channels]
the stream is a 1d-surround encoding. channel order: left,
center, right
\item[four channels]
the stream is quadraphonic surround. channel order: front left,
front right, rear left, rear right
\item[five channels]
the stream is five-channel surround. channel order: front left,
center, front right, rear left, rear right
\item[six channels]
the stream is 5.1 surround. channel order: front left, center,
front right, rear left, rear right, LFE
\item[seven channels]
the stream is 6.1 surround. channel order: front left, center,
front right, side left, side right, rear center, LFE
\item[eight channels]
the stream is 7.1 surround. channel order: front left, center,
front right, side left, side right, rear left, rear right,
LFE
\item[greater than eight channels]
channel use and order is defined by the application
\end{description}
Applications using Vorbis for dedicated purposes may define channel
mapping as seen fit. Future channel mappings (such as three and four
channel \href{http://www.ambisonic.net/}{Ambisonics}) will
make use of channel mappings other than mapping 0.

239
rhubarb/lib/vorbis-1.3.6/doc/05-comment.tex Normal file
View File

@ -0,0 +1,239 @@
% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*-
%!TEX root = Vorbis_I_spec.tex
\section{comment field and header specification} \label{vorbis:spec:comment}
\subsection{Overview}
The Vorbis text comment header is the second (of three) header
packets that begin a Vorbis bitstream. It is meant for short text
comments, not arbitrary metadata; arbitrary metadata belongs in a
separate logical bitstream (usually an XML stream type) that provides
greater structure and machine parseability.
The comment field is meant to be used much like someone jotting a
quick note on the bottom of a CDR. It should be a little information to
remember the disc by and explain it to others; a short, to-the-point
text note that need not only be a couple words, but isn't going to be
more than a short paragraph. The essentials, in other words, whatever
they turn out to be, eg:
\begin{quote}
Honest Bob and the Factory-to-Dealer-Incentives, \textit{``I'm Still
Around''}, opening for Moxy Fr\"{u}vous, 1997.
\end{quote}
\subsection{Comment encoding}
\subsubsection{Structure}
The comment header is logically a list of eight-bit-clean vectors; the
number of vectors is bounded to $2^{32}-1$ and the length of each vector
is limited to $2^{32}-1$ bytes. The vector length is encoded; the vector
contents themselves are not null terminated. In addition to the vector
list, there is a single vector for vendor name (also 8 bit clean,
length encoded in 32 bits). For example, the 1.0 release of libvorbis
set the vendor string to ``Xiph.Org libVorbis I 20020717''.
The vector lengths and number of vectors are stored lsb first, according
to the bit packing conventions of the vorbis codec. However, since data
in the comment header is octet-aligned, they can simply be read as
unaligned 32 bit little endian unsigned integers.
The comment header is decoded as follows:
\begin{programlisting}
1) [vendor\_length] = read an unsigned integer of 32 bits
2) [vendor\_string] = read a UTF-8 vector as [vendor\_length] octets
3) [user\_comment\_list\_length] = read an unsigned integer of 32 bits
4) iterate [user\_comment\_list\_length] times {
5) [length] = read an unsigned integer of 32 bits
6) this iteration's user comment = read a UTF-8 vector as [length] octets
}
7) [framing\_bit] = read a single bit as boolean
8) if ( [framing\_bit] unset or end-of-packet ) then ERROR
9) done.
\end{programlisting}
\subsubsection{Content vector format}
The comment vectors are structured similarly to a UNIX environment variable.
That is, comment fields consist of a field name and a corresponding value and
look like:
\begin{quote}
\begin{programlisting}
comment[0]="ARTIST=me";
comment[1]="TITLE=the sound of Vorbis";
\end{programlisting}
\end{quote}
The field name is case-insensitive and may consist of ASCII 0x20
through 0x7D, 0x3D ('=') excluded. ASCII 0x41 through 0x5A inclusive
(characters A-Z) is to be considered equivalent to ASCII 0x61 through
0x7A inclusive (characters a-z).
The field name is immediately followed by ASCII 0x3D ('=');
this equals sign is used to terminate the field name.
0x3D is followed by 8 bit clean UTF-8 encoded value of the
field contents to the end of the field.
\paragraph{Field names}
Below is a proposed, minimal list of standard field names with a
description of intended use. No single or group of field names is
mandatory; a comment header may contain one, all or none of the names
in this list.
\begin{description} %[style=nextline]
\item[TITLE]
Track/Work name
\item[VERSION]
The version field may be used to differentiate multiple
versions of the same track title in a single collection. (e.g. remix
info)
\item[ALBUM]
The collection name to which this track belongs
\item[TRACKNUMBER]
The track number of this piece if part of a specific larger collection or album
\item[ARTIST]
The artist generally considered responsible for the work. In popular music this is usually the performing band or singer. For classical music it would be the composer. For an audio book it would be the author of the original text.
\item[PERFORMER]
The artist(s) who performed the work. In classical music this would be the conductor, orchestra, soloists. In an audio book it would be the actor who did the reading. In popular music this is typically the same as the ARTIST and is omitted.
\item[COPYRIGHT]
Copyright attribution, e.g., '2001 Nobody's Band' or '1999 Jack Moffitt'
\item[LICENSE]
License information, eg, 'All Rights Reserved', 'Any
Use Permitted', a URL to a license such as a Creative Commons license
("www.creativecommons.org/blahblah/license.html") or the EFF Open
Audio License ('distributed under the terms of the Open Audio
License. see http://www.eff.org/IP/Open\_licenses/eff\_oal.html for
details'), etc.
\item[ORGANIZATION]
Name of the organization producing the track (i.e.
the 'record label')
\item[DESCRIPTION]
A short text description of the contents
\item[GENRE]
A short text indication of music genre
\item[DATE]
Date the track was recorded
\item[LOCATION]
Location where track was recorded
\item[CONTACT]
Contact information for the creators or distributors of the track. This could be a URL, an email address, the physical address of the producing label.
\item[ISRC]
International Standard Recording Code for the
track; see \href{http://www.ifpi.org/isrc/}{the ISRC
intro page} for more information on ISRC numbers.
\end{description}
\paragraph{Implications}
Field names should not be 'internationalized'; this is a
concession to simplicity not an attempt to exclude the majority of
the world that doesn't speak English. Field \emph{contents},
however, use the UTF-8 character encoding to allow easy representation
of any language.
We have the length of the entirety of the field and restrictions on
the field name so that the field name is bounded in a known way. Thus
we also have the length of the field contents.
Individual 'vendors' may use non-standard field names within
reason. The proper use of comment fields should be clear through
context at this point. Abuse will be discouraged.
There is no vendor-specific prefix to 'nonstandard' field names.
Vendors should make some effort to avoid arbitrarily polluting the
common namespace. We will generally collect the more useful tags
here to help with standardization.
Field names are not required to be unique (occur once) within a
comment header. As an example, assume a track was recorded by three
well know artists; the following is permissible, and encouraged:
\begin{quote}
\begin{programlisting}
ARTIST=Dizzy Gillespie
ARTIST=Sonny Rollins
ARTIST=Sonny Stitt
\end{programlisting}
\end{quote}
\subsubsection{Encoding}
The comment header comprises the entirety of the second bitstream
header packet. Unlike the first bitstream header packet, it is not
generally the only packet on the second page and may not be restricted
to within the second bitstream page. The length of the comment header
packet is (practically) unbounded. The comment header packet is not
optional; it must be present in the bitstream even if it is
effectively empty.
The comment header is encoded as follows (as per Ogg's standard
bitstream mapping which renders least-significant-bit of the word to be
coded into the least significant available bit of the current
bitstream octet first):
\begin{enumerate}
\item
Vendor string length (32 bit unsigned quantity specifying number of octets)
\item
Vendor string ([vendor string length] octets coded from beginning of string to end of string, not null terminated)
\item
Number of comment fields (32 bit unsigned quantity specifying number of fields)
\item
Comment field 0 length (if [Number of comment fields] $>0$; 32 bit unsigned quantity specifying number of octets)
\item
Comment field 0 ([Comment field 0 length] octets coded from beginning of string to end of string, not null terminated)
\item
Comment field 1 length (if [Number of comment fields] $>1$...)...
\end{enumerate}
This is actually somewhat easier to describe in code; implementation of the above can be found in \filename{vorbis/lib/info.c}, \function{\_vorbis\_pack\_comment()} and \function{\_vorbis\_unpack\_comment()}.

201
rhubarb/lib/vorbis-1.3.6/doc/06-floor0.tex Normal file
View File

@ -0,0 +1,201 @@
% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*-
%!TEX root = Vorbis_I_spec.tex
\section{Floor type 0 setup and decode} \label{vorbis:spec:floor0}
\subsection{Overview}
Vorbis floor type zero uses Line Spectral Pair (LSP, also alternately
known as Line Spectral Frequency or LSF) representation to encode a
smooth spectral envelope curve as the frequency response of the LSP
filter. This representation is equivalent to a traditional all-pole
infinite impulse response filter as would be used in linear predictive
coding; LSP representation may be converted to LPC representation and
vice-versa.
\subsection{Floor 0 format}
Floor zero configuration consists of six integer fields and a list of
VQ codebooks for use in coding/decoding the LSP filter coefficient
values used by each frame.
\subsubsection{header decode}
Configuration information for instances of floor zero decodes from the
codec setup header (third packet). configuration decode proceeds as
follows:
\begin{Verbatim}[commandchars=\\\{\}]
1) [floor0\_order] = read an unsigned integer of 8 bits
2) [floor0\_rate] = read an unsigned integer of 16 bits
3) [floor0\_bark\_map\_size] = read an unsigned integer of 16 bits
4) [floor0\_amplitude\_bits] = read an unsigned integer of six bits
5) [floor0\_amplitude\_offset] = read an unsigned integer of eight bits
6) [floor0\_number\_of\_books] = read an unsigned integer of four bits and add 1
7) array [floor0\_book\_list] = read a list of [floor0\_number\_of\_books] unsigned integers of eight bits each;
\end{Verbatim}
An end-of-packet condition during any of these bitstream reads renders
this stream undecodable. In addition, any element of the array
\varname{[floor0\_book\_list]} that is greater than the maximum codebook
number for this bitstream is an error condition that also renders the
stream undecodable.
\subsubsection{packet decode} \label{vorbis:spec:floor0-decode}
Extracting a floor0 curve from an audio packet consists of first
decoding the curve amplitude and \varname{[floor0\_order]} LSP
coefficient values from the bitstream, and then computing the floor
curve, which is defined as the frequency response of the decoded LSP
filter.
Packet decode proceeds as follows:
\begin{Verbatim}[commandchars=\\\{\}]
1) [amplitude] = read an unsigned integer of [floor0\_amplitude\_bits] bits
2) if ( [amplitude] is greater than zero ) \{
3) [coefficients] is an empty, zero length vector
4) [booknumber] = read an unsigned integer of \link{vorbis:spec:ilog}{ilog}( [floor0\_number\_of\_books] ) bits
5) if ( [booknumber] is greater than the highest number decode codebook ) then packet is undecodable
6) [last] = zero;
7) vector [temp\_vector] = read vector from bitstream using codebook number [floor0\_book\_list] element [booknumber] in VQ context.
8) add the scalar value [last] to each scalar in vector [temp\_vector]
9) [last] = the value of the last scalar in vector [temp\_vector]
10) concatenate [temp\_vector] onto the end of the [coefficients] vector
11) if (length of vector [coefficients] is less than [floor0\_order], continue at step 6
\}
12) done.
\end{Verbatim}
Take note of the following properties of decode:
\begin{itemize}
\item An \varname{[amplitude]} value of zero must result in a return code that indicates this channel is unused in this frame (the output of the channel will be all-zeroes in synthesis). Several later stages of decode don't occur for an unused channel.
\item An end-of-packet condition during decode should be considered a
nominal occruence; if end-of-packet is reached during any read
operation above, floor decode is to return 'unused' status as if the
\varname{[amplitude]} value had read zero at the beginning of decode.
\item The book number used for decode
can, in fact, be stored in the bitstream in \link{vorbis:spec:ilog}{ilog}( \varname{[floor0\_number\_of\_books]} -
1 ) bits. Nevertheless, the above specification is correct and values
greater than the maximum possible book value are reserved.
\item The number of scalars read into the vector \varname{[coefficients]}
may be greater than \varname{[floor0\_order]}, the number actually
required for curve computation. For example, if the VQ codebook used
for the floor currently being decoded has a
\varname{[codebook\_dimensions]} value of three and
\varname{[floor0\_order]} is ten, the only way to fill all the needed
scalars in \varname{[coefficients]} is to to read a total of twelve
scalars as four vectors of three scalars each. This is not an error
condition, and care must be taken not to allow a buffer overflow in
decode. The extra values are not used and may be ignored or discarded.
\end{itemize}
\subsubsection{curve computation} \label{vorbis:spec:floor0-synth}
Given an \varname{[amplitude]} integer and \varname{[coefficients]}
vector from packet decode as well as the [floor0\_order],
[floor0\_rate], [floor0\_bark\_map\_size], [floor0\_amplitude\_bits] and
[floor0\_amplitude\_offset] values from floor setup, and an output
vector size \varname{[n]} specified by the decode process, we compute a
floor output vector.
If the value \varname{[amplitude]} is zero, the return value is a
length \varname{[n]} vector with all-zero scalars. Otherwise, begin by
assuming the following definitions for the given vector to be
synthesized:
\begin{displaymath}
\mathrm{map}_i = \left\{
\begin{array}{ll}
\min (
\mathtt{floor0\texttt{\_}bark\texttt{\_}map\texttt{\_}size} - 1,
foobar
) & \textrm{for } i \in [0,n-1] \\
-1 & \textrm{for } i = n
\end{array}
\right.
\end{displaymath}
where
\begin{displaymath}
foobar =
\left\lfloor
\mathrm{bark}\left(\frac{\mathtt{floor0\texttt{\_}rate} \cdot i}{2n}\right) \cdot \frac{\mathtt{floor0\texttt{\_}bark\texttt{\_}map\texttt{\_}size}} {\mathrm{bark}(.5 \cdot \mathtt{floor0\texttt{\_}rate})}
\right\rfloor
\end{displaymath}
and
\begin{displaymath}
\mathrm{bark}(x) = 13.1 \arctan (.00074x) + 2.24 \arctan (.0000000185x^2) + .0001x
\end{displaymath}
The above is used to synthesize the LSP curve on a Bark-scale frequency
axis, then map the result to a linear-scale frequency axis.
Similarly, the below calculation synthesizes the output LSP curve \varname{[output]} on a log
(dB) amplitude scale, mapping it to linear amplitude in the last step:
\begin{enumerate}
\item \varname{[i]} = 0
\item \varname{[$\omega$]} = $\pi$ * map element \varname{[i]} / \varname{[floor0\_bark\_map\_size]}
\item if ( \varname{[floor0\_order]} is odd ) {
\begin{enumerate}
\item calculate \varname{[p]} and \varname{[q]} according to:
\begin{eqnarray*}
p & = & (1 - \cos^2\omega)\prod_{j=0}^{\frac{\mathtt{floor0\texttt{\_}order}-3}{2}} 4 (\cos([\mathtt{coefficients}]_{2j+1}) - \cos \omega)^2 \\
q & = & \frac{1}{4} \prod_{j=0}^{\frac{\mathtt{floor0\texttt{\_}order}-1}{2}} 4 (\cos([\mathtt{coefficients}]_{2j}) - \cos \omega)^2
\end{eqnarray*}
\end{enumerate}
} else \varname{[floor0\_order]} is even {
\begin{enumerate}[resume]
\item calculate \varname{[p]} and \varname{[q]} according to:
\begin{eqnarray*}
p & = & \frac{(1 - \cos\omega)}{2} \prod_{j=0}^{\frac{\mathtt{floor0\texttt{\_}order}-2}{2}} 4 (\cos([\mathtt{coefficients}]_{2j+1}) - \cos \omega)^2 \\
q & = & \frac{(1 + \cos\omega)}{2} \prod_{j=0}^{\frac{\mathtt{floor0\texttt{\_}order}-2}{2}} 4 (\cos([\mathtt{coefficients}]_{2j}) - \cos \omega)^2
\end{eqnarray*}
\end{enumerate}
}
\item calculate \varname{[linear\_floor\_value]} according to:
\begin{displaymath}
\exp \left( .11512925 \left(\frac{\mathtt{amplitude} \cdot \mathtt{floor0\texttt{\_}amplitute\texttt{\_}offset}}{(2^{\mathtt{floor0\texttt{\_}amplitude\texttt{\_}bits}}-1)\sqrt{p+q}}
- \mathtt{floor0\texttt{\_}amplitude\texttt{\_}offset} \right) \right)
\end{displaymath}
\item \varname{[iteration\_condition]} = map element \varname{[i]}
\item \varname{[output]} element \varname{[i]} = \varname{[linear\_floor\_value]}
\item increment \varname{[i]}
\item if ( map element \varname{[i]} is equal to \varname{[iteration\_condition]} ) continue at step 5
\item if ( \varname{[i]} is less than \varname{[n]} ) continue at step 2
\item done
\end{enumerate}
\paragraph{Errata 20150227: Bark scale computation}
Due to a typo when typesetting this version of the specification from the original HTML document, the Bark scale computation previously erroneously read:
\begin{displaymath}
\hbox{\sout{$
\mathrm{bark}(x) = 13.1 \arctan (.00074x) + 2.24 \arctan (.0000000185x^2 + .0001x)
$}}
\end{displaymath}
Note that the last parenthesis is misplaced. This document now uses the correct equation as it appeared in the original HTML spec document:
\begin{displaymath}
\mathrm{bark}(x) = 13.1 \arctan (.00074x) + 2.24 \arctan (.0000000185x^2) + .0001x
\end{displaymath}

404
rhubarb/lib/vorbis-1.3.6/doc/07-floor1.tex Normal file
View File

@ -0,0 +1,404 @@
% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*-
%!TEX root = Vorbis_I_spec.tex
\section{Floor type 1 setup and decode} \label{vorbis:spec:floor1}
\subsection{Overview}
Vorbis floor type one uses a piecewise straight-line representation to
encode a spectral envelope curve. The representation plots this curve
mechanically on a linear frequency axis and a logarithmic (dB)
amplitude axis. The integer plotting algorithm used is similar to
Bresenham's algorithm.
\subsection{Floor 1 format}
\subsubsection{model}
Floor type one represents a spectral curve as a series of
line segments. Synthesis constructs a floor curve using iterative
prediction in a process roughly equivalent to the following simplified
description:
\begin{itemize}
\item the first line segment (base case) is a logical line spanning
from x_0,y_0 to x_1,y_1 where in the base case x_0=0 and x_1=[n], the
full range of the spectral floor to be computed.
\item the induction step chooses a point x_new within an existing
logical line segment and produces a y_new value at that point computed
from the existing line's y value at x_new (as plotted by the line) and
a difference value decoded from the bitstream packet.
\item floor computation produces two new line segments, one running from
x_0,y_0 to x_new,y_new and from x_new,y_new to x_1,y_1. This step is
performed logically even if y_new represents no change to the
amplitude value at x_new so that later refinement is additionally
bounded at x_new.
\item the induction step repeats, using a list of x values specified in
the codec setup header at floor 1 initialization time. Computation
is completed at the end of the x value list.
\end{itemize}
Consider the following example, with values chosen for ease of
understanding rather than representing typical configuration:
For the below example, we assume a floor setup with an [n] of 128.
The list of selected X values in increasing order is
0,16,32,48,64,80,96,112 and 128. In list order, the values interleave
as 0, 128, 64, 32, 96, 16, 48, 80 and 112. The corresponding
list-order Y values as decoded from an example packet are 110, 20, -5,
-45, 0, -25, -10, 30 and -10. We compute the floor in the following
way, beginning with the first line:
\begin{center}
\includegraphics[width=8cm]{floor1-1}
\captionof{figure}{graph of example floor}
\end{center}
We now draw new logical lines to reflect the correction to new_Y, and
iterate for X positions 32 and 96:
\begin{center}
\includegraphics[width=8cm]{floor1-2}
\captionof{figure}{graph of example floor}
\end{center}
Although the new Y value at X position 96 is unchanged, it is still
used later as an endpoint for further refinement. From here on, the
pattern should be clear; we complete the floor computation as follows:
\begin{center}
\includegraphics[width=8cm]{floor1-3}
\captionof{figure}{graph of example floor}
\end{center}
\begin{center}
\includegraphics[width=8cm]{floor1-4}
\captionof{figure}{graph of example floor}
\end{center}
A more efficient algorithm with carefully defined integer rounding
behavior is used for actual decode, as described later. The actual
algorithm splits Y value computation and line plotting into two steps
with modifications to the above algorithm to eliminate noise
accumulation through integer roundoff/truncation.
\subsubsection{header decode}
A list of floor X values is stored in the packet header in interleaved
format (used in list order during packet decode and synthesis). This
list is split into partitions, and each partition is assigned to a
partition class. X positions 0 and [n] are implicit and do not belong
to an explicit partition or partition class.
A partition class consists of a representation vector width (the
number of Y values which the partition class encodes at once), a
'subclass' value representing the number of alternate entropy books
the partition class may use in representing Y values, the list of
[subclass] books and a master book used to encode which alternate
books were chosen for representation in a given packet. The
master/subclass mechanism is meant to be used as a flexible
representation cascade while still using codebooks only in a scalar
context.
\begin{Verbatim}[commandchars=\\\{\}]
1) [floor1\_partitions] = read 5 bits as unsigned integer
2) [maximum\_class] = -1
3) iterate [i] over the range 0 ... [floor1\_partitions]-1 \{
4) vector [floor1\_partition\_class\_list] element [i] = read 4 bits as unsigned integer
\}
5) [maximum\_class] = largest integer scalar value in vector [floor1\_partition\_class\_list]
6) iterate [i] over the range 0 ... [maximum\_class] \{
7) vector [floor1\_class\_dimensions] element [i] = read 3 bits as unsigned integer and add 1
8) vector [floor1\_class\_subclasses] element [i] = read 2 bits as unsigned integer
9) if ( vector [floor1\_class\_subclasses] element [i] is nonzero ) \{
10) vector [floor1\_class\_masterbooks] element [i] = read 8 bits as unsigned integer
\}
11) iterate [j] over the range 0 ... (2 exponent [floor1\_class\_subclasses] element [i]) - 1 \{
12) array [floor1\_subclass\_books] element [i],[j] =
read 8 bits as unsigned integer and subtract one
\}
\}
13) [floor1\_multiplier] = read 2 bits as unsigned integer and add one
14) [rangebits] = read 4 bits as unsigned integer
15) vector [floor1\_X\_list] element [0] = 0
16) vector [floor1\_X\_list] element [1] = 2 exponent [rangebits];
17) [floor1\_values] = 2
18) iterate [i] over the range 0 ... [floor1\_partitions]-1 \{
19) [current\_class\_number] = vector [floor1\_partition\_class\_list] element [i]
20) iterate [j] over the range 0 ... ([floor1\_class\_dimensions] element [current\_class\_number])-1 \{
21) vector [floor1\_X\_list] element ([floor1\_values]) =
read [rangebits] bits as unsigned integer
22) increment [floor1\_values] by one
\}
\}
23) done
\end{Verbatim}
An end-of-packet condition while reading any aspect of a floor 1
configuration during setup renders a stream undecodable. In addition,
a \varname{[floor1\_class\_masterbooks]} or
\varname{[floor1\_subclass\_books]} scalar element greater than the
highest numbered codebook configured in this stream is an error
condition that renders the stream undecodable. Vector
[floor1\_x\_list] is limited to a maximum length of 65 elements; a
setup indicating more than 65 total elements (including elements 0 and
1 set prior to the read loop) renders the stream undecodable. All
vector [floor1\_x\_list] element values must be unique within the
vector; a non-unique value renders the stream undecodable.
\subsubsection{packet decode} \label{vorbis:spec:floor1-decode}
Packet decode begins by checking the \varname{[nonzero]} flag:
\begin{Verbatim}[commandchars=\\\{\}]
1) [nonzero] = read 1 bit as boolean
\end{Verbatim}
If \varname{[nonzero]} is unset, that indicates this channel contained
no audio energy in this frame. Decode immediately returns a status
indicating this floor curve (and thus this channel) is unused this
frame. (A return status of 'unused' is different from decoding a
floor that has all points set to minimum representation amplitude,
which happens to be approximately -140dB).
Assuming \varname{[nonzero]} is set, decode proceeds as follows:
\begin{Verbatim}[commandchars=\\\{\}]
1) [range] = vector \{ 256, 128, 86, 64 \} element ([floor1\_multiplier]-1)
2) vector [floor1\_Y] element [0] = read \link{vorbis:spec:ilog}{ilog}([range]-1) bits as unsigned integer
3) vector [floor1\_Y] element [1] = read \link{vorbis:spec:ilog}{ilog}([range]-1) bits as unsigned integer
4) [offset] = 2;
5) iterate [i] over the range 0 ... [floor1\_partitions]-1 \{
6) [class] = vector [floor1\_partition\_class] element [i]
7) [cdim] = vector [floor1\_class\_dimensions] element [class]
8) [cbits] = vector [floor1\_class\_subclasses] element [class]
9) [csub] = (2 exponent [cbits])-1
10) [cval] = 0
11) if ( [cbits] is greater than zero ) \{
12) [cval] = read from packet using codebook number
(vector [floor1\_class\_masterbooks] element [class]) in scalar context
\}
13) iterate [j] over the range 0 ... [cdim]-1 \{
14) [book] = array [floor1\_subclass\_books] element [class],([cval] bitwise AND [csub])
15) [cval] = [cval] right shifted [cbits] bits
16) if ( [book] is not less than zero ) \{
17) vector [floor1\_Y] element ([j]+[offset]) = read from packet using codebook
[book] in scalar context
\} else [book] is less than zero \{
18) vector [floor1\_Y] element ([j]+[offset]) = 0
\}
\}
19) [offset] = [offset] + [cdim]
\}
20) done
\end{Verbatim}
An end-of-packet condition during curve decode should be considered a
nominal occurrence; if end-of-packet is reached during any read
operation above, floor decode is to return 'unused' status as if the
\varname{[nonzero]} flag had been unset at the beginning of decode.
Vector \varname{[floor1\_Y]} contains the values from packet decode
needed for floor 1 synthesis.
\subsubsection{curve computation} \label{vorbis:spec:floor1-synth}
Curve computation is split into two logical steps; the first step
derives final Y amplitude values from the encoded, wrapped difference
values taken from the bitstream. The second step plots the curve
lines. Also, although zero-difference values are used in the
iterative prediction to find final Y values, these points are
conditionally skipped during final line computation in step two.
Skipping zero-difference values allows a smoother line fit.
Although some aspects of the below algorithm look like inconsequential
optimizations, implementors are warned to follow the details closely.
Deviation from implementing a strictly equivalent algorithm can result
in serious decoding errors.
{\em Additional note:} Although \varname{[floor1\_final\_Y]} values in
the prediction loop and at the end of step 1 are inherently limited by
the prediction algorithm to [0, \varname{[range]}), it is possible to
abuse the setup and codebook machinery to produce negative or
over-range results. We suggest that decoder implementations guard
the values in vector \varname{[floor1\_final\_Y]} by clamping each
element to [0, \varname{[range]}) after step 1. Variants of this
suggestion are acceptable as valid floor1 setups cannot produce
out of range values.
\begin{description}
\item[step 1: amplitude value synthesis]
Unwrap the always-positive-or-zero values read from the packet into
+/- difference values, then apply to line prediction.
\begin{Verbatim}[commandchars=\\\{\}]
1) [range] = vector \{ 256, 128, 86, 64 \} element ([floor1\_multiplier]-1)
2) vector [floor1\_step2\_flag] element [0] = set
3) vector [floor1\_step2\_flag] element [1] = set
4) vector [floor1\_final\_Y] element [0] = vector [floor1\_Y] element [0]
5) vector [floor1\_final\_Y] element [1] = vector [floor1\_Y] element [1]
6) iterate [i] over the range 2 ... [floor1\_values]-1 \{
7) [low\_neighbor\_offset] = \link{vorbis:spec:low:neighbor}{low\_neighbor}([floor1\_X\_list],[i])
8) [high\_neighbor\_offset] = \link{vorbis:spec:high:neighbor}{high\_neighbor}([floor1\_X\_list],[i])
9) [predicted] = \link{vorbis:spec:render:point}{render\_point}( vector [floor1\_X\_list] element [low\_neighbor\_offset],
vector [floor1\_final\_Y] element [low\_neighbor\_offset],
vector [floor1\_X\_list] element [high\_neighbor\_offset],
vector [floor1\_final\_Y] element [high\_neighbor\_offset],
vector [floor1\_X\_list] element [i] )
10) [val] = vector [floor1\_Y] element [i]
11) [highroom] = [range] - [predicted]
12) [lowroom] = [predicted]
13) if ( [highroom] is less than [lowroom] ) \{
14) [room] = [highroom] * 2
\} else [highroom] is not less than [lowroom] \{
15) [room] = [lowroom] * 2
\}
16) if ( [val] is nonzero ) \{
17) vector [floor1\_step2\_flag] element [low\_neighbor\_offset] = set
18) vector [floor1\_step2\_flag] element [high\_neighbor\_offset] = set
19) vector [floor1\_step2\_flag] element [i] = set
20) if ( [val] is greater than or equal to [room] ) \{
21) if ( [highroom] is greater than [lowroom] ) \{
22) vector [floor1\_final\_Y] element [i] = [val] - [lowroom] + [predicted]
\} else [highroom] is not greater than [lowroom] \{
23) vector [floor1\_final\_Y] element [i] = [predicted] - [val] + [highroom] - 1
\}
\} else [val] is less than [room] \{
24) if ([val] is odd) \{
25) vector [floor1\_final\_Y] element [i] =
[predicted] - (([val] + 1) divided by 2 using integer division)
\} else [val] is even \{
26) vector [floor1\_final\_Y] element [i] =
[predicted] + ([val] / 2 using integer division)
\}
\}
\} else [val] is zero \{
27) vector [floor1\_step2\_flag] element [i] = unset
28) vector [floor1\_final\_Y] element [i] = [predicted]
\}
\}
29) done
\end{Verbatim}
\item[step 2: curve synthesis]
Curve synthesis generates a return vector \varname{[floor]} of length
\varname{[n]} (where \varname{[n]} is provided by the decode process
calling to floor decode). Floor 1 curve synthesis makes use of the
\varname{[floor1\_X\_list]}, \varname{[floor1\_final\_Y]} and
\varname{[floor1\_step2\_flag]} vectors, as well as [floor1\_multiplier]
and [floor1\_values] values.
Decode begins by sorting the scalars from vectors
\varname{[floor1\_X\_list]}, \varname{[floor1\_final\_Y]} and
\varname{[floor1\_step2\_flag]} together into new vectors
\varname{[floor1\_X\_list]'}, \varname{[floor1\_final\_Y]'} and
\varname{[floor1\_step2\_flag]'} according to ascending sort order of the
values in \varname{[floor1\_X\_list]}. That is, sort the values of
\varname{[floor1\_X\_list]} and then apply the same permutation to
elements of the other two vectors so that the X, Y and step2\_flag
values still match.
Then compute the final curve in one pass:
\begin{Verbatim}[commandchars=\\\{\}]
1) [hx] = 0
2) [lx] = 0
3) [ly] = vector [floor1\_final\_Y]' element [0] * [floor1\_multiplier]
4) iterate [i] over the range 1 ... [floor1\_values]-1 \{
5) if ( [floor1\_step2\_flag]' element [i] is set ) \{
6) [hy] = [floor1\_final\_Y]' element [i] * [floor1\_multiplier]
7) [hx] = [floor1\_X\_list]' element [i]
8) \link{vorbis:spec:render:line}{render\_line}( [lx], [ly], [hx], [hy], [floor] )
9) [lx] = [hx]
10) [ly] = [hy]
\}
\}
11) if ( [hx] is less than [n] ) \{
12) \link{vorbis:spec:render:line}{render\_line}( [hx], [hy], [n], [hy], [floor] )
\}
13) if ( [hx] is greater than [n] ) \{
14) truncate vector [floor] to [n] elements
\}
15) for each scalar in vector [floor], perform a lookup substitution using
the scalar value from [floor] as an offset into the vector \link{vorbis:spec:floor1:inverse:dB:table}{[floor1\_inverse\_dB\_static\_table]}
16) done
\end{Verbatim}
\end{description}

451
rhubarb/lib/vorbis-1.3.6/doc/08-residue.tex Normal file
View File

@ -0,0 +1,451 @@
% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*-
%!TEX root = Vorbis_I_spec.tex
\section{Residue setup and decode} \label{vorbis:spec:residue}
\subsection{Overview}
A residue vector represents the fine detail of the audio spectrum of
one channel in an audio frame after the encoder subtracts the floor
curve and performs any channel coupling. A residue vector may
represent spectral lines, spectral magnitude, spectral phase or
hybrids as mixed by channel coupling. The exact semantic content of
the vector does not matter to the residue abstraction.
Whatever the exact qualities, the Vorbis residue abstraction codes the
residue vectors into the bitstream packet, and then reconstructs the
vectors during decode. Vorbis makes use of three different encoding
variants (numbered 0, 1 and 2) of the same basic vector encoding
abstraction.
\subsection{Residue format}
Residue format partitions each vector in the vector bundle into chunks,
classifies each chunk, encodes the chunk classifications and finally
encodes the chunks themselves using the the specific VQ arrangement
defined for each selected classification.
The exact interleaving and partitioning vary by residue encoding number,
however the high-level process used to classify and encode the residue
vector is the same in all three variants.
A set of coded residue vectors are all of the same length. High level
coding structure, ignoring for the moment exactly how a partition is
encoded and simply trusting that it is, is as follows:
\begin{itemize}
\item Each vector is partitioned into multiple equal sized chunks
according to configuration specified. If we have a vector size of
\emph{n}, a partition size \emph{residue\_partition\_size}, and a total
of \emph{ch} residue vectors, the total number of partitioned chunks
coded is \emph{n}/\emph{residue\_partition\_size}*\emph{ch}. It is
important to note that the integer division truncates. In the below
example, we assume an example \emph{residue\_partition\_size} of 8.
\item Each partition in each vector has a classification number that
specifies which of multiple configured VQ codebook setups are used to
decode that partition. The classification numbers of each partition
can be thought of as forming a vector in their own right, as in the
illustration below. Just as the residue vectors are coded in grouped
partitions to increase encoding efficiency, the classification vector
is also partitioned into chunks. The integer elements of each scalar
in a classification chunk are built into a single scalar that
represents the classification numbers in that chunk. In the below
example, the classification codeword encodes two classification
numbers.
\item The values in a residue vector may be encoded monolithically in a
single pass through the residue vector, but more often efficient
codebook design dictates that each vector is encoded as the additive
sum of several passes through the residue vector using more than one
VQ codebook. Thus, each residue value potentially accumulates values
from multiple decode passes. The classification value associated with
a partition is the same in each pass, thus the classification codeword
is coded only in the first pass.
\end{itemize}
\begin{center}
\includegraphics[width=\textwidth]{residue-pack}
\captionof{figure}{illustration of residue vector format}
\end{center}
\subsection{residue 0}
Residue 0 and 1 differ only in the way the values within a residue
partition are interleaved during partition encoding (visually treated
as a black box--or cyan box or brown box--in the above figure).
Residue encoding 0 interleaves VQ encoding according to the
dimension of the codebook used to encode a partition in a specific
pass. The dimension of the codebook need not be the same in multiple
passes, however the partition size must be an even multiple of the
codebook dimension.
As an example, assume a partition vector of size eight, to be encoded
by residue 0 using codebook sizes of 8, 4, 2 and 1:
\begin{programlisting}
original residue vector: [ 0 1 2 3 4 5 6 7 ]
codebook dimensions = 8 encoded as: [ 0 1 2 3 4 5 6 7 ]
codebook dimensions = 4 encoded as: [ 0 2 4 6 ], [ 1 3 5 7 ]
codebook dimensions = 2 encoded as: [ 0 4 ], [ 1 5 ], [ 2 6 ], [ 3 7 ]
codebook dimensions = 1 encoded as: [ 0 ], [ 1 ], [ 2 ], [ 3 ], [ 4 ], [ 5 ], [ 6 ], [ 7 ]
\end{programlisting}
It is worth mentioning at this point that no configurable value in the
residue coding setup is restricted to a power of two.
\subsection{residue 1}
Residue 1 does not interleave VQ encoding. It represents partition
vector scalars in order. As with residue 0, however, partition length
must be an integer multiple of the codebook dimension, although
dimension may vary from pass to pass.
As an example, assume a partition vector of size eight, to be encoded
by residue 0 using codebook sizes of 8, 4, 2 and 1:
\begin{programlisting}
original residue vector: [ 0 1 2 3 4 5 6 7 ]
codebook dimensions = 8 encoded as: [ 0 1 2 3 4 5 6 7 ]
codebook dimensions = 4 encoded as: [ 0 1 2 3 ], [ 4 5 6 7 ]
codebook dimensions = 2 encoded as: [ 0 1 ], [ 2 3 ], [ 4 5 ], [ 6 7 ]
codebook dimensions = 1 encoded as: [ 0 ], [ 1 ], [ 2 ], [ 3 ], [ 4 ], [ 5 ], [ 6 ], [ 7 ]
\end{programlisting}
\subsection{residue 2}
Residue type two can be thought of as a variant of residue type 1.
Rather than encoding multiple passed-in vectors as in residue type 1,
the \emph{ch} passed in vectors of length \emph{n} are first
interleaved and flattened into a single vector of length
\emph{ch}*\emph{n}. Encoding then proceeds as in type 1. Decoding is
as in type 1 with decode interleave reversed. If operating on a single
vector to begin with, residue type 1 and type 2 are equivalent.
\begin{center}
\includegraphics[width=\textwidth]{residue2}
\captionof{figure}{illustration of residue type 2}
\end{center}
\subsection{Residue decode}
\subsubsection{header decode}
Header decode for all three residue types is identical.
\begin{programlisting}
1) [residue\_begin] = read 24 bits as unsigned integer
2) [residue\_end] = read 24 bits as unsigned integer
3) [residue\_partition\_size] = read 24 bits as unsigned integer and add one
4) [residue\_classifications] = read 6 bits as unsigned integer and add one
5) [residue\_classbook] = read 8 bits as unsigned integer
\end{programlisting}
\varname{[residue\_begin]} and
\varname{[residue\_end]} select the specific sub-portion of
each vector that is actually coded; it implements akin to a bandpass
where, for coding purposes, the vector effectively begins at element
\varname{[residue\_begin]} and ends at
\varname{[residue\_end]}. Preceding and following values in
the unpacked vectors are zeroed. Note that for residue type 2, these
values as well as \varname{[residue\_partition\_size]}apply to
the interleaved vector, not the individual vectors before interleave.
\varname{[residue\_partition\_size]} is as explained above,
\varname{[residue\_classifications]} is the number of possible
classification to which a partition can belong and
\varname{[residue\_classbook]} is the codebook number used to
code classification codewords. The number of dimensions in book
\varname{[residue\_classbook]} determines how many
classification values are grouped into a single classification
codeword. Note that the number of entries and dimensions in book
\varname{[residue\_classbook]}, along with
\varname{[residue\_classifications]}, overdetermines to
possible number of classification codewords.
If \varname{[residue\_classifications]}\^{}\varname{[residue\_classbook]}.dimensions
exceeds \varname{[residue\_classbook]}.entries, the
bitstream should be regarded to be undecodable.
Next we read a bitmap pattern that specifies which partition classes
code values in which passes.
\begin{programlisting}
1) iterate [i] over the range 0 ... [residue\_classifications]-1 {
2) [high\_bits] = 0
3) [low\_bits] = read 3 bits as unsigned integer
4) [bitflag] = read one bit as boolean
5) if ( [bitflag] is set ) then [high\_bits] = read five bits as unsigned integer
6) vector [residue\_cascade] element [i] = [high\_bits] * 8 + [low\_bits]
}
7) done
\end{programlisting}
Finally, we read in a list of book numbers, each corresponding to
specific bit set in the cascade bitmap. We loop over the possible
codebook classifications and the maximum possible number of encoding
stages (8 in Vorbis I, as constrained by the elements of the cascade
bitmap being eight bits):
\begin{programlisting}
1) iterate [i] over the range 0 ... [residue\_classifications]-1 {
2) iterate [j] over the range 0 ... 7 {
3) if ( vector [residue\_cascade] element [i] bit [j] is set ) {
4) array [residue\_books] element [i][j] = read 8 bits as unsigned integer
} else {
5) array [residue\_books] element [i][j] = unused
}
}
}
6) done
\end{programlisting}
An end-of-packet condition at any point in header decode renders the
stream undecodable. In addition, any codebook number greater than the
maximum numbered codebook set up in this stream also renders the
stream undecodable. All codebooks in array [residue\_books] are
required to have a value mapping. The presence of codebook in array
[residue\_books] without a value mapping (maptype equals zero) renders
the stream undecodable.
\subsubsection{packet decode}
Format 0 and 1 packet decode is identical except for specific
partition interleave. Format 2 packet decode can be built out of the
format 1 decode process. Thus we describe first the decode
infrastructure identical to all three formats.
In addition to configuration information, the residue decode process
is passed the number of vectors in the submap bundle and a vector of
flags indicating if any of the vectors are not to be decoded. If the
passed in number of vectors is 3 and vector number 1 is marked 'do not
decode', decode skips vector 1 during the decode loop. However, even
'do not decode' vectors are allocated and zeroed.
Depending on the values of \varname{[residue\_begin]} and
\varname{[residue\_end]}, it is obvious that the encoded
portion of a residue vector may be the entire possible residue vector
or some other strict subset of the actual residue vector size with
zero padding at either uncoded end. However, it is also possible to
set \varname{[residue\_begin]} and
\varname{[residue\_end]} to specify a range partially or
wholly beyond the maximum vector size. Before beginning residue
decode, limit \varname{[residue\_begin]} and
\varname{[residue\_end]} to the maximum possible vector size
as follows. We assume that the number of vectors being encoded,
\varname{[ch]} is provided by the higher level decoding
process.
\begin{programlisting}
1) [actual\_size] = current blocksize/2;
2) if residue encoding is format 2
3) [actual\_size] = [actual\_size] * [ch];
4) [limit\_residue\_begin] = minimum of ([residue\_begin],[actual\_size]);
5) [limit\_residue\_end] = minimum of ([residue\_end],[actual\_size]);
\end{programlisting}
The following convenience values are conceptually useful to clarifying
the decode process:
\begin{programlisting}
1) [classwords\_per\_codeword] = [codebook\_dimensions] value of codebook [residue\_classbook]
2) [n\_to\_read] = [limit\_residue\_end] - [limit\_residue\_begin]
3) [partitions\_to\_read] = [n\_to\_read] / [residue\_partition\_size]
\end{programlisting}
Packet decode proceeds as follows, matching the description offered earlier in the document.
\begin{programlisting}
1) allocate and zero all vectors that will be returned.
2) if ([n\_to\_read] is zero), stop; there is no residue to decode.
3) iterate [pass] over the range 0 ... 7 {
4) [partition\_count] = 0
5) while [partition\_count] is less than [partitions\_to\_read]
6) if ([pass] is zero) {
7) iterate [j] over the range 0 .. [ch]-1 {
8) if vector [j] is not marked 'do not decode' {
9) [temp] = read from packet using codebook [residue\_classbook] in scalar context
10) iterate [i] descending over the range [classwords\_per\_codeword]-1 ... 0 {
11) array [classifications] element [j],([i]+[partition\_count]) =
[temp] integer modulo [residue\_classifications]
12) [temp] = [temp] / [residue\_classifications] using integer division
}
}
}
}
13) iterate [i] over the range 0 .. ([classwords\_per\_codeword] - 1) while [partition\_count]
is also less than [partitions\_to\_read] {
14) iterate [j] over the range 0 .. [ch]-1 {
15) if vector [j] is not marked 'do not decode' {
16) [vqclass] = array [classifications] element [j],[partition\_count]
17) [vqbook] = array [residue\_books] element [vqclass],[pass]
18) if ([vqbook] is not 'unused') {
19) decode partition into output vector number [j], starting at scalar
offset [limit\_residue\_begin]+[partition\_count]*[residue\_partition\_size] using
codebook number [vqbook] in VQ context
}
}
20) increment [partition\_count] by one
}
}
}
21) done
\end{programlisting}
An end-of-packet condition during packet decode is to be considered a
nominal occurrence. Decode returns the result of vector decode up to
that point.
\subsubsection{format 0 specifics}
Format zero decodes partitions exactly as described earlier in the
'Residue Format: residue 0' section. The following pseudocode
presents the same algorithm. Assume:
\begin{itemize}
\item \varname{[n]} is the value in \varname{[residue\_partition\_size]}
\item \varname{[v]} is the residue vector
\item \varname{[offset]} is the beginning read offset in [v]
\end{itemize}
\begin{programlisting}
1) [step] = [n] / [codebook\_dimensions]
2) iterate [i] over the range 0 ... [step]-1 {
3) vector [entry\_temp] = read vector from packet using current codebook in VQ context
4) iterate [j] over the range 0 ... [codebook\_dimensions]-1 {
5) vector [v] element ([offset]+[i]+[j]*[step]) =
vector [v] element ([offset]+[i]+[j]*[step]) +
vector [entry\_temp] element [j]
}
}
6) done
\end{programlisting}
\subsubsection{format 1 specifics}
Format 1 decodes partitions exactly as described earlier in the
'Residue Format: residue 1' section. The following pseudocode
presents the same algorithm. Assume:
\begin{itemize}
\item \varname{[n]} is the value in
\varname{[residue\_partition\_size]}
\item \varname{[v]} is the residue vector
\item \varname{[offset]} is the beginning read offset in [v]
\end{itemize}
\begin{programlisting}
1) [i] = 0
2) vector [entry\_temp] = read vector from packet using current codebook in VQ context
3) iterate [j] over the range 0 ... [codebook\_dimensions]-1 {
4) vector [v] element ([offset]+[i]) =
vector [v] element ([offset]+[i]) +
vector [entry\_temp] element [j]
5) increment [i]
}
6) if ( [i] is less than [n] ) continue at step 2
7) done
\end{programlisting}
\subsubsection{format 2 specifics}
Format 2 is reducible to format 1. It may be implemented as an additional step prior to and an additional post-decode step after a normal format 1 decode.
Format 2 handles 'do not decode' vectors differently than residue 0 or
1; if all vectors are marked 'do not decode', no decode occurrs.
However, if at least one vector is to be decoded, all the vectors are
decoded. We then request normal format 1 to decode a single vector
representing all output channels, rather than a vector for each
channel. After decode, deinterleave the vector into independent vectors, one for each output channel. That is:
\begin{enumerate}
\item If all vectors 0 through \emph{ch}-1 are marked 'do not decode', allocate and clear a single vector \varname{[v]}of length \emph{ch*n} and skip step 2 below; proceed directly to the post-decode step.
\item Rather than performing format 1 decode to produce \emph{ch} vectors of length \emph{n} each, call format 1 decode to produce a single vector \varname{[v]} of length \emph{ch*n}.
\item Post decode: Deinterleave the single vector \varname{[v]} returned by format 1 decode as described above into \emph{ch} independent vectors, one for each outputchannel, according to:
\begin{programlisting}
1) iterate [i] over the range 0 ... [n]-1 {
2) iterate [j] over the range 0 ... [ch]-1 {
3) output vector number [j] element [i] = vector [v] element ([i] * [ch] + [j])
}
}
4) done
\end{programlisting}
\end{enumerate}

180
rhubarb/lib/vorbis-1.3.6/doc/09-helper.tex Normal file
View File

@ -0,0 +1,180 @@
% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*-
%!TEX root = Vorbis_I_spec.tex
\section{Helper equations} \label{vorbis:spec:helper}
\subsection{Overview}
The equations below are used in multiple places by the Vorbis codec
specification. Rather than cluttering up the main specification
documents, they are defined here and referenced where appropriate.
\subsection{Functions}
\subsubsection{ilog} \label{vorbis:spec:ilog}
The "ilog(x)" function returns the position number (1 through n) of the highest set bit in the two's complement integer value
\varname{[x]}. Values of \varname{[x]} less than zero are defined to return zero.
\begin{programlisting}
1) [return\_value] = 0;
2) if ( [x] is greater than zero ) {
3) increment [return\_value];
4) logical shift [x] one bit to the right, padding the MSb with zero
5) repeat at step 2)
}
6) done
\end{programlisting}
Examples:
\begin{itemize}
\item ilog(0) = 0;
\item ilog(1) = 1;
\item ilog(2) = 2;
\item ilog(3) = 2;
\item ilog(4) = 3;
\item ilog(7) = 3;
\item ilog(negative number) = 0;
\end{itemize}
\subsubsection{float32\_unpack} \label{vorbis:spec:float32:unpack}
"float32\_unpack(x)" is intended to translate the packed binary
representation of a Vorbis codebook float value into the
representation used by the decoder for floating point numbers. For
purposes of this example, we will unpack a Vorbis float32 into a
host-native floating point number.
\begin{programlisting}
1) [mantissa] = [x] bitwise AND 0x1fffff (unsigned result)
2) [sign] = [x] bitwise AND 0x80000000 (unsigned result)
3) [exponent] = ( [x] bitwise AND 0x7fe00000) shifted right 21 bits (unsigned result)
4) if ( [sign] is nonzero ) then negate [mantissa]
5) return [mantissa] * ( 2 ^ ( [exponent] - 788 ) )
\end{programlisting}
\subsubsection{lookup1\_values} \label{vorbis:spec:lookup1:values}
"lookup1\_values(codebook\_entries,codebook\_dimensions)" is used to
compute the correct length of the value index for a codebook VQ lookup
table of lookup type 1. The values on this list are permuted to
construct the VQ vector lookup table of size
\varname{[codebook\_entries]}.
The return value for this function is defined to be 'the greatest
integer value for which \varname{[return\_value]} to the power of
\varname{[codebook\_dimensions]} is less than or equal to
\varname{[codebook\_entries]}'.
\subsubsection{low\_neighbor} \label{vorbis:spec:low:neighbor}
"low\_neighbor(v,x)" finds the position \varname{n} in vector \varname{[v]} of
the greatest value scalar element for which \varname{n} is less than
\varname{[x]} and vector \varname{[v]} element \varname{n} is less
than vector \varname{[v]} element \varname{[x]}.
\subsubsection{high\_neighbor} \label{vorbis:spec:high:neighbor}
"high\_neighbor(v,x)" finds the position \varname{n} in vector [v] of
the lowest value scalar element for which \varname{n} is less than
\varname{[x]} and vector \varname{[v]} element \varname{n} is greater
than vector \varname{[v]} element \varname{[x]}.
\subsubsection{render\_point} \label{vorbis:spec:render:point}
"render\_point(x0,y0,x1,y1,X)" is used to find the Y value at point X
along the line specified by x0, x1, y0 and y1. This function uses an
integer algorithm to solve for the point directly without calculating
intervening values along the line.
\begin{programlisting}
1) [dy] = [y1] - [y0]
2) [adx] = [x1] - [x0]
3) [ady] = absolute value of [dy]
4) [err] = [ady] * ([X] - [x0])
5) [off] = [err] / [adx] using integer division
6) if ( [dy] is less than zero ) {
7) [Y] = [y0] - [off]
} else {
8) [Y] = [y0] + [off]
}
9) done
\end{programlisting}
\subsubsection{render\_line} \label{vorbis:spec:render:line}
Floor decode type one uses the integer line drawing algorithm of
"render\_line(x0, y0, x1, y1, v)" to construct an integer floor
curve for contiguous piecewise line segments. Note that it has not
been relevant elsewhere, but here we must define integer division as
rounding division of both positive and negative numbers toward zero.
\begin{programlisting}
1) [dy] = [y1] - [y0]
2) [adx] = [x1] - [x0]
3) [ady] = absolute value of [dy]
4) [base] = [dy] / [adx] using integer division
5) [x] = [x0]
6) [y] = [y0]
7) [err] = 0
8) if ( [dy] is less than 0 ) {
9) [sy] = [base] - 1
} else {
10) [sy] = [base] + 1
}
11) [ady] = [ady] - (absolute value of [base]) * [adx]
12) vector [v] element [x] = [y]
13) iterate [x] over the range [x0]+1 ... [x1]-1 {
14) [err] = [err] + [ady];
15) if ( [err] >= [adx] ) {
16) [err] = [err] - [adx]
17) [y] = [y] + [sy]
} else {
18) [y] = [y] + [base]
}
19) vector [v] element [x] = [y]
}
\end{programlisting}

76
rhubarb/lib/vorbis-1.3.6/doc/10-tables.tex Normal file
View File

@ -0,0 +1,76 @@
% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*-
%!TEX root = Vorbis_I_spec.tex
\section{Tables} \label{vorbis:spec:tables}
\subsection{floor1\_inverse\_dB\_table} \label{vorbis:spec:floor1:inverse:dB:table}
The vector \varname{[floor1\_inverse\_dB\_table]} is a 256 element static
lookup table consisting of the following values (read left to right
then top to bottom):
\begin{Verbatim}
1.0649863e-07, 1.1341951e-07, 1.2079015e-07, 1.2863978e-07,
1.3699951e-07, 1.4590251e-07, 1.5538408e-07, 1.6548181e-07,
1.7623575e-07, 1.8768855e-07, 1.9988561e-07, 2.1287530e-07,
2.2670913e-07, 2.4144197e-07, 2.5713223e-07, 2.7384213e-07,
2.9163793e-07, 3.1059021e-07, 3.3077411e-07, 3.5226968e-07,
3.7516214e-07, 3.9954229e-07, 4.2550680e-07, 4.5315863e-07,
4.8260743e-07, 5.1396998e-07, 5.4737065e-07, 5.8294187e-07,
6.2082472e-07, 6.6116941e-07, 7.0413592e-07, 7.4989464e-07,
7.9862701e-07, 8.5052630e-07, 9.0579828e-07, 9.6466216e-07,
1.0273513e-06, 1.0941144e-06, 1.1652161e-06, 1.2409384e-06,
1.3215816e-06, 1.4074654e-06, 1.4989305e-06, 1.5963394e-06,
1.7000785e-06, 1.8105592e-06, 1.9282195e-06, 2.0535261e-06,
2.1869758e-06, 2.3290978e-06, 2.4804557e-06, 2.6416497e-06,
2.8133190e-06, 2.9961443e-06, 3.1908506e-06, 3.3982101e-06,
3.6190449e-06, 3.8542308e-06, 4.1047004e-06, 4.3714470e-06,
4.6555282e-06, 4.9580707e-06, 5.2802740e-06, 5.6234160e-06,
5.9888572e-06, 6.3780469e-06, 6.7925283e-06, 7.2339451e-06,
7.7040476e-06, 8.2047000e-06, 8.7378876e-06, 9.3057248e-06,
9.9104632e-06, 1.0554501e-05, 1.1240392e-05, 1.1970856e-05,
1.2748789e-05, 1.3577278e-05, 1.4459606e-05, 1.5399272e-05,
1.6400004e-05, 1.7465768e-05, 1.8600792e-05, 1.9809576e-05,
2.1096914e-05, 2.2467911e-05, 2.3928002e-05, 2.5482978e-05,
2.7139006e-05, 2.8902651e-05, 3.0780908e-05, 3.2781225e-05,
3.4911534e-05, 3.7180282e-05, 3.9596466e-05, 4.2169667e-05,
4.4910090e-05, 4.7828601e-05, 5.0936773e-05, 5.4246931e-05,
5.7772202e-05, 6.1526565e-05, 6.5524908e-05, 6.9783085e-05,
7.4317983e-05, 7.9147585e-05, 8.4291040e-05, 8.9768747e-05,
9.5602426e-05, 0.00010181521, 0.00010843174, 0.00011547824,
0.00012298267, 0.00013097477, 0.00013948625, 0.00014855085,
0.00015820453, 0.00016848555, 0.00017943469, 0.00019109536,
0.00020351382, 0.00021673929, 0.00023082423, 0.00024582449,
0.00026179955, 0.00027881276, 0.00029693158, 0.00031622787,
0.00033677814, 0.00035866388, 0.00038197188, 0.00040679456,
0.00043323036, 0.00046138411, 0.00049136745, 0.00052329927,
0.00055730621, 0.00059352311, 0.00063209358, 0.00067317058,
0.00071691700, 0.00076350630, 0.00081312324, 0.00086596457,
0.00092223983, 0.00098217216, 0.0010459992, 0.0011139742,
0.0011863665, 0.0012634633, 0.0013455702, 0.0014330129,
0.0015261382, 0.0016253153, 0.0017309374, 0.0018434235,
0.0019632195, 0.0020908006, 0.0022266726, 0.0023713743,
0.0025254795, 0.0026895994, 0.0028643847, 0.0030505286,
0.0032487691, 0.0034598925, 0.0036847358, 0.0039241906,
0.0041792066, 0.0044507950, 0.0047400328, 0.0050480668,
0.0053761186, 0.0057254891, 0.0060975636, 0.0064938176,
0.0069158225, 0.0073652516, 0.0078438871, 0.0083536271,
0.0088964928, 0.009474637, 0.010090352, 0.010746080,
0.011444421, 0.012188144, 0.012980198, 0.013823725,
0.014722068, 0.015678791, 0.016697687, 0.017782797,
0.018938423, 0.020169149, 0.021479854, 0.022875735,
0.024362330, 0.025945531, 0.027631618, 0.029427276,
0.031339626, 0.033376252, 0.035545228, 0.037855157,
0.040315199, 0.042935108, 0.045725273, 0.048696758,
0.051861348, 0.055231591, 0.058820850, 0.062643361,
0.066714279, 0.071049749, 0.075666962, 0.080584227,
0.085821044, 0.091398179, 0.097337747, 0.10366330,
0.11039993, 0.11757434, 0.12521498, 0.13335215,
0.14201813, 0.15124727, 0.16107617, 0.17154380,
0.18269168, 0.19456402, 0.20720788, 0.22067342,
0.23501402, 0.25028656, 0.26655159, 0.28387361,
0.30232132, 0.32196786, 0.34289114, 0.36517414,
0.38890521, 0.41417847, 0.44109412, 0.46975890,
0.50028648, 0.53279791, 0.56742212, 0.60429640,
0.64356699, 0.68538959, 0.72993007, 0.77736504,
0.82788260, 0.88168307, 0.9389798, 1.
\end{Verbatim}

1142
rhubarb/lib/vorbis-1.3.6/doc/Doxyfile.in Normal file
View File

File diff suppressed because it is too large Load Diff

148
rhubarb/lib/vorbis-1.3.6/doc/Makefile.am Normal file
View File

@ -0,0 +1,148 @@
## Process this with automake to create Makefile.in
SUBDIRS = libvorbis vorbisfile vorbisenc
docdir = $(datadir)/doc/$(PACKAGE)-$(VERSION)
### all of the static docs, commited to SVN and included as is
static_docs = \
rfc5215.xml \
rfc5215.txt \
eightphase.png \
fish_xiph_org.png \
floor1_inverse_dB_table.html \
floorval.png \
fourphase.png \
framing.html \
helper.html \
index.html \
oggstream.html \
programming.html \
squarepolar.png \
stereo.html \
stream.png \
v-comment.html \
vorbis-clip.txt \
vorbis-errors.txt \
vorbis-fidelity.html
# bits needed by the spec
SPEC_PNG = \
components.png \
floor1-1.png \
floor1-2.png \
floor1-3.png \
floor1-4.png \
hufftree.png \
hufftree-under.png \
residue-pack.png \
residue2.png \
window1.png \
window2.png \
Vorbis_I_spec0x.png \
Vorbis_I_spec1x.png \
Vorbis_I_spec2x.png \
Vorbis_I_spec3x.png \
Vorbis_I_spec4x.png \
Vorbis_I_spec5x.png \
Vorbis_I_spec6x.png \
Vorbis_I_spec7x.png \
Vorbis_I_spec8x.png \
Vorbis_I_spec9x.png \
Vorbis_I_spec10x.png \
Vorbis_I_spec11x.png \
Vorbis_I_spec12x.png \
Vorbis_I_spec13x.png \
Vorbis_I_spec14x.png
SPEC_TEX = \
Vorbis_I_spec.tex \
01-introduction.tex \
02-bitpacking.tex \
03-codebook.tex \
04-codec.tex \
05-comment.tex \
06-floor0.tex \
07-floor1.tex \
08-residue.tex \
09-helper.tex \
10-tables.tex \
a1-encapsulation-ogg.tex \
a2-encapsulation-rtp.tex \
footer.tex
built_docs = Vorbis_I_spec.pdf Vorbis_I_spec.html Vorbis_I_spec.css
# conditionally make the generated documentation
if BUILD_DOCS
doc_DATA = $(static_docs) $(SPEC_PNG) $(built_docs) doxygen-build.stamp
else
doc_DATA = $(static_docs) doxygen-build.stamp
endif
EXTRA_DIST = $(static_docs) $(built_docs) \
$(SPEC_TEX) $(SPEC_PNG) $(SPEC_PDF) Vorbis_I_spec.cfg Doxyfile.in
# these are expensive; only remove if we have to
MAINTAINERCLEANFILES = $(built_docs)
CLEANFILES = $(SPEC_TEX:%.tex=%.aux) \
Vorbis_I_spec.4ct Vorbis_I_spec.4tc \
Vorbis_I_spec.dvi Vorbis_I_spec.idv \
Vorbis_I_spec.lg Vorbis_I_spec.log \
Vorbis_I_spec.out Vorbis_I_spec.tmp \
Vorbis_I_spec.toc Vorbis_I_spec.xref \
zzVorbis_I_spec.ps
DISTCLEANFILES = $(built_docs)
# explicit rules for generating docs
if BUILD_DOCS
Vorbis_I_spec.html Vorbis_I_spec.css: $(SPEC_TEX) $(SPEC_PNG) fish_xiph_org.png
htlatex $<
Vorbis_I_spec.pdf: $(SPEC_TEX) $(SPEC_PNG)
pdflatex $<
pdflatex $<
pdflatex $<
else
Vorbis_I_spec.html: NO_DOCS_ERROR
Vorbis_I_spec.pdf: NO_DOCS_ERROR
NO_DOCS_ERROR:
@echo
@echo "*** Documentation has not been built! ***"
@echo "Try re-running after passing --enable-docs to configure."
@echo
endif
if HAVE_DOXYGEN
doxygen-build.stamp: Doxyfile $(top_srcdir)/include/vorbis/*.h
doxygen
touch doxygen-build.stamp
else
doxygen-build.stamp:
echo "*** Warning: Documentation build is disabled."
touch doxygen-build.stamp
endif
install-data-local: doxygen-build.stamp
$(mkinstalldirs) $(DESTDIR)$(docdir)
if test -d vorbis; then \
for dir in vorbis/*; do \
if test -d $$dir; then \
b=`basename $$dir`; \
$(mkinstalldirs) $(DESTDIR)$(docdir)/$$b; \
for f in $$dir/*; do \
$(INSTALL_DATA) $$f $(DESTDIR)$(docdir)/$$b; \
done \
fi \
done \
fi
uninstall-local:
rm -rf $(DESTDIR)$(docdir)
clean-local:
if test -d vorbis; then rm -rf vorbis; fi
if test -f doxygen-build.stamp; then rm -f doxygen-build.stamp; fi

4
rhubarb/lib/vorbis-1.3.6/doc/Vorbis_I_spec.cfg Normal file
View File

@ -0,0 +1,4 @@
\Preamble{html}
\begin{document}
\DeclareGraphicsExtensions{.png}
\EndPreamble

144
rhubarb/lib/vorbis-1.3.6/doc/Vorbis_I_spec.css Normal file
View File

@ -0,0 +1,144 @@
/* start css.sty */
.cmex-10{font-size:83%;}
.cmssbx-10x-x-120{ font-family: sans-serif; font-weight: bold;}
.cmssbx-10x-x-120{ font-family: sans-serif; font-weight: bold;}
.cmssbx-10x-x-248{font-size:206%; font-family: sans-serif; font-weight: bold;}
.cmssbx-10x-x-248{ font-family: sans-serif; font-weight: bold;}
.cmr-17{font-size:141%;}
.cmmi-12{font-style: italic;}
.cmtt-12{font-family: monospace;}
.cmtt-12{font-family: monospace;}
.cmtt-12{font-family: monospace;}
.cmbx-12{ font-weight: bold;}
.cmti-12{ font-style: italic;}
.cmr-8{font-size:66%;}
.cmr-6{font-size:50%;}
.cmmi-8{font-size:66%;font-style: italic;}
.cmsy-8{font-size:66%;}
.cmsy-6{font-size:50%;}
.cmtt-8{font-size:66%;font-family: monospace;}
.cmtt-8{font-family: monospace;}
.cmtt-8{font-family: monospace;}
.cmtt-8x-x-75{font-size:50%;font-family: monospace;}
.cmtt-8x-x-75{font-family: monospace;}
.cmtt-8x-x-75{font-family: monospace;}
p.noindent { text-indent: 0em }
td p.noindent { text-indent: 0em; margin-top:0em; }
p.nopar { text-indent: 0em; }
p.indent{ text-indent: 1.5em }
@media print {div.crosslinks {visibility:hidden;}}
a img { border-top: 0; border-left: 0; border-right: 0; }
center { margin-top:1em; margin-bottom:1em; }
td center { margin-top:0em; margin-bottom:0em; }
.Canvas { position:relative; }
img.math{vertical-align:middle;}
li p.indent { text-indent: 0em }
li p:first-child{ margin-top:0em; }
li p:last-child, li div:last-child { margin-bottom:0.5em; }
li p~ul:last-child, li p~ol:last-child{ margin-bottom:0.5em; }
.enumerate1 {list-style-type:decimal;}
.enumerate2 {list-style-type:lower-alpha;}
.enumerate3 {list-style-type:lower-roman;}
.enumerate4 {list-style-type:upper-alpha;}
div.newtheorem { margin-bottom: 2em; margin-top: 2em;}
.obeylines-h,.obeylines-v {white-space: nowrap; }
div.obeylines-v p { margin-top:0; margin-bottom:0; }
.overline{ text-decoration:overline; }
.overline img{ border-top: 1px solid black; }
td.displaylines {text-align:center; white-space:nowrap;}
.centerline {text-align:center;}
.rightline {text-align:right;}
div.verbatim {font-family: monospace; white-space: nowrap; text-align:left; clear:both; }
.fbox {padding-left:3.0pt; padding-right:3.0pt; text-indent:0pt; border:solid black 0.4pt; }
div.fbox {display:table}
div.center div.fbox {text-align:center; clear:both; padding-left:3.0pt; padding-right:3.0pt; text-indent:0pt; border:solid black 0.4pt; }
div.minipage{width:100%;}
div.center, div.center div.center {text-align: center; margin-left:1em; margin-right:1em;}
div.center div {text-align: left;}
div.flushright, div.flushright div.flushright {text-align: right;}
div.flushright div {text-align: left;}
div.flushleft {text-align: left;}
.underline{ text-decoration:underline; }
.underline img{ border-bottom: 1px solid black; margin-bottom:1pt; }
.framebox-c, .framebox-l, .framebox-r { padding-left:3.0pt; padding-right:3.0pt; text-indent:0pt; border:solid black 0.4pt; }
.framebox-c {text-align:center;}
.framebox-l {text-align:left;}
.framebox-r {text-align:right;}
span.thank-mark{ vertical-align: super }
span.footnote-mark sup.textsuperscript, span.footnote-mark a sup.textsuperscript{ font-size:80%; }
div.tabular, div.center div.tabular {text-align: center; margin-top:0.5em; margin-bottom:0.5em; }
table.tabular td p{margin-top:0em;}
table.tabular {margin-left: auto; margin-right: auto;}
td p:first-child{ margin-top:0em; }
td p:last-child{ margin-bottom:0em; }
div.td00{ margin-left:0pt; margin-right:0pt; }
div.td01{ margin-left:0pt; margin-right:5pt; }
div.td10{ margin-left:5pt; margin-right:0pt; }
div.td11{ margin-left:5pt; margin-right:5pt; }
table[rules] {border-left:solid black 0.4pt; border-right:solid black 0.4pt; }
td.td00{ padding-left:0pt; padding-right:0pt; }
td.td01{ padding-left:0pt; padding-right:5pt; }
td.td10{ padding-left:5pt; padding-right:0pt; }
td.td11{ padding-left:5pt; padding-right:5pt; }
table[rules] {border-left:solid black 0.4pt; border-right:solid black 0.4pt; }
.hline hr, .cline hr{ height : 1px; margin:0px; }
.tabbing-right {text-align:right;}
span.TEX {letter-spacing: -0.125em; }
span.TEX span.E{ position:relative;top:0.5ex;left:-0.0417em;}
a span.TEX span.E {text-decoration: none; }
span.LATEX span.A{ position:relative; top:-0.5ex; left:-0.4em; font-size:85%;}
span.LATEX span.TEX{ position:relative; left: -0.4em; }
div.float, div.figure {margin-left: auto; margin-right: auto;}
div.float img {text-align:center;}
div.figure img {text-align:center;}
.marginpar {width:20%; float:right; text-align:left; margin-left:auto; margin-top:0.5em; font-size:85%; text-decoration:underline;}
.marginpar p{margin-top:0.4em; margin-bottom:0.4em;}
table.equation {width:100%;}
.equation td{text-align:center; }
td.equation { margin-top:1em; margin-bottom:1em; }
td.equation-label { width:5%; text-align:center; }
td.eqnarray4 { width:5%; white-space: normal; }
td.eqnarray2 { width:5%; }
table.eqnarray-star, table.eqnarray {width:100%;}
div.eqnarray{text-align:center;}
div.array {text-align:center;}
div.pmatrix {text-align:center;}
table.pmatrix {width:100%;}
span.pmatrix img{vertical-align:middle;}
div.pmatrix {text-align:center;}
table.pmatrix {width:100%;}
span.bar-css {text-decoration:overline;}
img.cdots{vertical-align:middle;}
.partToc a, .partToc, .likepartToc a, .likepartToc {line-height: 200%; font-weight:bold; font-size:110%;}
.chapterToc a, .chapterToc, .likechapterToc a, .likechapterToc, .appendixToc a, .appendixToc {line-height: 200%; font-weight:bold;}
.index-item, .index-subitem, .index-subsubitem {display:block}
div.caption {text-indent:-2em; margin-left:3em; margin-right:1em; text-align:left;}
div.caption span.id{font-weight: bold; white-space: nowrap; }
h1.partHead{text-align: center}
p.bibitem { text-indent: -2em; margin-left: 2em; margin-top:0.6em; margin-bottom:0.6em; }
p.bibitem-p { text-indent: 0em; margin-left: 2em; margin-top:0.6em; margin-bottom:0.6em; }
.paragraphHead, .likeparagraphHead { margin-top:2em; font-weight: bold;}
.subparagraphHead, .likesubparagraphHead { font-weight: bold;}
.quote {margin-bottom:0.25em; margin-top:0.25em; margin-left:1em; margin-right:1em; text-align:justify;}
.verse{white-space:nowrap; margin-left:2em}
div.maketitle {text-align:center;}
h2.titleHead{text-align:center;}
div.maketitle{ margin-bottom: 2em; }
div.author, div.date {text-align:center;}
div.thanks{text-align:left; margin-left:10%; font-size:85%; font-style:italic; }
div.author{white-space: nowrap;}
.quotation {margin-bottom:0.25em; margin-top:0.25em; margin-left:1em; }
.abstract p {margin-left:5%; margin-right:5%;}
div.abstract {width:100%;}
span.footnote-mark sup.textsuperscript, span.footnote-mark a sup.textsuperscript{ font-size:80%; }
.figure img.graphics {margin-left:10%;}
P.fancyvrb {white-space: nowrap; margin:0em;}
dt.enumerate-enumitem{float:left; clear:left; margin-left:1em; margin-right:1em;}
.uline{ text-decoration:underline; }
.uuline{ text-decoration:underline; }
span.sout {text-decoration: line-through }
span.xout {text-decoration: line-through }
span.uwave {text-decoration:underline }
/* end css.sty */

13243
rhubarb/lib/vorbis-1.3.6/doc/Vorbis_I_spec.html Normal file
View File

File diff suppressed because it is too large Load Diff

BIN
rhubarb/lib/vorbis-1.3.6/doc/Vorbis_I_spec.pdf Normal file
View File

Binary file not shown.

141
rhubarb/lib/vorbis-1.3.6/doc/Vorbis_I_spec.tex Normal file
View File

@ -0,0 +1,141 @@
\documentclass[12pt,paper=a4]{scrartcl}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Packages
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% ...
%\usepackage[margin=3cm]{geometry}
\usepackage{a4wide}
% ...
\usepackage[english]{babel}
%\usepackage[latin1]{inputenc}
%\usepackage[T1]{fontenc}
% Do not indent paragraphs, instead separate them via vertical spacing
\usepackage{parskip}
% Support for graphics, provides \includegraphics
\usepackage{graphicx}
%\graphicspath{{images/}} % Specify subdir containing the images
% Hyperref enriches the generated PDF with clickable links,
% and provides many other useful features.
\usepackage{nameref}
\usepackage[colorlinks]{hyperref}
\def\sectionautorefname{Section} % Write section with capital 'S'
\def\subsectionautorefname{Subsection} % Write subsection with capital 'S'
% The fancyvrb package provides the "Verbatim" environment, which,
% unlike the built-in "verbatim", allows embedding TeX commands, as
% well as tons of other neat stuff (line numbers, formatting adjustments, ...)
\usepackage{fancyvrb}
\fvset{tabsize=4,fontsize=\scriptsize,numbers=left}
% Normally, one can not use the underscore character in LaTeX without
% escaping it (\_ instead of _). Since the Vorbis specs use it a lot,
% we use the underscore package to change this default behavior.
\usepackage[nohyphen]{underscore}
\usepackage{enumitem}
% In LaTeX, pictures are normally put into floating environments, and it is
% left to the typesetting engine to place them in the "optimal" spot. These
% docs however expect pictures to be placed in a *specific* position. So we
% don't use \begin{figure}...\end{figure}, but rather a center environment.
% To still be able to use captions, we use the capt-of package.
\usepackage{capt-of}
% strikeout support
\usepackage[normalem]{ulem}
% blockquote support
\usepackage{csquotes}
% allow 'special' characters in filenames, like undescore :-P
\usepackage{grffile}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Custom commands
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Custom ref command, using hyperrefs autoref & nameref, to simulate the
% behavior of DocBook's '<xref>'.
\newcommand{\xref}[1]{\autoref{#1}, ``\nameref{#1}''}
% Emulat DocBook's '<link>'.
\newcommand{\link}[2]{\hyperref[#1]{#2}}
% Simple 'Note' environment. Can be customized later on.
\newenvironment{note}{\subparagraph*{Note:}}{}
% Map DocBook's <programlisting> to fancyvrb's Verbatim environment
\let\programlisting\Verbatim
\let\endprogramlisting\endVerbatim
% Fake some more DocBook elements
\newcommand{\function}[1]{\texttt{#1}}
\newcommand{\filename}[1]{\texttt{#1}}
\newcommand{\varname}[1]{\texttt{#1}}
\newcommand{\literal}[1]{\texttt{#1}}
% Redefine \~ to generate something that looks more appropriate when used in text.
\renewcommand{\~}{$\sim$}
% Useful helper macro that inserts TODO comments very visibly into the generated
% file. Helps you to not forget to resolve those TODOs... :)
\newcommand{\TODO}[1]{\textcolor{red}{*** #1 ***}}
% Configure graphics formats: Prefer PDF, fall back to PNG or JPG, as available.
\DeclareGraphicsExtensions{.pdf,.png,.jpg,.jpeg}
% NOTE: Things to watch out for: Some chars are reserved in LaTeX. You need to translate them...
% ~ -> $\sim$ (or \~ which we defined above)
% % -> \%
% & -> \&
% < -> $<$
% > -> $>$
% and others. Refer to any of the many LaTeX refs out there if in doubt!
\begin{document}
\title{Vorbis I specification}
\author{Xiph.Org Foundation}
\maketitle
\tableofcontents
\include{01-introduction}
\include{02-bitpacking}
\include{03-codebook}
\include{04-codec}
\include{05-comment}
\include{06-floor0}
\include{07-floor1}
\include{08-residue}
\include{09-helper}
\include{10-tables}
\appendix
\include{a1-encapsulation-ogg}
\include{a2-encapsulation-rtp}
\include{footer}
% TODO: Use a bibliography, as in the example below?
\begin{thebibliography}{99}
\bibitem{Sporer/Brandenburg/Edler} T.~Sporer, K.~Brandenburg and B.~Edler,
The use of multirate filter banks for coding of high quality digital audio,
\url{http://www.iocon.com/resource/docs/ps/eusipco_corrected.ps}.
\end{thebibliography}
\end{document}

BIN
rhubarb/lib/vorbis-1.3.6/doc/Vorbis_I_spec0x.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.3 KiB

BIN
rhubarb/lib/vorbis-1.3.6/doc/Vorbis_I_spec10x.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.7 KiB

BIN
rhubarb/lib/vorbis-1.3.6/doc/Vorbis_I_spec11x.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.7 KiB

BIN
rhubarb/lib/vorbis-1.3.6/doc/Vorbis_I_spec12x.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.3 KiB

BIN
rhubarb/lib/vorbis-1.3.6/doc/Vorbis_I_spec13x.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.7 KiB

BIN
rhubarb/lib/vorbis-1.3.6/doc/Vorbis_I_spec14x.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.8 KiB

BIN
rhubarb/lib/vorbis-1.3.6/doc/Vorbis_I_spec1x.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 556 B

BIN
rhubarb/lib/vorbis-1.3.6/doc/Vorbis_I_spec2x.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 556 B

BIN
rhubarb/lib/vorbis-1.3.6/doc/Vorbis_I_spec3x.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 556 B

BIN
rhubarb/lib/vorbis-1.3.6/doc/Vorbis_I_spec4x.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 556 B

BIN
rhubarb/lib/vorbis-1.3.6/doc/Vorbis_I_spec5x.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 556 B

BIN
rhubarb/lib/vorbis-1.3.6/doc/Vorbis_I_spec6x.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 557 B

BIN
rhubarb/lib/vorbis-1.3.6/doc/Vorbis_I_spec7x.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.4 KiB

BIN
rhubarb/lib/vorbis-1.3.6/doc/Vorbis_I_spec8x.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.5 KiB

BIN
rhubarb/lib/vorbis-1.3.6/doc/Vorbis_I_spec9x.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.8 KiB

184
rhubarb/lib/vorbis-1.3.6/doc/a1-encapsulation-ogg.tex Normal file
View File

@ -0,0 +1,184 @@
% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*-
%!TEX root = Vorbis_I_spec.tex
\section{Embedding Vorbis into an Ogg stream} \label{vorbis:over:ogg}
\subsection{Overview}
This document describes using Ogg logical and physical transport
streams to encapsulate Vorbis compressed audio packet data into file
form.
The \xref{vorbis:spec:intro} provides an overview of the construction
of Vorbis audio packets.
The \href{oggstream.html}{Ogg
bitstream overview} and \href{framing.html}{Ogg logical
bitstream and framing spec} 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.
\subsubsection{Restrictions}
The Ogg/Vorbis I specification currently dictates that Ogg/Vorbis
streams use Ogg transport streams in degenerate, unmultiplexed
form only. That is:
\begin{itemize}
\item
A meta-headerless Ogg file encapsulates the Vorbis I packets
\item
The Ogg stream may be chained, i.e., contain multiple, contigous logical streams (links).
\item
The Ogg stream must be unmultiplexed (only one stream, a Vorbis audio stream, per link)
\end{itemize}
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).
\subsubsection{MIME type}
The MIME type of Ogg files depend on the context. Specifically, complex
multimedia and applications should use \literal{application/ogg},
while visual media should use \literal{video/ogg}, and audio
\literal{audio/ogg}. Vorbis data encapsulated in Ogg may appear
in any of those types. RTP encapsulated Vorbis should use
\literal{audio/vorbis} + \literal{audio/vorbis-config}.
\subsection{Encapsulation}
Ogg encapsulation of a Vorbis packet stream is straightforward.
\begin{itemize}
\item
The first Vorbis packet (the identification 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.
\item
This first page is marked 'beginning of stream' in the page flags.
\item
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.
\item
The granule position of these first pages containing only headers is zero.
\item
The first audio packet of the logical stream begins a fresh Ogg page.
\item
Packets are placed into ogg pages in order until the end of stream.
\item
The last page is marked 'end of stream' in the page flags.
\item
Vorbis packets may span page boundaries.
\item
The granule position of pages containing Vorbis audio is in units
of PCM audio samples (per channel; a stereo stream's granule position
does not increment at twice the speed of a mono stream).
\item
The granule position of a page represents the end PCM sample
position of the last packet \emph{completed} on that
page. The 'last PCM sample' is the last complete sample returned by
decode, not an internal sample awaiting lapping with a
subsequent block. 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'.
Note that the last decoded (fully lapped) PCM sample from a packet
is not necessarily the middle sample from that block. If, eg, the
current Vorbis packet encodes a "long block" and the next Vorbis
packet encodes a "short block", the last decodable sample from the
current packet be at position (3*long\_block\_length/4) -
(short\_block\_length/4).
\item
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.
\begin{itemize}
\item
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.
\item
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.
\end{itemize}
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.
\begin{note}
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.
\end{note}
\item
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.
\end{itemize}

8
rhubarb/lib/vorbis-1.3.6/doc/a2-encapsulation-rtp.tex Normal file
View File

@ -0,0 +1,8 @@
% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*-
%!TEX root = Vorbis_I_spec.tex
\section{Vorbis encapsulation in RTP} \label{vorbis:over:rtp}
% TODO: Include draft-rtp.xml somehow?
Please consult RFC 5215 \textit{``RTP Payload Format for Vorbis Encoded
Audio''} for description of how to embed Vorbis audio in an RTP stream.

BIN
rhubarb/lib/vorbis-1.3.6/doc/components.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.5 KiB

BIN
rhubarb/lib/vorbis-1.3.6/doc/eightphase.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 11 KiB

BIN
rhubarb/lib/vorbis-1.3.6/doc/fish_xiph_org.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.4 KiB

BIN
rhubarb/lib/vorbis-1.3.6/doc/floor1-1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.3 KiB

BIN
rhubarb/lib/vorbis-1.3.6/doc/floor1-2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.7 KiB

BIN
rhubarb/lib/vorbis-1.3.6/doc/floor1-3.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 4.5 KiB

BIN
rhubarb/lib/vorbis-1.3.6/doc/floor1-4.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 4.1 KiB

154
rhubarb/lib/vorbis-1.3.6/doc/floor1_inverse_dB_table.html Normal file
View File

@ -0,0 +1,154 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15"/>
<title>Ogg Vorbis Documentation</title>
<style type="text/css">
body {
margin: 0 18px 0 18px;
padding-bottom: 30px;
font-family: Verdana, Arial, Helvetica, sans-serif;
color: #333333;
font-size: .8em;
}
a {
color: #3366cc;
}
img {
border: 0;
}
#xiphlogo {
margin: 30px 0 16px 0;
}
#content p {
line-height: 1.4;
}
h1, h1 a, h2, h2 a, h3, h3 a {
font-weight: bold;
color: #ff9900;
margin: 1.3em 0 8px 0;
}
h1 {
font-size: 1.3em;
}
h2 {
font-size: 1.2em;
}
h3 {
font-size: 1.1em;
}
li {
line-height: 1.4;
}
#copyright {
margin-top: 30px;
line-height: 1.5em;
text-align: center;
font-size: .8em;
color: #888888;
clear: both;
}
</style>
</head>
<body>
<div id="xiphlogo">
<a href="http://www.xiph.org/"><img src="fish_xiph_org.png" alt="Fish Logo and Xiph.Org"/></a>
</div>
<h1>Ogg Vorbis I format specification: floor1_inverse_dB_table</h1>
<p>The vector <tt>[floor1_inverse_dB_table]</tt> is a 256 element static
lookup table consiting of the following values (read left to right
then top to bottom):</p>
<pre>
1.0649863e-07, 1.1341951e-07, 1.2079015e-07, 1.2863978e-07,
1.3699951e-07, 1.4590251e-07, 1.5538408e-07, 1.6548181e-07,
1.7623575e-07, 1.8768855e-07, 1.9988561e-07, 2.1287530e-07,
2.2670913e-07, 2.4144197e-07, 2.5713223e-07, 2.7384213e-07,
2.9163793e-07, 3.1059021e-07, 3.3077411e-07, 3.5226968e-07,
3.7516214e-07, 3.9954229e-07, 4.2550680e-07, 4.5315863e-07,
4.8260743e-07, 5.1396998e-07, 5.4737065e-07, 5.8294187e-07,
6.2082472e-07, 6.6116941e-07, 7.0413592e-07, 7.4989464e-07,
7.9862701e-07, 8.5052630e-07, 9.0579828e-07, 9.6466216e-07,
1.0273513e-06, 1.0941144e-06, 1.1652161e-06, 1.2409384e-06,
1.3215816e-06, 1.4074654e-06, 1.4989305e-06, 1.5963394e-06,
1.7000785e-06, 1.8105592e-06, 1.9282195e-06, 2.0535261e-06,
2.1869758e-06, 2.3290978e-06, 2.4804557e-06, 2.6416497e-06,
2.8133190e-06, 2.9961443e-06, 3.1908506e-06, 3.3982101e-06,
3.6190449e-06, 3.8542308e-06, 4.1047004e-06, 4.3714470e-06,
4.6555282e-06, 4.9580707e-06, 5.2802740e-06, 5.6234160e-06,
5.9888572e-06, 6.3780469e-06, 6.7925283e-06, 7.2339451e-06,
7.7040476e-06, 8.2047000e-06, 8.7378876e-06, 9.3057248e-06,
9.9104632e-06, 1.0554501e-05, 1.1240392e-05, 1.1970856e-05,
1.2748789e-05, 1.3577278e-05, 1.4459606e-05, 1.5399272e-05,
1.6400004e-05, 1.7465768e-05, 1.8600792e-05, 1.9809576e-05,
2.1096914e-05, 2.2467911e-05, 2.3928002e-05, 2.5482978e-05,
2.7139006e-05, 2.8902651e-05, 3.0780908e-05, 3.2781225e-05,
3.4911534e-05, 3.7180282e-05, 3.9596466e-05, 4.2169667e-05,
4.4910090e-05, 4.7828601e-05, 5.0936773e-05, 5.4246931e-05,
5.7772202e-05, 6.1526565e-05, 6.5524908e-05, 6.9783085e-05,
7.4317983e-05, 7.9147585e-05, 8.4291040e-05, 8.9768747e-05,
9.5602426e-05, 0.00010181521, 0.00010843174, 0.00011547824,
0.00012298267, 0.00013097477, 0.00013948625, 0.00014855085,
0.00015820453, 0.00016848555, 0.00017943469, 0.00019109536,
0.00020351382, 0.00021673929, 0.00023082423, 0.00024582449,
0.00026179955, 0.00027881276, 0.00029693158, 0.00031622787,
0.00033677814, 0.00035866388, 0.00038197188, 0.00040679456,
0.00043323036, 0.00046138411, 0.00049136745, 0.00052329927,
0.00055730621, 0.00059352311, 0.00063209358, 0.00067317058,
0.00071691700, 0.00076350630, 0.00081312324, 0.00086596457,
0.00092223983, 0.00098217216, 0.0010459992, 0.0011139742,
0.0011863665, 0.0012634633, 0.0013455702, 0.0014330129,
0.0015261382, 0.0016253153, 0.0017309374, 0.0018434235,
0.0019632195, 0.0020908006, 0.0022266726, 0.0023713743,
0.0025254795, 0.0026895994, 0.0028643847, 0.0030505286,
0.0032487691, 0.0034598925, 0.0036847358, 0.0039241906,
0.0041792066, 0.0044507950, 0.0047400328, 0.0050480668,
0.0053761186, 0.0057254891, 0.0060975636, 0.0064938176,
0.0069158225, 0.0073652516, 0.0078438871, 0.0083536271,
0.0088964928, 0.009474637, 0.010090352, 0.010746080,
0.011444421, 0.012188144, 0.012980198, 0.013823725,
0.014722068, 0.015678791, 0.016697687, 0.017782797,
0.018938423, 0.020169149, 0.021479854, 0.022875735,
0.024362330, 0.025945531, 0.027631618, 0.029427276,
0.031339626, 0.033376252, 0.035545228, 0.037855157,
0.040315199, 0.042935108, 0.045725273, 0.048696758,
0.051861348, 0.055231591, 0.058820850, 0.062643361,
0.066714279, 0.071049749, 0.075666962, 0.080584227,
0.085821044, 0.091398179, 0.097337747, 0.10366330,
0.11039993, 0.11757434, 0.12521498, 0.13335215,
0.14201813, 0.15124727, 0.16107617, 0.17154380,
0.18269168, 0.19456402, 0.20720788, 0.22067342,
0.23501402, 0.25028656, 0.26655159, 0.28387361,
0.30232132, 0.32196786, 0.34289114, 0.36517414,
0.38890521, 0.41417847, 0.44109412, 0.46975890,
0.50028648, 0.53279791, 0.56742212, 0.60429640,
0.64356699, 0.68538959, 0.72993007, 0.77736504,
0.82788260, 0.88168307, 0.9389798, 1.
</pre>
<div id="copyright">
The Xiph Fish Logo is a
trademark (&trade;) of Xiph.Org.<br/>
These pages &copy; 1994 - 2005 Xiph.Org. All rights reserved.
</div>
</body>
</html>

BIN
rhubarb/lib/vorbis-1.3.6/doc/floorval.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.5 KiB

31
rhubarb/lib/vorbis-1.3.6/doc/footer.tex Normal file
View File

@ -0,0 +1,31 @@
% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*-
%!TEX root = Vorbis_I_spec.tex
\section*{Colophon}
\includegraphics[width=5cm]{fish_xiph_org}
\label{footer}
Ogg is a \href{http://www.xiph.org/}{Xiph.Org Foundation} 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 \href{http://www.xiph.org/about.html}{About
the Xiph.Org Foundation} for details.
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.
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.
Ogg, Vorbis, Xiph.Org Foundation and their logos are trademarks (tm)
of the \href{http://www.xiph.org/}{Xiph.Org Foundation}. These
pages are copyright (C) 1994-2015 Xiph.Org Foundation. All rights
reserved.
This document is set using \LaTeX.

BIN
rhubarb/lib/vorbis-1.3.6/doc/fourphase.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.8 KiB

431
rhubarb/lib/vorbis-1.3.6/doc/framing.html Normal file
View File

@ -0,0 +1,431 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15"/>
<title>Ogg Vorbis Documentation</title>
<style type="text/css">
body {
margin: 0 18px 0 18px;
padding-bottom: 30px;
font-family: Verdana, Arial, Helvetica, sans-serif;
color: #333333;
font-size: .8em;
}
a {
color: #3366cc;
}
img {
border: 0;
}
#xiphlogo {
margin: 30px 0 16px 0;
}
#content p {
line-height: 1.4;
}
h1, h1 a, h2, h2 a, h3, h3 a {
font-weight: bold;
color: #ff9900;
margin: 1.3em 0 8px 0;
}
h1 {
font-size: 1.3em;
}
h2 {
font-size: 1.2em;
}
h3 {
font-size: 1.1em;
}
li {
line-height: 1.4;
}
#copyright {
margin-top: 30px;
line-height: 1.5em;
text-align: center;
font-size: .8em;
color: #888888;
clear: both;
}
</style>
</head>
<body>
<div id="xiphlogo">
<a href="http://www.xiph.org/"><img src="fish_xiph_org.png" alt="Fish Logo and Xiph.Org"/></a>
</div>
<h1>Ogg logical bitstream framing</h1>
<h2>Ogg bitstreams</h2>
<p>The Ogg transport bitstream is designed to provide framing, error
protection and seeking structure for higher-level codec streams that
consist of raw, unencapsulated data packets, such as the Vorbis audio
codec or Theora video codec.</p>
<h2>Application example: Vorbis</h2>
<p>Vorbis encodes short-time blocks of PCM data into raw packets of
bit-packed data. These raw packets may be used directly by transport
mechanisms that provide their own framing and packet-separation
mechanisms (such as UDP datagrams). For stream based storage (such as
files) and transport (such as TCP streams or pipes), Vorbis uses the
Ogg bitstream format to provide framing/sync, sync recapture
after error, landmarks during seeking, and enough information to
properly separate data back into packets at the original packet
boundaries without relying on decoding to find packet boundaries.</p>
<h2>Design constraints for Ogg bitstreams</h2>
<ol>
<li>True streaming; we must not need to seek to build a 100%
complete bitstream.</li>
<li>Use no more than approximately 1-2% of bitstream bandwidth for
packet boundary marking, high-level framing, sync and seeking.</li>
<li>Specification of absolute position within the original sample
stream.</li>
<li>Simple mechanism to ease limited editing, such as a simplified
concatenation mechanism.</li>
<li>Detection of corruption, recapture after error and direct, random
access to data at arbitrary positions in the bitstream.</li>
</ol>
<h2>Logical and Physical Bitstreams</h2>
<p>A <em>logical</em> Ogg bitstream is a contiguous stream of
sequential pages belonging only to the logical bitstream. A
<em>physical</em> Ogg bitstream is constructed from one or more
than one logical Ogg bitstream (the simplest physical bitstream
is simply a single logical bitstream). We describe below the exact
formatting of an Ogg logical bitstream. Combining logical
bitstreams into more complex physical bitstreams is described in the
<a href="oggstream.html">Ogg bitstream overview</a>. The exact
mapping of raw Vorbis packets into a valid Ogg Vorbis physical
bitstream is described in the Vorbis I Specification.</p>
<h2>Bitstream structure</h2>
<p>An Ogg stream is structured by dividing incoming packets into
segments of up to 255 bytes and then wrapping a group of contiguous
packet segments into a variable length page preceded by a page
header. Both the header size and page size are variable; the page
header contains sizing information and checksum data to determine
header/page size and data integrity.</p>
<p>The bitstream is captured (or recaptured) by looking for the beginning
of a page, specifically the capture pattern. Once the capture pattern
is found, the decoder verifies page sync and integrity by computing
and comparing the checksum. At that point, the decoder can extract the
packets themselves.</p>
<h3>Packet segmentation</h3>
<p>Packets are logically divided into multiple segments before encoding
into a page. Note that the segmentation and fragmentation process is a
logical one; it's used to compute page header values and the original
page data need not be disturbed, even when a packet spans page
boundaries.</p>
<p>The raw packet is logically divided into [n] 255 byte segments and a
last fractional segment of &lt; 255 bytes. A packet size may well
consist only of the trailing fractional segment, and a fractional
segment may be zero length. These values, called "lacing values" are
then saved and placed into the header segment table.</p>
<p>An example should make the basic concept clear:</p>
<pre>
<tt>
raw packet:
___________________________________________
|______________packet data__________________| 753 bytes
lacing values for page header segment table: 255,255,243
</tt>
</pre>
<p>We simply add the lacing values for the total size; the last lacing
value for a packet is always the value that is less than 255. Note
that this encoding both avoids imposing a maximum packet size as well
as imposing minimum overhead on small packets (as opposed to, eg,
simply using two bytes at the head of every packet and having a max
packet size of 32k. Small packets (&lt;255, the typical case) are
penalized with twice the segmentation overhead). Using the lacing
values as suggested, small packets see the minimum possible
byte-aligned overheade (1 byte) and large packets, over 512 bytes or
so, see a fairly constant ~.5% overhead on encoding space.</p>
<p>Note that a lacing value of 255 implies that a second lacing value
follows in the packet, and a value of &lt; 255 marks the end of the
packet after that many additional bytes. A packet of 255 bytes (or a
multiple of 255 bytes) is terminated by a lacing value of 0:</p>
<pre><tt>
raw packet:
_______________________________
|________packet data____________| 255 bytes
lacing values: 255, 0
</tt></pre>
<p>Note also that a 'nil' (zero length) packet is not an error; it
consists of nothing more than a lacing value of zero in the header.</p>
<h3>Packets spanning pages</h3>
<p>Packets are not restricted to beginning and ending within a page,
although individual segments are, by definition, required to do so.
Packets are not restricted to a maximum size, although excessively
large packets in the data stream are discouraged; the Ogg
bitstream specification strongly recommends nominal page size of
approximately 4-8kB (large packets are foreseen as being useful for
initialization data at the beginning of a logical bitstream).</p>
<p>After segmenting a packet, the encoder may decide not to place all the
resulting segments into the current page; to do so, the encoder places
the lacing values of the segments it wishes to belong to the current
page into the current segment table, then finishes the page. The next
page is begun with the first value in the segment table belonging to
the next packet segment, thus continuing the packet (data in the
packet body must also correspond properly to the lacing values in the
spanned pages. The segment data in the first packet corresponding to
the lacing values of the first page belong in that page; packet
segments listed in the segment table of the following page must begin
the page body of the subsequent page).</p>
<p>The last mechanic to spanning a page boundary is to set the header
flag in the new page to indicate that the first lacing value in the
segment table continues rather than begins a packet; a header flag of
0x01 is set to indicate a continued packet. Although mandatory, it
is not actually algorithmically necessary; one could inspect the
preceding segment table to determine if the packet is new or
continued. Adding the information to the packet_header flag allows a
simpler design (with no overhead) that needs only inspect the current
page header after frame capture. This also allows faster error
recovery in the event that the packet originates in a corrupt
preceding page, implying that the previous page's segment table
cannot be trusted.</p>
<p>Note that a packet can span an arbitrary number of pages; the above
spanning process is repeated for each spanned page boundary. Also a
'zero termination' on a packet size that is an even multiple of 255
must appear even if the lacing value appears in the next page as a
zero-length continuation of the current packet. The header flag
should be set to 0x01 to indicate that the packet spanned, even though
the span is a nil case as far as data is concerned.</p>
<p>The encoding looks odd, but is properly optimized for speed and the
expected case of the majority of packets being between 50 and 200
bytes (note that it is designed such that packets of wildly different
sizes can be handled within the model; placing packet size
restrictions on the encoder would have only slightly simplified design
in page generation and increased overall encoder complexity).</p>
<p>The main point behind tracking individual packets (and packet
segments) is to allow more flexible encoding tricks that requiring
explicit knowledge of packet size. An example is simple bandwidth
limiting, implemented by simply truncating packets in the nominal case
if the packet is arranged so that the least sensitive portion of the
data comes last.</p>
<h3>Page header</h3>
<p>The headering mechanism is designed to avoid copying and re-assembly
of the packet data (ie, making the packet segmentation process a
logical one); the header can be generated directly from incoming
packet data. The encoder buffers packet data until it finishes a
complete page at which point it writes the header followed by the
buffered packet segments.</p>
<h4>capture_pattern</h4>
<p>A header begins with a capture pattern that simplifies identifying
pages; once the decoder has found the capture pattern it can do a more
intensive job of verifying that it has in fact found a page boundary
(as opposed to an inadvertent coincidence in the byte stream).</p>
<pre><tt>
byte value
0 0x4f 'O'
1 0x67 'g'
2 0x67 'g'
3 0x53 'S'
</tt></pre>
<h4>stream_structure_version</h4>
<p>The capture pattern is followed by the stream structure revision:</p>
<pre><tt>
byte value
4 0x00
</tt></pre>
<h4>header_type_flag</h4>
<p>The header type flag identifies this page's context in the bitstream:</p>
<pre><tt>
byte value
5 bitflags: 0x01: unset = fresh packet
set = continued packet
0x02: unset = not first page of logical bitstream
set = first page of logical bitstream (bos)
0x04: unset = not last page of logical bitstream
set = last page of logical bitstream (eos)
</tt></pre>
<h4>absolute granule position</h4>
<p>(This is packed in the same way the rest of Ogg data is packed; LSb
of LSB first. Note that the 'position' data specifies a 'sample'
number (eg, in a CD quality sample is four octets, 16 bits for left
and 16 bits for right; in video it would likely be the frame number.
It is up to the specific codec in use to define the semantic meaning
of the granule position value). The position specified is the total
samples encoded after including all packets finished on this page
(packets begun on this page but continuing on to the next page do not
count). The rationale here is that the position specified in the
frame header of the last page tells how long the data coded by the
bitstream is. A truncated stream will still return the proper number
of samples that can be decoded fully.</p>
<p>A special value of '-1' (in two's complement) indicates that no packets
finish on this page.</p>
<pre><tt>
byte value
6 0xXX LSB
7 0xXX
8 0xXX
9 0xXX
10 0xXX
11 0xXX
12 0xXX
13 0xXX MSB
</tt></pre>
<h4>stream serial number</h4>
<p>Ogg allows for separate logical bitstreams to be mixed at page
granularity in a physical bitstream. The most common case would be
sequential arrangement, but it is possible to interleave pages for
two separate bitstreams to be decoded concurrently. The serial
number is the means by which pages physical pages are associated with
a particular logical stream. Each logical stream must have a unique
serial number within a physical stream:</p>
<pre><tt>
byte value
14 0xXX LSB
15 0xXX
16 0xXX
17 0xXX MSB
</tt></pre>
<h4>page sequence no</h4>
<p>Page counter; lets us know if a page is lost (useful where packets
span page boundaries).</p>
<pre><tt>
byte value
18 0xXX LSB
19 0xXX
20 0xXX
21 0xXX MSB
</tt></pre>
<h4>page checksum</h4>
<p>32 bit CRC value (direct algorithm, initial val and final XOR = 0,
generator polynomial=0x04c11db7). The value is computed over the
entire header (with the CRC field in the header set to zero) and then
continued over the page. The CRC field is then filled with the
computed value.</p>
<p>(A thorough discussion of CRC algorithms can be found in <a
href="http://www.ross.net/crc/download/crc_v3.txt">"A
Painless Guide to CRC Error Detection Algorithms"</a> by Ross
Williams <a href="mailto:ross@ross.net">ross@ross.net</a>.)</p>
<pre><tt>
byte value
22 0xXX LSB
23 0xXX
24 0xXX
25 0xXX MSB
</tt></pre>
<h4>page_segments</h4>
<p>The number of segment entries to appear in the segment table. The
maximum number of 255 segments (255 bytes each) sets the maximum
possible physical page size at 65307 bytes or just under 64kB (thus
we know that a header corrupted so as destroy sizing/alignment
information will not cause a runaway bitstream. We'll read in the
page according to the corrupted size information that's guaranteed to
be a reasonable size regardless, notice the checksum mismatch, drop
sync and then look for recapture).</p>
<pre><tt>
byte value
26 0x00-0xff (0-255)
</tt></pre>
<h4>segment_table (containing packet lacing values)</h4>
<p>The lacing values for each packet segment physically appearing in
this page are listed in contiguous order.</p>
<pre><tt>
byte value
27 0x00-0xff (0-255)
[...]
n 0x00-0xff (0-255, n=page_segments+26)
</tt></pre>
<p>Total page size is calculated directly from the known header size and
lacing values in the segment table. Packet data segments follow
immediately after the header.</p>
<p>Page headers typically impose a flat .25-.5% space overhead assuming
nominal ~8k page sizes. The segmentation table needed for exact
packet recovery in the streaming layer adds approximately .5-1%
nominal assuming expected encoder behavior in the 44.1kHz, 128kbps
stereo encodings.</p>
<div id="copyright">
The Xiph Fish Logo is a
trademark (&trade;) of Xiph.Org.<br/>
These pages &copy; 1994 - 2005 Xiph.Org. All rights reserved.
</div>
</body>
</html>

239
rhubarb/lib/vorbis-1.3.6/doc/helper.html Normal file
View File

@ -0,0 +1,239 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15"/>
<title>Ogg Vorbis Documentation</title>
<style type="text/css">
body {
margin: 0 18px 0 18px;
padding-bottom: 30px;
font-family: Verdana, Arial, Helvetica, sans-serif;
color: #333333;
font-size: .8em;
}
a {
color: #3366cc;
}
img {
border: 0;
}
#xiphlogo {
margin: 30px 0 16px 0;
}
#content p {
line-height: 1.4;
}
h1, h1 a, h2, h2 a, h3, h3 a {
font-weight: bold;
color: #ff9900;
margin: 1.3em 0 8px 0;
}
h1 {
font-size: 1.3em;
}
h2 {
font-size: 1.2em;
}
h3 {
font-size: 1.1em;
}
li {
line-height: 1.4;
}
#copyright {
margin-top: 30px;
line-height: 1.5em;
text-align: center;
font-size: .8em;
color: #888888;
clear: both;
}
</style>
</head>
<body>
<div id="xiphlogo">
<a href="http://www.xiph.org/"><img src="fish_xiph_org.png" alt="Fish Logo and Xiph.Org"/></a>
</div>
<h1>Ogg Vorbis I format specification: helper equations</h1>
<h1>Overview</h1>
<p>The equations below are used in multiple places by the Vorbis codec
specification. Rather than cluttering up the main specification
documents, they are defined here and linked in the main documents
where appropriate.</p>
<h2><a name="log">ilog</a></h2>
<p>The "ilog(x)" function returns the position number (1 through n) of the
highest set bit in the two's complement integer value
<tt>[x]</tt>. Values of <tt>[x]</tt> less than zero are defined to return zero.</p>
<pre>
1) [return_value] = 0;
2) if ( [x] is greater than zero ){
3) increment [return_value];
4) logical shift [x] one bit to the right, padding the MSb with zero
5) repeat at step 2)
}
6) done
</pre>
<p>Examples:</p>
<ul>
<li>ilog(0) = 0;</li>
<li>ilog(1) = 1;</li>
<li>ilog(2) = 2;</li>
<li>ilog(3) = 2;</li>
<li>ilog(4) = 3;</li>
<li>ilog(7) = 3;</li>
<li>ilog(negative number) = 0;</li>
</ul>
<h2><a name="float32_unpack">float32_unpack</a></h2>
<p>"float32_unpack(x)" is intended to translate the packed binary
representation of a Vorbis codebook float value into the
representation used by the decoder for floating point numbers. For
purposes of this example, we will unpack a Vorbis float32 into a
host-native floating point number.</p>
<pre>
1) [mantissa] = [x] bitwise AND 0x1fffff (unsigned result)
2) [sign] = [x] bitwise AND 0x80000000 (unsigned result)
3) [exponent] = ( [x] bitwise AND 0x7fe00000) shifted right 21 bits (unsigned result)
4) if ( [sign] is nonzero ) then negate [mantissa]
5) return [mantissa] * ( 2 ^ ( [exponent] - 788 ) )
</pre>
<h2><a name="lookup1_values">lookup1_values</a></h2>
<p>"lookup1_values(codebook_entries,codebook_dimensions)" is used to
compute the correct length of the value index for a codebook VQ lookup
table of lookup type 1. The values on this list are permuted to
construct the VQ vector lookup table of size
<tt>[codebook_entries]</tt>.</p>
<p>The return value for this function is defined to be 'the greatest
integer value for which <tt>[return_value] to the power of
[codebook_dimensions] is less than or equal to
[codebook_entries]</tt>'.</p>
<h2><a name="low_neighbor">low_neighbor</a></h2>
<p>"low_neighbor(v,x)" finds the position <i>n</i> in vector [v] of
the greatest value scalar element for which <i>n</i> is less than
<tt>[x]</tt> and <tt>vector [v] element <i>n</i> is less
than vector [v] element [x]</tt>.</p>
<h2><a name="high_neighbor">high_neighbor</a></h2>
<p>"high_neighbor(v,x)" finds the position <i>n</i> in vector [v] of
the lowest value scalar element for which <i>n</i> is less than
<tt>[x]</tt> and <tt>vector [v] element <i>n</i> is greater
than vector [v] element [x]</tt>.</p>
<h2><a name="render_point">render_point</a></h2>
<p>"render_point(x0,y0,x1,y1,X)" is used to find the Y value at point X
along the line specified by x0, x1, y0 and y1. This function uses an
integer algorithm to solve for the point directly without calculating
intervening values along the line.</p>
<pre>
1) [dy] = [y1] - [y0]
2) [adx] = [x1] - [x0]
3) [ady] = absolute value of [dy]
4) [err] = [ady] * ([X] - [x0])
5) [off] = [err] / [adx] using integer division
6) if ( [dy] is less than zero ) {
7) [Y] = [y0] - [off]
} else {
8) [Y] = [y0] + [off]
}
9) done
</pre>
<h2><a name="render_line">render_line</a></h2>
<p>Floor decode type one uses the integer line drawing algorithm of
"render_line(x0, y0, x1, y1, v)" to construct an integer floor
curve for contiguous piecewise line segments. Note that it has not
been relevant elsewhere, but here we must define integer division as
rounding division of both positive and negative numbers toward zero.</p>
<pre>
1) [dy] = [y1] - [y0]
2) [adx] = [x1] - [x0]
3) [ady] = absolute value of [dy]
4) [base] = [dy] / [adx] using integer division
5) [x] = [x0]
6) [y] = [y0]
7) [err] = 0
8) if ( [dy] is less than 0 ) {
9) [sy] = [base] - 1
} else {
10) [sy] = [base] + 1
}
11) [ady] = [ady] - (absolute value of [base]) * [adx]
12) vector [v] element [x] = [y]
13) iterate [x] over the range [x0]+1 ... [x1]-1 {
14) [err] = [err] + [ady];
15) if ( [err] >= [adx] ) {
15) [err] = [err] - [adx]
16) [y] = [y] + [sy]
} else {
17) [y] = [y] + [base]
}
18) vector [v] element [x] = [y]
}
</pre>
<div id="copyright">
The Xiph Fish Logo is a
trademark (&trade;) of Xiph.Org.<br/>
These pages &copy; 1994 - 2005 Xiph.Org. All rights reserved.
</div>
</body>
</html>

BIN
rhubarb/lib/vorbis-1.3.6/doc/hufftree-under.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.2 KiB

BIN
rhubarb/lib/vorbis-1.3.6/doc/hufftree.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.2 KiB

114
rhubarb/lib/vorbis-1.3.6/doc/index.html Normal file
View File

@ -0,0 +1,114 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15"/>
<title>Ogg Vorbis Documentation</title>
<style type="text/css">
body {
margin: 0 18px 0 18px;
padding-bottom: 30px;
font-family: Verdana, Arial, Helvetica, sans-serif;
color: #333333;
font-size: .8em;
}
a {
color: #3366cc;
}
img {
border: 0;
}
#xiphlogo {
margin: 30px 0 16px 0;
}
#content p {
line-height: 1.4;
}
h1, h1 a, h2, h2 a, h3, h3 a {
font-weight: bold;
color: #ff9900;
margin: 1.3em 0 8px 0;
}
h1 {
font-size: 1.3em;
}
h2 {
font-size: 1.2em;
}
h3 {
font-size: 1.1em;
}
li {
line-height: 1.4;
}
#copyright {
margin-top: 30px;
line-height: 1.5em;
text-align: center;
font-size: .8em;
color: #888888;
clear: both;
}
</style>
</head>
<body>
<div id="xiphlogo">
<a href="http://www.xiph.org/"><img src="fish_xiph_org.png" alt="Fish Logo and Xiph.Org"/></a>
</div>
<h1>Ogg Vorbis Documentation</h1>
<h2>Vorbis technical discussion documents</h2>
<ul>
<li><a href="vorbis-fidelity.html">Fidelity measurement terminology</a></li>
<li><a href="stereo.html">Vorbis channel coupling and stereo-specific application</a></li>
</ul>
<h2>Ogg Vorbis I specification</h2>
<ul>
<li>Vorbis I specification [<a href="Vorbis_I_spec.html">html</a>]
[<a href="Vorbis_I_spec.pdf">pdf</a>]</li>
<li><a href="v-comment.html">Vorbis comment header specification</a></li>
<li><a href="rfc5215.txt">Embedding Vorbis encoded
audio in an RTP payload format</a></li>
</ul>
<h2>Ogg Vorbis programming documents</h2>
<ul>
<li><a href="libvorbis/index.html">Programming with libvorbis</a></li>
<li><a href="vorbisfile/index.html">Programming with vorbisfile</a></li>
<li><a href="vorbisenc/index.html">Programming with vorbisenc</a></li>
</ul>
<h2>Ogg bitstream documentation</h2>
<ul>
<li><a href="oggstream.html">Ogg bitstream overview</a></li>
<li><a href="framing.html">Ogg logical bitstream and framing spec</a></li>
</ul>
<div id="copyright">
The Xiph Fish Logo is a
trademark (&trade;) of Xiph.Org.<br/>
These pages &copy; 1994 - 2010 Xiph.Org. All rights reserved.
</div>
</body>
</html>

24
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/Makefile.am Normal file
View File

@ -0,0 +1,24 @@
## Process this file with automake to produce Makefile.in
docdir = $(datadir)/doc/$(PACKAGE)-$(VERSION)/libvorbis
doc_DATA = index.html reference.html style.css vorbis_comment.html\
vorbis_info.html vorbis_analysis_blockout.html vorbis_analysis_buffer.html\
vorbis_analysis_headerout.html vorbis_analysis_init.html \
vorbis_analysis_wrote.html vorbis_analysis.html vorbis_bitrate_addblock.html\
vorbis_bitrate_flushpacket.html vorbis_block_init.html \
vorbis_block_clear.html vorbis_dsp_clear.html vorbis_granule_time.html \
vorbis_version_string.html vorbis_info_blocksize.html vorbis_info_clear.html\
vorbis_info_init.html vorbis_comment_add.html vorbis_comment_add_tag.html\
vorbis_comment_clear.html vorbis_comment_init.html vorbis_comment_query.html\
vorbis_comment_query_count.html vorbis_commentheader_out.html\
vorbis_packet_blocksize.html vorbis_synthesis.html \
vorbis_synthesis_blockin.html vorbis_synthesis_halfrate.html \
vorbis_synthesis_halfrate_p.html vorbis_synthesis_headerin.html \
vorbis_synthesis_idheader.html vorbis_synthesis_init.html \
vorbis_synthesis_lapout.html vorbis_synthesis_pcmout.html \
vorbis_synthesis_read.html vorbis_synthesis_restart.html \
vorbis_synthesis_trackonly.html vorbis_block.html vorbis_dsp_state.html \
return.html overview.html
EXTRA_DIST = $(doc_DATA)

44
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/index.html Normal file
View File

@ -0,0 +1,44 @@
<html>
<head>
<title>libvorbis - Documentation</title>
<link rel=stylesheet href="style.css" type="text/css">
</head>
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
<table border=0 width=100%>
<tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
<h1>Libvorbis Documentation</h1>
<p>
Libvorbis contains the Vorbis reference encoder and decoder.
<p>
This is the lowest-level interface to the Vorbis encoder and decoder. If
you're just looking for a simple way to extract the
audio from an Ogg Vorbis file, you probably want to use <a
href="../vorbisfile/index.html">vorbisfile</a> rather than using libogg
and libvorbis directly.
<p>
<a href="overview.html">Libvorbis API overview</a><br>
<a href="reference.html">Libvorbis API reference</a><br>
<br><br>
<hr noshade>
<table border=0 width=100%>
<tr valign=top>
<td><p class=tiny>copyright &copy; 2000-2010 Xiph.Org</p></td>
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/">Ogg Vorbis</a></p></td>
</tr><tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
</body>
</html>

136
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/overview.html Normal file
View File

@ -0,0 +1,136 @@
<html>
<head>
<title>libvorbis - API Overview</title>
<link rel=stylesheet href="style.css" type="text/css">
</head>
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
<table border=0 width=100%>
<tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
<h1>Libvorbis API Overview</h1>
<p>Libvorbis is the reference implementation of the Vorbis codec. It is
the lowest-level interface to the Vorbis encoder and decoder, working
with packets directly.</p>
<p>All libvorbis routines and structures are declared in "vorbis/codec.h".</p>
<h2>Encoding workflow</h2>
<ol>
<li>Initialize a <a href="vorbis_info.html">vorbis_info</a> structure
by calling <a href="vorbis_info_init.html">vorbis_info_init</a> and
then functions from <a href="../vorbisenc/index.html">libvorbisenc</a>
on it.</li>
<li>Initialize a <a href="vorbis_dsp_state.html">vorbis_dsp_state</a>
for encoding based on the parameters in the vorbis_info by using <a
href="vorbis_analysis_init.html">vorbis_analysis_init</a>.</li>
<li>Initialize a <a href="vorbis_comment.html">vorbis_comment</a>
structure using <a href="vorbis_comment_init.html">vorbis_comment_init</a>,
populate it with any comments you wish to store in the stream, and call
<a href="vorbis_analysis_headerout.html">vorbis_analysis_headerout</a> to
get the three Vorbis stream header packets. Output the packets.</li>
<li>Initialize a <a href="vorbis_block.html">vorbis_block</a> structure
using <a href="vorbis_block_init.html">vorbis_block_init</a>.</li>
<li>While there is more audio to encode:<ol>
<li>Submit a chunk of audio data using <a
href="vorbis_analysis_buffer.html">vorbis_analysis_buffer</a> and <a
href="vorbis_analysis_wrote.html">vorbis_analysis_wrote</a>.</li>
<li>Obtain all available blocks using <a
href="vorbis_analysis_blockout.html">vorbis_analysis_blockout</a>
in a loop. For each block obtained:<ol>
<li>Encode the block into a packet (or prepare it for bitrate management)
using <a href="vorbis_analysis.html">vorbis_analysis</a>. (It's a good
idea to always pass the blocks through the bitrate
management mechanism; more information is on the <a
href="vorbis_analysis.html">vorbis_analysis</a> page. It does not affect
the resulting packets unless you are actually using a bitrate-managed
mode.)</li>
<li>If you are using bitrate management, submit the block using <a
href="vorbis_bitrate_addblock.html">vorbis_bitrate_addblock</a> and obtain
packets using <a
href="vorbis_bitrate_flushpacket.html">vorbis_bitrate_flushpacket</a>.</li>
<li>Output any obtained packets.</li>
</ol></li>
</ol></li>
<li>Submit an empty buffer to indicate the end of input; this will result
in an end-of-stream packet after all encoding steps are done to it.</li>
<li>Destroy the structures using the appropriate vorbis_*_clear routines.</li>
</ol>
<h2>Decoding workflow</h2>
<em>Note: if you do not need to do anything more involved than just
decoding the audio from an Ogg Vorbis file, you can use the far simpler
<a href="../vorbisfile/index.html">libvorbisfile</a> interface, which
will take care of all of the demuxing and low-level decoding operations
(and even the I/O, if you want) for you.</em>
<ol>
<li>When reading the header packets of an Ogg stream, you can use <a
href="vorbis_synthesis_idheader.html">vorbis_synthesis_idheader</a> to
check whether a stream might be Vorbis.</li>
<li>Initialize a <a href="vorbis_info.html">vorbis_info</a> and a <a
href="vorbis_comment.html">vorbis_comment</a> structure using the
appropriate vorbis_*_init routines, then pass the first three packets
from the stream (the Vorbis stream header packets) to <a
href="vorbis_synthesis_headerin.html">vorbis_synthesis_headerin</a> in
order. At this point, you can see the comments and basic parameters of
the Vorbis stream.</li>
<li>Initialize a <a href="vorbis_dsp_state.html">vorbis_dsp_state</a>
for decoding based on the parameters in the vorbis_info by using <a
href="vorbis_synthesis_init.html">vorbis_synthesis_init</a>.</li>
<li>Initialize a <a href="vorbis_block.html">vorbis_block</a> structure
using <a href="vorbis_block_init.html">vorbis_block_init</a>.</li>
<li>While there are more packets to decode:<ol>
<li>Decode the next packet into a block using <a
href="vorbis_synthesis.html">vorbis_synthesis</a>.</li>
<li>Submit the block to the reassembly layer using <a
href="vorbis_synthesis_blockin.html">vorbis_synthesis_blockin</a>.</li>
<li>Obtain some decoded audio using <a
href="vorbis_synthesis_pcmout.html">vorbis_synthesis_pcmout</a> and <a
href="vorbis_synthesis_read.html">vorbis_synthesis_read</a>. Any audio data
returned but not marked as consumed using vorbis_synthesis_read carries
over to the next call to vorbis_synthesis_pcmout.</li>
</ol></li>
<li>Destroy the structures using the appropriate vorbis_*_clear routines.</li>
</ol>
<h2>Metadata workflow</h2>
<em>Note: if you do not need to do anything more involved than just
reading the metadata from an Ogg Vorbis file, <a
href="../vorbisfile/index.html">libvorbisfile</a> can do this for you.</em>
<ol>
<li>Follow the decoding workflow above until you have access to the comments
and basic parameters of the Vorbis stream.</li>
<li>If you want to alter the comments, copy the first packet to the output
file, then create a packet for the modified comments using <a
href="vorbis_commentheader_out.html">vorbis_commentheader_out</a> and output
it, then copy the third packet and all subsequent packets into the output
file.</li>
</ol>
<br><br>
<hr noshade>
<table border=0 width=100%>
<tr valign=top>
<td><p class=tiny>copyright &copy; 2010 Xiph.Org</p></td>
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a></p></td>
</tr><tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
</body>
</html>

86
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/reference.html Normal file
View File

@ -0,0 +1,86 @@
<html>
<head>
<title>Libvorbis API Reference</title>
<link rel=stylesheet href="style.css" type="text/css">
</head>
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
<table border=0 width=100%>
<tr>
<td><p class=tiny>Libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
<h1>Libvorbis API Reference</h1>
<p>
<b>Data Structures</b><br>
<a href="vorbis_block.html">vorbis_block</a><br>
<a href="vorbis_comment.html">vorbis_comment</a><br>
<a href="vorbis_dsp_state.html">vorbis_dsp_state</a><br>
<a href="vorbis_info.html">vorbis_info</a><br>
<br>
<b>Functions used by both decode and encode</b><br>
<a href="vorbis_block_clear.html">vorbis_block_clear()</a><br>
<a href="vorbis_block_init.html">vorbis_block_init()</a><br>
<a href="vorbis_dsp_clear.html">vorbis_dsp_clear()</a><br>
<a href="vorbis_granule_time.html">vorbis_granule_time()</a><br>
<a href="vorbis_info_blocksize.html">vorbis_info_blocksize()</a><br>
<a href="vorbis_info_clear.html">vorbis_info_clear()</a><br>
<a href="vorbis_info_init.html">vorbis_info_init()</a><br>
<a href="vorbis_version_string.html">vorbis_version_string()</a><br>
<br>
<b>Decoding</b><br>
<a href="vorbis_packet_blocksize.html">vorbis_packet_blocksize()</a><br>
<a href="vorbis_synthesis.html">vorbis_synthesis()</a><br>
<a href="vorbis_synthesis_blockin.html">vorbis_synthesis_blockin()</a><br>
<a href="vorbis_synthesis_halfrate.html">vorbis_synthesis_halfrate()</a><br>
<a href="vorbis_synthesis_halfrate_p.html">vorbis_synthesis_halfrate_p()</a><br>
<a href="vorbis_synthesis_headerin.html">vorbis_synthesis_headerin()</a><br>
<a href="vorbis_synthesis_idheader.html">vorbis_synthesis_idheader()</a><br>
<a href="vorbis_synthesis_init.html">vorbis_synthesis_init()</a><br>
<a href="vorbis_synthesis_lapout.html">vorbis_synthesis_lapout()</a><br>
<a href="vorbis_synthesis_pcmout.html">vorbis_synthesis_pcmout()</a><br>
<a href="vorbis_synthesis_read.html">vorbis_synthesis_read()</a><br>
<a href="vorbis_synthesis_restart.html">vorbis_synthesis_restart()</a><br>
<a href="vorbis_synthesis_trackonly.html">vorbis_synthesis_trackonly()</a><br>
<br>
<b>Encoding</b><br>
<a href="vorbis_analysis.html">vorbis_analysis()</a><br>
<a href="vorbis_analysis_blockout.html">vorbis_analysis_blockout()</a><br>
<a href="vorbis_analysis_buffer.html">vorbis_analysis_buffer()</a><br>
<a href="vorbis_analysis_headerout.html">vorbis_analysis_headerout()</a><br>
<a href="vorbis_analysis_init.html">vorbis_analysis_init()</a><br>
<a href="vorbis_analysis_wrote.html">vorbis_analysis_wrote()</a><br>
<a href="vorbis_bitrate_addblock.html">vorbis_bitrate_addblock()</a><br>
<a href="vorbis_bitrate_flushpacket.html">vorbis_bitrate_flushpacket()</a><br>
<br>
<b>Metadata</b><br>
<a href="vorbis_comment_add.html">vorbis_comment_add()</a><br>
<a href="vorbis_comment_add_tag.html">vorbis_comment_add_tag()</a><br>
<a href="vorbis_comment_clear.html">vorbis_comment_clear()</a><br>
<a href="vorbis_comment_init.html">vorbis_comment_init()</a><br>
<a href="vorbis_comment_query.html">vorbis_comment_query()</a><br>
<a href="vorbis_comment_query_count.html">vorbis_comment_query_count()</a><br>
<a href="vorbis_commentheader_out.html">vorbis_commentheader_out()</a><br>
<br>
<b><a href="return.html">Return Codes</a></b><br>
<br><br>
<hr noshade>
<table border=0 width=100%>
<tr valign=top>
<td><p class=tiny>copyright &copy; 2010 Xiph.Org</p></td>
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/">Ogg Vorbis</a></p></td>
</tr><tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
</body>
</html>

79
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/return.html Normal file
View File

@ -0,0 +1,79 @@
<html>
<head>
<title>libvorbis - Return Codes</title>
<link rel=stylesheet href="style.css" type="text/css">
</head>
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
<table border=0 width=100%>
<tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
<h1>Return Codes</h1>
<p>
The following return codes are <tt>#define</tt>d in "vorbis/codec.h" and
may be returned by functions from libvorbis, <a
href="../vorbisfile/index.html">libvorbisfile</a>, and <a
href="../vorbisenc/index.html">libvorbisenc</a>. Descriptions of a code
relevant to a specific function are found in the reference description
of that function.
<dl>
<dt>OV_FALSE</dt>
<dd>Not true, or no data available</dd>
<dt>OV_HOLE</dt>
<dd>Vorbisfile encoutered missing or corrupt data in the bitstream. Recovery
is normally automatic and this return code is for informational purposes only.</dd>
<dt>OV_EREAD</dt>
<dd>Read error while fetching compressed data for decode</dd>
<dt>OV_EFAULT</dt>
<dd>Internal inconsistency in encode or decode state. Continuing is likely not possible.</dd>
<dt>OV_EIMPL</dt>
<dd>Feature not implemented</dd>
<dt>OV_EINVAL</dt>
<dd>Either an invalid argument, or incompletely initialized argument passed to a call</dd>
<dt>OV_ENOTVORBIS</dt>
<dd>The given file/data was not recognized as Ogg Vorbis data.</dd>
<dt>OV_EBADHEADER</dt>
<dd>The file/data is apparently an Ogg Vorbis stream, but contains a corrupted or undecipherable header.</dd>
<dt>OV_EVERSION</dt>
<dd>The bitstream format revision of the given stream is not supported.</dd>
<dt>OV_EBADLINK</dt>
<dd>The given link exists in the Vorbis data stream, but is not decipherable due to garbacge or corruption.</dd>
<dt>OV_ENOSEEK</dt>
<dd>The given stream is not seekable</dd>
</dl>
<br><br>
<hr noshade>
<table border=0 width=100%>
<tr valign=top>
<td><p class=tiny>copyright &copy; 2000-2010 Xiph.Org</p></td>
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/">Ogg Vorbis</a></p></td>
</tr><tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
</body>
</html>

7
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/style.css Normal file
View File

@ -0,0 +1,7 @@
BODY { font-family: Helvetica, sans-serif }
TD { font-family: Helvetica, sans-serif }
P { font-family: Helvetica, sans-serif }
H1 { font-family: Helvetica, sans-serif }
H2 { font-family: Helvetica, sans-serif }
H4 { font-family: Helvetica, sans-serif }
P.tiny { font-size: 8pt }

86
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/vorbis_analysis.html Normal file
View File

@ -0,0 +1,86 @@
<html>
<head>
<title>libvorbis - function - vorbis_analysis</title>
<link rel=stylesheet href="style.css" type="text/css">
</head>
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
<table border=0 width=100%>
<tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
<h1>vorbis_analysis</h1>
<p><i>declared in "vorbis/codec.h";</i></p>
<p>Once the uncompressed audio data has been divided into blocks, this
function is called on each block. It looks up the encoding mode and
dispatches the block to the forward transform provided by that mode.
</p>
<p>When using a basic encoding mode, with no bitrate management,
an ogg_packet pointer can be given, and the coded block is returned
directly through that structure and can be placed in the output stream.
</p>
<p>Otherwise, NULL should be passed for the ogg_packet pointer. In
that case, after the transform has been applied, the block must passed
to vorbis_bitrate_addblock() for further coding. This method works with
both basic and managed encoding modes, so it's recommended for new code.
</p>
<table border=0 color=black cellspacing=0 cellpadding=7>
<tr bgcolor=#cccccc>
<td>
<pre><b>
extern int vorbis_analysis(vorbis_block *vb,ogg_packet *op);
</b></pre>
</td>
</tr>
</table>
<h3>Parameters</h3>
<dl>
<dt><i>vb</i></dt>
<dd>Pointer to the vorbis_block to be encoded.</dd>
<dt><i>op</i></dt>
<dd>Optional pointer to an ogg_packet. This is normally NULL,
and the final output is obtained by passing <i>vb</i> though the
vorbis_bitrate_*() interface to perform further refinement.
However, when not using a bitrate managed encoding mode, it
is possible to skip that step by providing an ogg_packet pointer
here, obtaining the compressed data directly.</dd>
</dl>
<h3>Return Values</h3>
<ul>
<li>0 for success</li>
<li>negative values for failure:
<ul>
<li>OV_EINVAL - Invalid request; a non-NULL value was passed for <i>op</i> when the encoder is using a bitrate managed mode.</li>
<li>OV_EFAULT - Internal fault; indicates a bug or memory corruption.</li>
<li>OV_EIMPL - Unimplemented; not supported by this version of the library.</li>
</ul>
</li>
</ul>
<p>
<br><br>
<hr noshade>
<table border=0 width=100%>
<tr valign=top>
<td><p class=tiny>copyright &copy; 2010 Xiph.Org</p></td>
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a></p></td>
</tr><tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
</body>
</html>

79
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/vorbis_analysis_blockout.html Normal file
View File

@ -0,0 +1,79 @@
<html>
<head>
<title>libvorbis - function - vorbis_analysis_blockout</title>
<link rel=stylesheet href="style.css" type="text/css">
</head>
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
<table border=0 width=100%>
<tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
<h1>vorbis_analysis_blockout</h1>
<p><i>declared in "vorbis/codec.h";</i></p>
<p>This fuction examines the available uncompressed data and tries to
break it into appropriate sized blocks. It should be called in a loop
after adding new data with vorbis_analysis_buffer()/vorbis_analysis_wrote()
until it returns zero (need more data) or an negative value (error).
</p>
<p>
Each block returned should be passed to vorbis_analysis() for transform
and coding.
</p>
<table border=0 color=black cellspacing=0 cellpadding=7>
<tr bgcolor=#cccccc>
<td>
<pre><b>
extern int vorbis_analysis_blockout(vorbis_dsp_state *v,vorbis_block *vb);
</b></pre>
</td>
</tr>
</table>
<h3>Parameters</h3>
<dl>
<dt><i>v</i></dt>
<dd>Pointer to the vorbis_dsp_state representing the encoder.</dd>
<dt><i>vb</i></dt>
<dd>Pointer to a previously initialized vorbis_block object to hold the
returned data.
</dl>
<h3>Return Values</h3>
<ul>
<li>1 for success when more blocks are available.</li>
<li>0 for success when this is the last block available from the current input.</li>
<li>negative values for failure:
<ul>
<li>OV_EINVAL - Invalid parameters.</li>
<li>OV_EFAULT - Internal fault; indicates a bug or memory corruption.</li>
<li>OV_EIMPL - Unimplemented; not supported by this version of the library.</li>
</ul>
</li>
</ul>
<br><br>
<hr noshade>
<table border=0 width=100%>
<tr valign=top>
<td><p class=tiny>copyright &copy; 2010 Xiph.Org</p></td>
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a></p></td>
</tr><tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
</body>
</html>

74
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/vorbis_analysis_buffer.html Normal file
View File

@ -0,0 +1,74 @@
<html>
<head>
<title>libvorbis - function - vorbis_analysis_buffer</title>
<link rel=stylesheet href="style.css" type="text/css">
</head>
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
<table border=0 width=100%>
<tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
<h1>vorbis_analysis_buffer</h1>
<p><i>declared in "vorbis/codec.h";</i></p>
<p>This fuction requests a buffer array for delivering audio to the
encoder for compression.</p>
<p>The Vorbis encoder expects the caller to write audio data as
non-interleaved floating point samples into its internal buffers.
</p>
<p>
The general procedure is to call this function with the number of samples
you have available. The encoder will arrange for that much internal storage
and return an array of buffer pointers, one for each channel of audio.
The caller must then write the audio samples into those buffers, as
float values, and finally call vorbis_analysis_wrote() to tell the
encoder the data is available for analysis.
</p>
<table border=0 color=black cellspacing=0 cellpadding=7>
<tr bgcolor=#cccccc>
<td>
<pre><b>
extern float **vorbis_analysis_buffer(vorbis_dsp_state *v,int vals);
</b></pre>
</td>
</tr>
</table>
<h3>Parameters</h3>
<dl>
<dt><i>v</i></dt>
<dd>Pointer to the vorbis_dsp_state representing the encoder.</dd>
<dt><i>vals</i></dt>
<dd>Number of samples to provide space for in the returned buffer. 1024 is a reasonable choice.</dd>
</dl>
<h3>Return Values</h3>
<p>Returns an array of floating point buffers which can accept data.
A (**float) where the first index is the channel, and the second is
the sample index.<p>
<br><br>
<hr noshade>
<table border=0 width=100%>
<tr valign=top>
<td><p class=tiny>copyright &copy; 2010 Xiph.Org</p></td>
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a></p></td>
</tr><tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
</body>
</html>

83
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/vorbis_analysis_headerout.html Normal file
View File

@ -0,0 +1,83 @@
<html>
<head>
<title>libvorbis - function - vorbis_analysis_headerout</title>
<link rel=stylesheet href="style.css" type="text/css">
</head>
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
<table border=0 width=100%>
<tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
<h1>vorbis_analysis_headerout</h1>
<p><i>declared in "vorbis/codec.h";</i></p>
<p>This function creates and returns the three header packets needed
to configure a decoder to accept compressed data. I should be called
after all encoder initialization and configuration is complete. The
output packets should be placed in order at the start of the compressed
vorbis stream, prior to the first data packet.
</p>
<table border=0 color=black cellspacing=0 cellpadding=7>
<tr bgcolor=#cccccc>
<td>
<pre><b>
extern int vorbis_analysis_headerout(vorbis_dsp_state *v,
vorbis_comment *vc,
ogg_packet *op,
ogg_packet *op_comm,
ogg_packet *op_code);
</b></pre>
</td>
</tr>
</table>
<h3>Parameters</h3>
<dl>
<dt><i>v</i></dt>
<dd>Pointer to an initialized vorbis_dsp_state which holds the encoder configuration.</dd>
<dt><i>vc</i></dt>
<dd>Pointer to an initialized vorbis_comment structure which holds the metadata associated with the stream being encoded.</dd>
<dt><i>op</i></dt>
<dd>Pointer to an ogg_packet structure to be filled out with the stream identification header.</dd>
<dt><i>op_comm</i></dt>
<dd>Pointer to an ogg_packet structure to be filled out with the serialied vorbis_comment data.</dd>
<dt><i>op_code</i></dt>
<dd>Pointer to an ogg_packet structure to be filled out with the codebooks, mode descriptions, etc. which will be used encoding the stream.</dd>
</dl>
<h3>Return Values</h3>
<ul>
<li>0 for success</li>
<li>negative values for failure:
<ul>
<li>OV_EFAULT - Internal fault; indicates a bug or memory corruption.</li>
<li>OV_EIMPL - Unimplemented; not supported by this version of the library.</li>
</ul>
</li>
</ul>
<p>
<br><br>
<hr noshade>
<table border=0 width=100%>
<tr valign=top>
<td><p class=tiny>copyright &copy; 2010 Xiph.Org</p></td>
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a></p></td>
</tr><tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
</body>
</html>

66
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/vorbis_analysis_init.html Normal file
View File

@ -0,0 +1,66 @@
<html>
<head>
<title>libvorbis - function - vorbis_analysis_init</title>
<link rel=stylesheet href="style.css" type="text/css">
</head>
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
<table border=0 width=100%>
<tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
<h1>vorbis_analysis_init</h1>
<p><i>declared in "vorbis/codec.h";</i></p>
<p>This function allocates and initializes the encoder's analysis state
inside a is vorbis_dsp_state, based on the configuration in a vorbis_info
struct.
</p>
<table border=0 color=black cellspacing=0 cellpadding=7>
<tr bgcolor=#cccccc>
<td>
<pre><b>
extern int vorbis_analysis_init(vorbis_dsp_state *v,vorbis_info *vi);
</b></pre>
</td>
</tr>
</table>
<h3>Parameters</h3>
<dl>
<dt><i>v</i</dt>
<dd>Pointer to the vorbis_dsp_state structure to be initialized for encoding.</dd>
<dt><i>vi</i></dt>
<dd>Pointer to an initialized <a href="vorbis_info.html">vorbis_info</a> struct describing the encoder configuration.</dd>
</dl>
<h3>Return Values</h3>
<blockquote>
<li>
0 for success</li>
</blockquote>
<p>
<br><br>
<hr noshade>
<table border=0 width=100%>
<tr valign=top>
<td><p class=tiny>copyright &copy; 2010 Xiph.Org</p></td>
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a></p></td>
</tr><tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
</body>
</html>

80
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/vorbis_analysis_wrote.html Normal file
View File

@ -0,0 +1,80 @@
<html>
<head>
<title>libvorbis - function - vorbis_analysis_wrote</title>
<link rel=stylesheet href="style.css" type="text/css">
</head>
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
<table border=0 width=100%>
<tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
<h1>vorbis_analysis_wrote</h1>
<p><i>declared in "vorbis/codec.h";</i></p>
<p>This function tells the encoder new data is available for compression.
Call this after writing new audio into the buffer array returned by
vorbis_analysis_buffer().
</p>
<p>
Call with the <i>vals</i> parameter set to zero to signal the end
of the input data.
</p>
<table border=0 color=black cellspacing=0 cellpadding=7>
<tr bgcolor=#cccccc>
<td>
<pre><b>
extern int vorbis_analysis_wrote(vorbis_dsp_state *v,int vals);
</b></pre>
</td>
</tr>
</table>
<h3>Parameters</h3>
<dl>
<dt><i>v</i></dt>
<dd>Pointer to the vorbis_dsp_state representing the encoder.</dd>
<dt><i>vals</i></dt>
<dd>Number of samples successfully written. This must be less than
or equal to the value passed to vorbis_analysis_buffer(). A value
of zero means all input data has been provided and the compressed
stream should be finalized.</dd>
</dl>
<h3>Return Values</h3>
<ul>
<li>0 for success</li>
<li>negative values for failure:
<ul>
<li>OV_EINVAL - Invalid request; e.g. vals overflows the allocated space.</li>
<li>OV_EFAULT - Internal fault; indicates a bug or memory corruption.</li>
<li>OV_EIMPL - Unimplemented; not supported by this version of the library.</li>
</ul>
</li>
</ul>
<p>
<br><br>
<hr noshade>
<table border=0 width=100%>
<tr valign=top>
<td><p class=tiny>copyright &copy; 2010 Xiph.Org</p></td>
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a></p></td>
</tr><tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
</body>
</html>

74
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/vorbis_bitrate_addblock.html Normal file
View File

@ -0,0 +1,74 @@
<html>
<head>
<title>libvorbis - function - vorbis_bitrate_addblock</title>
<link rel=stylesheet href="style.css" type="text/css">
</head>
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
<table border=0 width=100%>
<tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
<h1>vorbis_bitrate_addblock</h1>
<p><i>declared in "vorbis/codec.h";</i></p>
<p>This fuction submits a transformed block to the bitrate management
engine for final encoding. Packets are buffered and the packet boundaries
adjusted and padded to meet the target bitrate, if any.</p>
<p>After calling vorbis_bitrate_addblock(), the passed vorbis_block
structure can be reused in another call to vorbis_analysis_blockout().
Call vorbis_bitrate_flushpacket() to obtain the final compressed data.
</p>
<table border=0 color=black cellspacing=0 cellpadding=7>
<tr bgcolor=#cccccc>
<td>
<pre><b>
extern int vorbis_bitrate_addblock(vorbis_block *vb);
</b></pre>
</td>
</tr>
</table>
<h3>Parameters</h3>
<dl>
<dt><i>vb</i></dt>
<dd>Pointer to the vorbis_block to be submitted.</dd>
</dl>
<h3>Return Values</h3>
<ul>
<li>0 for success.</li>
<li>negative values for failure:
<ul>
<li>OV_EINVAL - Invalid parameters.</li>
<li>OV_EFAULT - Internal fault; indicates a bug or memory corruption.</li>
<li>OV_EIMPL - Unimplemented; not supported by this version of the library.</li>
</ul>
</li>
</ul>
<br><br>
<hr noshade>
<table border=0 width=100%>
<tr valign=top>
<td><p class=tiny>copyright &copy; 2010 Xiph.Org</p></td>
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a></p></td>
</tr><tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
</body>
</html>

80
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/vorbis_bitrate_flushpacket.html Normal file
View File

@ -0,0 +1,80 @@
<html>
<head>
<title>libvorbis - function - vorbis_bitrate_flushpacket</title>
<link rel=stylesheet href="style.css" type="text/css">
</head>
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
<table border=0 width=100%>
<tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
<h1>vorbis_bitrate_flushpacket</h1>
<p><i>declared in "vorbis/codec.h";</i></p>
<p>This function returns the next available completed packet from the
bitrate management engine. It should be called in a loop after any call
to vorbis_bitrate_addblock() until it returns either 0 (more data needed)
or a negative value (error).
</p>
<p>
The data returned in the ogg_packet structure can be copied to the
final compressed output stream.
</p>
<table border=0 color=black cellspacing=0 cellpadding=7>
<tr bgcolor=#cccccc>
<td>
<pre><b>
extern int vorbis_bitrate_flushpacket(vorbis_dsp_state *vd,
ogg_packet *op);
</b></pre>
</td>
</tr>
</table>
<h3>Parameters</h3>
<dl>
<dt><i>vd</i></dt>
<dd>Pointer to the vorbis_dsp_state represending the encoder.</dd>
<dt><i>op</i></dt>
<dd>Pointer to an ogg_packet to be filled out with the compressed data.</dd>
</dl>
<h3>Return Values</h3>
<ul>
<li>1 for success when more packets are available.
<li>0 for success when this is the last packet available from the current input.</li>
<li>negative values for failure:
<ul>
<li>OV_EINVAL - Invalid parameters.</li>
<li>OV_EFAULT - Internal fault; indicates a bug or memory corruption.</li>
<li>OV_EIMPL - Unimplemented; not supported by this version of the library.</li>
</ul>
</li>
</ul>
<br><br>
<hr noshade>
<table border=0 width=100%>
<tr valign=top>
<td><p class=tiny>copyright &copy; 2010 Xiph.Org</p></td>
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a></p></td>
</tr><tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
</body>
</html>

60
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/vorbis_block.html Normal file
View File

@ -0,0 +1,60 @@
<html>
<head>
<title>libvorbis - datatype - vorbis_block</title>
<link rel=stylesheet href="style.css" type="text/css">
</head>
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
<table border=0 width=100%>
<tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
<h1>vorbis_block</h1>
<p><i>declared in "vorbis/codec.h"</i></p>
<p>
The vorbis_block structure holds the data for a single block of audio. One
vorbis_block translates to one codec packet. The encoding process consists
of splitting the audio into blocks and encoding the blocks into packets;
decoding consists of decoding the packets into blocks and reassembling
the audio from the blocks.
<p>
This structure is intended to be private. Although the fields are given
in the header file, they should not be directly modified or relied upon
in any way.
<p>
<table border=0 width=100% color=black cellspacing=0 cellpadding=7>
<tr bgcolor=#cccccc>
<td>
<pre><b>typedef struct vorbis_block{
/* private */
} vorbis_block;</b></pre>
</td>
</tr>
</table>
<h3>Parameters</h3>
<ul><li>None public.</li></ul>
<br><br>
<hr noshade>
<table border=0 width=100%>
<tr valign=top>
<td><p class=tiny>copyright &copy; 2010 Xiph.Org</p></td>
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/">Ogg Vorbis</a></p></td>
</tr><tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
</body>
</html>

61
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/vorbis_block_clear.html Normal file
View File

@ -0,0 +1,61 @@
<html>
<head>
<title>libvorbis - function - vorbis_block_clear</title>
<link rel=stylesheet href="style.css" type="text/css">
</head>
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
<table border=0 width=100%>
<tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
<h1>vorbis_block_clear</h1>
<p><i>declared in "vorbis/codec.h";</i></p>
<p>This function frees the internal storage for a vorbis_block structure.</p>
<table border=0 color=black cellspacing=0 cellpadding=7>
<tr bgcolor=#cccccc>
<td>
<pre><b>
extern int vorbis_block_clear(vorbis_block *vb);
</b></pre>
</td>
</tr>
</table>
<h3>Parameters</h3>
<dl>
<dt><i>vb</i></dt>
<dd>Pointer to a vorbis_block struct to be cleared.</dd>
</dl>
<h3>Return Values</h3>
<blockquote>
<li>
0 for success</li>
</blockquote>
<p>
<br><br>
<hr noshade>
<table border=0 width=100%>
<tr valign=top>
<td><p class=tiny>copyright &copy; 2010 Xiph.Org</p></td>
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a></p></td>
</tr><tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
</body>
</html>

66
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/vorbis_block_init.html Normal file
View File

@ -0,0 +1,66 @@
<html>
<head>
<title>libvorbis - function - vorbis_block_init</title>
<link rel=stylesheet href="style.css" type="text/css">
</head>
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
<table border=0 width=100%>
<tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
<h1>vorbis_block_init</h1>
<p><i>declared in "vorbis/codec.h";</i></p>
<p>This function initializes a vorbis_block structure and allocates its
internal storage. A vorbis_block is used to represent a particular block
of input audio which can be analyzed and coded as a unit.
</p>
<table border=0 color=black cellspacing=0 cellpadding=7>
<tr bgcolor=#cccccc>
<td>
<pre><b>
extern int vorbis_block_init(vorbis_dsp_state *v, vorbis_block *vb);
</b></pre>
</td>
</tr>
</table>
<h3>Parameters</h3>
<dl>
<dt><i>v</i</dt>
<dd>Pointer to an initialized vorbis_dsp_state with which to associate the new block.</dd>
<dt><i>vb</i></dt>
<dd>Pointer to a vorbis_block struct to be initialized.</dd>
</dl>
<h3>Return Values</h3>
<blockquote>
<li>
0 for success</li>
</blockquote>
<p>
<br><br>
<hr noshade>
<table border=0 width=100%>
<tr valign=top>
<td><p class=tiny>copyright &copy; 2010 Xiph.Org</p></td>
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a></p></td>
</tr><tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
</body>
</html>

80
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/vorbis_comment.html Normal file
View File

@ -0,0 +1,80 @@
<html>
<head>
<title>libvorbis - datatype - vorbis_comment</title>
<link rel=stylesheet href="style.css" type="text/css">
</head>
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
<table border=0 width=100%>
<tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
<h1>vorbis_comment</h1>
<p><i>declared in "vorbis/codec.h"</i></p>
<p>
The vorbis_comment structure defines an Ogg Vorbis comment.
<p>
Only the fields the program needs must be defined. If a field isn't
defined by the application, it will either be blank (if it's a string value)
or set to some reasonable default (usually 0).
<p>
<i>Note:</i> When encoding, while it <i>is</i> supported to modify a
vorbis_comment structure directly, be sure to read the notes on the
<a href="vorbis_comment_init.html">vorbis_comment_init</a> and
<a href="vorbis_comment_clear.html">vorbis_comment_clear</a> pages for
considerations on memory allocation and freeing before you do so. Rule of
thumb: call vorbis_comment_init, then <i>either</i> do all allocation,
freeing, and modification yourself and <i>do not</i> call
vorbis_comment_clear, <i>or</i> do all modification using libvorbis
functions and <i>do</i> call vorbis_comment_clear.
<p>
<table border=0 width=100% color=black cellspacing=0 cellpadding=7>
<tr bgcolor=#cccccc>
<td>
<pre><b>typedef struct vorbis_comment{
/* unlimited user comment fields. */
char **user_comments;
int *comment_lengths;
int comments;
char *vendor;
} vorbis_comment;</b></pre>
</td>
</tr>
</table>
<h3>Parameters</h3>
<dl>
<dt><i>user_comments</i></dt>
<dd>Unlimited user comment array. The individual strings in the array are 8 bit clean, by the Vorbis specification, and as such the <tt>comment_lengths</tt> array should be consulted to determine string length. For convenience, each string is also NULL-terminated by the decode library (although Vorbis comments are not NULL terminated within the bitstream itself).</dd>
<dt><i>comment_lengths</i></dt>
<dd>An int array that stores the length of each comment string</dd>
<dt><i>comments</i></dt>
<dd>Int signifying number of user comments in user_comments field.</dd>
<dt><i>vendor</i></dt>
<dd>Information about the Vorbis implementation that encoded the file. Stored in a standard C 0-terminated string. Libvorbis will fill this in itself when encoding a comment packet from this structure; when decoding, this contains the vendor string that was in the comment packet.</dd>
</dl>
<br><br>
<hr noshade>
<table border=0 width=100%>
<tr valign=top>
<td><p class=tiny>copyright &copy; 2000-2010 Xiph.Org</p></td>
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/">Ogg Vorbis</a></p></td>
</tr><tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
</body>
</html>

70
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/vorbis_comment_add.html Normal file
View File

@ -0,0 +1,70 @@
<html>
<head>
<title>libvorbis - function - vorbis_comment_add</title>
<link rel=stylesheet href="style.css" type="text/css">
</head>
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
<table border=0 width=100%>
<tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
<h1>vorbis_comment_add</h1>
<p><i>declared in "vorbis/codec.h";</i></p>
<p>This function adds a raw comment string to a
<a href="vorbis_comment.html">vorbis_comment</a> structure.</p>
<p>This function should be used if the string is already in the
form "KEY=value". If you have a separate key and value, use
<a href="vorbis_comment_add_tag.html">vorbis_comment_add_tag</a>
instead.</p>
<table border=0 color=black cellspacing=0 cellpadding=7>
<tr bgcolor=#cccccc>
<td>
<pre><b>
extern void vorbis_comment_add(vorbis_comment *vc, const char *comment);
</b></pre>
</td>
</tr>
</table>
<h3>Parameters</h3>
<dl>
<dt><i>vc</i></dt>
<dd>Pointer to a vorbis_comment structure to add the comment to.</dd>
<dt><i>comment</i></dt>
<dd>Pointer to the null-terminated raw comment string. The string will
be copied, so it can be freed or modified after this function returns
without affecting the vorbis_comment structure's contents.</dd>
</dl>
<h3>Return Values</h3>
<blockquote>
<li>None.</li>
</blockquote>
<p>
<br><br>
<hr noshade>
<table border=0 width=100%>
<tr valign=top>
<td><p class=tiny>copyright &copy; 2010 Xiph.Org</p></td>
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a></p></td>
</tr><tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
</body>
</html>

74
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/vorbis_comment_add_tag.html Normal file
View File

@ -0,0 +1,74 @@
<html>
<head>
<title>libvorbis - function - vorbis_comment_add_tag</title>
<link rel=stylesheet href="style.css" type="text/css">
</head>
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
<table border=0 width=100%>
<tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
<h1>vorbis_comment_add_tag</h1>
<p><i>declared in "vorbis/codec.h";</i></p>
<p>This function adds a tag-comment pair to a
<a href="vorbis_comment.html">vorbis_comment</a> structure. There can
be more than one comment value for the same tag; if a comment with the
same tag already exists, another comment with the same tag is added.</p>
<p>If you already have a string in the form "KEY=value", see
<a href="vorbis_comment_add.html">vorbis_comment_add</a> instead.</p>
<table border=0 color=black cellspacing=0 cellpadding=7>
<tr bgcolor=#cccccc>
<td>
<pre><b>
extern void vorbis_comment_add_tag(vorbis_comment *vc,
const char *tag, const char *contents);
</b></pre>
</td>
</tr>
</table>
<h3>Parameters</h3>
<dl>
<dt><i>vc</i></dt>
<dd>Pointer to a vorbis_comment structure to add the comment to.</dd>
<dt><i>tag</i></dt>
<dd>Pointer to the null-terminated tag string. The string will
be copied, so it can be freed or modified after this function returns
without affecting the vorbis_comment structure's contents.</dd>
<dt><i>contents</i></dt>
<dd>Pointer to the null-terminated comment contents string. This will
also be copied.</dd>
</dl>
<h3>Return Values</h3>
<blockquote>
<li>None.</li>
</blockquote>
<p>
<br><br>
<hr noshade>
<table border=0 width=100%>
<tr valign=top>
<td><p class=tiny>copyright &copy; 2010 Xiph.Org</p></td>
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a></p></td>
</tr><tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
</body>
</html>

69
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/vorbis_comment_clear.html Normal file
View File

@ -0,0 +1,69 @@
<html>
<head>
<title>libvorbis - function - vorbis_comment_clear</title>
<link rel=stylesheet href="style.css" type="text/css">
</head>
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
<table border=0 width=100%>
<tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
<h1>vorbis_comment_clear</h1>
<p><i>declared in "vorbis/codec.h";</i></p>
<p>This function frees the internal storage associated with a <a href="vorbis_comment.html">vorbis_comment</a> structure.</p>
<p><i>Note:</i> Be careful if you have modified the vorbis_comment
structure yourself, as libvorbis will try to use its own wrappers of
memory allocation functions to free the contents of the vorbis_comment
structure. This will not work correctly unless all arrays and comment
strings contained in the vorbis_comment structure were allocated by
libvorbis itself. This function is only guaranteed to be safe if all
modification to the vorbis_comment structure was done using libvorbis
functions.</p>
<table border=0 color=black cellspacing=0 cellpadding=7>
<tr bgcolor=#cccccc>
<td>
<pre><b>
extern void vorbis_comment_clear(vorbis_comment *vc);
</b></pre>
</td>
</tr>
</table>
<h3>Parameters</h3>
<dl>
<dt><i>vc</i></dt>
<dd>The vorbis_comment structure to clear.</dd>
</dl>
<h3>Return Values</h3>
<blockquote>
<li>None.</li>
</blockquote>
<p>
<br><br>
<hr noshade>
<table border=0 width=100%>
<tr valign=top>
<td><p class=tiny>copyright &copy; 2010 Xiph.Org</p></td>
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a></p></td>
</tr><tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
</body>
</html>

72
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/vorbis_comment_init.html Normal file
View File

@ -0,0 +1,72 @@
<html>
<head>
<title>libvorbis - function - vorbis_comment_init</title>
<link rel=stylesheet href="style.css" type="text/css">
</head>
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
<table border=0 width=100%>
<tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
<h1>vorbis_comment_init</h1>
<p><i>declared in "vorbis/codec.h";</i></p>
<p>This function initializes a <a href="vorbis_comment.html">vorbis_comment</a>
structure for use. After calling this function, the vorbis_comment
structure contains no comments.</p>
<p><i>Note:</i> No internal storage is allocated by this function;
internal storage is allocated as needed by other libvorbis functions that
modify the vorbis_comment structure. If you modify the vorbis_comment
structure directly, without using libvorbis, you should <i>not</i>
call <a href="vorbis_comment_clear.html">vorbis_comment_clear</a> when
you are finished but instead clean up after it yourself. See the note
on the <a href="vorbis_comment_clear.html">vorbis_comment_clear</a>
page for more information.</p>
<table border=0 color=black cellspacing=0 cellpadding=7>
<tr bgcolor=#cccccc>
<td>
<pre><b>
extern void vorbis_comment_init(vorbis_comment *vc);
</b></pre>
</td>
</tr>
</table>
<h3>Parameters</h3>
<dl>
<dt><i>vc</i></dt>
<dd>Pointer to the <a href="vorbis_comment.html">vorbis_comment</a>
structure to initialize.</dd>
</dl>
<h3>Return Values</h3>
<blockquote>
<li>None.</li>
</blockquote>
<p>
<br><br>
<hr noshade>
<table border=0 width=100%>
<tr valign=top>
<td><p class=tiny>copyright &copy; 2010 Xiph.Org</p></td>
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a></p></td>
</tr><tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
</body>
</html>

72
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/vorbis_comment_query.html Normal file
View File

@ -0,0 +1,72 @@
<html>
<head>
<title>libvorbis - function - vorbis_comment_query</title>
<link rel=stylesheet href="style.css" type="text/css">
</head>
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
<table border=0 width=100%>
<tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
<h1>vorbis_comment_query</h1>
<p><i>declared in "vorbis/codec.h";</i></p>
<p>This function retrieves a comment string for a given tag in a
<a href="vorbis_comment.html">vorbis_comment</a> structure.</p>
<table border=0 color=black cellspacing=0 cellpadding=7>
<tr bgcolor=#cccccc>
<td>
<pre><b>
extern char *vorbis_comment_query(vorbis_comment *vc, const char *tag, int count);
</b></pre>
</td>
</tr>
</table>
<h3>Parameters</h3>
<dl>
<dt><i>vc</i></dt>
<dd>Pointer to the vorbis_comment structure.</dd>
<dt><i>tag</i></dt>
<dd>Pointer to a null-terminated string of the comment tag to look
for. Tags are compared case-insensitively.</dd>
<dt><i>count</i></dt>
<dd>The index of the comment string to retrieve. A value of 0 indicates
the first comment whose tag matches <i>tag</i>. Use
<a href="vorbis_comment_query_count.html">vorbis_comment_query_count</a>
to determine the number of matching comments.</dd>
</dl>
<h3>Return Values</h3>
<blockquote>
<li>A pointer to the comment string. The underlying buffer is owned by
the vorbis_comment structure.</li>
<li>NULL on a nonexistent tag or if <i>count</i> is greater than or
equal to the number of matching comments.</li>
</blockquote>
<p>
<br><br>
<hr noshade>
<table border=0 width=100%>
<tr valign=top>
<td><p class=tiny>copyright &copy; 2010 Xiph.Org</p></td>
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a></p></td>
</tr><tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
</body>
</html>

66
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/vorbis_comment_query_count.html Normal file
View File

@ -0,0 +1,66 @@
<html>
<head>
<title>libvorbis - function - vorbis_comment_query_count</title>
<link rel=stylesheet href="style.css" type="text/css">
</head>
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
<table border=0 width=100%>
<tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
<h1>vorbis_comment_query_count</h1>
<p><i>declared in "vorbis/codec.h";</i></p>
<p>This function determines the number of comments with a given tag
that are present in a <a href="vorbis_comment.html">vorbis_comment</a>
structure.</p>
<table border=0 color=black cellspacing=0 cellpadding=7>
<tr bgcolor=#cccccc>
<td>
<pre><b>
extern int vorbis_comment_query_count(vorbis_comment *vc, const char *tag);
</b></pre>
</td>
</tr>
</table>
<h3>Parameters</h3>
<dl>
<dt><i>vc</i></dt>
<dd>Pointer to the vorbis_comment structure.</dd>
<dt><i>tag</i></dt>
<dd>Pointer to a null-terminated string of the comment tag to look
for. Tags are compared case-insensitively.</dd>
</dl>
<h3>Return Values</h3>
<blockquote>
<li>The number of comments present with the given tag.</li>
<li>0 if no such comments are present.</li>
</blockquote>
<p>
<br><br>
<hr noshade>
<table border=0 width=100%>
<tr valign=top>
<td><p class=tiny>copyright &copy; 2010 Xiph.Org</p></td>
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a></p></td>
</tr><tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
</body>
</html>

65
rhubarb/lib/vorbis-1.3.6/doc/libvorbis/vorbis_commentheader_out.html Normal file
View File

@ -0,0 +1,65 @@
<html>
<head>
<title>libvorbis - function - vorbis_commentheader_out</title>
<link rel=stylesheet href="style.css" type="text/css">
</head>
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
<table border=0 width=100%>
<tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
<h1>vorbis_commentheader_out</h1>
<p><i>declared in "vorbis/codec.h";</i></p>
<p>This function encodes the contents of a
<a href="vorbis_comment.html">vorbis_comment</a> structure into an
ogg_packet.</p>
<table border=0 color=black cellspacing=0 cellpadding=7>
<tr bgcolor=#cccccc>
<td>
<pre><b>
extern int vorbis_commentheader_out(vorbis_comment *vc, ogg_packet *op);
</b></pre>
</td>
</tr>
</table>
<h3>Parameters</h3>
<dl>
<dt><i>vc</i></dt>
<dd>The vorbis_comment structure to encode.</dd>
<dt><i>op</i></dt>
<dd>The ogg_packet to place the encoded comment packet into.</dd>
</dl>
<h3>Return Values</h3>
<blockquote>
<li>0 on success.</li>
<li>OV_EIMPL on error.</li>
</blockquote>
<p>
<br><br>
<hr noshade>
<table border=0 width=100%>
<tr valign=top>
<td><p class=tiny>copyright &copy; 2010 Xiph.Org</p></td>
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a></p></td>
</tr><tr>
<td><p class=tiny>libvorbis documentation</p></td>
<td align=right><p class=tiny>libvorbis version 1.3.2 - 20101101</p></td>
</tr>
</table>
</body>
</html>

Some files were not shown because too many files have changed in this diff Show More