[xiph-commits] r14647 - in branches/vorbis-aotuv: . doc doc/vorbisfile doc/xml examples include/vorbis lib lib/books/coupled lib/books/floor lib/books/uncoupled lib/modes macosx macosx/Vorbis.xcodeproj vq win32 win32/VS2005 win32/VS2005/libvorbis win32/VS2005/libvorbisfile win32/VS2005/vorbisdec win32/VS2005/vorbisenc
j at svn.xiph.org
j at svn.xiph.org
Tue Apr 1 03:48:05 PDT 2008
Author: j
Date: 2008-04-01 03:47:58 -0700 (Tue, 01 Apr 2008)
New Revision: 14647
Added:
branches/vorbis-aotuv/doc/draft-ietf-avt-rtp-vorbis-06.txt
branches/vorbis-aotuv/doc/draft-ietf-avt-rtp-vorbis-06.xml
branches/vorbis-aotuv/doc/vorbisfile/ov_fopen.html
branches/vorbis-aotuv/lib/psy_table.h
branches/vorbis-aotuv/win32/VS2005/
branches/vorbis-aotuv/win32/VS2005/libvorbis/
branches/vorbis-aotuv/win32/VS2005/libvorbis/libvorbis.vcproj
branches/vorbis-aotuv/win32/VS2005/libvorbisfile/
branches/vorbis-aotuv/win32/VS2005/libvorbisfile/libvorbisfile.def
branches/vorbis-aotuv/win32/VS2005/libvorbisfile/libvorbisfile.vcproj
branches/vorbis-aotuv/win32/VS2005/vorbisdec/
branches/vorbis-aotuv/win32/VS2005/vorbisdec/vorbisdec.vcproj
branches/vorbis-aotuv/win32/VS2005/vorbisenc/
branches/vorbis-aotuv/win32/VS2005/vorbisenc/vorbisenc.vcproj
Modified:
branches/vorbis-aotuv/CHANGES
branches/vorbis-aotuv/COPYING
branches/vorbis-aotuv/Makefile.am
branches/vorbis-aotuv/README
branches/vorbis-aotuv/aoTuV_README-1st.txt
branches/vorbis-aotuv/aoTuV_technical.txt
branches/vorbis-aotuv/autogen.sh
branches/vorbis-aotuv/configure.in
branches/vorbis-aotuv/doc/Makefile.am
branches/vorbis-aotuv/doc/Vorbis_I_spec.html
branches/vorbis-aotuv/doc/Vorbis_I_spec.pdf
branches/vorbis-aotuv/doc/floor1_inverse_dB_table.html
branches/vorbis-aotuv/doc/framing.html
branches/vorbis-aotuv/doc/helper.html
branches/vorbis-aotuv/doc/index.html
branches/vorbis-aotuv/doc/oggstream.html
branches/vorbis-aotuv/doc/programming.html
branches/vorbis-aotuv/doc/stereo.html
branches/vorbis-aotuv/doc/v-comment.html
branches/vorbis-aotuv/doc/vorbis-fidelity.html
branches/vorbis-aotuv/doc/vorbis.html
branches/vorbis-aotuv/doc/vorbisfile/OggVorbis_File.html
branches/vorbis-aotuv/doc/vorbisfile/callbacks.html
branches/vorbis-aotuv/doc/vorbisfile/chaining_example_c.html
branches/vorbis-aotuv/doc/vorbisfile/chainingexample.html
branches/vorbis-aotuv/doc/vorbisfile/crosslap.html
branches/vorbis-aotuv/doc/vorbisfile/datastructures.html
branches/vorbis-aotuv/doc/vorbisfile/decoding.html
branches/vorbis-aotuv/doc/vorbisfile/example.html
branches/vorbis-aotuv/doc/vorbisfile/exampleindex.html
branches/vorbis-aotuv/doc/vorbisfile/fileinfo.html
branches/vorbis-aotuv/doc/vorbisfile/index.html
branches/vorbis-aotuv/doc/vorbisfile/initialization.html
branches/vorbis-aotuv/doc/vorbisfile/ov_bitrate.html
branches/vorbis-aotuv/doc/vorbisfile/ov_bitrate_instant.html
branches/vorbis-aotuv/doc/vorbisfile/ov_callbacks.html
branches/vorbis-aotuv/doc/vorbisfile/ov_clear.html
branches/vorbis-aotuv/doc/vorbisfile/ov_comment.html
branches/vorbis-aotuv/doc/vorbisfile/ov_crosslap.html
branches/vorbis-aotuv/doc/vorbisfile/ov_info.html
branches/vorbis-aotuv/doc/vorbisfile/ov_open.html
branches/vorbis-aotuv/doc/vorbisfile/ov_open_callbacks.html
branches/vorbis-aotuv/doc/vorbisfile/ov_pcm_seek.html
branches/vorbis-aotuv/doc/vorbisfile/ov_pcm_seek_lap.html
branches/vorbis-aotuv/doc/vorbisfile/ov_pcm_seek_page.html
branches/vorbis-aotuv/doc/vorbisfile/ov_pcm_seek_page_lap.html
branches/vorbis-aotuv/doc/vorbisfile/ov_pcm_tell.html
branches/vorbis-aotuv/doc/vorbisfile/ov_pcm_total.html
branches/vorbis-aotuv/doc/vorbisfile/ov_raw_seek.html
branches/vorbis-aotuv/doc/vorbisfile/ov_raw_seek_lap.html
branches/vorbis-aotuv/doc/vorbisfile/ov_raw_tell.html
branches/vorbis-aotuv/doc/vorbisfile/ov_raw_total.html
branches/vorbis-aotuv/doc/vorbisfile/ov_read.html
branches/vorbis-aotuv/doc/vorbisfile/ov_read_float.html
branches/vorbis-aotuv/doc/vorbisfile/ov_seekable.html
branches/vorbis-aotuv/doc/vorbisfile/ov_serialnumber.html
branches/vorbis-aotuv/doc/vorbisfile/ov_streams.html
branches/vorbis-aotuv/doc/vorbisfile/ov_test.html
branches/vorbis-aotuv/doc/vorbisfile/ov_test_callbacks.html
branches/vorbis-aotuv/doc/vorbisfile/ov_test_open.html
branches/vorbis-aotuv/doc/vorbisfile/ov_time_seek.html
branches/vorbis-aotuv/doc/vorbisfile/ov_time_seek_lap.html
branches/vorbis-aotuv/doc/vorbisfile/ov_time_seek_page.html
branches/vorbis-aotuv/doc/vorbisfile/ov_time_seek_page_lap.html
branches/vorbis-aotuv/doc/vorbisfile/ov_time_tell.html
branches/vorbis-aotuv/doc/vorbisfile/ov_time_total.html
branches/vorbis-aotuv/doc/vorbisfile/overview.html
branches/vorbis-aotuv/doc/vorbisfile/reference.html
branches/vorbis-aotuv/doc/vorbisfile/return.html
branches/vorbis-aotuv/doc/vorbisfile/seekexample.html
branches/vorbis-aotuv/doc/vorbisfile/seeking.html
branches/vorbis-aotuv/doc/vorbisfile/seeking_example_c.html
branches/vorbis-aotuv/doc/vorbisfile/seeking_test_c.html
branches/vorbis-aotuv/doc/vorbisfile/seekingexample.html
branches/vorbis-aotuv/doc/vorbisfile/threads.html
branches/vorbis-aotuv/doc/vorbisfile/vorbis_comment.html
branches/vorbis-aotuv/doc/vorbisfile/vorbis_info.html
branches/vorbis-aotuv/doc/vorbisfile/vorbisfile_example_c.html
branches/vorbis-aotuv/doc/xml/05-comment.xml
branches/vorbis-aotuv/doc/xml/08-residue.xml
branches/vorbis-aotuv/doc/xml/footer.xml
branches/vorbis-aotuv/examples/chaining_example.c
branches/vorbis-aotuv/examples/decoder_example.c
branches/vorbis-aotuv/examples/encoder_example.c
branches/vorbis-aotuv/examples/seeking_example.c
branches/vorbis-aotuv/examples/vorbisfile_example.c
branches/vorbis-aotuv/include/vorbis/Makefile.am
branches/vorbis-aotuv/include/vorbis/codec.h
branches/vorbis-aotuv/include/vorbis/vorbisenc.h
branches/vorbis-aotuv/include/vorbis/vorbisfile.h
branches/vorbis-aotuv/lib/Makefile.am
branches/vorbis-aotuv/lib/analysis.c
branches/vorbis-aotuv/lib/backends.h
branches/vorbis-aotuv/lib/barkmel.c
branches/vorbis-aotuv/lib/bitrate.c
branches/vorbis-aotuv/lib/bitrate.h
branches/vorbis-aotuv/lib/block.c
branches/vorbis-aotuv/lib/books/coupled/res_books_stereo.h
branches/vorbis-aotuv/lib/books/floor/floor_books.h
branches/vorbis-aotuv/lib/books/uncoupled/res_books_uncoupled.h
branches/vorbis-aotuv/lib/codebook.c
branches/vorbis-aotuv/lib/codebook.h
branches/vorbis-aotuv/lib/codec_internal.h
branches/vorbis-aotuv/lib/envelope.c
branches/vorbis-aotuv/lib/envelope.h
branches/vorbis-aotuv/lib/floor0.c
branches/vorbis-aotuv/lib/floor1.c
branches/vorbis-aotuv/lib/highlevel.h
branches/vorbis-aotuv/lib/info.c
branches/vorbis-aotuv/lib/lookup.c
branches/vorbis-aotuv/lib/lookup.h
branches/vorbis-aotuv/lib/lookup_data.h
branches/vorbis-aotuv/lib/lookups.pl
branches/vorbis-aotuv/lib/lpc.c
branches/vorbis-aotuv/lib/lpc.h
branches/vorbis-aotuv/lib/lsp.c
branches/vorbis-aotuv/lib/lsp.h
branches/vorbis-aotuv/lib/mapping0.c
branches/vorbis-aotuv/lib/masking.h
branches/vorbis-aotuv/lib/mdct.c
branches/vorbis-aotuv/lib/mdct.h
branches/vorbis-aotuv/lib/misc.h
branches/vorbis-aotuv/lib/modes/floor_all.h
branches/vorbis-aotuv/lib/modes/psych_11.h
branches/vorbis-aotuv/lib/modes/psych_16.h
branches/vorbis-aotuv/lib/modes/psych_44.h
branches/vorbis-aotuv/lib/modes/psych_8.h
branches/vorbis-aotuv/lib/modes/residue_16.h
branches/vorbis-aotuv/lib/modes/residue_44.h
branches/vorbis-aotuv/lib/modes/residue_44u.h
branches/vorbis-aotuv/lib/modes/residue_8.h
branches/vorbis-aotuv/lib/modes/setup_11.h
branches/vorbis-aotuv/lib/modes/setup_16.h
branches/vorbis-aotuv/lib/modes/setup_22.h
branches/vorbis-aotuv/lib/modes/setup_32.h
branches/vorbis-aotuv/lib/modes/setup_44.h
branches/vorbis-aotuv/lib/modes/setup_44u.h
branches/vorbis-aotuv/lib/modes/setup_8.h
branches/vorbis-aotuv/lib/modes/setup_X.h
branches/vorbis-aotuv/lib/os.h
branches/vorbis-aotuv/lib/psy.c
branches/vorbis-aotuv/lib/psy.h
branches/vorbis-aotuv/lib/psytune.c
branches/vorbis-aotuv/lib/registry.c
branches/vorbis-aotuv/lib/registry.h
branches/vorbis-aotuv/lib/res0.c
branches/vorbis-aotuv/lib/scales.h
branches/vorbis-aotuv/lib/sharedbook.c
branches/vorbis-aotuv/lib/smallft.c
branches/vorbis-aotuv/lib/smallft.h
branches/vorbis-aotuv/lib/synthesis.c
branches/vorbis-aotuv/lib/vorbisenc.c
branches/vorbis-aotuv/lib/vorbisfile.c
branches/vorbis-aotuv/lib/window.c
branches/vorbis-aotuv/lib/window.h
branches/vorbis-aotuv/macosx/Info.plist
branches/vorbis-aotuv/macosx/Vorbis.xcodeproj/project.pbxproj
branches/vorbis-aotuv/vq/Makefile.am
branches/vorbis-aotuv/vq/bookutil.c
branches/vorbis-aotuv/vq/bookutil.h
branches/vorbis-aotuv/vq/build.c
branches/vorbis-aotuv/vq/cascade.c
branches/vorbis-aotuv/vq/distribution.c
branches/vorbis-aotuv/vq/genericdata.c
branches/vorbis-aotuv/vq/huffbuild.c
branches/vorbis-aotuv/vq/latticebuild.c
branches/vorbis-aotuv/vq/latticehint.c
branches/vorbis-aotuv/vq/latticepare.c
branches/vorbis-aotuv/vq/latticetune.c
branches/vorbis-aotuv/vq/localcodebook.h
branches/vorbis-aotuv/vq/lspdata.c
branches/vorbis-aotuv/vq/metrics.c
branches/vorbis-aotuv/vq/residuedata.c
branches/vorbis-aotuv/vq/residuesplit.c
branches/vorbis-aotuv/vq/run.c
branches/vorbis-aotuv/vq/train.c
branches/vorbis-aotuv/vq/vqext.h
branches/vorbis-aotuv/vq/vqgen.c
branches/vorbis-aotuv/vq/vqgen.h
branches/vorbis-aotuv/vq/vqsplit.c
branches/vorbis-aotuv/vq/vqsplit.h
branches/vorbis-aotuv/win32/vorbis.def
Log:
import "aoTuV" beta5.5
* based on libvorbis 1.2.0
* The noise control of the Impulse block was expanded.
This is effective with the outstanding sample of the pre-echo.
* The pre-echo reduction code came to work at a lower bit rate.
* Noise Normalization was reviewed. As a result, the bug is revised.
* The detailed tuning was done again.
Modified: branches/vorbis-aotuv/CHANGES
===================================================================
--- branches/vorbis-aotuv/CHANGES 2008-03-31 15:23:02 UTC (rev 14646)
+++ branches/vorbis-aotuv/CHANGES 2008-04-01 10:47:58 UTC (rev 14647)
@@ -1,3 +1,14 @@
+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
Modified: branches/vorbis-aotuv/COPYING
===================================================================
--- branches/vorbis-aotuv/COPYING 2008-03-31 15:23:02 UTC (rev 14646)
+++ branches/vorbis-aotuv/COPYING 2008-04-01 10:47:58 UTC (rev 14647)
@@ -1,5 +1,5 @@
-aoTuV - Copyright (c) 2003-2006 Aoyumi
-libvorbis - Copyright (c) 2002-2005 Xiph.org Foundation
+aoTuV - Copyright (c) 2003-2008 Aoyumi
+libvorbis - Copyright (c) 2002-2007 Xiph.org Foundation
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
Modified: branches/vorbis-aotuv/Makefile.am
===================================================================
--- branches/vorbis-aotuv/Makefile.am 2008-03-31 15:23:02 UTC (rev 14646)
+++ branches/vorbis-aotuv/Makefile.am 2008-04-01 10:47:58 UTC (rev 14647)
@@ -1,6 +1,6 @@
## Process this file with automake to produce Makefile.in
-AUTOMAKE_OPTIONS = foreign dist-zip
+AUTOMAKE_OPTIONS = 1.6 foreign dist-zip dist-bzip2
SUBDIRS = lib include doc examples vq
@@ -10,11 +10,8 @@
pkgconfigdir = $(libdir)/pkgconfig
pkgconfig_DATA = vorbis.pc vorbisenc.pc vorbisfile.pc
-# we include the whole debian/ dir in EXTRA_DIST because there's a problem
-# with autotools and HFS+ MacOSX file systems that caused debian/Makefile.am
-# to pick up on the lowercase changelog file and add ChangeLog to DIST_COMMON
-# because of it, breaking make dist. This works just as well.
EXTRA_DIST = \
+ CHANGES COPYING \
todo.txt autogen.sh \
libvorbis.spec libvorbis.spec.in \
vorbis.m4 \
@@ -22,17 +19,20 @@
vorbis-uninstalled.pc.in \
vorbisenc-uninstalled.pc.in \
vorbisfile-uninstalled.pc.in \
- debian macos macosx win32
+ doc examples symbian vq \
+ macos macosx win32
DISTCHECK_CONFIGURE_FLAGS = --enable-docs
dist-hook:
- rm -rf `find $(distdir)/debian -name .svn`
- rm -rf `find $(distdir)/debian -name "Makefile*"`
- rm -rf `find $(distdir)/macos -name .svn`
- rm -rf `find $(distdir)/macosx -name .svn`
- rm -rf `find $(distdir)/win32 -name .svn`
+ 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@"
Modified: branches/vorbis-aotuv/README
===================================================================
--- branches/vorbis-aotuv/README 2008-03-31 15:23:02 UTC (rev 14646)
+++ branches/vorbis-aotuv/README 2008-04-01 10:47:58 UTC (rev 14647)
@@ -5,7 +5,7 @@
* GOVERNED BY A BSD-STYLE SOURCE LICENSE INCLUDED WITH THIS SOURCE *
* IN 'COPYING'. PLEASE READ THESE TERMS BEFORE DISTRIBUTING. *
* *
-* THE OggVorbis SOURCE CODE IS (C) COPYRIGHT 1994-2004 *
+* THE OggVorbis SOURCE CODE IS (C) COPYRIGHT 1994-2007 *
* by the Xiph.org Foundation, http://www.xiph.org/ *
* *
********************************************************************
Modified: branches/vorbis-aotuv/aoTuV_README-1st.txt
===================================================================
--- branches/vorbis-aotuv/aoTuV_README-1st.txt 2008-03-31 15:23:02 UTC (rev 14646)
+++ branches/vorbis-aotuv/aoTuV_README-1st.txt 2008-04-01 10:47:58 UTC (rev 14647)
@@ -1,4 +1,4 @@
-aoTuV Beta 5
+aoTuV Beta 5.5
"aoTuV" tunes up Xiph.Org's libvorbis uniquely.
A license is taken as "BSD-style license" as well as original libvorbis.
@@ -14,8 +14,8 @@
aoTuV based on <Xiph.Org libvorbis>
-Copyright (c) 2002-2005 Xiph.Org Foundation
-Copyright (c) 2003-2006 Aoyumi
+Copyright (c) 2002-2007 Xiph.Org Foundation
+Copyright (c) 2003-2008 Aoyumi
AUTHOR : aoyumi <aoyumi at gmail.com>
Modified: branches/vorbis-aotuv/aoTuV_technical.txt
===================================================================
--- branches/vorbis-aotuv/aoTuV_technical.txt 2008-03-31 15:23:02 UTC (rev 14646)
+++ branches/vorbis-aotuv/aoTuV_technical.txt 2008-04-01 10:47:58 UTC (rev 14647)
@@ -1,3 +1,30 @@
+aoTuV beta5.5 technical information
+
+
+The differences from the aoTuV beta 5...
+
+ 1. The frequency domain width of M6 was revised.
+
+ 2. For q-1/-2, a pre-echo reduction code was applied (M3). In addition,
+ the M3 code was improved.
+
+ 3. The floor setup parameters in the low bit-rate was changed.
+
+ 4. The part including bug of noise normalization was rewritten.
+
+ 5. libvorbis 1.2.0 were merged. Furthermore, a revision of Bug #300 and
+ #1229 was applied.
+
+ 6. The ATH curve of the high frequency area (more than 32kHz) was revised.
+
+...and I tune up many parameters.
+
+
+2008/03/30
+Aoyumi
+
+----------------------------------------------------------------------------
+
aoTuV beta5 technical information
@@ -17,7 +44,8 @@
5. In order to decrease artifact by collapse of audio energy, noise
normalization processing of point stereo was extended. [32/44.1/48kHz only]
- 6. The threshold of channel coupling (lossless <=> point) is changed dynamically. This is a method based on a certain idea. [M6]
+ 6. The threshold of channel coupling (lossless <=> point) is changed
+ dynamically. This is a method based on a certain idea. [M6]
...and I tune up many parameters.
Modified: branches/vorbis-aotuv/autogen.sh
===================================================================
--- branches/vorbis-aotuv/autogen.sh 2008-03-31 15:23:02 UTC (rev 14646)
+++ branches/vorbis-aotuv/autogen.sh 2008-04-01 10:47:58 UTC (rev 14647)
@@ -20,19 +20,71 @@
DIE=1
}
-echo "checking for automake... "
-(automake --version) < /dev/null > /dev/null 2>&1 || {
+VERSIONGREP="sed -e s/.*[^0-9\.]\([0-9][0-9]*\.[0-9][0-9]*\).*/\1/"
+VERSIONMKMAJ="sed -e s/\([0-9][0-9]*\)[^0-9].*/\\1/"
+VERSIONMKMIN="sed -e s/.*[0-9][0-9]*\.//"
+
+# do we need automake?
+if test -r Makefile.am; then
+ AM_OPTIONS=`fgrep AUTOMAKE_OPTIONS Makefile.am`
+ AM_NEEDED=`echo $AM_OPTIONS | $VERSIONGREP`
+ if test x"$AM_NEEDED" = "x$AM_OPTIONS"; then
+ AM_NEEDED=""
+ fi
+ if test -z $AM_NEEDED; then
+ echo -n "checking for automake... "
+ AUTOMAKE=automake
+ ACLOCAL=aclocal
+ if ($AUTOMAKE --version < /dev/null > /dev/null 2>&1); then
+ echo "yes"
+ else
+ echo "no"
+ AUTOMAKE=
+ fi
+ else
+ echo -n "checking for automake $AM_NEEDED or later... "
+ majneeded=`echo $AM_NEEDED | $VERSIONMKMAJ`
+ minneeded=`echo $AM_NEEDED | $VERSIONMKMIN`
+ for am in automake-$AM_NEEDED automake$AM_NEEDED \
+ automake automake-1.7 automake-1.8 automake-1.9 automake-1.10; do
+ ($am --version < /dev/null > /dev/null 2>&1) || continue
+ ver=`$am --version < /dev/null | head -n 1 | $VERSIONGREP`
+ maj=`echo $ver | $VERSIONMKMAJ`
+ min=`echo $ver | $VERSIONMKMIN`
+ if test $maj -eq $majneeded -a $min -ge $minneeded; then
+ AUTOMAKE=$am
+ echo $AUTOMAKE
+ break
+ fi
+ done
+ test -z $AUTOMAKE && echo "no"
+ echo -n "checking for aclocal $AM_NEEDED or later... "
+ for ac in aclocal-$AM_NEEDED aclocal$AM_NEEDED \
+ aclocal aclocal-1.7 aclocal-1.8 aclocal-1.9 aclocal-1.10; do
+ ($ac --version < /dev/null > /dev/null 2>&1) || continue
+ ver=`$ac --version < /dev/null | head -n 1 | $VERSIONGREP`
+ maj=`echo $ver | $VERSIONMKMAJ`
+ min=`echo $ver | $VERSIONMKMIN`
+ if test $maj -eq $majneeded -a $min -ge $minneeded; then
+ ACLOCAL=$ac
+ echo $ACLOCAL
+ break
+ fi
+ done
+ test -z $ACLOCAL && echo "no"
+ fi
+ test -z $AUTOMAKE || test -z $ACLOCAL && {
echo
echo "You must have automake installed to compile $package."
- echo "Download the appropriate package for your system,"
- echo "or get the source from one of the GNU ftp sites"
- echo "listed in http://www.gnu.org/order/ftp.html"
- DIE=1
-}
+ echo "Download the appropriate package for your distribution,"
+ echo "or get the source tarball at ftp://ftp.gnu.org/pub/gnu/"
+ exit 1
+ }
+fi
echo -n "checking for libtool... "
for LIBTOOLIZE in libtoolize glibtoolize nope; do
- (type $LIBTOOLIZE) > /dev/null 2>&1 && break
+ ($LIBTOOLIZE --version) < /dev/null > /dev/null 2>&1 && break
done
if test x$LIBTOOLIZE = xnope; then
echo "nope."
@@ -60,14 +112,14 @@
echo "Generating configuration files for $package, please wait...."
-echo " aclocal $ACLOCAL_FLAGS"
-aclocal $ACLOCAL_FLAGS || exit 1
+echo " $ACLOCAL $ACLOCAL_FLAGS"
+$ACLOCAL $ACLOCAL_FLAGS || exit 1
+echo " $LIBTOOLIZE --automake"
+$LIBTOOLIZE --automake || exit 1
echo " autoheader"
autoheader || exit 1
-echo " $LIBTOOLIZE --automake"
-$LIBTOOLIZE --automake || exit 1
-echo " automake --add-missing $AUTOMAKE_FLAGS"
-automake --add-missing $AUTOMAKE_FLAGS || exit 1
+echo " $AUTOMAKE --add-missing $AUTOMAKE_FLAGS"
+$AUTOMAKE --add-missing $AUTOMAKE_FLAGS || exit 1
echo " autoconf"
autoconf || exit 1
Modified: branches/vorbis-aotuv/configure.in
===================================================================
--- branches/vorbis-aotuv/configure.in 2008-03-31 15:23:02 UTC (rev 14646)
+++ branches/vorbis-aotuv/configure.in 2008-04-01 10:47:58 UTC (rev 14647)
@@ -11,19 +11,19 @@
AM_CONFIG_HEADER([config.h])
-AM_INIT_AUTOMAKE(libvorbis,1.1.2)
+AM_INIT_AUTOMAKE(libvorbis,1.2.0)
AM_MAINTAINER_MODE
dnl Library versioning
-V_LIB_CURRENT=3
-V_LIB_REVISION=1
-V_LIB_AGE=3
-VF_LIB_CURRENT=4
-VF_LIB_REVISION=1
-VF_LIB_AGE=1
+V_LIB_CURRENT=4
+V_LIB_REVISION=0
+V_LIB_AGE=4
+VF_LIB_CURRENT=5
+VF_LIB_REVISION=0
+VF_LIB_AGE=2
VE_LIB_CURRENT=2
-VE_LIB_REVISION=2
+VE_LIB_REVISION=3
VE_LIB_AGE=0
AC_SUBST(V_LIB_CURRENT)
AC_SUBST(V_LIB_REVISION)
Modified: branches/vorbis-aotuv/doc/Makefile.am
===================================================================
--- branches/vorbis-aotuv/doc/Makefile.am 2008-03-31 15:23:02 UTC (rev 14646)
+++ branches/vorbis-aotuv/doc/Makefile.am 2008-04-01 10:47:58 UTC (rev 14647)
@@ -6,7 +6,8 @@
### all of the static docs, commited to SVN and included as is
static_docs = \
- draft-kerr-avt-vorbis-rtp-03.txt \
+ draft-ietf-avt-rtp-vorbis-06.xml \
+ draft-ietf-avt-rtp-vorbis-06.txt \
eightphase.png \
evenlsp.png \
floor1_inverse_dB_table.html \
@@ -100,7 +101,7 @@
@mkdir -p $(BUILDDIR)
@for file in $(doc_sources); do cp $(srcdir)/$$file $(BUILDDIR); done
# translate the draft rtp.txt to .xml in the BUILDDIR
-$(BUILDDIR)/draft-rtp.xml: draft-kerr-avt-vorbis-rtp-03.txt
+$(BUILDDIR)/draft-rtp.xml: draft-ietf-avt-rtp-vorbis-05.txt
cat $< | sed 's/ //g' > $@
# cat $< | sed 's/ //g' | sed 's/</\</g' | sed 's/>/\>/g' > $@
@@ -112,15 +113,13 @@
Vorbis_I_spec.fo: $(BUILDDIR)/Vorbis_I_spec.xml
cd build; xsltproc --xinclude --output $@ spec-fo.xsl Vorbis_I_spec.xml && mv $@ ..
-# we add the two newlines to pdfxmltex because on a number of Fedora systems
-# tex prompts for input complaining about something;
-# and surprisingly there's no way to tell tex to ignore that
-# also, --interaction doesn't seem to actually do anything different
-# if you change it
+# we add the two newlines to pdfxmltex because this entire XML
+# toolchain is built from wishful thinking and bonghits and the
+# default supplied passivetex config files are buggy.
Vorbis_I_spec.pdf: Vorbis_I_spec.fo $(SPEC_PNG_BUILD) $(SPEC_PDF_BUILD)
cp $< build/spec.fo # work around a passivetex bug
- cd build; echo -e -n "\n\n" | pdfxmltex --interaction nonstopmode spec.fo
- cd build; echo -e -n "\n\n" | pdfxmltex --interaction nonstopmode spec.fo
+ -cd build; echo -e -n "\n\n" | pdfxmltex spec.fo
+ -cd build; echo -e -n "\n\n" | pdfxmltex spec.fo
rm build/spec.fo
mv build/spec.pdf $@
else
Modified: branches/vorbis-aotuv/doc/Vorbis_I_spec.html
===================================================================
--- branches/vorbis-aotuv/doc/Vorbis_I_spec.html 2008-03-31 15:23:02 UTC (rev 14646)
+++ branches/vorbis-aotuv/doc/Vorbis_I_spec.html 2008-04-01 10:47:58 UTC (rev 14647)
@@ -1,12 +1,12 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Vorbis I specification</title><meta name="generator" content="DocBook XSL Stylesheets V1.68.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="article" lang="en"><div class="titlepage"><div><div><h1 class="title"><a name="id2405333"></a>Vorbis I specification</h1></div><div><h3 class="corpauthor">Xiph.org Foundation</h3></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#vorbis-spec-intro">1. Introduction and Description</a></span></dt><dd><dl><dt><span class="section"><a href="#id2519516">1.1. Overview</a></span></dt><dt><span class="section"><a href="#id2518126">1.2. Decoder Configuration</a></span></dt><dt><span class="section"><a href="#id2449172">1.3. High-level Decode Process</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-bitpacking">2. Bitpacki
ng Convention</a></span></dt><dd><dl><dt><span class="section"><a href="#id2524173">2.1. Overview</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-codebook">3. Probability Model and Codebooks</a></span></dt><dd><dl><dt><span class="section"><a href="#id2523292">3.1. Overview</a></span></dt><dt><span class="section"><a href="#id2509016">3.2. Packed codebook format</a></span></dt><dt><span class="section"><a href="#id2450655">3.3. Use of the codebook abstraction</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-codec">4. Codec Setup and Packet Decode</a></span></dt><dd><dl><dt><span class="section"><a href="#id2512199">4.1. Overview</a></span></dt><dt><span class="section"><a href="#id2531940">4.2. Header decode and decode setup</a></span></dt><dt><span class="section"><a href="#id2545699">4.3. Audio packet decode and synthesis</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-comment">5. comment field and h
eader specification</a></span></dt><dd><dl><dt><span class="section"><a href="#id2541891">5.1. Overview</a></span></dt><dt><span class="section"><a href="#id2541925">5.2. Comment encoding</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-floor0">6. Floor type 0 setup and decode</a></span></dt><dd><dl><dt><span class="section"><a href="#id2512128">6.1. Overview</a></span></dt><dt><span class="section"><a href="#id2505686">6.2. Floor 0 format</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-floor1">7. Floor type 1 setup and decode</a></span></dt><dd><dl><dt><span class="section"><a href="#id2541060">7.1. Overview</a></span></dt><dt><span class="section"><a href="#id2540135">7.2. Floor 1 format</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-residue">8. Residue setup and decode</a></span></dt><dd><dl><dt><span class="section"><a href="#id2524422">8.1. Overview</a></span></dt><dt><span class="section"><a hre
f="#id2517330">8.2. Residue format</a></span></dt><dt><span class="section"><a href="#id2506346">8.3. residue 0</a></span></dt><dt><span class="section"><a href="#id2517602">8.4. residue 1</a></span></dt><dt><span class="section"><a href="#id2517633">8.5. residue 2</a></span></dt><dt><span class="section"><a href="#id2538870">8.6. Residue decode</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-helper">9. Helper equations</a></span></dt><dd><dl><dt><span class="section"><a href="#id2507758">9.1. Overview</a></span></dt><dt><span class="section"><a href="#id2512257">9.2. Functions</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-tables">10. Tables</a></span></dt><dd><dl><dt><span class="section"><a href="#vorbis-spec-floor1_inverse_dB_table">10.1. floor1_inverse_dB_table</a></span></dt></dl></dd><dt><span class="appendix"><a href="#vorbis-over-ogg">A. Embedding Vorbis into an Ogg stream</a></span></dt><dd><dl><dt><span class="sec
tion"><a href="#id2520211">A.1. Overview</a></span></dt><dd><dl><dt><span class="section"><a href="#id2530380">A.1.1. Restrictions</a></span></dt><dt><span class="section"><a href="#id2512176">A.1.2. MIME type</a></span></dt></dl></dd><dt><span class="section"><a href="#id2520628">A.2. Encapsulation</a></span></dt></dl></dd><dt><span class="appendix"><a href="#vorbis-over-rtp">B. Vorbis encapsulation in RTP</a></span></dt><dt><span class="appendix"><a href="#footer">C. Colophon</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="vorbis-spec-intro"></a>1. Introduction and Description</h2></div><div><p class="releaseinfo">
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Vorbis I specification</title><meta name="generator" content="DocBook XSL Stylesheets V1.71.0"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="article" lang="en"><div class="titlepage"><div><div><h1 class="title"><a name="id291327"></a>Vorbis I specification</h1></div><div><h3 class="corpauthor">Xiph.org Foundation</h3></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#vorbis-spec-intro">1. Introduction and Description</a></span></dt><dd><dl><dt><span class="section"><a href="#id311592">1.1. Overview</a></span></dt><dt><span class="section"><a href="#id258770">1.2. Decoder Configuration</a></span></dt><dt><span class="section"><a href="#id258461">1.3. High-level Decode Process</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-bitpacking">2. Bitpacking C
onvention</a></span></dt><dd><dl><dt><span class="section"><a href="#id304831">2.1. Overview</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-codebook">3. Probability Model and Codebooks</a></span></dt><dd><dl><dt><span class="section"><a href="#id310158">3.1. Overview</a></span></dt><dt><span class="section"><a href="#id310216">3.2. Packed codebook format</a></span></dt><dt><span class="section"><a href="#id316518">3.3. Use of the codebook abstraction</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-codec">4. Codec Setup and Packet Decode</a></span></dt><dd><dl><dt><span class="section"><a href="#id336024">4.1. Overview</a></span></dt><dt><span class="section"><a href="#id326710">4.2. Header decode and decode setup</a></span></dt><dt><span class="section"><a href="#id342709">4.3. Audio packet decode and synthesis</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-comment">5. comment field and header speci
fication</a></span></dt><dd><dl><dt><span class="section"><a href="#id314030">5.1. Overview</a></span></dt><dt><span class="section"><a href="#id314058">5.2. Comment encoding</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-floor0">6. Floor type 0 setup and decode</a></span></dt><dd><dl><dt><span class="section"><a href="#id336814">6.1. Overview</a></span></dt><dt><span class="section"><a href="#id321046">6.2. Floor 0 format</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-floor1">7. Floor type 1 setup and decode</a></span></dt><dd><dl><dt><span class="section"><a href="#id336243">7.1. Overview</a></span></dt><dt><span class="section"><a href="#id334800">7.2. Floor 1 format</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-residue">8. Residue setup and decode</a></span></dt><dd><dl><dt><span class="section"><a href="#id320982">8.1. Overview</a></span></dt><dt><span class="section"><a href="#id307154">8.2.
Residue format</a></span></dt><dt><span class="section"><a href="#id326310">8.3. residue 0</a></span></dt><dt><span class="section"><a href="#id326344">8.4. residue 1</a></span></dt><dt><span class="section"><a href="#id334893">8.5. residue 2</a></span></dt><dt><span class="section"><a href="#id334939">8.6. Residue decode</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-helper">9. Helper equations</a></span></dt><dd><dl><dt><span class="section"><a href="#id316603">9.1. Overview</a></span></dt><dt><span class="section"><a href="#id317505">9.2. Functions</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-tables">10. Tables</a></span></dt><dd><dl><dt><span class="section"><a href="#vorbis-spec-floor1_inverse_dB_table">10.1. floor1_inverse_dB_table</a></span></dt></dl></dd><dt><span class="appendix"><a href="#vorbis-over-ogg">1. Embedding Vorbis into an Ogg stream</a></span></dt><dd><dl><dt><span class="section"><a href="#id319760"
>1.1. Overview</a></span></dt><dd><dl><dt><span class="section"><a href="#id336562">1.1.1. Restrictions</a></span></dt><dt><span class="section"><a href="#id330723">1.1.2. MIME type</a></span></dt></dl></dd><dt><span class="section"><a href="#id328095">1.2. Encapsulation</a></span></dt></dl></dd><dt><span class="appendix"><a href="#vorbis-over-rtp">2. Vorbis encapsulation in RTP</a></span></dt><dt><span class="appendix"><a href="#footer">3. Colophon</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="vorbis-spec-intro"></a>1. Introduction and Description</h2></div><div><p class="releaseinfo">
$Id: 01-introduction.xml 7186 2004-07-20 07:19:25Z xiphmont $
-</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2519516"></a>1.1. Overview</h3></div></div></div><p>
+</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id311592"></a>1.1. Overview</h3></div></div></div><p>
This document provides a high level description of the Vorbis codec's
construction. A bit-by-bit specification appears beginning in
<a href="#vorbis-spec-codec" title="4. Codec Setup and Packet Decode">Section 4, “Codec Setup and Packet Decode”</a>.
The later sections assume a high-level
understanding of the Vorbis decode process, which is
-provided here.</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2528250"></a>1.1.1. Application</h4></div></div></div><p>
+provided here.</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id317198"></a>1.1.1. Application</h4></div></div></div><p>
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
@@ -18,13 +18,13 @@
masters) and a range of channel representations (monaural,
polyphonic, stereo, quadraphonic, 5.1, ambisonic, or up to 255
discrete channels).
-</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2525977"></a>1.1.2. Classification</h4></div></div></div><p>
+</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id315630"></a>1.1.2. Classification</h4></div></div></div><p>
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.
-</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2517154"></a>1.1.3. Assumptions</h4></div></div></div><p>
+</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id323943"></a>1.1.3. Assumptions</h4></div></div></div><p>
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
@@ -56,8 +56,8 @@
embedded in an Ogg stream specifically, although this is by no means a
requirement or fundamental assumption in the Vorbis design.</p><p>
The specification for embedding Vorbis into
-an Ogg transport stream is in <a href="#vorbis-over-ogg" title="A. Embedding Vorbis into an Ogg stream">Appendix A, <i>Embedding Vorbis into an Ogg stream</i></a>.
-</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2518614"></a>1.1.4. Codec Setup and Probability Model</h4></div></div></div><p>
+an Ogg transport stream is in <a href="#vorbis-over-ogg" title="1. Embedding Vorbis into an Ogg stream">Appendix 1, <i>Embedding Vorbis into an Ogg stream</i></a>.
+</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id324282"></a>1.1.4. Codec Setup and Probability Model</h4></div></div></div><p>
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.
@@ -85,29 +85,29 @@
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2518094"></a>1.1.5. Format Specification</h4></div></div></div><p>
+Vorbis' suitable application space.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id258744"></a>1.1.5. Format Specification</h4></div></div></div><p>
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2518110"></a>1.1.6. Hardware Profile</h4></div></div></div><p>
+a proper Vorbis decoder.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id258756"></a>1.1.6. Hardware Profile</h4></div></div></div><p>
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.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2518126"></a>1.2. Decoder Configuration</h3></div></div></div><p>
+optional omissions are labelled in the spec where relevant.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id258770"></a>1.2. Decoder Configuration</h3></div></div></div><p>
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:</p><div class="mediaobject"><img src="components.png" alt="decoder pipeline configuration"></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2518164"></a>1.2.1. Global Config</h4></div></div></div><p>
+as follows:</p><div class="mediaobject"><img src="components.png" alt="decoder pipeline configuration"></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id258803"></a>1.2.1. Global Config</h4></div></div></div><p>
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2518178"></a>1.2.2. Mode</h4></div></div></div><p>
+configuration is in the context of specific components.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id258815"></a>1.2.2. Mode</h4></div></div></div><p>
Each Vorbis frame is coded according to a master 'mode'. A bitstream
may use one or many modes.</p><p>
The mode mechanism is used to encode a frame according to one of
@@ -120,7 +120,7 @@
(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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2518208"></a>1.2.3. Mapping</h4></div></div></div><p>
+low-level packet decode and synthesis.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id258359"></a>1.2.3. Mapping</h4></div></div></div><p>
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
@@ -141,7 +141,7 @@
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2462918"></a>1.2.4. Floor</h4></div></div></div><p>
+bass-only representation.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id258391"></a>1.2.4. Floor</h4></div></div></div><p>
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
@@ -165,7 +165,7 @@
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2518290"></a>1.2.5. Residue</h4></div></div></div><p>
+codebooks when coding/decoding.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id258423"></a>1.2.5. Residue</h4></div></div></div><p>
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
@@ -174,7 +174,7 @@
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2518309"></a>1.2.6. Codebooks</h4></div></div></div><p>
+codebooks.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id258437"></a>1.2.6. Codebooks</h4></div></div></div><p>
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
@@ -186,7 +186,7 @@
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).</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2449172"></a>1.3. High-level Decode Process</h3></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2449178"></a>1.3.1. Decode Setup</h4></div></div></div><p>
+a list of n-dimensional rows (lattice VQ).</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id258461"></a>1.3. High-level Decode Process</h3></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id258467"></a>1.3.1. Decode Setup</h4></div></div></div><p>
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
@@ -194,16 +194,16 @@
belonging to the Vorbis stream. In Vorbis I, all packets after the
three initial headers are audio packets. </p><p>
The header packets are, in order, the identification
-header, the comments header, and the setup header.</p><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2449199"></a>1.3.1.1. Identification Header</h5></div></div></div><p>
+header, the comments header, and the setup header.</p><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id314074"></a>1.3.1.1. Identification Header</h5></div></div></div><p>
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2449212"></a>1.3.1.2. Comment Header</h5></div></div></div><p>
+sample rate and number of channels.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id314086"></a>1.3.1.2. Comment Header</h5></div></div></div><p>
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
-<a href="#vorbis-spec-comment" title="5. comment field and header specification">Section 5, “comment field and header specification”</a>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2449230"></a>1.3.1.3. Setup Header</h5></div></div></div><p>
+<a href="#vorbis-spec-comment" title="5. comment field and header specification">Section 5, “comment field and header specification”</a>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id314101"></a>1.3.1.3. Setup Header</h5></div></div></div><p>
The setup header includes extensive CODEC setup information as well as
-the complete VQ and Huffman codebooks needed for decode.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2449243"></a>1.3.2. Decode Procedure</h4></div></div></div><div class="highlights"><p>
+the complete VQ and Huffman codebooks needed for decode.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id314113"></a>1.3.2. Decode Procedure</h4></div></div></div><div class="highlights"><p>
The decoding and synthesis procedure for all audio packets is
fundamentally the same.
</p><div class="orderedlist"><ol type="1"><li>decode packet type flag</li><li>decode mode number</li><li>decode window shape (long windows only)</li><li>decode floor</li><li>decode residue into residue vectors</li><li>inverse channel coupling of residue vectors</li><li>generate floor curve from decoded floor data</li><li>compute dot product of floor and residue, producing audio spectrum vector</li><li>inverse monolithic transform of audio spectrum vector, always an MDCT in Vorbis I</li><li>overlap/add left-hand output of transform with right-hand output of previous frame</li><li>store right hand-data from transform of current frame for future lapping</li><li>if not first frame, return results of overlap/add as audio result of current frame</li></ol></div><p>
@@ -215,7 +215,7 @@
later before overlap/add with the next frame. This optimization
produces entirely equivalent output and is naturally perfectly legal.
The decoder must be <span class="emphasis"><em>entirely mathematically equivalent</em></span> to the
-specification, it need not be a literal semantic implementation.</p><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2449344"></a>1.3.2.1. Packet type decode</h5></div></div></div><p>
+specification, it need not be a literal semantic implementation.</p><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id314203"></a>1.3.2.1. Packet type decode</h5></div></div></div><p>
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
@@ -225,7 +225,7 @@
verify the packet type; <span class="emphasis"><em>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</em></span>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2449370"></a>1.3.2.2. Mode decode</h5></div></div></div><p>
+audio</em></span>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id314225"></a>1.3.2.2. Mode decode</h5></div></div></div><p>
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
@@ -261,11 +261,11 @@
The use of multirate filter banks for coding of high quality digital
audio</a></span>”, by T. Sporer, K. Brandenburg and B. Edler. Vorbis windows
all use the slope function
- <span class="inlinemediaobject"></span>.
-</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2450128"></a>1.3.2.4. floor decode</h5></div></div></div><p>
+ <span class="inlinemediaobject"><span>$y = \sin(.5*\pi \, \sin^2((x+.5)/n*\pi))$</span></span>.
+</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id339168"></a>1.3.2.4. floor decode</h5></div></div></div><p>
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2450140"></a>1.3.2.5. residue decode</h5></div></div></div><p>
+use. All floors are decoded before residue decode begins.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id339179"></a>1.3.2.5. residue decode</h5></div></div></div><p>
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
@@ -275,7 +275,7 @@
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2450165"></a>1.3.2.6. inverse channel coupling</h5></div></div></div><p>
+are coded individually in channel order.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id339196"></a>1.3.2.6. inverse channel coupling</h5></div></div></div><p>
A detailed discussion of stereo in the Vorbis codec can be found in
the document <a href="stereo.html" target="_top"><em class="citetitle">Stereo Channel Coupling in the
Vorbis CODEC</em></a>. Vorbis is not limited to only stereo coupling, but
@@ -289,7 +289,7 @@
angle) back to Cartesian representation.</p><p>
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2450201"></a>1.3.2.7. generate floor curve</h5></div></div></div><p>
+of each output channel.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id339224"></a>1.3.2.7. generate floor curve</h5></div></div></div><p>
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
@@ -298,7 +298,7 @@
some working space.</p><p>
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2450222"></a>1.3.2.8. compute floor/residue dot product</h5></div></div></div><p>
+linear-domain spectral residue.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id339240"></a>1.3.2.8. compute floor/residue dot product</h5></div></div></div><p>
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.</p><p>
@@ -321,7 +321,7 @@
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2450264"></a>1.3.2.9. inverse monolithic transform (MDCT)</h5></div></div></div><p>
+representation.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id339268"></a>1.3.2.9. inverse monolithic transform (MDCT)</h5></div></div></div><p>
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 the paper <a href="http://www.iocon.com/resource/docs/ps/eusipco_corrected.ps" target="_top">“<span class="citetitle">The use of multirate filter banks for coding of high quality digital
@@ -329,16 +329,16 @@
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2450296"></a>1.3.2.10. overlap/add data</h5></div></div></div><p>
+orthogonal.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id339292"></a>1.3.2.10. overlap/add data</h5></div></div></div><p>
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. </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2450312"></a>1.3.2.11. cache right hand data</h5></div></div></div><p>
+now finished and ready to be returned. </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id339304"></a>1.3.2.11. cache right hand data</h5></div></div></div><p>
The decoder must cache the right hand portion of the current frame to
be lapped with the left hand portion of the next frame.
-</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2542059"></a>1.3.2.12. return finished audio data</h5></div></div></div><p>
+</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id339314"></a>1.3.2.12. return finished audio data</h5></div></div></div><p>
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
@@ -360,7 +360,7 @@
calculating PCM offsets; after the first frame, the proper PCM output
offset is '0' (as no data has been returned yet).</p></div></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="vorbis-spec-bitpacking"></a>2. Bitpacking Convention</h2></div><div><p class="releaseinfo">
$Id: 02-bitpacking.xml 7186 2004-07-20 07:19:25Z xiphmont $
-</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2524173"></a>2.1. Overview</h3></div></div></div><p>
+</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id304831"></a>2.1. Overview</h3></div></div></div><p>
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
@@ -370,7 +370,7 @@
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.
-</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2498786"></a>2.1.1. octets, bytes and words</h4></div></div></div><p>
+</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id304890"></a>2.1.1. octets, bytes and words</h4></div></div></div><p>
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
@@ -386,13 +386,13 @@
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2516522"></a>2.1.2. bit order</h4></div></div></div><p>
+that a byte is one octet for purposes of example.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id304832"></a>2.1.2. bit order</h4></div></div></div><p>
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
<span class="emphasis"><em>n</em></span> (<span class="emphasis"><em>n</em></span>=7 in an octet) for the
-MSb.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2483456"></a>2.1.3. byte order</h4></div></div></div><p>
+MSb.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id327953"></a>2.1.3. byte order</h4></div></div></div><p>
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
@@ -404,7 +404,7 @@
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 <span class="emphasis"><em>n</em></span>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2513509"></a>2.1.4. coding bits into byte sequences</h4></div></div></div><p>
+through byte <span class="emphasis"><em>n</em></span>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id336382"></a>2.1.4. coding bits into byte sequences</h4></div></div></div><p>
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
@@ -420,13 +420,13 @@
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2537805"></a>2.1.5. signedness</h4></div></div></div><p>
+from the byte stream and reassembling them into integers.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id310906"></a>2.1.5. signedness</h4></div></div></div><p>
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2513546"></a>2.1.6. coding example</h4></div></div></div><p>
+be treated as signed or unsigned.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id258112"></a>2.1.6. coding example</h4></div></div></div><p>
Code the 4 bit integer value '12' [b1100] into an empty bytestream.
Bytestream result:
@@ -490,7 +490,7 @@
byte n [ ] bytestream length == 4 bytes
</pre><p>
-</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2513617"></a>2.1.7. decoding example</h4></div></div></div><p>
+</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id258160"></a>2.1.7. decoding example</h4></div></div></div><p>
Reading from the beginning of the bytestream encoded in the above example:
</p><pre class="screen">
@@ -515,7 +515,7 @@
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.</p></li></ul></div><p>
-</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2513669"></a>2.1.8. end-of-packet alignment</h4></div></div></div><p>
+</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id259912"></a>2.1.8. end-of-packet alignment</h4></div></div></div><p>
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,
@@ -533,7 +533,7 @@
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'.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2520883"></a>2.1.9. reading zero bits</h4></div></div></div><p>
+condition shall also return 'end-of-packet'.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id259938"></a>2.1.9. reading zero bits</h4></div></div></div><p>
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)
@@ -542,7 +542,7 @@
integer after a previous read sets 'end-of-packet' shall also fail
with 'end-of-packet'.</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="vorbis-spec-codebook"></a>3. Probability Model and Codebooks</h2></div><div><p class="releaseinfo">
$Id: 03-codebook.xml 7186 2004-07-20 07:19:25Z xiphmont $
-</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2523292"></a>3.1. Overview</h3></div></div></div><p>
+</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id310158"></a>3.1. Overview</h3></div></div></div><p>
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
@@ -551,15 +551,15 @@
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.</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2497985"></a>3.1.1. Bitwise operation</h4></div></div></div><p>
+decoded output corresponding to a given compressed codeword.</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id335318"></a>3.1.1. Bitwise operation</h4></div></div></div><p>
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 <a href="#vorbis-spec-bitpacking" title="2. Bitpacking Convention">Section 2, “Bitpacking Convention”</a>.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2509016"></a>3.2. Packed codebook format</h3></div></div></div><p>
+stream according to <a href="#vorbis-spec-bitpacking" title="2. Bitpacking Convention">Section 2, “Bitpacking Convention”</a>.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id310216"></a>3.2. Packed codebook format</h3></div></div></div><p>
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 <a href="#vorbis-spec-bitpacking" title="2. Bitpacking Convention">Section 2, “Bitpacking Convention”</a> for discussion
-relating to non-eight-bit bytes.</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2450934"></a>3.2.1. codebook decode</h4></div></div></div><p>
+relating to non-eight-bit bytes.</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id324957"></a>3.2.1. codebook decode</h4></div></div></div><p>
A codebook begins with a 24 bit sync pattern, 0x564342:
</p><pre class="screen">
@@ -689,7 +689,7 @@
document.</p></li></ul></div><p>
</p><p>
An 'end of packet' during any read operation in the above steps is
-considered an error condition rendering the stream undecodable.</p><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2519623"></a>3.2.1.1. Huffman decision tree representation</h5></div></div></div><p>
+considered an error condition rendering the stream undecodable.</p><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id258959"></a>3.2.1.1. Huffman decision tree representation</h5></div></div></div><p>
The <code class="varname">[codebook_codeword_lengths]</code> array and
<code class="varname">[codebook_entries]</code> value uniquely define the Huffman decision
tree used for entropy decoding.</p><p>
@@ -747,7 +747,7 @@
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2450540"></a>3.2.1.2. VQ lookup table vector representation</h5></div></div></div><p>
+decode to that entry number.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id316419"></a>3.2.1.2. VQ lookup table vector representation</h5></div></div></div><p>
Unpacking the VQ lookup table vectors relies on the following values:
</p><pre class="programlisting">
the [codebook_multiplicands] array
@@ -763,7 +763,7 @@
Decoding (unpacking) a specific vector in the vector lookup table
proceeds according to <code class="varname">[codebook_lookup_type]</code>. The unpacked
vector values are what a codebook would return during audio packet
-decode in a VQ context.</p><div class="section" lang="en"><div class="titlepage"><div><div><h6 class="title"><a name="id2450569"></a>3.2.1.2.1. Vector value decode: Lookup type 1</h6></div></div></div><p>
+decode in a VQ context.</p><div class="section" lang="en"><div class="titlepage"><div><div><h6 class="title"><a name="id316444"></a>3.2.1.2.1. Vector value decode: Lookup type 1</h6></div></div></div><p>
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
@@ -790,7 +790,7 @@
}
8) vector calculation completed.
-</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h6 class="title"><a name="id2450608"></a>3.2.1.2.2. Vector value decode: Lookup type 2</h6></div></div></div><p>
+</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h6 class="title"><a name="id316478"></a>3.2.1.2.2. Vector value decode: Lookup type 2</h6></div></div></div><p>
Lookup type two specifies a VQ lookup table in which each scalar in
each vector is explicitly set by the <code class="varname">[codebook_multiplicands]</code>
array in a one-to-one mapping. Calculate [unpack] the
@@ -815,7 +815,7 @@
}
7) vector calculation completed.
-</pre></div></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2450655"></a>3.3. Use of the codebook abstraction</h3></div></div></div><p>
+</pre></div></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id316518"></a>3.3. Use of the codebook abstraction</h3></div></div></div><p>
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
@@ -848,18 +848,18 @@
offset into the VQ lookup table. The value returned to the decoder is
the vector of scalars corresponding to this offset.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="vorbis-spec-codec"></a>4. Codec Setup and Packet Decode</h2></div><div><p class="releaseinfo">
$Id: 04-codec.xml 10466 2005-11-28 00:34:44Z giles $
-</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2512199"></a>4.1. Overview</h3></div></div></div><p>
+</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id336024"></a>4.1. Overview</h3></div></div></div><p>
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 <a href="#vorbis-spec-intro" title="1. Introduction and Description">Section 1, “Introduction and Description”</a>. <a href="#vorbis-spec-bitpacking" title="2. Bitpacking Convention">Section 2, “Bitpacking Convention”</a> covers reading and writing bit fields from
-and to bitstream packets.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2531940"></a>4.2. Header decode and decode setup</h3></div></div></div><p>
+and to bitstream packets.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id326710"></a>4.2. Header decode and decode setup</h3></div></div></div><p>
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.</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2531581"></a>4.2.1. Common header decode</h4></div></div></div><p>
+comment header is a non-fatal error condition.</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id337747"></a>4.2.1. Common header decode</h4></div></div></div><p>
Each header packet begins with the same header fields.
</p><pre class="screen">
1) [packet_type] : 8 bit value
@@ -869,7 +869,7 @@
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2522768"></a>4.2.2. Identification header</h4></div></div></div><p>
+identification, comment, setup.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id317806"></a>4.2.2. Identification header</h4></div></div></div><p>
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
@@ -895,9 +895,9 @@
field especially may be considerably off in purely VBR streams. The
fields are meaningful only when greater than zero.</p><p>
</p><div class="itemizedlist"><ul type="disc"><li>All three fields set to the same value implies a fixed rate, or tightly bounded, nearly fixed-rate bitstream</li><li>Only nominal set implies a VBR or ABR stream that averages the nominal bitrate</li><li>Maximum and or minimum set implies a VBR bitstream that obeys the bitrate limits</li><li>None set indicates the encoder does not care to speculate.</li></ul></div><p>
-</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2505902"></a>4.2.3. Comment header</h4></div></div></div><p>
+</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id320370"></a>4.2.3. Comment header</h4></div></div></div><p>
Comment header decode and data specification is covered in
-<a href="#vorbis-spec-comment" title="5. comment field and header specification">Section 5, “comment field and header specification”</a>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2505916"></a>4.2.4. Setup header</h4></div></div></div><p>
+<a href="#vorbis-spec-comment" title="5. comment field and header specification">Section 5, “comment field and header specification”</a>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id320384"></a>4.2.4. Setup header</h4></div></div></div><p>
Vorbis codec setup is configurable to an extreme degree:
</p><div class="mediaobject"><img src="components.png" alt="[decoder pipeline configuration]"></div><p>
@@ -908,13 +908,13 @@
(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:</p><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2524640"></a>4.2.4.1. Codebooks</h5></div></div></div><div class="orderedlist"><ol type="1"><li><code class="varname">[vorbis_codebook_count]</code> = read eight bits as unsigned integer and add one</li><li>Decode <code class="varname">[vorbis_codebook_count]</code> codebooks in order as defined
+proceeds in the following order:</p><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id305504"></a>4.2.4.1. Codebooks</h5></div></div></div><div class="orderedlist"><ol type="1"><li><code class="varname">[vorbis_codebook_count]</code> = read eight bits as unsigned integer and add one</li><li>Decode <code class="varname">[vorbis_codebook_count]</code> codebooks in order as defined
in <a href="#vorbis-spec-codebook" title="3. Probability Model and Codebooks">Section 3, “Probability Model and Codebooks”</a>. Save each configuration, in
order, in an array of
-codebook configurations <code class="varname">[vorbis_codebook_configurations]</code>.</li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2524679"></a>4.2.4.2. Time domain transforms</h5></div></div></div><p>
+codebook configurations <code class="varname">[vorbis_codebook_configurations]</code>.</li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id305539"></a>4.2.4.2. Time domain transforms</h5></div></div></div><p>
These hooks are placeholders in Vorbis I. Nevertheless, the
configuration placeholder values must be read to maintain bitstream
-sync.</p><div class="orderedlist"><ol type="1"><li><code class="varname">[vorbis_time_count]</code> = read 6 bits as unsigned integer and add one</li><li>read <code class="varname">[vorbis_time_count]</code> 16 bit values; each value should be zero. If any value is nonzero, this is an error condition and the stream is undecodable.</li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2524718"></a>4.2.4.3. Floors</h5></div></div></div><p>
+sync.</p><div class="orderedlist"><ol type="1"><li><code class="varname">[vorbis_time_count]</code> = read 6 bits as unsigned integer and add one</li><li>read <code class="varname">[vorbis_time_count]</code> 16 bit values; each value should be zero. If any value is nonzero, this is an error condition and the stream is undecodable.</li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id328542"></a>4.2.4.3. Floors</h5></div></div></div><p>
Vorbis uses two floor types; header decode is handed to the decode
abstraction of the appropriate type.</p><div class="orderedlist"><ol type="1"><li><code class="varname">[vorbis_floor_count]</code> = read 6 bits as unsigned integer and add one</li><li><p>For each <code class="varname">[i]</code> of <code class="varname">[vorbis_floor_count]</code> floor numbers:
</p><div class="orderedlist"><ol type="a"><li>read the floor type: vector <code class="varname">[vorbis_floor_types]</code> element <code class="varname">[i]</code> =
@@ -923,13 +923,13 @@
this
configuration in slot <code class="varname">[i]</code> of the floor configuration array <code class="varname">[vorbis_floor_configurations]</code>.</li><li>If the floor type is one,
decode the floor configuration as defined in <a href="#vorbis-spec-floor1" title="7. Floor type 1 setup and decode">Section 7, “Floor type 1 setup and decode”</a>; save this configuration in slot <code class="varname">[i]</code> of the floor configuration array <code class="varname">[vorbis_floor_configurations]</code>.</li><li>If the the floor type is greater than one, this stream is undecodable; ERROR CONDITION</li></ol></div><p>
- </p></li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2510370"></a>4.2.4.4. Residues</h5></div></div></div><p>
+ </p></li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id328635"></a>4.2.4.4. Residues</h5></div></div></div><p>
Vorbis uses three residue types; header decode of each type is identical.
</p><div class="orderedlist"><ol type="1"><li><code class="varname">[vorbis_residue_count]</code> = read 6 bits as unsigned integer and add one
</li><li><p>For each of <code class="varname">[vorbis_residue_count]</code> residue numbers:
</p><div class="orderedlist"><ol type="a"><li>read the residue type; vector <code class="varname">[vorbis_residue_types]</code> element <code class="varname">[i]</code> = read 16 bits as unsigned integer</li><li>If the residue type is zero,
one or two, decode the residue configuration as defined in <a href="#vorbis-spec-residue" title="8. Residue setup and decode">Section 8, “Residue setup and decode”</a>; save this configuration in slot <code class="varname">[i]</code> of the residue configuration array <code class="varname">[vorbis_residue_configurations]</code>.</li><li>If the the residue type is greater than two, this stream is undecodable; ERROR CONDITION</li></ol></div><p>
-</p></li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2510452"></a>4.2.4.5. Mappings</h5></div></div></div><p>
+</p></li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id275059"></a>4.2.4.5. Mappings</h5></div></div></div><p>
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.</p><div class="orderedlist"><ol type="1"><li><code class="varname">[vorbis_mapping_count]</code> = read 6 bits as unsigned integer and add one</li><li><p>For each <code class="varname">[i]</code> of <code class="varname">[vorbis_mapping_count]</code> mapping numbers:
@@ -943,19 +943,19 @@
</p></li></ol></div><p>
</p></li><li>if unset, <code class="varname">[vorbis_mapping_coupling_steps]</code> = 0</li></ol></div><p>
</p></li><li>read 2 bits (reserved field); if the value is nonzero, the stream is undecodable</li><li><p>if <code class="varname">[vorbis_mapping_submaps]</code> is greater than one, we read channel multiplex settings. For each <code class="varname">[j]</code> of <code class="varname">[audio_channels]</code> channels:</p><div class="orderedlist"><ol type="A"><li>vector <code class="varname">[vorbis_mapping_mux]</code> element <code class="varname">[j]</code> = read 4 bits as unsigned integer</li><li>if the value is greater than the highest numbered submap (<code class="varname">[vorbis_mapping_submaps]</code> - 1), this in an error condition rendering the stream undecodable</li></ol></div></li><li><p>for each submap <code class="varname">[j]</code> of <code class="varname">[vorbis_mapping_submaps]</code> submaps, read the floor and residue numbers for use in decoding that submap:</p><div class="orderedlist"><ol type="A"><li>read and discard 8 bits (the unused time con
figuration placeholder)</li><li>read 8 bits as unsigned integer for the floor number; save in vector <code class="varname">[vorbis_mapping_submap_floor]</code> element <code class="varname">[j]</code></li><li>verify the floor number is not greater than the highest number floor configured for the bitstream. If it is, the bitstream is undecodable</li><li>read 8 bits as unsigned integer for the residue number; save in vector <code class="varname">[vorbis_mapping_submap_residue]</code> element <code class="varname">[j]</code></li><li>verify the residue number is not greater than the highest number residue configured for the bitstream. If it is, the bitstream is undecodable</li></ol></div></li><li>save this mapping configuration in slot <code class="varname">[i]</code> of the mapping configuration array <code class="varname">[vorbis_mapping_configurations]</code>.</li></ol></div></li></ol></div><p>
- </p></li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2528009"></a>4.2.4.6. Modes</h5></div></div></div><div class="orderedlist"><ol type="1"><li><code class="varname">[vorbis_mode_count]</code> = read 6 bits as unsigned integer and add one</li><li><p>For each of <code class="varname">[vorbis_mode_count]</code> mode numbers:</p><div class="orderedlist"><ol type="a"><li><code class="varname">[vorbis_mode_blockflag]</code> = read 1 bit</li><li><code class="varname">[vorbis_mode_windowtype]</code> = read 16 bits as unsigned integer</li><li><code class="varname">[vorbis_mode_transformtype]</code> = read 16 bits as unsigned integer</li><li><code class="varname">[vorbis_mode_mapping]</code> = read 8 bits as unsigned integer</li><li>verify ranges; zero is the only legal value in Vorbis I for
+ </p></li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id342611"></a>4.2.4.6. Modes</h5></div></div></div><div class="orderedlist"><ol type="1"><li><code class="varname">[vorbis_mode_count]</code> = read 6 bits as unsigned integer and add one</li><li><p>For each of <code class="varname">[vorbis_mode_count]</code> mode numbers:</p><div class="orderedlist"><ol type="a"><li><code class="varname">[vorbis_mode_blockflag]</code> = read 1 bit</li><li><code class="varname">[vorbis_mode_windowtype]</code> = read 16 bits as unsigned integer</li><li><code class="varname">[vorbis_mode_transformtype]</code> = read 16 bits as unsigned integer</li><li><code class="varname">[vorbis_mode_mapping]</code> = read 8 bits as unsigned integer</li><li>verify ranges; zero is the only legal value in Vorbis I for
<code class="varname">[vorbis_mode_windowtype]</code>
and <code class="varname">[vorbis_mode_transformtype]</code>. <code class="varname">[vorbis_mode_mapping]</code> must not be greater than the highest number mapping in use. Any illegal values render the stream undecodable.</li><li>save this mode configuration in slot <code class="varname">[i]</code> of the mode configuration array
<code class="varname">[vorbis_mode_configurations]</code>.</li></ol></div></li><li>read 1 bit as a framing flag. If unset, a framing error occurred and the stream is not
decodable.</li></ol></div><p>
After reading mode descriptions, setup header decode is complete.
-</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2545699"></a>4.3. Audio packet decode and synthesis</h3></div></div></div><p>
+</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id342709"></a>4.3. Audio packet decode and synthesis</h3></div></div></div><p>
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. <span class="emphasis"><em>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</em></span>.
-</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2545717"></a>4.3.1. packet type, mode and window decode</h4></div></div></div><div class="orderedlist"><ol type="1"><li>read 1 bit <code class="varname">[packet_type]</code>; check that packet type is 0 (audio)</li><li>read <a href="#vorbis-spec-ilog" title="9.2.1. ilog">ilog</a>([vorbis_mode_count]-1) bits
+</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id342724"></a>4.3.1. packet type, mode and window decode</h4></div></div></div><div class="orderedlist"><ol type="1"><li>read 1 bit <code class="varname">[packet_type]</code>; check that packet type is 0 (audio)</li><li>read <a href="#vorbis-spec-ilog" title="9.2.1. ilog">ilog</a>([vorbis_mode_count]-1) bits
<code class="varname">[mode_number]</code></li><li>decode blocksize <code class="varname">[n]</code> is equal to <code class="varname">[blocksize_0]</code> if
<code class="varname">[vorbis_mode_blockflag]</code> is 0, else <code class="varname">[n]</code> is equal to <code class="varname">[blocksize_1]</code>.</li><li><p>perform window selection and setup; this window is used later by the inverse MDCT:</p><div class="orderedlist"><ol type="a"><li><p>if this is a long window (the <code class="varname">[vorbis_mode_blockflag]</code> flag of this mode is
set):</p><div class="orderedlist"><ol type="i"><li>read 1 bit for <code class="varname">[previous_window_flag]</code></li><li>read 1 bit for <code class="varname">[next_window_flag]</code></li><li>if <code class="varname">[previous_window_flag]</code> is not set, the left half
@@ -991,7 +991,7 @@
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2546181"></a>4.3.2. floor curve decode</h4></div></div></div><p>
+occurrence.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id343132"></a>4.3.2. floor curve decode</h4></div></div></div><p>
From this point on, we assume out decode context is using mode number
<code class="varname">[mode_number]</code> from configuration array
<code class="varname">[vorbis_mode_configurations]</code> and the map number
@@ -1013,7 +1013,7 @@
</p><p>
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2546321"></a>4.3.3. nonzero vector propagate</h4></div></div></div><p>
+add/overlap output stage.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id343249"></a>4.3.3. nonzero vector propagate</h4></div></div></div><p>
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
@@ -1029,13 +1029,13 @@
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.</li></ol></div><p>
-</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2546383"></a>4.3.4. residue decode</h4></div></div></div><p>
+</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id343299"></a>4.3.4. residue decode</h4></div></div></div><p>
Unlike floors, which are decoded in channel order, the residue vectors
are decoded in submap order.</p><p>
for each submap <code class="varname">[i]</code> in order from 0 ... <code class="varname">[vorbis_mapping_submaps]</code>-1</p><div class="orderedlist"><ol type="1"><li><code class="varname">[ch]</code> = 0</li><li><p>for each channel <code class="varname">[j]</code> in order from 0 ... <code class="varname">[audio_channels]</code> - 1</p><div class="orderedlist"><ol type="a"><li><p>if channel <code class="varname">[j]</code> in submap <code class="varname">[i]</code> (vector <code class="varname">[vorbis_mapping_mux]</code> element <code class="varname">[j]</code> is equal to <code class="varname">[i]</code>)</p><div class="orderedlist"><ol type="i"><li><p>if vector <code class="varname">[no_residue]</code> element <code class="varname">[j]</code> is true
</p><div class="orderedlist"><ol type="A"><li>vector <code class="varname">[do_not_decode_flag]</code> element <code class="varname">[ch]</code> is set</li></ol></div><p>
else
- </p><div class="orderedlist"><ol type="A"><li>vector <code class="varname">[do_not_decode_flag]</code> element <code class="varname">[ch]</code> is unset</li></ol></div></li><li>increment <code class="varname">[ch]</code></li></ol></div></li></ol></div></li><li><code class="varname">[residue_number]</code> = vector <code class="varname">[vorbis_mapping_submap_residue]</code> element <code class="varname">[i]</code></li><li><code class="varname">[residue_type]</code> = vector <code class="varname">[vorbis_residue_types]</code> element <code class="varname">[residue_number]</code></li><li>decode <code class="varname">[ch]</code> vectors using residue <code class="varname">[residue_number]</code>, according to type <code class="varname">[residue_type]</code>, also passing vector <code class="varname">[do_not_decode_flag]</code> to indicate which vectors in the bundle should not be decoded. Correct per-vector decode length is <code class="varname">[n]</code>/2.</li><li><co
de class="varname">[ch]</code> = 0</li><li><p>for each channel <code class="varname">[j]</code> in order from 0 ... <code class="varname">[audio_channels]</code></p><div class="orderedlist"><ol type="a"><li><p>if channel <code class="varname">[j]</code> is in submap <code class="varname">[i]</code> (vector <code class="varname">[vorbis_mapping_mux]</code> element <code class="varname">[j]</code> is equal to <code class="varname">[i]</code>)</p><div class="orderedlist"><ol type="i"><li>residue vector for channel <code class="varname">[j]</code> is set to decoded residue vector <code class="varname">[ch]</code></li><li>increment <code class="varname">[ch]</code></li></ol></div></li></ol></div></li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2546633"></a>4.3.5. inverse coupling</h4></div></div></div><p>
+ </p><div class="orderedlist"><ol type="A"><li>vector <code class="varname">[do_not_decode_flag]</code> element <code class="varname">[ch]</code> is unset</li></ol></div></li><li>increment <code class="varname">[ch]</code></li></ol></div></li></ol></div></li><li><code class="varname">[residue_number]</code> = vector <code class="varname">[vorbis_mapping_submap_residue]</code> element <code class="varname">[i]</code></li><li><code class="varname">[residue_type]</code> = vector <code class="varname">[vorbis_residue_types]</code> element <code class="varname">[residue_number]</code></li><li>decode <code class="varname">[ch]</code> vectors using residue <code class="varname">[residue_number]</code>, according to type <code class="varname">[residue_type]</code>, also passing vector <code class="varname">[do_not_decode_flag]</code> to indicate which vectors in the bundle should not be decoded. Correct per-vector decode length is <code class="varname">[n]</code>/2.</li><li><co
de class="varname">[ch]</code> = 0</li><li><p>for each channel <code class="varname">[j]</code> in order from 0 ... <code class="varname">[audio_channels]</code></p><div class="orderedlist"><ol type="a"><li><p>if channel <code class="varname">[j]</code> is in submap <code class="varname">[i]</code> (vector <code class="varname">[vorbis_mapping_mux]</code> element <code class="varname">[j]</code> is equal to <code class="varname">[i]</code>)</p><div class="orderedlist"><ol type="i"><li>residue vector for channel <code class="varname">[j]</code> is set to decoded residue vector <code class="varname">[ch]</code></li><li>increment <code class="varname">[ch]</code></li></ol></div></li></ol></div></li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id343545"></a>4.3.5. inverse coupling</h4></div></div></div><p>
for each <code class="varname">[i]</code> from <code class="varname">[vorbis_mapping_coupling_steps]</code>-1 descending to 0
</p><div class="orderedlist"><ol type="1"><li><code class="varname">[magnitude_vector]</code> = the residue vector for channel
@@ -1053,7 +1053,7 @@
</p><div class="orderedlist"><ol type="A"><li><code class="varname">[new_A]</code> = <code class="varname">[M]</code></li><li><code class="varname">[new_M]</code> = <code class="varname">[M]</code>-<code class="varname">[A]</code></li></ol></div><p>
</p></li></ol></div><p>
</p></li><li>set scalar value <code class="varname">[M]</code> in vector <code class="varname">[magnitude_vector]</code> to <code class="varname">[new_M]</code></li><li>set scalar value <code class="varname">[A]</code> in vector <code class="varname">[angle_vector]</code> to <code class="varname">[new_A]</code></li></ol></div></li></ol></div><p>
-</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2546883"></a>4.3.6. dot product</h4></div></div></div><p>
+</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id343790"></a>4.3.6. dot product</h4></div></div></div><p>
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 <code class="varname">[n]</code>/2.</p><p>
@@ -1081,14 +1081,14 @@
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2546936"></a>4.3.7. inverse MDCT</h4></div></div></div><p>
+representation.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id343829"></a>4.3.7. inverse MDCT</h4></div></div></div><p>
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 the paper
<a href="http://www.iocon.com/resource/docs/ps/eusipco_corrected.ps" target="_top">“<span class="citetitle">The
use of multirate filter banks for coding of high quality digital
audio</span>”</a>, by T. Sporer, K. Brandenburg and B. Edler. The window
-function used for the MDCT is the function described earlier.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2546961"></a>4.3.8. overlap_add</h4></div></div></div><p>
+function used for the MDCT is the function described earlier.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id343850"></a>4.3.8. overlap_add</h4></div></div></div><p>
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
@@ -1112,7 +1112,7 @@
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).</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2547004"></a>4.3.9. output channel order</h4></div></div></div><p>
+offset is '0' (as no data has been returned yet).</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id343883"></a>4.3.9. output channel order</h4></div></div></div><p>
Vorbis I specifies only a channel mapping type 0. In mapping type 0,
channel mapping is implicitly defined as follows for standard audio
applications:</p><div class="variablelist"><dl><dt><span class="term">one channel</span></dt><dd>the stream is monophonic</dd><dt><span class="term">two channels</span></dt><dd>the stream is stereo. channel order: left, right</dd><dt><span class="term">three channels</span></dt><dd>the stream is a 1d-surround encoding. channel order: left,
@@ -1124,8 +1124,8 @@
mapping as seen fit. Future channel mappings (such as three and four
channel <a href="http://www.ambisonic.net/" target="_top">Ambisonics</a>) will
make use of channel mappings other than mapping 0.</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="vorbis-spec-comment"></a>5. comment field and header specification</h2></div><div><p class="releaseinfo">
- $Id: 05-comment.xml 10465 2005-11-28 00:33:05Z giles $
-</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2541891"></a>5.1. Overview</h3></div></div></div><p>The Vorbis text comment header is the second (of three) header
+ $Id: 05-comment.xml 11703 2006-07-17 16:33:17Z giles $
+</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id314030"></a>5.1. Overview</h3></div></div></div><p>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
@@ -1138,7 +1138,7 @@
</p><div class="blockquote"><blockquote class="blockquote"><p>Honest Bob and the Factory-to-Dealer-Incentives, <em class="citetitle">I'm Still
Around</em>, opening for Moxy Früvous, 1997.</p></blockquote></div><p>
-</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2541925"></a>5.2. Comment encoding</h3></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2541929"></a>5.2.1. Structure</h4></div></div></div><p>
+</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id314058"></a>5.2. Comment encoding</h3></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id322574"></a>5.2.1. Structure</h4></div></div></div><p>
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
@@ -1159,7 +1159,7 @@
8) if ( [framing_bit] unset or end-of-packet ) then ERROR
9) done.
</pre><p>
-</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2498376"></a>5.2.2. Content vector format</h4></div></div></div><p>
+</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id326883"></a>5.2.2. Content vector format</h4></div></div></div><p>
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:</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">
@@ -1176,7 +1176,7 @@
</p><p>
0x3D is followed by 8 bit clean UTF-8 encoded value of the
field contents to the end of the field.
-</p><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2529464"></a>5.2.2.1. Field names</h5></div></div></div><p>Below is a proposed, minimal list of standard field names with a
+</p><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id322620"></a>5.2.2.1. Field names</h5></div></div></div><p>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.</p><div class="variablelist"><dl><dt><span class="term">TITLE</span></dt><dd>Track/Work name</dd><dt><span class="term">VERSION</span></dt><dd>The version field may be used to
@@ -1202,13 +1202,13 @@
</dd><dt><span class="term">LOCATION</span></dt><dd>Location where track was recorded
</dd><dt><span class="term">CONTACT</span></dt><dd>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.
</dd><dt><span class="term">ISRC</span></dt><dd>International Standard Recording Code for the
-track; see <a href="http://www.ifpi.org/site-content/online/isrc_intro.html" target="_top">the ISRC
+track; see <a href="http://www.ifpi.org/isrc/" target="_top">the ISRC
intro page</a> for more information on ISRC numbers.
-</dd></dl></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id2527296"></a>5.2.2.2. Implications</h5></div></div></div><p>Field names should not be 'internationalized'; this is a
+</dd></dl></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id306349"></a>5.2.2.2. Implications</h5></div></div></div><p>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 <span class="emphasis"><em>contents</em></span>
-however, use the UTF-8 character encoding to allow easy representation of any
-language.</p><p>We have the length of the entirety of the field and restrictions on
+the world that doesn't speak English. Field <span class="emphasis"><em>contents</em></span>,
+however, use the UTF-8 character encoding to allow easy representation
+of any language.</p><p>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.</p><p>Individual 'vendors' may use non-standard field names within
reason. The proper use of comment fields should be clear through
@@ -1225,7 +1225,7 @@
ARTIST=Sonny Stitt
</pre></blockquote></div><p>
-</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2525558"></a>5.2.3. Encoding</h4></div></div></div><p>
+</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id306394"></a>5.2.3. Encoding</h4></div></div></div><p>
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
@@ -1255,17 +1255,17 @@
This is actually somewhat easier to describe in code; implementation of the above can be found in <code class="filename">vorbis/lib/info.c</code>, <code class="function">_vorbis_pack_comment()</code> and <code class="function">_vorbis_unpack_comment()</code>.
</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="vorbis-spec-floor0"></a>6. Floor type 0 setup and decode</h2></div><div><p class="releaseinfo">
$Id: 06-floor0.xml 10424 2005-11-23 08:44:18Z xiphmont $
-</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2512128"></a>6.1. Overview</h3></div></div></div><p>
+</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id336814"></a>6.1. Overview</h3></div></div></div><p>
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2505686"></a>6.2. Floor 0 format</h3></div></div></div><p>
+vice-versa.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id321046"></a>6.2. Floor 0 format</h3></div></div></div><p>
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. </p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2515774"></a>6.2.1. header decode</h4></div></div></div><p>
+values used by each frame. </p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id313179"></a>6.2.1. header decode</h4></div></div></div><p>
Configuration information for instances of floor zero decodes from the
codec setup header (third packet). configuration decode proceeds as
follows:</p><pre class="screen">
@@ -1351,12 +1351,12 @@
</p><div class="informalequation"><div class="mediaobject"><img src="floorval.png" alt="[expression for floorval]"></div></div><p>
</p></li><li><code class="varname">[iteration_condition]</code> = map element <code class="varname">[i]</code></li><li><code class="varname">[output]</code> element <code class="varname">[i]</code> = <code class="varname">[linear_floor_value]</code></li><li>increment <code class="varname">[i]</code></li><li>if ( map element <code class="varname">[i]</code> is equal to <code class="varname">[iteration_condition]</code> ) continue at step 5</li><li>if ( <code class="varname">[i]</code> is less than <code class="varname">[n]</code> ) continue at step 2</li><li>done</li></ol></div></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="vorbis-spec-floor1"></a>7. Floor type 1 setup and decode</h2></div><div><p class="releaseinfo">
$Id: 07-floor1.xml 10466 2005-11-28 00:34:44Z giles $
-</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2541060"></a>7.1. Overview</h3></div></div></div><p>
+</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id336243"></a>7.1. Overview</h3></div></div></div><p>
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2540135"></a>7.2. Floor 1 format</h3></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2451267"></a>7.2.1. model</h4></div></div></div><p>
+Bresenham's algorithm.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id334800"></a>7.2. Floor 1 format</h3></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id316161"></a>7.2.1. model</h4></div></div></div><p>
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
@@ -1392,7 +1392,7 @@
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. </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2516615"></a>7.2.2. header decode</h4></div></div></div><p>
+accumulation through integer roundoff/truncation. </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id317351"></a>7.2.2. header decode</h4></div></div></div><p>
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
@@ -1524,7 +1524,7 @@
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.</p><div class="section" lang="en"><div class="titlepage"><div><div><h6 class="title"><a name="id2521765"></a>7.2.2.2.1. step 1: amplitude value synthesis</h6></div></div></div><p>
+in serious decoding errors.</p><div class="section" lang="en"><div class="titlepage"><div><div><h6 class="title"><a name="id326536"></a>7.2.2.2.1. step 1: amplitude value synthesis</h6></div></div></div><p>
Unwrap the always-positive-or-zero values read from the packet into
+/- difference values, then apply to line prediction.</p><pre class="screen">
1) [range] = vector { 256, 128, 86, 64 } element ([floor1_multiplier]-1)
@@ -1600,7 +1600,7 @@
29) done
-</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h6 class="title"><a name="id2521846"></a>7.2.2.2.2. step 2: curve synthesis</h6></div></div></div><p>
+</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h6 class="title"><a name="id326571"></a>7.2.2.2.2. step 2: curve synthesis</h6></div></div></div><p>
Curve synthesis generates a return vector <code class="varname">[floor]</code> of length
<code class="varname">[n]</code> (where <code class="varname">[n]</code> is provided by the decode process
calling to floor decode). Floor 1 curve synthesis makes use of the
@@ -1650,8 +1650,8 @@
16) done
</pre></div></div></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="vorbis-spec-residue"></a>8. Residue setup and decode</h2></div><div><p class="releaseinfo">
- $Id: 08-residue.xml 10466 2005-11-28 00:34:44Z giles $
- </p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2524422"></a>8.1. Overview</h3></div></div></div><p>
+ $Id: 08-residue.xml 13159 2007-06-21 05:22:35Z xiphmont $
+ </p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id320982"></a>8.1. Overview</h3></div></div></div><p>
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
@@ -1662,7 +1662,7 @@
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2517330"></a>8.2. Residue format</h3></div></div></div><p>
+abstraction.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id307154"></a>8.2. Residue format</h3></div></div></div><p>
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
@@ -1697,7 +1697,7 @@
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.</p></li></ul></div><p>
-</p><div class="mediaobject"><img src="residue-pack.png" alt="[illustration of residue vector format]"></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2506346"></a>8.3. residue 0</h3></div></div></div><p>
+</p><div class="mediaobject"><img src="residue-pack.png" alt="[illustration of residue vector format]"></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id326310"></a>8.3. residue 0</h3></div></div></div><p>
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).</p><p>
@@ -1721,7 +1721,7 @@
</pre><p>
It is worth mentioning at this point that no configurable value in the
-residue coding setup is restricted to a power of two.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2517602"></a>8.4. residue 1</h3></div></div></div><p>
+residue coding setup is restricted to a power of two.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id326344"></a>8.4. residue 1</h3></div></div></div><p>
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
@@ -1739,14 +1739,14 @@
codebook dimensions = 1 encoded as: [ 0 ], [ 1 ], [ 2 ], [ 3 ], [ 4 ], [ 5 ], [ 6 ], [ 7 ]
-</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2517633"></a>8.5. residue 2</h3></div></div></div><p>
+</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id334893"></a>8.5. residue 2</h3></div></div></div><p>
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 <span class="emphasis"><em>ch</em></span> passed in vectors of length <span class="emphasis"><em>n</em></span> are first
interleaved and flattened into a single vector of length
<span class="emphasis"><em>ch</em></span>*<span class="emphasis"><em>n</em></span>. 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.</p><div class="mediaobject"><img src="residue2.png" alt="[illustration of residue type 2]"></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2538870"></a>8.6. Residue decode</h3></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2538876"></a>8.6.1. header decode</h4></div></div></div><p>
+vector to begin with, residue type 1 and type 2 are equivalent.</p><div class="mediaobject"><img src="residue2.png" alt="[illustration of residue type 2]"></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id334939"></a>8.6. Residue decode</h3></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id334945"></a>8.6.1. header decode</h4></div></div></div><p>
Header decode for all three residue types is identical.</p><pre class="programlisting">
1) [residue_begin] = read 24 bits as unsigned integer
2) [residue_end] = read 24 bits as unsigned integer
@@ -1807,7 +1807,7 @@
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2538992"></a>8.6.2. packet decode</h4></div></div></div><p>
+stream undecodable.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id325037"></a>8.6.2. packet decode</h4></div></div></div><p>
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
@@ -1818,32 +1818,52 @@
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.</p><p>
+Depending on the values of <code class="varname">[residue_begin]</code> and
+<code class="varname">[residue_end]</code>, 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 <code class="varname">[residue_begin]</code> and
+<code class="varname">[residue_end]</code> to specify a range partially or
+wholly beyond the maximum vector size. Before beginning residue
+decode, limit <code class="varname">[residue_begin]</code> and
+<code class="varname">[residue_end]</code> to the maximum possible vector size
+as follows. We assume that the number of vectors being encoded,
+<code class="varname">[ch]</code> is provided by the higher level decoding
+process.</p><pre class="programlisting">
+ 1) [actual_size] = current blocksize/2;
+ 2) if residue encoding is format 2
+ 3) [actual_size] = [actual_size] * [ch];
+ 4) [limit_residue_begin] = maximum of ([residue_begin],[actual_size]);
+ 5) [limit_residue_end] = maximum of ([residue_end],[actual_size]);
+</pre><p>
The following convenience values are conceptually useful to clarifying
the decode process:</p><pre class="programlisting">
1) [classwords_per_codeword] = [codebook_dimensions] value of codebook [residue_classbook]
- 2) [n_to_read] = [residue_end] - [residue_begin]
+ 2) [n_to_read] = [limit_residue_end] - [limit_residue_begin]
3) [partitions_to_read] = [n_to_read] / [residue_partition_size]
</pre><p>
-Packet decode proceeds as follows, matching the description offered earlier in the document. We assume that the number of vectors being encoded, <code class="varname">[ch]</code> is provided by the higher level decoding process.</p><pre class="programlisting">
+Packet decode proceeds as follows, matching the description offered earlier in the document. </p><pre class="programlisting">
1) allocate and zero all vectors that will be returned.
- 2) iterate [pass] over the range 0 ... 7 {
+ 2) if ([n_to_read] is zero), stop; there is no residue to decode.
+ 3) iterate [pass] over the range 0 ... 7 {
- 3) [partition_count] = 0
+ 4) [partition_count] = 0
- 4) while [partition_count] is less than [partitions_to_read]
+ 5) while [partition_count] is less than [partitions_to_read]
- 5) if ([pass] is zero) {
+ 6) if ([pass] is zero) {
- 6) iterate [j] over the range 0 .. [ch]-1 {
+ 7) iterate [j] over the range 0 .. [ch]-1 {
- 7) if vector [j] is not marked 'do not decode' {
+ 8) if vector [j] is not marked 'do not decode' {
- 8) [temp] = read from packet using codebook [residue_classbook] in scalar context
- 9) iterate [i] descending over the range [classwords_per_codeword]-1 ... 0 {
+ 9) [temp] = read from packet using codebook [residue_classbook] in scalar context
+ 10) iterate [i] descending over the range [classwords_per_codeword]-1 ... 0 {
- 10) array [classifications] element [j],([i]+[partition_count]) =
+ 11) array [classifications] element [j],([i]+[partition_count]) =
[temp] integer modulo [residue_classifications]
- 11) [temp] = [temp] / [residue_classifications] using integer division
+ 12) [temp] = [temp] / [residue_classifications] using integer division
}
@@ -1853,35 +1873,35 @@
}
- 12) iterate [i] over the range 0 .. ([classwords_per_codeword] - 1) while [partition_count]
+ 13) iterate [i] over the range 0 .. ([classwords_per_codeword] - 1) while [partition_count]
is also less than [partitions_to_read] {
- 13) iterate [j] over the range 0 .. [ch]-1 {
+ 14) iterate [j] over the range 0 .. [ch]-1 {
- 14) if vector [j] is not marked 'do not decode' {
+ 15) if vector [j] is not marked 'do not decode' {
- 15) [vqclass] = array [classifications] element [j],[partition_count]
- 16) [vqbook] = array [residue_books] element [vqclass],[pass]
- 17) if ([vqbook] is not 'unused') {
+ 16) [vqclass] = array [classifications] element [j],[partition_count]
+ 17) [vqbook] = array [residue_books] element [vqclass],[pass]
+ 18) if ([vqbook] is not 'unused') {
- 18) decode partition into output vector number [j], starting at scalar
- offset [residue_begin]+[partition_count]*[residue_partition_size] using
+ 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
}
}
- 19) increment [partition_count] by one
+ 20) increment [partition_count] by one
}
}
}
- 20) done
+ 21) done
</pre><p>
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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2498601"></a>8.6.3. format 0 specifics</h4></div></div></div><p>
+that point.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id341700"></a>8.6.3. format 0 specifics</h4></div></div></div><p>
Format zero decodes partitions exactly as described earlier in the
'Residue Format: residue 0' section. The following pseudocode
presents the same algorithm. Assume:</p><p>
@@ -1903,7 +1923,7 @@
6) done
-</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2498659"></a>8.6.4. format 1 specifics</h4></div></div></div><p>
+</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id341754"></a>8.6.4. format 1 specifics</h4></div></div></div><p>
Format 1 decodes partitions exactly as described earlier in the
'Residue Format: residue 1' section. The following pseudocode
presents the same algorithm. Assume:</p><p>
@@ -1923,7 +1943,7 @@
6) if ( [i] is less than [n] ) continue at step 2
7) done
-</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2498716"></a>8.6.5. format 2 specifics</h4></div></div></div><p>
+</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id341807"></a>8.6.5. format 2 specifics</h4></div></div></div><p>
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.
</p><p>
Format 2 handles 'do not decode' vectors differently than residue 0 or
@@ -1946,11 +1966,11 @@
</pre><p>
</p></li></ol></div></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="vorbis-spec-helper"></a>9. Helper equations</h2></div><div><p class="releaseinfo">
$Id: 09-helper.xml 7186 2004-07-20 07:19:25Z xiphmont $
-</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2507758"></a>9.1. Overview</h3></div></div></div><p>
+</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id316603"></a>9.1. Overview</h3></div></div></div><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 referenced where appropriate.
-</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2512257"></a>9.2. Functions</h3></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="vorbis-spec-ilog"></a>9.2.1. ilog</h4></div></div></div><p>
+</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id317505"></a>9.2. Functions</h3></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="vorbis-spec-ilog"></a>9.2.1. ilog</h4></div></div></div><p>
The "ilog(x)" function returns the position number (1 through n) of the highest set bit in the two's complement integer value
<code class="varname">[x]</code>. Values of <code class="varname">[x]</code> less than zero are defined to return zero.</p><pre class="programlisting">
1) [return_value] = 0;
@@ -2131,7 +2151,7 @@
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></div><div class="appendix" lang="en"><h2 class="title" style="clear: both"><a name="vorbis-over-ogg"></a>A. Embedding Vorbis into an Ogg stream</h2><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2520211"></a>A.1. Overview</h3></div></div></div><p>
+</pre></div></div><div class="appendix" lang="en"><h2 class="title" style="clear: both"><a name="vorbis-over-ogg"></a>1. Embedding Vorbis into an Ogg stream</h2><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id319760"></a>1.1. Overview</h3></div></div></div><p>
This document describes using Ogg logical and physical transport
streams to encapsulate Vorbis compressed audio packet data into file
form.</p><p>
@@ -2142,7 +2162,7 @@
bitstream and framing spec</a> 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.</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2530380"></a>A.1.1. Restrictions</h4></div></div></div><p>
+documents. Please read them first.</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id336562"></a>1.1.1. Restrictions</h4></div></div></div><p>
The Ogg/Vorbis I specification currently dictates that Ogg/Vorbis
streams use Ogg transport streams in degenerate, unmultiplexed
form only. That is:
@@ -2165,11 +2185,11 @@
specific support of Vorbis within a degenrate ogg stream (naturally,
application authors are encouraged to support full multiplexed Ogg
handling).
-</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2512176"></a>A.1.2. MIME type</h4></div></div></div><p>
+</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id330723"></a>1.1.2. MIME type</h4></div></div></div><p>
The correct MIME type of any Ogg file is <code class="literal">application/ogg</code>.
However, if a file is a Vorbis I audio file (which implies a
degenerate Ogg stream including only unmultiplexed Vorbis audio), the
-mime type <code class="literal">audio/x-vorbis</code> is also allowed.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2520628"></a>A.2. Encapsulation</h3></div></div></div><p>
+mime type <code class="literal">audio/x-vorbis</code> is also allowed.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id328095"></a>1.2. Encapsulation</h3></div></div></div><p>
Ogg encapsulation of a Vorbis packet stream is straightforward.</p><div class="itemizedlist"><ul type="disc"><li>
The first Vorbis packet (the identification header), which
uniquely identifies a stream as Vorbis audio, is placed alone in the
@@ -2241,14 +2261,14 @@
between the actual available data returned and the declared amount
indicates how many trailing samples to discard from the decoding
process.
- </li></ul></div></div></div><div class="appendix" lang="en"><h2 class="title" style="clear: both"><a name="vorbis-over-rtp"></a>B. Vorbis encapsulation in RTP</h2><pre class="literallayout">
+ </li></ul></div></div></div><div class="appendix" lang="en"><h2 class="title" style="clear: both"><a name="vorbis-over-rtp"></a>2. Vorbis encapsulation in RTP</h2><pre class="literallayout">
<p>Please consult the internet draft <em class="citetitle">RTP Payload Format for Vorbis Encoded
Audio</em> for description of how to embed Vorbis audio in an RTP stream.</p>
-</pre></div><div class="appendix" lang="en"><h2 class="title" style="clear: both"><a name="footer"></a>C. Colophon</h2><div class="mediaobject"><img src="white-xifish.png" alt="[Xiph.org logo]"></div><p>
+</pre></div><div class="appendix" lang="en"><h2 class="title" style="clear: both"><a name="footer"></a>3. Colophon</h2><div class="mediaobject"><img src="white-xifish.png" alt="[Xiph.org logo]"></div><p>
Ogg is a <a href="http://www.xiph.org/" target="_top">Xiph.org Foundation</a> effort
to protect essential tenets of Internet multimedia from corporate
hostage-taking; Open Source is the net's greatest tool to keep
@@ -2266,7 +2286,7 @@
other licenses.</p><p>
Ogg, Vorbis, Xiph.org Foundation and their logos are trademarks (tm)
of the <a href="http://www.xiph.org/" target="_top">Xiph.org Foundation</a>. These
-pages are copyright (C) 1994-2004 Xiph.org Foundation. All rights
+pages are copyright (C) 1994-2007 Xiph.org Foundation. All rights
reserved.</p><p>
This document is set in DocBook XML.
</p></div></div></body></html>
Modified: branches/vorbis-aotuv/doc/Vorbis_I_spec.pdf
===================================================================
(Binary files differ)
Added: branches/vorbis-aotuv/doc/draft-ietf-avt-rtp-vorbis-06.txt
===================================================================
--- branches/vorbis-aotuv/doc/draft-ietf-avt-rtp-vorbis-06.txt (rev 0)
+++ branches/vorbis-aotuv/doc/draft-ietf-avt-rtp-vorbis-06.txt 2008-04-01 10:47:58 UTC (rev 14647)
@@ -0,0 +1,1401 @@
+
+
+
+AVT Working Group L. Barbato
+Internet-Draft Xiph.Org
+Expires: December 27, 2007 Jun 25, 2007
+
+
+ draft-ietf-avt-rtp-vorbis-06
+ RTP Payload Format for Vorbis Encoded Audio
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on December 27, 2007.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ This document describes an RTP payload format for transporting Vorbis
+ encoded audio. It details the RTP encapsulation mechanism for raw
+ Vorbis data and details the delivery mechanisms for the decoder
+ probability model, referred to as a codebook and other setup
+ information.
+
+ Also included within this memo are media type registrations, and the
+ details necessary for the use of Vorbis with the Session Description
+ Protocol (SDP).
+
+
+
+Barbato Expires December 27, 2007 [Page 1]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+Editors Note
+
+ All references to RFC XXXX are to be replaced by references to the
+ RFC number of this memo, when published.
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 5
+ 2.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.4. Example RTP Packet . . . . . . . . . . . . . . . . . . . . 7
+ 3. Configuration Headers . . . . . . . . . . . . . . . . . . . . 8
+ 3.1. In-band Header Transmission . . . . . . . . . . . . . . . 9
+ 3.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 9
+ 3.2. Out of Band Transmission . . . . . . . . . . . . . . . . . 11
+ 3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 11
+ 3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 12
+ 4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 12
+ 5. Frame Packetization . . . . . . . . . . . . . . . . . . . . . 13
+ 5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 14
+ 5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 16
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
+ 6.1. Packed Headers IANA Considerations . . . . . . . . . . . . 19
+ 7. SDP related considerations . . . . . . . . . . . . . . . . . . 20
+ 7.1. Mapping Media Type Parameters into SDP . . . . . . . . . . 20
+ 7.1.1. SDP Example . . . . . . . . . . . . . . . . . . . . . 21
+ 7.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 21
+ 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 22
+ 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 9.1. Stream Radio . . . . . . . . . . . . . . . . . . . . . . . 22
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
+ 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
+ 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23
+ 12.2. Informative References . . . . . . . . . . . . . . . . . . 24
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
+ Intellectual Property and Copyright Statements . . . . . . . . . . 25
+
+
+
+
+
+
+
+
+
+
+Barbato Expires December 27, 2007 [Page 2]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+1. Introduction
+
+ 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 AAC. 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).
+
+ Vorbis encoded audio is generally encapsulated within an Ogg format
+ bitstream [11], which provides framing and synchronization. For the
+ purposes of RTP transport, this layer is unnecessary, and so raw
+ Vorbis packets are used in the payload.
+
+1.1. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [1].
+
+
+2. Payload Format
+
+ For RTP based transport of Vorbis encoded audio the standard RTP
+ header is followed by a 4 octets payload header, then the payload
+ data. The payload headers are used to associate the Vorbis data with
+ its associated decoding codebooks as well as indicating if the
+ following packet contains fragmented Vorbis data and/or the number of
+ whole Vorbis data frames. The payload data contains the raw Vorbis
+ bitstream information. There are 3 types of Vorbis payload data, an
+ RTP packet MUST contain just one of them at a time.
+
+2.1. RTP Header
+
+ The format of the RTP header is specified in [2] and shown in Figure
+ Figure 1. This payload format uses the fields of the header in a
+ manner consistent with that specification.
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato Expires December 27, 2007 [Page 3]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | sequence number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | timestamp |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1: RTP Header
+
+ The RTP header begins with an octet of fields (V, P, X, and CC) to
+ support specialized RTP uses (see [2] and [3] for details). For
+ Vorbis RTP, the following values are used.
+
+ Version (V): 2 bits
+
+ This field identifies the version of RTP. The version used by this
+ specification is two (2).
+
+ Padding (P): 1 bit
+
+ Padding MAY be used with this payload format according to section 5.1
+ of [2].
+
+ Extension (X): 1 bit
+
+ The Extension bit is used in accordance with [2].
+
+ CSRC count (CC): 4 bits
+
+ The CSRC count is used in accordance with [2].
+
+ Marker (M): 1 bit
+
+ Set to zero. Audio silence suppression not used. This conforms to
+ section 4.1 of [13].
+
+ Payload Type (PT): 7 bits
+
+ An RTP profile for a class of applications is expected to assign a
+ payload type for this format, or a dynamically allocated payload type
+ SHOULD be chosen which designates the payload as Vorbis.
+
+
+
+
+Barbato Expires December 27, 2007 [Page 4]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+ Sequence number: 16 bits
+
+ The sequence number increments by one for each RTP data packet sent,
+ and may be used by the receiver to detect packet loss and to restore
+ packet sequence. This field is detailed further in [2].
+
+ Timestamp: 32 bits
+
+ A timestamp representing the sampling time of the first sample of the
+ first Vorbis packet in the RTP packet. The clock frequency MUST be
+ set to the sample rate of the encoded audio data and is conveyed out-
+ of-band (e.g. as a SDP parameter).
+
+ SSRC/CSRC identifiers:
+
+ These two fields, 32 bits each with one SSRC field and a maximum of
+ 16 CSRC fields, are as defined in [2].
+
+2.2. Payload Header
+
+ The 4 octets following the RTP Header section are the Payload Header.
+ This header is split into a number of bitfields detailing the format
+ of the following payload data packets.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | F |VDT|# pkts.|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 2: Payload Header
+
+ Ident: 24 bits
+
+ This 24 bit field is used to associate the Vorbis data to a decoding
+ Configuration. It is stored as network byte order integer.
+
+ Fragment type (F): 2 bits
+
+ This field is set according to the following list
+
+ 0 = Not Fragmented
+ 1 = Start Fragment
+ 2 = Continuation Fragment
+ 3 = End Fragment
+
+ Vorbis Data Type (VDT): 2 bits
+
+
+
+
+Barbato Expires December 27, 2007 [Page 5]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+ This field specifies the kind of Vorbis data stored in this RTP
+ packet. There are currently three different types of Vorbis
+ payloads. Each packet MUST contain only a single type of Vorbis
+ payload (e.g. you MUST not aggregate configuration and comment
+ payload in the same packet)
+
+ 0 = Raw Vorbis payload
+ 1 = Vorbis Packed Configuration payload
+ 2 = Legacy Vorbis Comment payload
+ 3 = Reserved
+
+ The packets with a VDT of value 3 MUST be ignored
+
+ The last 4 bits represent the number of complete packets in this
+ payload. This provides for a maximum number of 15 Vorbis packets in
+ the payload. If the packet contains fragmented data the number of
+ packets MUST be set to 0.
+
+2.3. Payload Data
+
+ Raw Vorbis packets are currently unbounded in length, application
+ profiles will likely define a practical limit. Typical Vorbis packet
+ sizes range from very small (2-3 bytes) to quite large (8-12
+ kilobytes). The reference implementation [12] typically produces
+ packets less than ~800 bytes, except for the setup header packets
+ which are ~4-12 kilobytes. Within an RTP context, to avoid
+ fragmentation, the Vorbis data packet size SHOULD be kept
+ sufficiently small so that after adding the RTP and payload headers,
+ the complete RTP packet is smaller than the path MTU.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | vorbis packet data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 3: Payload Data Header
+
+ Each Vorbis payload packet starts with a two octet length header,
+ which is used to represent the size in bytes of the following data
+ payload, followed by the raw Vorbis data padded to the nearest byte
+ boundary, as explained by the vorbis specification [13]. The length
+ value is stored as network byte order integer.
+
+ For payloads which consist of multiple Vorbis packets the payload
+ data consists of the packet length followed by the packet data for
+ each of the Vorbis packets in the payload.
+
+
+
+
+Barbato Expires December 27, 2007 [Page 6]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+ The Vorbis packet length header is the length of the Vorbis data
+ block only and does not count the length field.
+
+ The payload packing of the Vorbis data packets MUST follow the
+ guidelines set-out in [3] where the oldest packet occurs immediately
+ after the RTP packet header. Subsequent packets, if any, MUST follow
+ in temporal order.
+
+ Channel mapping of the audio is in accordance with the Vorbis I
+ Specification [13].
+
+2.4. Example RTP Packet
+
+ Here is an example RTP packet containing two Vorbis packets.
+
+ RTP Packet Header:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 2 |0|0| 0 |0| PT | sequence number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | timestamp (in sample rate units) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronisation source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 0 | 0 | 2 pks |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | vorbis data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | next vorbis packet data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 4: Example Raw Vorbis Packet
+
+ The payload data section of the RTP packet begins with the 24 bit
+ Ident field followed by the one octet bitfield header, which has the
+ number of Vorbis frames set to 2. Each of the Vorbis data frames is
+
+
+
+Barbato Expires December 27, 2007 [Page 7]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+ prefixed by the two octets length field. The Packet Type and
+ Fragment Type are set to 0. The Configuration that will be used to
+ decode the packets is the one indexed by the ident value.
+
+
+3. Configuration Headers
+
+ Unlike other mainstream audio codecs Vorbis has no statically
+ configured probability model. Instead, it packs all entropy decoding
+ configuration, Vector Quantization and Huffman models into a data
+ block that must be transmitted to the decoder along with the
+ compressed data. A decoder also requires information detailing the
+ number of audio channels, bitrates and similar information to
+ configure itself for a particular compressed data stream. These two
+ blocks of information are often referred to collectively as the
+ "codebooks" for a Vorbis stream, and are nominally included as
+ special "header" packets at the start of the compressed data. In
+ addition, the Vorbis I specification [13] requires the presence of a
+ comment header packet which gives simple metadata about the stream,
+ but this information is not required for decoding the frame sequence.
+
+ Thus these two codebook header packets must be received by the
+ decoder before any audio data can be interpreted. These requirements
+ pose problems in RTP, which is often used over unreliable transports.
+
+ Since this information must be transmitted reliably and, as the RTP
+ stream may change certain configuration data mid-session, there are
+ different methods for delivering this configuration data to a client,
+ both in-band and out-of-band which is detailed below. SDP delivery
+ is typically used to set up an initial state for the client
+ application. The changes may be due to different codebooks as well
+ as different bitrates of the stream.
+
+ The delivery vectors in use can be specified by an SDP attribute to
+ indicate the method and the optional URI where the Vorbis Packed
+ Configuration (Section 3.1.1) Packets could be fetched. Different
+ delivery methods MAY be advertised for the same session. The in-band
+ Configuration delivery SHOULD be considered as baseline, out-of-band
+ delivery methods that don't use RTP will not be described in this
+ document. For non chained streams, the Configuration recommended
+ delivery method is inline the Packed Configuration (Section 3.1.1) in
+ the SDP as explained in the IANA considerations (Section 7.1).
+
+ The 24 bit Ident field is used to map which Configuration will be
+ used to decode a packet. When the Ident field changes, it indicates
+ that a change in the stream has taken place. The client application
+ MUST have in advance the correct configuration and if the client
+ detects a change in the Ident value and does not have this
+
+
+
+Barbato Expires December 27, 2007 [Page 8]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+ information it MUST NOT decode the raw Vorbis data associated until
+ it fetches the correct Configuration.
+
+3.1. In-band Header Transmission
+
+ The Packed Configuration (Section 3.1.1) Payload is sent in-band with
+ the packet type bits set to match the Vorbis Data Type. Clients MUST
+ be capable of dealing with fragmentation and periodic re-transmission
+ of the configuration headers.
+
+3.1.1. Packed Configuration
+
+ A Vorbis Packed Configuration is indicated with the Vorbis Data Type
+ field set to 1. Of the three headers defined in the Vorbis I
+ specification [13], the identification and the setup MUST be packed
+ as they are, while the comment header MAY be replaced with a dummy
+ one. The packed configuration follows a generic way to store xiph
+ codec configurations: The first field stores the number of the
+ following packets minus one (count field), the next ones represent
+ the size of the headers (length fields), the headers immediately
+ follow the list of length fields. The size of the last header is
+ implicit. The count and the length fields are encoded using the
+ following logic: the data is in network order, every byte has the
+ most significant bit used as flag and the following 7 used to store
+ the value. The first N bit are to be taken, where N is number of
+ bits representing the value modulo 7, and stored in the first byte.
+ If there are more bits, the flag bit is set to 1 and the subsequent
+ 7bit are stored in the following byte, if there are remaining bits
+ set the flag to 1 and the same procedure is repeated. The ending
+ byte has the flag bit set to 0. In order to decode it is enough to
+ iterate over the bytes until the flag bit set to 0, for every byte
+ the data is added to the accumulated value multiplied by 128. The
+ headers are packed in the same order they are present in ogg:
+ identification, comment, setup.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato Expires December 27, 2007 [Page 9]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | xxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | xxxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 1 | 0 | 0|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | n. of headers | length1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length2 | Identification ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Identification ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Identification ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Identification ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Identification | Comment ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Comment ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Comment ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Comment ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Comment | Setup ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Setup ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Setup ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 5: Packed Configuration Figure
+
+ The Ident field is set with the value that will be used by the Raw
+ Payload Packets to address this Configuration. The Fragment type is
+ set to 0 since the packet bears the full Packed configuration, the
+ number of packet is set to 1.
+
+
+
+
+
+Barbato Expires December 27, 2007 [Page 10]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+3.2. Out of Band Transmission
+
+ This section, as stated above, does not cover all the possible out-
+ of-band delivery methods since they rely on different protocols and
+ are linked to specific applications. The following packet definition
+ SHOULD be used in out-of-band delivery and MUST be used when
+ Configuration is inlined in the SDP.
+
+3.2.1. Packed Headers
+
+ As mentioned above the RECOMMENDED delivery vector for Vorbis
+ configuration data is via a retrieval method that can be performed
+ using a reliable transport protocol. As the RTP headers are not
+ required for this method of delivery the structure of the
+ configuration data is slightly different. The packed header starts
+ with a 32 bit (network ordered) count field which details the number
+ of packed headers that are contained in the bundle. Next is the
+ Packed header payload for each chained Vorbis stream.
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Number of packed headers |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Packed header |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Packed header |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 6: Packed Headers Overview
+
+ Since the Configuration Ident and the Identification Header are fixed
+ length there is only a 2 byte length tag to define the length of the
+ packed headers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato Expires December 27, 2007 [Page 11]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | length ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. | n. of headers | length1 | length2 ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. | Identification Header ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .................................................................
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. | Comment Header ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .................................................................
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Comment Header |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Setup Header ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .................................................................
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Setup Header |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 7: Packed Headers Detail
+
+ The key difference between the in-band format and this one, is that
+ there is no need for the payload header octet. In this figure the
+ comment has a size bigger than 127 bytes.
+
+3.3. Loss of Configuration Headers
+
+ Unlike the loss of raw Vorbis payload data, loss of a configuration
+ header can lead to a situation where it will not be possible to
+ successfully decode the stream.
+
+ Loss of Configuration Packet results in the halting of stream
+ decoding.
+
+
+4. Comment Headers
+
+ With the Vorbis Data Type flag set to 2, this indicates that the
+ packet contain the comment metadata, such as artist name, track title
+ and so on. These metadata messages are not intended to be fully
+ descriptive but to offer basic track/song information. Clients MAY
+ ignore it completely. The details on the format of the comments can
+ be found in the Vorbis documentation [13].
+
+
+
+Barbato Expires December 27, 2007 [Page 12]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | xxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | xxxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 0 | 2 | 1|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | Comment ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Comment ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Comment |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 8: Comment Packet
+
+ The 2 bytes length field is necessary since this packet could be
+ fragmented.
+
+
+5. Frame Packetization
+
+ Each RTP packet contains either one Vorbis packet fragment, or an
+ integer number of complete Vorbis packets (up to a maximum of 15
+ packets, since the number of packets is defined by a 4 bit value).
+
+ Any Vorbis data packet that is less than path MTU SHOULD be bundled
+ in the RTP packet with as many Vorbis packets as will fit, up to a
+ maximum of 15, except when such bundling would exceed an
+ application's desired transmission latency. Path MTU is detailed in
+ [6] and [7].
+
+ A fragmented packet has a zero in the last four bits of the payload
+ header. The first fragment will set the Fragment type to 1. Each
+ fragment after the first will set the Fragment type to 2 in the
+ payload header. The RTP packet containing the last fragment of the
+ Vorbis packet will have the Fragment type set to 3. To maintain the
+ correct sequence for fragmented packet reception the timestamp field
+ of fragmented packets MUST be the same as the first packet sent, with
+ the sequence number incremented as normal for the subsequent RTP
+
+
+
+Barbato Expires December 27, 2007 [Page 13]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+ packets. The length field shows the fragment length.
+
+5.1. Example Fragmented Vorbis Packet
+
+ Here is an example fragmented Vorbis packet split over three RTP
+ packets. Each packet contains the standard RTP headers as well as
+ the 4 octets Vorbis headers.
+
+ Packet 1:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | 1000 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 12345 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 1 | 0 | 0|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | vorbis data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 9: Example Fragmented Packet (Packet 1)
+
+ In this packet the initial sequence number is 1000 and the timestamp
+ is 12345. The Fragment type is set to 1, the number of packets field
+ is set to 0, and as the payload is raw Vorbis data the VDT field is
+ set to 0.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato Expires December 27, 2007 [Page 14]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+ Packet 2:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | 1001 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 12345 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 2 | 0 | 0|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | vorbis data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 10: Example Fragmented Packet (Packet 2)
+
+ The Fragment type field is set to 2 and the number of packets field
+ is set to 0. For large Vorbis fragments there can be several of
+ these type of payload packets. The maximum packet size SHOULD be no
+ greater than the path MTU, including all RTP and payload headers.
+ The sequence number has been incremented by one but the timestamp
+ field remains the same as the initial packet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato Expires December 27, 2007 [Page 15]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+ Packet 3:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | 1002 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 12345 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 3 | 0 | 0|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | vorbis data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 11: Example Fragmented Packet (Packet 3)
+
+ This is the last Vorbis fragment packet. The Fragment type is set to
+ 3 and the packet count remains set to 0. As in the previous packets
+ the timestamp remains set to the first packet in the sequence and the
+ sequence number has been incremented.
+
+5.2. Packet Loss
+
+ As there is no error correction within the Vorbis stream, packet loss
+ will result in a loss of signal. Packet loss is more of an issue for
+ fragmented Vorbis packets as the client will have to cope with the
+ handling of the Fragment Type. In case of loss of fragments the
+ client MUST discard all the remaining fragments and decode the
+ incomplete packet. If we use the fragmented Vorbis packet example
+ above and the first packet is lost the client MUST detect that the
+ next packet has the packet count field set to 0 and the Fragment type
+ 2 and MUST drop it. The next packet, which is the final fragmented
+ packet, MUST be dropped in the same manner. If the missing packet is
+ the last, the received two fragments will be kept and the incomplete
+ vorbis packet decoded.
+
+ Loss of any of the Configuration fragment will result in the loss of
+ the full Configuration packet with the result detailed in the Loss of
+ Configuration Headers (Section 3.3) section.
+
+
+
+
+Barbato Expires December 27, 2007 [Page 16]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+6. IANA Considerations
+
+ Type name: audio
+
+ Subtype name: vorbis
+
+ Required parameters:
+
+ rate: indicates the RTP timestamp clock rate as described in RTP
+ Profile for Audio and Video Conferences with Minimal Control.
+ [3]
+
+ channels: indicates the number of audio channels as described in
+ RTP Profile for Audio and Video Conferences with Minimal
+ Control. [3]
+
+ delivery-method: indicates the delivery methods in use, the
+ possible values are: inline, in_band, out_band, MAY be included
+ multiple times
+
+ configuration: the base64 [9] representation of the Packed
+ Headers (Section 3.2.1). It MUST follow the associated
+ delivery-method parameter ("inline").
+
+ Optional parameters:
+
+ configuration-uri: the URI [4] of the configuration headers in
+ case of out of band transmission. In the form of
+ "protocol://path/to/resource/", depending on the specific
+ method, a single configuration packet could be retrived by its
+ Ident number, or multiple packets could be aggregated in a
+ single stream. Such aggregates MAY be compressed using either
+ bzip2 [16] or gzip [14]. A sha1 [10] checksum MAY be provided
+ for aggregates. In this latter case the URI will end with the
+ aggregate name, followed by its compressed extension if
+ applies, a "!" and the base64 [9] representation of the
+ sha1hash of the above mentioned compressed aggregated as in:
+ "protocol://path/to/resource/aggregated.bz2!sha1hash". The
+ trailing '/' discriminates which of two methods are in use.
+ The configuration-uri MUST follow the associated delivery
+ method parameter ("out_band"). Non hierarchical protocols and
+ protocols using for special purposes the '!' separator MAY
+ point just to a resource aggregate using their specific syntax.
+
+
+
+
+
+
+
+
+Barbato Expires December 27, 2007 [Page 17]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+ Encoding considerations:
+
+ This media type is framed and contains binary data.
+
+ Security considerations:
+
+ See Section 10 of RFC XXXX.
+
+ Interoperability considerations:
+
+ None
+
+ Published specification:
+
+ RFC XXXX [RFC Editor: please replace by the RFC number of this
+ memo, when published]
+
+ Ogg Vorbis I specification: Codec setup and packet decode.
+ Available from the Xiph website, http://www.xiph.org
+
+ Applications which use this media type:
+
+ Audio streaming and conferencing tools
+
+ Additional information:
+
+ None
+
+ Person & email address to contact for further information:
+
+ Luca Barbato: <lu_zero at gentoo.org> IETF Audio/Video Transport
+ Working Group
+
+ Intended usage:
+
+ COMMON
+
+ Restriction on usage:
+
+ This media type depends on RTP framing, and hence is only defined
+ for transfer via RTP [2]
+
+ Author:
+
+ Luca Barbato
+
+
+
+
+
+
+Barbato Expires December 27, 2007 [Page 18]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+ Change controller:
+
+ IETF AVT Working Group delegated from the IESG
+
+
+6.1. Packed Headers IANA Considerations
+
+ The following IANA considerations MUST only be applied to the packed
+ headers.
+
+ Type name: audio
+
+ Subtype name: vorbis-config
+
+ Required parameters:
+
+ None
+
+ Optional parameters:
+
+ None
+
+ Encoding considerations:
+
+ This media type contains binary data.
+
+ Security considerations:
+
+ See Section 10 of RFC XXXX.
+
+ Interoperability considerations:
+
+ None
+
+ Published specification:
+
+ RFC XXXX [RFC Editor: please replace by the RFC number of this
+ memo, when published]
+
+ Applications which use this media type:
+
+ Vorbis encoded audio, configuration data.
+
+ Additional information:
+
+ None
+
+
+
+
+
+Barbato Expires December 27, 2007 [Page 19]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+ Person & email address to contact for further information:
+
+ Luca Barbato: <lu_zero at gentoo.org>
+ IETF Audio/Video Transport Working Group
+
+ Intended usage: COMMON
+
+ Restriction on usage:
+
+ This media type doesn't depend on the transport.
+
+ Author:
+
+ Luca Barbato
+
+ Change controller:
+
+ IETF AVT Working Group delegated from the IESG
+
+
+7. SDP related considerations
+
+ The following paragraphs defines the mapping of the parameters
+ described in the IANA considerations section and their usage in the
+ Offer/Answer Model [8].
+
+7.1. Mapping Media Type Parameters into SDP
+
+ The information carried in the Media Type media type specification
+ has a specific mapping to fields in the Session Description Protocol
+ (SDP) [5], which is commonly used to describe RTP sessions. When SDP
+ is used to specify sessions the mapping are as follows:
+
+ o The type name ("audio") goes in SDP "m=" as the media name.
+
+ o The subtype name ("vorbis") goes in SDP "a=rtpmap" as the encoding
+ name.
+
+ o The parameter "rate" also goes in "a=rtpmap" as clock rate.
+
+ o The parameter "channels" also goes in "a=rtpmap" as channel count.
+
+ o The mandated parameters "delivery-method" and "configuration" MUST
+ be included in the SDP "a=fmtp" attribute.
+
+ o The optional parameter "configuration-uri", when present, MUST be
+ included in the SDP "a=fmtp" attribute and MUST follow the
+ delivery-method that applies.
+
+
+
+Barbato Expires December 27, 2007 [Page 20]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+ If the stream comprises chained Vorbis files and all of them are
+ known in advance, the Configuration Packet for each file SHOULD be
+ passed to the client using the configuration attribute.
+
+ The URI specified in the configuration-uri attribute MUST point to a
+ location where all of the Configuration Packets needed for the life
+ of the session reside.
+
+ The port value is specified by the server application bound to the
+ address specified in the c= line. The bitrate value and channels
+ specified in the rtpmap attribute MUST match the Vorbis sample rate
+ value. An example is found below.
+
+7.1.1. SDP Example
+
+ The following example shows a basic SDP single stream. The first
+ configuration packet is inlined in the sdp, other configurations
+ could be fetched at any time from the first provided uri using or all
+ the known configuration could be downloaded using the second uri.
+ The inline base64 [9] configuration string is omitted because of the
+ length.
+ c=IN IP4 192.0.2.1
+ m=audio RTP/AVP 98
+ a=rtpmap:98 vorbis/44100/2
+ a=fmtp:98 delivery-method=inline; configuration=base64string;
+ delivery-method=out_band;
+ configuration-uri=rtsp://path/to/the/resource; delivery-
+ method=out_band; configuration-uri=http://another/path/to/
+ resource/aggregate.bz2!8b6237eb5154a0ea12811a94e8e2697b3312bc6c;
+
+ Note that the payload format (encoding) names are commonly shown in
+ upper case. Media Type subtypes are commonly shown in lower case.
+ These names are case-insensitive in both places. Similarly,
+ parameter names are case-insensitive both in Media Type types and in
+ the default mapping to the SDP a=fmtp attribute. The exception
+ regarding case sensitivity is the configuration-uri URI which MUST be
+ regarded as being case sensitive. The a=fmtp line is a single line
+ even if it is presented broken because of clarity.
+
+7.2. Usage with the SDP Offer/Answer Model
+
+ The only paramenter negotiable is the delivery method. All the
+ others are declarative: the offer, as described in An Offer/Answer
+ Model Session Description Protocol [8], may contain a large number of
+ delivery methods per single fmtp attribute, the answerer MUST remove
+ every delivery-method and configuration-uri not supported. All the
+ parameters MUST not be altered on answer otherwise.
+
+
+
+
+Barbato Expires December 27, 2007 [Page 21]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+8. Congestion Control
+
+ Vorbis clients SHOULD send regular receiver reports detailing
+ congestion. A mechanism for dynamically downgrading the stream,
+ known as bitrate peeling, will allow for a graceful backing off of
+ the stream bitrate. This feature is not available at present so an
+ alternative would be to redirect the client to a lower bitrate stream
+ if one is available.
+
+
+9. Examples
+
+ The following examples are common usage patterns that MAY be applied
+ in such situations, the main scope of this section is to explain
+ better usage of the transmission vectors.
+
+9.1. Stream Radio
+
+ This is one of the most common situation: one single server streaming
+ content in multicast, the clients may start a session at random time.
+ The content itself could be a mix of live stream, as the wj's voice,
+ and stored streams as the music she plays.
+
+ In this situation we don't know in advance how many codebooks we will
+ use. The clients can join anytime and users expect to start
+ listening to the content in a short time.
+
+ On join the client will receive the current Configuration necessary
+ to decode the current stream inlined in the SDP so that the decoding
+ will start immediately after.
+
+ When the streamed content changes the new Configuration is sent in-
+ band before the actual stream, and the Configuration that has to be
+ sent inline in the SDP updated. Since the in-band method is
+ unreliable, an out of band fallback is provided.
+
+ The client could choose to fetch the Configuration from the alternate
+ source as soon as it discovers a Configuration packet got lost in-
+ band or use selective retransmission [15], if the server supports the
+ feature.
+
+ A serverside optimization would be to keep an hash list of the
+ Configurations per session to avoid packing all of them and send the
+ same Configuration with different Ident tags
+
+ A clientside optimization would be to keep a tag list of the
+ Configurations per session and don't process configuration packets
+ already known.
+
+
+
+Barbato Expires December 27, 2007 [Page 22]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+10. Security Considerations
+
+ RTP packets using this payload format are subject to the security
+ considerations discussed in the RTP specification [2]. This implies
+ that the confidentiality of the media stream is achieved by using
+ encryption. Because the data compression used with this payload
+ format is applied end-to-end, encryption may be performed on the
+ compressed data. Additional care MAY be needed for delivery methods
+ that point to external resources, using secure protocols to fetch the
+ configuration payloads. Where the size of a data block is set, care
+ MUST be taken to prevent buffer overflows in the client applications.
+
+
+11. Acknowledgments
+
+ This document is a continuation of draft-moffitt-vorbis-rtp-00.txt
+ and draft-kerr-avt-vorbis-rtp-04.txt. The Media Type type section is
+ a continuation of draft-short-avt-rtp-vorbis-mime-00.txt.
+
+ Thanks to the AVT, Ogg Vorbis Communities / Xiph.org including Steve
+ Casner, Aaron Colwell, Ross Finlayson, Fluendo, Ramon Garcia, Pascal
+ Hennequin, Ralph Giles, Tor-Einar Jarnbjo, Colin Law, John Lazzaro,
+ Jack Moffitt, Christopher Montgomery, Colin Perkins, Barry Short,
+ Mike Smith, Phil Kerr, Michael Sparks, Magnus Westerlund, David
+ Barrett, Silvia Pfeiffer, Stefan Ehmann, Alessandro Salvatori.
+ Politecnico di Torino (LS)^3/IMG Group in particular Federico
+ Ridolfo, Francesco Varano, Giampaolo Mancini, Dario Gallucci, Juan
+ Carlos De Martin.
+
+
+12. References
+
+12.1. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119.
+
+ [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
+ "RTP: A Transport Protocol for real-time applications",
+ RFC 3550.
+
+ [3] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
+ Conferences with Minimal Control.", RFC 3551.
+
+ [4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", RFC 3986.
+
+ [5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+
+
+
+Barbato Expires December 27, 2007 [Page 23]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+ Description Protocol", RFC 4566, July 2006.
+
+ [6] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
+ November 1990.
+
+ [7] McCann et al., J., "Path MTU Discovery for IP version 6",
+ RFC 1981.
+
+ [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
+ Session Description Protocol (SDP)", RFC 3264.
+
+ [9] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
+ RFC 3548.
+
+ [10] National Institute of Standards and Technology, "Secure Hash
+ Standard", May 1993.
+
+12.2. Informative References
+
+ [11] Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
+ RFC 3533.
+
+ [12] "libvorbis: Available from the Xiph website,
+ http://www.xiph.org".
+
+ [13] "Ogg Vorbis I specification: Codec setup and packet decode.
+ Available from the Xiph website, http://www.xiph.org".
+
+ [14] Deutsch, P., "GZIP file format specification version 4.3",
+ RFC 1952.
+
+ [15] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
+ Extended Reports (RTCP XR)", RFC 3611, November 2003.
+
+ [16] Seward, J., "libbz2 and bzip2".
+
+
+Author's Address
+
+ Luca Barbato
+ Xiph.Org
+
+ Email: lu_zero at gentoo.org
+ URI: http://www.xiph.org/
+
+
+
+
+
+
+
+Barbato Expires December 27, 2007 [Page 24]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+Barbato Expires December 27, 2007 [Page 25]
+
+
Added: branches/vorbis-aotuv/doc/draft-ietf-avt-rtp-vorbis-06.xml
===================================================================
--- branches/vorbis-aotuv/doc/draft-ietf-avt-rtp-vorbis-06.xml (rev 0)
+++ branches/vorbis-aotuv/doc/draft-ietf-avt-rtp-vorbis-06.xml 2008-04-01 10:47:58 UTC (rev 14647)
@@ -0,0 +1,1388 @@
+<?xml version='1.0'?>
+<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
+<?rfc toc="yes" ?>
+<?rfc compact='yes'?>
+
+<rfc ipr="full3978" docName="RTP Payload Format for Vorbis Encoded Audio">
+
+<front>
+<title>draft-ietf-avt-rtp-vorbis-06</title>
+
+<author initials="L" surname="Barbato" fullname="Luca Barbato">
+<organization>Xiph.Org</organization>
+<address>
+<email>lu_zero at gentoo.org</email>
+<uri>http://www.xiph.org/</uri>
+</address>
+</author>
+
+<date day="25" month="Jun" year="2007" />
+
+<area>General</area>
+<workgroup>AVT Working Group</workgroup>
+<keyword>I-D</keyword>
+
+<keyword>Internet-Draft</keyword>
+<keyword>Vorbis</keyword>
+<keyword>RTP</keyword>
+
+<abstract>
+
+<t>
+This document describes an RTP payload format for transporting Vorbis encoded
+audio. It details the RTP encapsulation mechanism for raw Vorbis data and
+details the delivery mechanisms for the decoder probability model, referred to
+as a codebook and other setup information.
+</t>
+
+<t>
+Also included within this memo are media type registrations, and the details
+necessary for the use of Vorbis with the Session Description Protocol (SDP).
+</t>
+
+</abstract>
+
+<note title="Editors Note">
+<t>
+All references to RFC XXXX are to be replaced by references to the RFC number
+of this memo, when published.
+</t>
+</note>
+
+</front>
+
+<middle>
+
+<section anchor="Introduction" title="Introduction">
+
+<t>
+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 AAC.
+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).
+</t>
+
+<t>
+Vorbis encoded audio is generally encapsulated within an Ogg format bitstream
+<xref target="rfc3533"></xref>, which provides framing and synchronization.
+For the purposes of RTP transport, this layer is unnecessary, and so raw Vorbis
+packets are used in the payload.
+</t>
+
+<section anchor="Terminology" title="Terminology">
+
+<t>
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
+in this document are to be interpreted as described in RFC 2119 <xref target="rfc2119"></xref>.
+</t>
+
+</section>
+</section>
+
+<section anchor="Payload Format" title="Payload Format">
+
+<t>
+For RTP based transport of Vorbis encoded audio the standard RTP header is
+followed by a 4 octets payload header, then the payload data. The payload
+headers are used to associate the Vorbis data with its associated decoding
+codebooks as well as indicating if the following packet contains fragmented
+Vorbis data and/or the number of whole Vorbis data frames. The payload data
+contains the raw Vorbis bitstream information. There are 3 types of Vorbis
+payload data, an RTP packet MUST contain just one of them at a time.
+</t>
+
+<section anchor="RTP Header" title="RTP Header">
+
+<t>
+The format of the RTP header is specified in <xref target="rfc3550"></xref>
+and shown in Figure <xref target="RTP Header Figure"/>. This payload format
+uses the fields of the header in a manner consistent with that specification.
+</t>
+
+<t>
+<figure anchor="RTP Header Figure" title="RTP Header">
+<artwork><![CDATA[
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | sequence number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | timestamp |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+</t>
+
+<t>
+The RTP header begins with an octet of fields (V, P, X, and CC) to support
+specialized RTP uses (see <xref target="rfc3550"></xref> and
+<xref target="rfc3551"></xref> for details). For Vorbis RTP, the following
+values are used.
+</t>
+
+<t>
+Version (V): 2 bits</t>
+<t>
+This field identifies the version of RTP. The version used by this
+specification is two (2).
+</t>
+
+<t>
+Padding (P): 1 bit</t>
+<t>
+Padding MAY be used with this payload format according to section 5.1 of
+<xref target="rfc3550"></xref>.
+</t>
+
+<t>
+Extension (X): 1 bit</t>
+<t>
+The Extension bit is used in accordance with <xref target="rfc3550"></xref>.
+</t>
+
+<t>
+CSRC count (CC): 4 bits</t>
+<t>
+The CSRC count is used in accordance with <xref target="rfc3550"></xref>.
+</t>
+
+<t>
+Marker (M): 1 bit</t>
+<t>
+Set to zero. Audio silence suppression not used. This conforms to section 4.1
+of <xref target="vorbis-spec-ref"></xref>.
+</t>
+
+<t>
+Payload Type (PT): 7 bits</t>
+<t>
+An RTP profile for a class of applications is expected to assign a payload type
+for this format, or a dynamically allocated payload type SHOULD be chosen which
+designates the payload as Vorbis.
+</t>
+
+<t>
+Sequence number: 16 bits</t>
+<t>
+The sequence number increments by one for each RTP data packet sent, and may be
+used by the receiver to detect packet loss and to restore packet sequence. This
+field is detailed further in <xref target="rfc3550"></xref>.
+</t>
+
+<t>
+Timestamp: 32 bits</t>
+<t>
+A timestamp representing the sampling time of the first sample of the first
+Vorbis packet in the RTP packet. The clock frequency MUST be set to the sample
+rate of the encoded audio data and is conveyed out-of-band (e.g. as a SDP parameter).
+</t>
+
+<t>
+SSRC/CSRC identifiers: </t>
+<t>
+These two fields, 32 bits each with one SSRC field and a maximum of 16 CSRC
+fields, are as defined in <xref target="rfc3550">
+</xref>.
+</t>
+
+</section>
+
+<section anchor="Payload Header" title="Payload Header">
+
+<t>
+The 4 octets following the RTP Header section are the Payload Header. This
+header is split into a number of bitfields detailing the format of the
+following payload data packets.
+</t>
+
+<figure anchor="Payload Header Figure" title="Payload Header">
+<artwork><![CDATA[
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | F |VDT|# pkts.|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+Ident: 24 bits</t>
+<t>
+This 24 bit field is used to associate the Vorbis data to a decoding
+Configuration. It is stored as network byte order integer.
+</t>
+
+<t>
+Fragment type (F): 2 bits</t>
+<t>
+This field is set according to the following list
+</t>
+<vspace blankLines="1" />
+<list style="empty">
+<t> 0 = Not Fragmented</t>
+<t> 1 = Start Fragment</t>
+<t> 2 = Continuation Fragment</t>
+<t> 3 = End Fragment</t>
+</list>
+
+<t>
+Vorbis Data Type (VDT): 2 bits</t>
+<t>
+This field specifies the kind of Vorbis data stored in this RTP packet. There
+are currently three different types of Vorbis payloads. Each packet MUST contain only a single type of Vorbis payload (e.g. you MUST not aggregate configuration and comment payload in the same packet)
+</t>
+
+<vspace blankLines="1" />
+<list style="empty">
+<t> 0 = Raw Vorbis payload</t>
+<t> 1 = Vorbis Packed Configuration payload</t>
+<t> 2 = Legacy Vorbis Comment payload</t>
+<t> 3 = Reserved</t>
+</list>
+
+<t> The packets with a VDT of value 3 MUST be ignored </t>
+
+<t>
+The last 4 bits represent the number of complete packets in this payload. This
+provides for a maximum number of 15 Vorbis packets in the payload. If the
+packet contains fragmented data the number of packets MUST be set to 0.
+</t>
+
+</section>
+
+<section anchor="Payload Data" title="Payload Data">
+
+<t>
+Raw Vorbis packets are currently unbounded in length, application profiles will
+likely define a practical limit. Typical Vorbis packet sizes range from very
+small (2-3 bytes) to quite large (8-12 kilobytes). The reference implementation
+<xref target="libvorbis"></xref> typically produces packets less than ~800
+bytes, except for the setup header packets which are ~4-12 kilobytes. Within an
+RTP context, to avoid fragmentation, the Vorbis data packet size SHOULD be kept
+sufficiently small so that after adding the RTP and payload headers, the
+complete RTP packet is smaller than the path MTU.
+</t>
+
+<figure anchor="Payload Data Figure" title="Payload Data Header">
+<artwork><![CDATA[
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | vorbis packet data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+Each Vorbis payload packet starts with a two octet length header, which is used
+to represent the size in bytes of the following data payload, followed by the
+raw Vorbis data padded to the nearest byte boundary, as explained by the <xref target="vorbis-spec-ref">vorbis specification</xref>. The length value is stored
+as network byte order integer.
+</t>
+
+<t>
+For payloads which consist of multiple Vorbis packets the payload data consists
+of the packet length followed by the packet data for each of the Vorbis packets
+in the payload.
+</t>
+
+<t>
+The Vorbis packet length header is the length of the Vorbis data block only and
+does not count the length field.
+</t>
+
+<t>
+The payload packing of the Vorbis data packets MUST follow the guidelines
+set-out in <xref target="rfc3551"></xref> where the oldest packet occurs
+immediately after the RTP packet header. Subsequent packets, if any, MUST
+follow in temporal order.
+</t>
+
+<t>
+Channel mapping of the audio is in accordance with the
+<xref target="vorbis-spec-ref">Vorbis I Specification</xref>.
+</t>
+
+</section>
+
+<section anchor="Example RTP Packet" title="Example RTP Packet">
+
+<t>
+Here is an example RTP packet containing two Vorbis packets.
+</t>
+
+<t>
+RTP Packet Header:
+</t>
+
+<figure anchor="Example Raw Vorbis Packet" title="Example Raw Vorbis Packet">
+<artwork><![CDATA[
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 2 |0|0| 0 |0| PT | sequence number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | timestamp (in sample rate units) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronisation source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 0 | 0 | 2 pks |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | vorbis data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | next vorbis packet data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+The payload data section of the RTP packet begins with the 24 bit Ident field
+followed by the one octet bitfield header, which has the number of Vorbis
+frames set to 2. Each of the Vorbis data frames is prefixed by the two octets
+length field. The Packet Type and Fragment Type are set to 0. The Configuration
+that will be used to decode the packets is the one indexed by the ident value.
+</t>
+
+</section>
+</section>
+
+
+
+<section anchor="Configuration Headers" title="Configuration Headers">
+
+<t>
+Unlike other mainstream audio codecs Vorbis has no statically
+configured probability model. Instead, it packs all entropy decoding
+configuration, Vector Quantization and Huffman models into a data block
+that must be transmitted to the decoder along with the compressed data.
+A decoder also requires information detailing the number of audio
+channels, bitrates and similar information to configure itself for a
+particular compressed data stream. These two blocks of information are
+often referred to collectively as the "codebooks" for a Vorbis stream,
+and are nominally included as special "header" packets at the start
+of the compressed data. In addition,
+the <xref target="vorbis-spec-ref">Vorbis I specification</xref>
+requires the presence of a comment header packet which gives simple
+metadata about the stream, but this information is not required for
+decoding the frame sequence.
+</t>
+
+<t>
+Thus these two codebook header packets must be received by the decoder before
+any audio data can be interpreted. These requirements pose problems in RTP,
+which is often used over unreliable transports.
+</t>
+
+<t>
+Since this information must be transmitted reliably and, as the RTP
+stream may change certain configuration data mid-session, there are
+different methods for delivering this configuration data to a
+client, both in-band and out-of-band which is detailed below. SDP
+delivery is typically used to set up an initial state for the client
+application. The changes may be due to different codebooks as well as
+different bitrates of the stream.
+</t>
+
+<t>
+The delivery vectors in use can be specified by an SDP attribute to indicate the
+method and the optional URI where the Vorbis
+<xref target="Packed Configuration">Packed Configuration</xref> Packets could
+be fetched. Different delivery methods MAY be advertised for the same session.
+The in-band Configuration delivery SHOULD be considered as baseline,
+out-of-band delivery methods that don't use RTP will not be described in this
+document. For non chained streams, the Configuration recommended delivery
+method is inline the <xref target="Packed Configuration">Packed Configuration</xref> in the SDP as explained in the <xref target="Mapping Media Type Parameters into SDP"> IANA considerations</xref>.
+</t>
+
+<t>
+The 24 bit Ident field is used to map which Configuration will be used to
+decode a packet. When the Ident field changes, it indicates that a change in
+the stream has taken place. The client application MUST have in advance the
+correct configuration and if the client detects a change in the Ident value and
+does not have this information it MUST NOT decode the raw Vorbis data
+associated until it fetches the correct Configuration.
+</t>
+
+<section anchor="In-band Header Transmission" title="In-band Header Transmission">
+
+<t>
+The <xref target="Packed Configuration">Packed Configuration</xref> Payload is
+sent in-band with the packet type bits set to match the Vorbis Data Type.
+Clients MUST be capable of dealing with fragmentation and periodic
+re-transmission of the configuration headers.
+</t>
+
+<section anchor="Packed Configuration" title="Packed Configuration">
+
+<t>
+A Vorbis Packed Configuration is indicated with the Vorbis Data Type field set
+to 1. Of the three headers defined in the
+<xref target="vorbis-spec-ref">Vorbis I specification</xref>, the
+identification and the setup MUST be packed as they are, while the comment header MAY be replaced with a dummy one. The packed configuration follows a generic way to store xiph codec configurations: The first field stores the number of the following packets minus one (count field), the next ones represent the size of the headers (length fields), the headers immediately follow the list of length fields. The size of the last header is implicit.
+The count and the length fields are encoded using the following logic: the data is in network order, every byte has the most significant bit used as flag and the following 7 used to store the value. The first N bit are to be taken, where N is number of bits representing the value modulo 7, and stored in the first byte.
+If there are more bits, the flag bit is set to 1 and the subsequent 7bit are stored in the following byte, if there are remaining bits set the flag to 1 and the same procedure is repeated. The ending byte has the flag bit set to 0. In order to decode it is enough to iterate over the bytes until the flag bit set to 0, for every byte the data is added to the accumulated value multiplied by 128.
+The headers are packed in the same order they are present in ogg: identification, comment, setup.</t>
+
+<figure anchor="Packed Configuration Figure" title="Packed Configuration Figure">
+<artwork><![CDATA[
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | xxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | xxxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 1 | 0 | 0|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | n. of headers | length1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length2 | Identification ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Identification ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Identification ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Identification ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Identification | Comment ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Comment ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Comment ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Comment ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Comment | Setup ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Setup ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Setup ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>The Ident field is set with the value that will be used by the Raw Payload
+Packets to address this Configuration. The Fragment type is set to 0 since the
+packet bears the full Packed configuration, the number of packet is set to 1.</t>
+</section>
+</section>
+
+<section anchor="Out of Band Transmission" title="Out of Band Transmission">
+
+<t>
+This section, as stated above, does not cover all the possible out-of-band
+delivery methods since they rely on different protocols and are linked to
+specific applications. The following packet definition SHOULD be used in
+out-of-band delivery and MUST be used when Configuration is inlined in the SDP.
+</t>
+
+<section anchor="Packed Headers" title="Packed Headers">
+
+<t>
+As mentioned above the RECOMMENDED delivery vector for Vorbis configuration
+data is via a retrieval method that can be performed using a reliable transport
+protocol. As the RTP headers are not required for this method of delivery the
+structure of the configuration data is slightly different. The packed header
+starts with a 32 bit (network ordered) count field which details the number of
+packed headers that are contained in the bundle. Next is the Packed header
+payload for each chained Vorbis stream.
+</t>
+
+<figure anchor="Packed Headers Overview Figure" title="Packed Headers Overview">
+<artwork><![CDATA[
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Number of packed headers |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Packed header |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Packed header |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+Since the Configuration Ident and the Identification Header are fixed length
+there is only a 2 byte length tag to define the length of the packed headers.
+</t>
+
+<figure anchor="Packed Headers Detail Figure" title="Packed Headers Detail">
+<artwork><![CDATA[
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | length ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. | n. of headers | length1 | length2 ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. | Identification Header ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .................................................................
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. | Comment Header ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .................................................................
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Comment Header |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Setup Header ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .................................................................
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Setup Header |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+<t>
+The key difference between the in-band format and this one, is that there is no
+need for the payload header octet. In this figure the comment has a size bigger
+than 127 bytes.
+</t>
+</section>
+
+</section>
+
+<section anchor="Loss of Configuration Headers" title="Loss of Configuration Headers">
+
+<t>
+Unlike the loss of raw Vorbis payload data, loss of a configuration header can
+lead to a situation where it will not be possible to successfully decode the
+stream.
+</t>
+
+<t>
+Loss of Configuration Packet results in the halting of stream decoding.
+</t>
+
+</section>
+
+</section>
+
+<section anchor="Comment Headers" title="Comment Headers">
+
+<t>
+With the Vorbis Data Type flag set to 2, this indicates that the packet contain
+the comment metadata, such as artist name, track title and so on. These
+metadata messages are not intended to be fully descriptive but to offer basic
+track/song information. Clients MAY ignore it completely. The details on the
+format of the comments can be found in the <xref target="vorbis-spec-ref">Vorbis documentation</xref>.
+</t>
+<figure anchor="Comment Packet Figure" title="Comment Packet">
+<artwork><![CDATA[
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | xxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | xxxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 0 | 2 | 1|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | Comment ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Comment ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Comment |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+The 2 bytes length field is necessary since this packet could be fragmented.
+</t>
+
+</section>
+<section anchor="Frame Packetization" title="Frame Packetization">
+
+<t>
+Each RTP packet contains either one Vorbis packet fragment, or an integer
+number of complete Vorbis packets (up to a maximum of 15 packets, since the
+number of packets is defined by a 4 bit value).
+</t>
+
+<t>
+Any Vorbis data packet that is less than path MTU SHOULD be bundled in the RTP
+packet with as many Vorbis packets as will fit, up to a maximum of 15, except
+when such bundling would exceed an application's desired transmission latency.
+Path MTU is detailed in <xref target="rfc1191"></xref> and <xref target="rfc1981"></xref>.
+</t>
+
+<t>
+A fragmented packet has a zero in the last four bits of the payload header.
+The first fragment will set the Fragment type to 1. Each fragment after the
+first will set the Fragment type to 2 in the payload header. The RTP packet
+containing the last fragment of the Vorbis packet will have the Fragment type
+set to 3. To maintain the correct sequence for fragmented packet reception
+the timestamp field of fragmented packets MUST be the same as the first packet
+sent, with the sequence number incremented as normal for the subsequent RTP
+packets. The length field shows the fragment length.
+</t>
+
+<section anchor="Example Fragmented Vorbis Packet" title="Example Fragmented Vorbis Packet">
+
+<t>
+Here is an example fragmented Vorbis packet split over three RTP packets.
+Each packet contains the standard RTP headers as well as the 4 octets Vorbis
+headers.
+</t>
+
+<figure anchor="Example Fragmented Packet (Packet 1)" title="Example Fragmented Packet (Packet 1)">
+<artwork><![CDATA[
+ Packet 1:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | 1000 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 12345 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 1 | 0 | 0|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | vorbis data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+In this packet the initial sequence number is 1000 and the timestamp is 12345. The Fragment type is set to 1, the number of packets field is set to 0, and as
+the payload is raw Vorbis data the VDT field is set to 0.
+</t>
+
+<figure anchor="Example Fragmented Packet (Packet 2)" title="Example Fragmented Packet (Packet 2)">
+<artwork><![CDATA[
+ Packet 2:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | 1001 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 12345 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 2 | 0 | 0|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | vorbis data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+The Fragment type field is set to 2 and the number of packets field is set to 0.
+For large Vorbis fragments there can be several of these type of payload
+packets. The maximum packet size SHOULD be no greater than the path MTU,
+including all RTP and payload headers. The sequence number has been incremented
+by one but the timestamp field remains the same as the initial packet.
+</t>
+
+<figure anchor="Example Fragmented Packet (Packet 3)" title="Example Fragmented Packet (Packet 3)">
+<artwork><![CDATA[
+ Packet 3:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | 1002 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 12345 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 3 | 0 | 0|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | vorbis data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+This is the last Vorbis fragment packet. The Fragment type is set to 3 and the
+packet count remains set to 0. As in the previous packets the timestamp remains
+set to the first packet in the sequence and the sequence number has been
+incremented.
+</t>
+</section>
+
+<section anchor="Packet Loss" title="Packet Loss">
+
+<t>
+As there is no error correction within the Vorbis stream, packet loss will
+result in a loss of signal. Packet loss is more of an issue for fragmented
+Vorbis packets as the client will have to cope with the handling of the
+Fragment Type. In case of loss of fragments the client MUST discard all the
+remaining fragments and decode the incomplete packet. If we use the fragmented
+Vorbis packet example above and the first packet is lost the client MUST detect
+that the next packet has the packet count field set to 0 and the Fragment type
+2 and MUST drop it. The next packet, which is the final fragmented packet, MUST
+be dropped in the same manner. If the missing packet is the last, the received
+two fragments will be kept and the incomplete vorbis packet decoded.
+</t>
+
+<t>
+Loss of any of the Configuration fragment will result in the loss of the full
+Configuration packet with the result detailed in the <xref target="Loss of Configuration Headers">Loss of Configuration Headers</xref> section.
+</t>
+
+</section>
+</section>
+<section anchor="IANA Considerations" title="IANA Considerations">
+
+<vspace blankLines="1" />
+<list style="hanging">
+<t hangText="Type name:"> audio </t>
+<vspace blankLines="1" />
+
+<t hangText="Subtype name:"> vorbis </t>
+<vspace blankLines="1" />
+
+<t hangText="Required parameters:">
+
+<vspace blankLines="1" />
+
+<list style="hanging">
+<t hangText="rate:"> indicates the RTP timestamp clock rate as described in <xref target="rfc3551">RTP Profile for Audio and Video Conferences with Minimal Control.</xref>
+</t>
+<vspace blankLines="1" />
+
+<t hangText="channels:"> indicates the number of audio channels as described in <xref target="rfc3551">RTP Profile for Audio and Video Conferences with Minimal Control.</xref>
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="delivery-method:"> indicates the delivery methods in use, the possible values are: inline, in_band, out_band, MAY be included multiple times
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="configuration:"> the <xref target="rfc3548">base64</xref> representation of the <xref target="Packed Headers">Packed Headers</xref>. It MUST follow the associated delivery-method parameter ("inline").
+</t>
+</list>
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Optional parameters:">
+
+<vspace blankLines="1" />
+
+<list style="hanging">
+<t hangText="configuration-uri:"> the <xref target="rfc3986">URI</xref> of
+the configuration headers in case of out of band transmission.
+In the form of "protocol://path/to/resource/", depending on the specific
+method, a single configuration packet could be retrived by its Ident number, or
+multiple packets could be aggregated in a single stream.
+Such aggregates MAY be compressed using either
+<xref target="BZ2">bzip2</xref> or <xref target="rfc1952">gzip</xref>.
+A <xref target="FIPS180">sha1</xref> checksum MAY be provided for aggregates.
+In this latter case the URI will end with the aggregate name, followed by its
+compressed extension if applies, a "!" and the <xref target="rfc3548">base64</xref> representation of the sha1hash of the above mentioned compressed aggregated
+as in: "protocol://path/to/resource/aggregated.bz2!sha1hash".
+The trailing '/' discriminates which of two methods are in use.
+The configuration-uri MUST follow the associated delivery method parameter ("out_band").
+Non hierarchical protocols and protocols using for special purposes the '!' separator MAY point just to a resource aggregate using their specific syntax.
+</t>
+</list>
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Encoding considerations:">
+<vspace blankLines="1" />
+This media type is framed and contains binary data.
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Security considerations:">
+<vspace blankLines="1" />
+See Section 10 of RFC XXXX.</t>
+
+<vspace blankLines="1" />
+<t hangText="Interoperability considerations:">
+<vspace blankLines="1" />
+None</t>
+
+<vspace blankLines="1" />
+<t hangText="Published specification:">
+
+<vspace blankLines="1" />
+RFC XXXX [RFC Editor: please replace by the RFC number of this memo, when published]
+<vspace blankLines="1" />
+Ogg Vorbis I specification: Codec setup and packet decode. Available from the Xiph website, http://www.xiph.org
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Applications which use this media type:">
+<vspace blankLines="1"/>
+Audio streaming and conferencing tools </t>
+
+<vspace blankLines="1" />
+
+<t hangText="Additional information:">
+<vspace blankLines="1" />
+None </t>
+
+<vspace blankLines="1" />
+
+<t hangText="Person & email address to contact for further information:">
+
+<vspace blankLines="1" />
+
+Luca Barbato: <lu_zero at gentoo.org><br/>
+IETF Audio/Video Transport Working Group
+
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Intended usage:">
+<vspace blankLines="1" />
+COMMON</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Restriction on usage:">
+<vspace blankLines="1" />
+This media type depends on RTP framing, and hence is only defined for transfer via <xref target="rfc3550">RTP</xref></t>
+
+<vspace blankLines="1" />
+
+<t hangText="Author:">
+<vspace blankLines="1"/>Luca Barbato</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Change controller:">
+<vspace blankLines="1"/>IETF AVT Working Group delegated from the IESG</t>
+
+<vspace blankLines="1" />
+</list>
+
+<section anchor="Packed Headers IANA Considerations" title="Packed Headers IANA Considerations">
+
+<t>
+The following IANA considerations MUST only be applied to the packed headers.
+</t>
+
+<vspace blankLines="1" />
+
+<list style="hanging">
+<t hangText="Type name:"> audio </t>
+
+<vspace blankLines="1" />
+
+<t hangText="Subtype name:"> vorbis-config </t>
+
+<vspace blankLines="1" />
+
+<t hangText="Required parameters:">
+<vspace blankLines="1" />
+None
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Optional parameters:">
+<vspace blankLines="1" />
+None
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Encoding considerations:">
+<vspace blankLines="1" />
+This media type contains binary data.
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Security considerations:">
+<vspace blankLines="1" />
+See Section 10 of RFC XXXX.
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Interoperability considerations:">
+<vspace blankLines="1" />
+None
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Published specification:">
+<vspace blankLines="1" />
+RFC XXXX [RFC Editor: please replace by the RFC number of this memo,
+ when published]
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Applications which use this media type:">
+<vspace blankLines="1" />
+Vorbis encoded audio, configuration data.
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Additional information:">
+<vspace blankLines="1" />
+None
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Person & email address to contact for further information:">
+<vspace blankLines="1" />
+Luca Barbato: <lu_zero at gentoo.org>
+<vspace blankLines="0" />
+IETF Audio/Video Transport Working Group
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Intended usage:">
+COMMON
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Restriction on usage:">
+<vspace blankLines="1" />
+This media type doesn't depend on the transport.
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Author:">
+<vspace blankLines="1" />
+Luca Barbato</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Change controller:">
+<vspace blankLines="1" />
+IETF AVT Working Group delegated from the IESG</t>
+</list>
+
+</section>
+
+</section>
+
+<section anchor="SDP related considerations" title="SDP related considerations">
+<t>
+The following paragraphs defines the mapping of the parameters described in the IANA considerations section and their usage in the <xref target="rfc3264">Offer/Answer Model</xref>.
+</t>
+
+<section anchor="Mapping Media Type Parameters into SDP" title="Mapping Media Type Parameters into SDP">
+
+<t>
+The information carried in the Media Type media type specification has a
+specific mapping to fields in the <xref target="rfc4566">Session Description
+Protocol (SDP)</xref>, which is commonly used to describe RTP sessions.
+When SDP is used to specify sessions the mapping are as follows:
+</t>
+
+<vspace blankLines="1" />
+<list style="symbols">
+
+<t>The type name ("audio") goes in SDP "m=" as the media name.</t>
+<vspace blankLines="1" />
+
+<t>The subtype name ("vorbis") goes in SDP "a=rtpmap" as the encoding name.</t>
+<vspace blankLines="1" />
+
+<t>The parameter "rate" also goes in "a=rtpmap" as clock rate.</t>
+<vspace blankLines="1" />
+
+<t>The parameter "channels" also goes in "a=rtpmap" as channel count.</t>
+<vspace blankLines="1" />
+
+<t>The mandated parameters "delivery-method" and "configuration" MUST be
+included in the SDP "a=fmtp" attribute.</t>
+<vspace blankLines="1" />
+
+<t>The optional parameter "configuration-uri", when present, MUST be included
+in the SDP "a=fmtp" attribute and MUST follow the delivery-method that applies.</t>
+
+</list>
+
+<t>
+If the stream comprises chained Vorbis files and all of them are known in
+advance, the Configuration Packet for each file SHOULD be passed to the client
+using the configuration attribute.
+</t>
+
+<t>
+The URI specified in the configuration-uri attribute MUST point to a location
+where all of the Configuration Packets needed for the life of the session
+reside.
+</t>
+
+<t>
+The port value is specified by the server application bound to the address
+specified in the c= line. The bitrate value and channels specified in the
+rtpmap attribute MUST match the Vorbis sample rate value. An example is found
+below.
+</t>
+
+<section anchor="SDP Example" title="SDP Example">
+<t>The following example shows a basic SDP single stream. The first
+configuration packet is inlined in the sdp, other configurations could be
+fetched at any time from the first provided uri using or all the known
+configuration could be downloaded using the second uri. The inline
+<xref target="rfc3548">base64</xref> configuration string is omitted because of
+the length.</t>
+
+<list style="empty">
+<t>c=IN IP4 192.0.2.1</t>
+<t>m=audio RTP/AVP 98</t>
+<t>a=rtpmap:98 vorbis/44100/2</t>
+<t>a=fmtp:98 delivery-method=inline; configuration=base64string; delivery-method=out_band; configuration-uri=rtsp://path/to/the/resource; delivery-method=out_band; configuration-uri=http://another/path/to/resource/aggregate.bz2!8b6237eb5154a0ea12811a94e8e2697b3312bc6c;</t>
+</list>
+</section>
+
+
+<t>
+Note that the payload format (encoding) names are commonly shown in upper case.
+Media Type subtypes are commonly shown in lower case. These names are
+case-insensitive in both places. Similarly, parameter names are
+case-insensitive both in Media Type types and in the default mapping to the SDP
+a=fmtp attribute. The exception regarding case sensitivity is the
+configuration-uri URI which MUST be regarded as being case sensitive. The
+a=fmtp line is a single line even if it is presented broken because of clarity.
+</t>
+
+</section>
+
+<section anchor="Usage with the SDP Offer/Answer Mode" title="Usage with the SDP Offer/Answer Model">
+
+<t>
+The only paramenter negotiable is the delivery method. All the others are
+declarative: the offer, as described in <xref target="rfc3264">An Offer/Answer
+Model Session Description Protocol</xref>, may contain a large number of
+delivery methods per single fmtp attribute, the answerer MUST remove every
+delivery-method and configuration-uri not supported. All the parameters MUST
+not be altered on answer otherwise.
+</t>
+
+</section>
+
+</section>
+
+<section anchor="Congestion Control" title="Congestion Control">
+
+<t>
+Vorbis clients SHOULD send regular receiver reports detailing congestion. A
+mechanism for dynamically downgrading the stream, known as bitrate peeling,
+will allow for a graceful backing off of the stream bitrate. This feature is
+not available at present so an alternative would be to redirect the client to
+a lower bitrate stream if one is available.
+</t>
+
+</section>
+
+<section anchor="Examples" title="Examples">
+
+<t>
+The following examples are common usage patterns that MAY be applied in such
+situations, the main scope of this section is to explain better usage of the
+transmission vectors.
+</t>
+
+<section anchor="Stream Radio" title="Stream Radio">
+
+<t>This is one of the most common situation: one single server streaming
+content in multicast, the clients may start a session at random time. The
+content itself could be a mix of live stream, as the wj's voice, and stored
+streams as the music she plays.</t>
+
+<t>In this situation we don't know in advance how many codebooks we will use.
+The clients can join anytime and users expect to start listening to the content
+in a short time.</t>
+
+<t>On join the client will receive the current Configuration necessary to
+decode the current stream inlined in the SDP so that the decoding will start
+immediately after.</t>
+
+<t>When the streamed content changes the new Configuration is sent in-band
+before the actual stream, and the Configuration that has to be sent inline in
+the SDP updated. Since the in-band method is unreliable, an out of band
+fallback is provided.</t>
+
+<t>The client could choose to fetch the Configuration from the alternate source
+as soon as it discovers a Configuration packet got lost in-band or use
+<xref target="RFC3611">selective retransmission</xref>, if the server supports
+the feature.</t>
+
+<t>A serverside optimization would be to keep an hash list of the
+Configurations per session to avoid packing all of them and send the same
+Configuration with different Ident tags</t>
+
+<t>A clientside optimization would be to keep a tag list of the Configurations
+per session and don't process configuration packets already known.</t>
+
+</section>
+</section>
+
+<section anchor="Security Considerations" title="Security Considerations">
+<t>
+RTP packets using this payload format are subject to the security
+considerations discussed in the RTP specification
+<xref target="rfc3550"></xref>. This implies that the confidentiality of the
+media stream is achieved by using encryption. Because the data compression used
+with this payload format is applied end-to-end, encryption may be performed on
+the compressed data. Additional care MAY be needed for delivery methods that
+point to external resources, using secure protocols to fetch the configuration
+payloads. Where the size of a data block is set, care MUST be taken to prevent
+buffer overflows in the client applications.
+</t>
+
+</section>
+
+<section anchor="Acknowledgments" title="Acknowledgments">
+
+<t>
+This document is a continuation of draft-moffitt-vorbis-rtp-00.txt and
+draft-kerr-avt-vorbis-rtp-04.txt. The Media Type type section is a
+continuation of draft-short-avt-rtp-vorbis-mime-00.txt.
+</t>
+
+<t>
+Thanks to the AVT, Ogg Vorbis Communities / Xiph.org including Steve Casner,
+Aaron Colwell, Ross Finlayson, Fluendo, Ramon Garcia, Pascal Hennequin, Ralph
+Giles, Tor-Einar Jarnbjo, Colin Law, John Lazzaro, Jack Moffitt, Christopher
+Montgomery, Colin Perkins, Barry Short, Mike Smith, Phil Kerr, Michael Sparks,
+Magnus Westerlund, David Barrett, Silvia Pfeiffer, Stefan Ehmann, Alessandro
+Salvatori. Politecnico di Torino (LS)³/IMG Group in particular Federico
+Ridolfo, Francesco Varano, Giampaolo Mancini, Dario Gallucci, Juan Carlos De Martin.
+</t>
+
+</section>
+
+</middle>
+
+<back>
+
+<references title="Normative References">
+
+<reference anchor="rfc2119">
+<front>
+<title>Key words for use in RFCs to Indicate Requirement Levels </title>
+<author initials="S." surname="Bradner" fullname="Scott Bradner"></author>
+</front>
+<seriesInfo name="RFC" value="2119" />
+</reference>
+
+<reference anchor="rfc3550">
+<front>
+<title>RTP: A Transport Protocol for real-time applications</title>
+<author initials="H." surname="Schulzrinne" fullname=""></author>
+<author initials="S." surname="Casner" fullname=""></author>
+<author initials="R." surname="Frederick" fullname=""></author>
+<author initials="V." surname="Jacobson" fullname=""></author>
+</front>
+<seriesInfo name="RFC" value="3550" />
+</reference>
+
+<reference anchor="rfc3551">
+<front>
+<title>RTP Profile for Audio and Video Conferences with Minimal Control.</title>
+<author initials="H." surname="Schulzrinne" fullname=""></author>
+<author initials="S." surname="Casner" fullname=""></author>
+</front>
+<date month="July" year="2003" />
+<seriesInfo name="RFC" value="3551" />
+</reference>
+
+<reference anchor='rfc3986'>
+<front>
+<title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title>
+<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
+</author>
+<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
+</author>
+<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
+</author>
+</front>
+<date year='2005' month='January' />
+<seriesInfo name='RFC' value='3986' />
+</reference>
+
+<reference anchor='rfc4566'>
+
+<front>
+<title>SDP: Session Description Protocol</title>
+<author initials='M.' surname='Handley' fullname='M. Handley'>
+<organization /></author>
+<author initials='V.' surname='Jacobson' fullname='V. Jacobson'>
+<organization /></author>
+<author initials='C.' surname='Perkins' fullname='C. Perkins'>
+<organization /></author>
+<date year='2006' month='July' />
+</front>
+
+<seriesInfo name='RFC' value='4566' />
+<format type='TXT' octets='108820' target='ftp://ftp.isi.edu/in-notes/rfc4566.txt' />
+</reference>
+
+<reference anchor='rfc1191'>
+
+<front>
+<title>Path MTU discovery</title>
+<author initials='J.' surname='Mogul' fullname='Jeffrey Mogul'>
+<organization>Digital Equipment Corporation (DEC) , Western Research Laboratory</organization>
+<address>
+<email>mogul at decwrl.dec.com</email></address></author>
+<author initials='S.' surname='Deering' fullname='Steve Deering'>
+<organization>Xerox Palo Alto Research Center</organization>
+<address>
+<email>deering at xerox.com</email></address></author>
+<date year='1990' day='1' month='November' />
+</front>
+
+<seriesInfo name='RFC' value='1191' />
+<format type='TXT' octets='47936' target='ftp://ftp.isi.edu/in-notes/rfc1191.txt' />
+</reference>
+
+<reference anchor="rfc1981">
+<front>
+<title>Path MTU Discovery for IP version 6</title>
+<author initials="J." surname="McCann et al." fullname="J. McCann et al."></author>
+</front>
+<seriesInfo name="RFC" value="1981" />
+</reference>
+
+<reference anchor="rfc3264">
+<front>
+<title>An Offer/Answer Model with Session Description Protocol (SDP)</title>
+<author initials="J." surname="Rosenberg" fullname="Jonathan Rosenberg"></author>
+<author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne"></author>
+</front>
+<seriesInfo name="RFC" value="3264" />
+</reference>
+
+<reference anchor="rfc3548">
+<front>
+<title>The Base16, Base32, and Base64 Data Encodings</title>
+<author initials="S." surname="Josefsson" fullname="Simon Josefsson"></author>
+</front>
+<seriesInfo name="RFC" value="3548" />
+</reference>
+<reference anchor="FIPS180">
+<front>
+<title>Secure Hash Standard</title>
+<author>
+<organization>National Institute of Standards and Technology</organization>
+</author>
+<date month="May" year="1993"/>
+</front>
+</reference>
+</references>
+
+<references title="Informative References">
+
+<reference anchor="rfc3533">
+<front>
+<title>The Ogg Encapsulation Format Version 0</title>
+<author initials="S." surname="Pfeiffer" fullname="Silvia Pfeiffer"></author>
+</front>
+<seriesInfo name="RFC" value="3533" />
+</reference>
+
+<reference anchor="libvorbis">
+<front>
+<title>libvorbis: Available from the Xiph website, http://www.xiph.org</title>
+</front>
+</reference>
+
+<reference anchor="vorbis-spec-ref">
+<front>
+<title>Ogg Vorbis I specification: Codec setup and packet decode. Available from the Xiph website, http://www.xiph.org</title>
+</front>
+</reference>
+
+<reference anchor="rfc1952">
+<front>
+<title>GZIP file format specification version 4.3</title>
+<author initials="P" surname="Deutsch" fullname="L. Peter Deutsch"></author>
+</front>
+<seriesInfo name="RFC" value="1952" />
+</reference>
+
+<reference anchor="RFC3611">
+<front>
+<title>RTP Control Protocol Extended Reports (RTCP XR)</title>
+<author initials="T." surname="Friedman" fullname="T. Friedman" />
+<author initials="R." surname="Caceres" fullname="R. Caceres" />
+<author initials="A." surname="Clark" fullname="A. Clark" />
+<date year="2003" month="November"/>
+</front>
+<seriesInfo name="RFC" value="3611"/>
+</reference>
+<reference anchor="BZ2">
+<front>
+
+<title>libbz2 and bzip2</title>
+<author initials="J" surname="Seward" fullname="Julian Seward" />
+</front>
+</reference>
+</references>
+</back>
+</rfc>
Modified: branches/vorbis-aotuv/doc/floor1_inverse_dB_table.html
===================================================================
--- branches/vorbis-aotuv/doc/floor1_inverse_dB_table.html 2008-03-31 15:23:02 UTC (rev 14646)
+++ branches/vorbis-aotuv/doc/floor1_inverse_dB_table.html 2008-04-01 10:47:58 UTC (rev 14647)
@@ -1,154 +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 (™) of Xiph.Org.<br/>
-
- These pages © 1994 - 2005 Xiph.Org. All rights reserved.
-</div>
-
-</body>
-</html>
+<!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 (™) of Xiph.Org.<br/>
+
+ These pages © 1994 - 2005 Xiph.Org. All rights reserved.
+</div>
+
+</body>
+</html>
Modified: branches/vorbis-aotuv/doc/framing.html
===================================================================
--- branches/vorbis-aotuv/doc/framing.html 2008-03-31 15:23:02 UTC (rev 14646)
+++ branches/vorbis-aotuv/doc/framing.html 2008-04-01 10:47:58 UTC (rev 14647)
@@ -1,433 +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 Tarkin 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 <a href="vorbis-stream.html">Vorbis
-bitstream mapping</a>.</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 < 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 (<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 < 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="ftp://ftp.rocksoft.com/papers/crc_v3.txt">"A
-Painless Guide to CRC Error Detection Algorithms"</a> by Ross
-Williams <a
-href="mailto:ross at guest.adelaide.edu.au">ross at guest.adelaide.edu.au</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 (™) of Xiph.Org.<br/>
-
- These pages © 1994 - 2005 Xiph.Org. All rights reserved.
-</div>
-
-</body>
-</html>
+<!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 < 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 (<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 < 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 at ross.net">ross at 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 (™) of Xiph.Org.<br/>
+
+ These pages © 1994 - 2005 Xiph.Org. All rights reserved.
+</div>
+
+</body>
+</html>
Modified: branches/vorbis-aotuv/doc/helper.html
===================================================================
--- branches/vorbis-aotuv/doc/helper.html 2008-03-31 15:23:02 UTC (rev 14646)
+++ branches/vorbis-aotuv/doc/helper.html 2008-04-01 10:47:58 UTC (rev 14647)
@@ -1,239 +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 (™) of Xiph.Org.<br/>
-
- These pages © 1994 - 2005 Xiph.Org. All rights reserved.
-</div>
-
-</body>
-</html>
+<!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 (™) of Xiph.Org.<br/>
+
+ These pages © 1994 - 2005 Xiph.Org. All rights reserved.
+</div>
+
+</body>
+</html>
Modified: branches/vorbis-aotuv/doc/index.html
===================================================================
--- branches/vorbis-aotuv/doc/index.html 2008-03-31 15:23:02 UTC (rev 14646)
+++ branches/vorbis-aotuv/doc/index.html 2008-04-01 10:47:58 UTC (rev 14647)
@@ -1,114 +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="draft-kerr-avt-vorbis-rtp-03.txt">Embedding Vorbis encoded
-audio in an RTP payload format</a></li>
-</ul>
-
-<h2>Ogg Vorbis programming documents</h2>
-
-<ul>
-<li>Programming with libvorbis</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 (™) of Xiph.Org.<br/>
-
- These pages © 1994 - 2005 Xiph.Org. All rights reserved.
-</div>
-
-</body>
-</html>
+<!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="draft-ietf-avt-rtp-vorbis-06.txt">Embedding Vorbis encoded
+audio in an RTP payload format</a></li>
+</ul>
+
+<h2>Ogg Vorbis programming documents</h2>
+
+<ul>
+<li>Programming with libvorbis</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 (™) of Xiph.Org.<br/>
+
+ These pages © 1994 - 2006 Xiph.Org. All rights reserved.
+</div>
+
+</body>
+</html>
Modified: branches/vorbis-aotuv/doc/oggstream.html
===================================================================
--- branches/vorbis-aotuv/doc/oggstream.html 2008-03-31 15:23:02 UTC (rev 14646)
+++ branches/vorbis-aotuv/doc/oggstream.html 2008-04-01 10:47:58 UTC (rev 14647)
@@ -1,234 +1,234 @@
-<!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 and physical bitstream overview</h1>
-
-<h2>Ogg bitstreams</h2>
-
-<p>Ogg codecs use octet vectors of raw, compressed data
-(<em>packets</em>). These compressed packets do not have any
-high-level structure or boundary information; strung together, they
-appear to be streams of random bytes with no landmarks.</p>
-
-<p>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 and other future Ogg codecs use
-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>Logical and physical bitstreams</h2>
-
-<p>Raw packets are grouped and encoded into contiguous pages of
-structured bitstream data called <em>logical bitstreams</em>. A
-logical bitstream consists of pages, in order, belonging to a single
-codec instance. Each page is a self contained entity (although it is
-possible that a packet may be split and encoded across one or more
-pages); that is, the page decode mechanism is designed to recognize,
-verify and handle single pages at a time from the overall bitstream.</p>
-
-<p>Multiple logical bitstreams can be combined (with restrictions) into a
-single <em>physical bitstream</em>. A physical bitstream consists of
-multiple logical bitstreams multiplexed at the page level and may
-include a 'meta-header' at the beginning of the multiplexed logical
-stream that serves as identification magic. Whole pages are taken in
-order from multiple logical bitstreams and combined into a single
-physical stream of pages. The decoder reconstructs the original
-logical bitstreams from the physical bitstream by taking the pages in
-order from the physical bitstream and redirecting them into the
-appropriate logical decoding entity. The simplest physical bitstream
-is a single, unmultiplexed logical bitstream with no meta-header; this
-is referred to as a 'degenerate stream'.</p>
-
-<p><a href="framing.html">Ogg Logical Bitstream Framing</a> discusses
-the page format of an Ogg bitstream, the packet coding process
-and logical bitstreams in detail. The remainder of this document
-specifies requirements for constructing finished, physical Ogg
-bitstreams.</p>
-
-<h2>Mapping Restrictions</h2>
-
-<p>Logical bitstreams may not be mapped/multiplexed into physical
-bitstreams without restriction. Here we discuss design restrictions
-on Ogg physical bitstreams in general, mostly to introduce
-design rationale. Each 'media' format defines its own (generally more
-restrictive) mapping. An 'Ogg Vorbis Audio Bitstream', for example, has a
-specific physical bitstream structure.
-An 'Ogg A/V' bitstream (not currently specified) will also mandate a
-specific, restricted physical bitstream format.</p>
-
-<h3>additional end-to-end structure</h3>
-
-<p>The <a href="framing.html">framing specification</a> defines
-'beginning of stream' and 'end of stream' page markers via a header
-flag (it is possible for a stream to consist of a single page). A
-stream always consists of an integer number of pages, an easy
-requirement given the variable size nature of pages.</p>
-
-<p>In addition to the header flag marking the first and last pages of a
-logical bitstream, the first page of an Ogg bitstream obeys
-additional restrictions. Each individual media mapping specifies its
-own implementation details regarding these restrictions.</p>
-
-<p>The first page of a logical Ogg bitstream consists of a single,
-small 'initial header' packet that includes sufficient information to
-identify the exact CODEC type and media requirements of the logical
-bitstream. The intent of this restriction is to simplify identifying
-the bitstream type and content; for a given media type (or across all
-Ogg media types) we can know that we only need a small, fixed
-amount of data to uniquely identify the bitstream type.</p>
-
-<p>As an example, Ogg Vorbis places the name and revision of the Vorbis
-CODEC, the audio rate and the audio quality into this initial header,
-thus simplifying vastly the certain identification of an Ogg Vorbis
-audio bitstream.</p>
-
-<h3>sequential multiplexing (chaining)</h3>
-
-<p>The simplest form of logical bitstream multiplexing is concatenation
-(<em>chaining</em>). Complete logical bitstreams are strung
-one-after-another in order. The bitstreams do not overlap; the final
-page of a given logical bitstream is immediately followed by the
-initial page of the next. Chaining is the only logical->physical
-mapping allowed by Ogg Vorbis.</p>
-
-<p>Each chained logical bitstream must have a unique serial number within
-the scope of the physical bitstream.</p>
-
-<h3>concurrent multiplexing (grouping)</h3>
-
-<p>Logical bitstreams may also be multiplexed 'in parallel'
-(<em>grouped</em>). An example of grouping would be to allow
-streaming of separate audio and video streams, using different codecs
-and different logical bitstreams, in the same physical bitstream.
-Whole pages from multiple logical bitstreams are mixed together.</p>
-
-<p>The initial pages of each logical bitstream must appear first; the
-media mapping specifies the order of the initial pages. For example,
-Ogg A/V will eventually specify an Ogg video bitstream with
-audio. The mapping may specify that the physical bitstream must begin
-with the initial page of a logical video bitstream, followed by the
-initial page of an audio stream. Unlike initial pages, terminal pages
-for the logical bitstreams need not all occur contiguously (although a
-specific media mapping may require this; it is not mandated by the
-generic Ogg stream spec). Terminal pages may be 'nil' pages,
-that is, pages containing no content but simply a page header with
-position information and the 'last page of bitstream' flag set in the
-page header.</p>
-
-<p>Each grouped bitstream must have a unique serial number within the
-scope of the physical bitstream.</p>
-
-<h3>sequential and concurrent multiplexing</h3>
-
-<p>Groups of concurrently multiplexed bitstreams may be chained
-consecutively. Such a physical bitstream obeys all the rules of both
-grouped and chained multiplexed streams; the groups, when unchained ,
-must stand on their own as a valid concurrently multiplexed
-bitstream.</p>
-
-<h3>multiplexing example</h3>
-
-<p>Below, we present an example of a grouped and chained bitstream:</p>
-
-<p><img src="stream.png" alt="stream"/></p>
-
-<p>In this example, we see pages from five total logical bitstreams
-multiplexed into a physical bitstream. Note the following
-characteristics:</p>
-
-<ol>
-<li>Grouped bitstreams begin together; all of the initial pages
-must appear before any data pages. When concurrently multiplexed
-groups are chained, the new group does not begin until all the
-bitstreams in the previous group have terminated.</li>
-
-<li>The pages of concurrently multiplexed bitstreams need not conform
-to a regular order; the only requirement is that page <tt>n</tt> of a
-logical bitstream follow page <tt>n-1</tt> in the physical bitstream.
-There are no restrictions on intervening pages belonging to other
-logical bitstreams. (Tying page appearance to bitrate demands is one
-logical strategy, ie, the page appears at the chronological point
-where decode requires more information).</li>
-</ol>
-
-<div id="copyright">
- The Xiph Fish Logo is a
- trademark (™) of Xiph.Org.<br/>
-
- These pages © 1994 - 2005 Xiph.Org. All rights reserved.
-</div>
-
-</body>
-</html>
+<!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 and physical bitstream overview</h1>
+
+<h2>Ogg bitstreams</h2>
+
+<p>Ogg codecs use octet vectors of raw, compressed data
+(<em>packets</em>). These compressed packets do not have any
+high-level structure or boundary information; strung together, they
+appear to be streams of random bytes with no landmarks.</p>
+
+<p>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 and other future Ogg codecs use
+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>Logical and physical bitstreams</h2>
+
+<p>Raw packets are grouped and encoded into contiguous pages of
+structured bitstream data called <em>logical bitstreams</em>. A
+logical bitstream consists of pages, in order, belonging to a single
+codec instance. Each page is a self contained entity (although it is
+possible that a packet may be split and encoded across one or more
+pages); that is, the page decode mechanism is designed to recognize,
+verify and handle single pages at a time from the overall bitstream.</p>
+
+<p>Multiple logical bitstreams can be combined (with restrictions) into a
+single <em>physical bitstream</em>. A physical bitstream consists of
+multiple logical bitstreams multiplexed at the page level and may
+include a 'meta-header' at the beginning of the multiplexed logical
+stream that serves as identification magic. Whole pages are taken in
+order from multiple logical bitstreams and combined into a single
+physical stream of pages. The decoder reconstructs the original
+logical bitstreams from the physical bitstream by taking the pages in
+order from the physical bitstream and redirecting them into the
+appropriate logical decoding entity. The simplest physical bitstream
+is a single, unmultiplexed logical bitstream with no meta-header; this
+is referred to as a 'degenerate stream'.</p>
+
+<p><a href="framing.html">Ogg Logical Bitstream Framing</a> discusses
+the page format of an Ogg bitstream, the packet coding process
+and logical bitstreams in detail. The remainder of this document
+specifies requirements for constructing finished, physical Ogg
+bitstreams.</p>
+
+<h2>Mapping Restrictions</h2>
+
+<p>Logical bitstreams may not be mapped/multiplexed into physical
+bitstreams without restriction. Here we discuss design restrictions
+on Ogg physical bitstreams in general, mostly to introduce
+design rationale. Each 'media' format defines its own (generally more
+restrictive) mapping. An 'Ogg Vorbis Audio Bitstream', for example, has a
+specific physical bitstream structure.
+An 'Ogg A/V' bitstream (not currently specified) will also mandate a
+specific, restricted physical bitstream format.</p>
+
+<h3>additional end-to-end structure</h3>
+
+<p>The <a href="framing.html">framing specification</a> defines
+'beginning of stream' and 'end of stream' page markers via a header
+flag (it is possible for a stream to consist of a single page). A
+stream always consists of an integer number of pages, an easy
+requirement given the variable size nature of pages.</p>
+
+<p>In addition to the header flag marking the first and last pages of a
+logical bitstream, the first page of an Ogg bitstream obeys
+additional restrictions. Each individual media mapping specifies its
+own implementation details regarding these restrictions.</p>
+
+<p>The first page of a logical Ogg bitstream consists of a single,
+small 'initial header' packet that includes sufficient information to
+identify the exact CODEC type and media requirements of the logical
+bitstream. The intent of this restriction is to simplify identifying
+the bitstream type and content; for a given media type (or across all
+Ogg media types) we can know that we only need a small, fixed
+amount of data to uniquely identify the bitstream type.</p>
+
+<p>As an example, Ogg Vorbis places the name and revision of the Vorbis
+CODEC, the audio rate and the audio quality into this initial header,
+thus simplifying vastly the certain identification of an Ogg Vorbis
+audio bitstream.</p>
+
+<h3>sequential multiplexing (chaining)</h3>
+
+<p>The simplest form of logical bitstream multiplexing is concatenation
+(<em>chaining</em>). Complete logical bitstreams are strung
+one-after-another in order. The bitstreams do not overlap; the final
+page of a given logical bitstream is immediately followed by the
+initial page of the next. Chaining is the only logical->physical
+mapping allowed by Ogg Vorbis.</p>
+
+<p>Each chained logical bitstream must have a unique serial number within
+the scope of the physical bitstream.</p>
+
+<h3>concurrent multiplexing (grouping)</h3>
+
+<p>Logical bitstreams may also be multiplexed 'in parallel'
+(<em>grouped</em>). An example of grouping would be to allow
+streaming of separate audio and video streams, using different codecs
+and different logical bitstreams, in the same physical bitstream.
+Whole pages from multiple logical bitstreams are mixed together.</p>
+
+<p>The initial pages of each logical bitstream must appear first; the
+media mapping specifies the order of the initial pages. For example,
+Ogg A/V will eventually specify an Ogg video bitstream with
+audio. The mapping may specify that the physical bitstream must begin
+with the initial page of a logical video bitstream, followed by the
+initial page of an audio stream. Unlike initial pages, terminal pages
+for the logical bitstreams need not all occur contiguously (although a
+specific media mapping may require this; it is not mandated by the
+generic Ogg stream spec). Terminal pages may be 'nil' pages,
+that is, pages containing no content but simply a page header with
+position information and the 'last page of bitstream' flag set in the
+page header.</p>
+
+<p>Each grouped bitstream must have a unique serial number within the
+scope of the physical bitstream.</p>
+
+<h3>sequential and concurrent multiplexing</h3>
+
+<p>Groups of concurrently multiplexed bitstreams may be chained
+consecutively. Such a physical bitstream obeys all the rules of both
+grouped and chained multiplexed streams; the groups, when unchained ,
+must stand on their own as a valid concurrently multiplexed
+bitstream.</p>
+
+<h3>multiplexing example</h3>
+
+<p>Below, we present an example of a grouped and chained bitstream:</p>
+
+<p><img src="stream.png" alt="stream"/></p>
+
+<p>In this example, we see pages from five total logical bitstreams
+multiplexed into a physical bitstream. Note the following
+characteristics:</p>
+
+<ol>
+<li>Grouped bitstreams begin together; all of the initial pages
+must appear before any data pages. When concurrently multiplexed
+groups are chained, the new group does not begin until all the
+bitstreams in the previous group have terminated.</li>
+
+<li>The pages of concurrently multiplexed bitstreams need not conform
+to a regular order; the only requirement is that page <tt>n</tt> of a
+logical bitstream follow page <tt>n-1</tt> in the physical bitstream.
+There are no restrictions on intervening pages belonging to other
+logical bitstreams. (Tying page appearance to bitrate demands is one
+logical strategy, ie, the page appears at the chronological point
+where decode requires more information).</li>
+</ol>
+
+<div id="copyright">
+ The Xiph Fish Logo is a
+ trademark (™) of Xiph.Org.<br/>
+
+ These pages © 1994 - 2005 Xiph.Org. All rights reserved.
+</div>
+
+</body>
+</html>
Modified: branches/vorbis-aotuv/doc/programming.html
===================================================================
--- branches/vorbis-aotuv/doc/programming.html 2008-03-31 15:23:02 UTC (rev 14646)
+++ branches/vorbis-aotuv/doc/programming.html 2008-04-01 10:47:58 UTC (rev 14647)
@@ -1,554 +1,554 @@
-<!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>Programming with Xiph.org <tt>libvorbis</tt></h1>
-
-<h2>Description</h2>
-
-<p>Libvorbis is the Xiph.org Foundation's portable Ogg Vorbis CODEC
-implemented as a programmatic library. Libvorbis provides primitives
-to handle framing and manipulation of Ogg bitstreams (used by the
-Vorbis for streaming), a full analysis (encoding) interface as well as
-packet decoding and synthesis for playback.</p>
-
-<p>The libvorbis library does not provide any system interface; a
-full-featured demonstration player included with the library
-distribtion provides example code for a variety of system interfaces
-as well as a working example of using libvorbis in production code.</p>
-
-<h2>Encoding Overview</h2>
-
-<h2>Decoding Overview</h2>
-
-<p>Decoding a bitstream with libvorbis follows roughly the following
-steps:</p>
-
-<ol>
-<li>Frame the incoming bitstream into pages</li>
-<li>Sort the pages by logical bitstream and buffer then into logical streams</li>
-<li>Decompose the logical streams into raw packets</li>
-<li>Reconstruct segments of the original data from each packet</li>
-<li>Glue the reconstructed segments back into a decoded stream</li>
-</ol>
-
-<h3>Framing</h3>
-
-<p>An Ogg bitstream is logically arranged into pages, but to decode
-the pages, we have to find them first. The raw bitstream is first fed
-into an <tt>ogg_sync_state</tt> buffer using <tt>ogg_sync_buffer()</tt>
-and <tt>ogg_sync_wrote()</tt>. After each block we submit to the sync
-buffer, we should check to see if we can frame and extract a complete
-page or pages using <tt>ogg_sync_pageout()</tt>. Extra pages are
-buffered; allowing them to build up in the <tt>ogg_sync_state</tt>
-buffer will eventually exhaust memory.</p>
-
-<p>The Ogg pages returned from <tt>ogg_sync_pageout</tt> need not be
-decoded further to be used as landmarks in seeking; seeking can be
-either a rough process of simply jumping to approximately intuited
-portions of the bitstream, or it can be a precise bisection process
-that captures pages and inspects data position. When seeking,
-however, sequential multiplexing (chaining) must be accounted for;
-beginning play in a new logical bitstream requires initializing a
-synthesis engine with the headers from that bitstream. Vorbis
-bitstreams do not make use of concurent multiplexing (grouping).</p>
-
-<h3>Sorting</h3>
-
-<p>The pages produced by <tt>ogg_sync_pageout</tt> are then sorted by
-serial number to seperate logical bitstreams. Initialize logical
-bitstream buffers (<tt>og_stream_state</tt>) using
-<tt>ogg_stream_init()</tt>. Pages are submitted to the matching
-logical bitstream buffer using <tt>ogg_stream_pagein</tt>; the serial
-number of the page and the stream buffer must match, or the page will
-be rejected. A page submitted out of sequence will simply be noted,
-and in the course of outputting packets, the hole will be flagged
-(<tt>ogg_sync_pageout</tt> and <tt>ogg_stream_packetout</tt> will
-return a negative value at positions where they had to recapture the
-stream).</p>
-
-<h3>Extracting packets</h3>
-
-<p>After submitting page[s] to a logical stream, read available packets
-using <tt>ogg_stream_packetout</tt>.</p>
-
-<h3>Decoding packets</h3>
-
-<h3>Reassembling data segments</h3>
-
-<h2>Ogg Bitstream Manipulation Structures</h2>
-
-<p>Two of the Ogg bitstream data structures are intended to be
-transparent to the developer; the fields should be used directly.</p>
-
-<h3>ogg_packet</h3>
-
-<pre>
-typedef struct {
- unsigned char *packet;
- long bytes;
- long b_o_s;
- long e_o_s;
-
- size64 granulepos;
-
-} ogg_packet;
-</pre>
-
-<dl>
-<dt>packet:</dt>
-<dd>a pointer to the byte data of the raw packet</dd>
-<dt>bytes:</dt>
-<dd>the size of the packet' raw data</dd>
-<dt>b_o_s:</dt>
-<dd>beginning of stream; nonzero if this is the first packet of
- the logical bitstream</dd>
-<dt>e_o_s:</dt>
-<dd>end of stream; nonzero if this is the last packet of the
- logical bitstream</dd>
-<dt>granulepos:</dt>
-<dd>the absolute position of this packet in the original
- uncompressed data stream.</dd>
-</dl>
-
-<h4>encoding notes</h4>
-
-<p>The encoder is responsible for setting all of
-the fields of the packet to appropriate values before submission to
-<tt>ogg_stream_packetin()</tt>; however, it is noted that the value in
-<tt>b_o_s</tt> is ignored; the first page produced from a given
-<tt>ogg_stream_state</tt> structure will be stamped as the initial
-page. <tt>e_o_s</tt>, however, must be set; this is the means by
-which the stream encoding primitives handle end of stream and cleanup.</p>
-
-<h4>decoding notes</h4>
-
-<p><tt>ogg_stream_packetout()</tt> sets the fields
-to appropriate values. Note that granulepos will be >= 0 only in the
-case that the given packet actually represents that position (ie, only
-the last packet completed on any page will have a meaningful
-<tt>granulepos</tt>). Intervening frames will see <tt>granulepos</tt> set
-to -1.</p>
-
-<h3>ogg_page</h3>
-
-<pre>
-typedef struct {
- unsigned char *header;
- long header_len;
- unsigned char *body;
- long body_len;
-} ogg_page;
-</pre>
-
-<dl>
-<dt>header:</dt>
-<dd>pointer to the page header data</dd>
-<dt>header_len:</dt>
-<dd>length of the page header in bytes</dd>
-<dt>body:</dt>
-<dd>pointer to the page body</dd>
-<dt>body_len:</dt>
-<dd>length of the page body</dd>
-</dl>
-
-<p>Note that although the <tt>header</tt> and <tt>body</tt> pointers do
-not necessarily point into a single contiguous page vector, the page
-body must immediately follow the header in the bitstream.</p>
-
-<h2>Ogg Bitstream Manipulation Functions</h2>
-
-<h3>
-int ogg_page_bos(ogg_page *og);
-</h3>
-
-<p>Returns the 'beginning of stream' flag for the given Ogg page. The
-beginning of stream flag is set on the initial page of a logical
-bitstream.</p>
-
-<p>Zero indicates the flag is cleared (this is not the initial page of a
-logical bitstream). Nonzero indicates the flag is set (this is the
-initial page of a logical bitstream).</p>
-
-<h3>
-int ogg_page_continued(ogg_page *og);
-</h3>
-
-<p>Returns the 'packet continued' flag for the given Ogg page. The packet
-continued flag indicates whether or not the body data of this page
-begins with packet continued from a preceeding page.</p>
-
-<p>Zero (unset) indicates that the body data begins with a new packet.
-Nonzero (set) indicates that the first packet data on the page is a
-continuation from the preceeding page.</p>
-
-<h3>
-int ogg_page_eos(ogg_page *og);
-</h3>
-
-<p>Returns the 'end of stream' flag for a give Ogg page. The end of page
-flag is set on the last (terminal) page of a logical bitstream.</p>
-
-<p>Zero (unset) indicates that this is not the last page of a logical
-bitstream. Nonzero (set) indicates that this is the last page of a
-logical bitstream and that no addiitonal pages belonging to this
-bitstream may follow.</p>
-
-<h3>
-size64 ogg_page_granulepos(ogg_page *og);
-</h3>
-
-<p>Returns the position of this page as an absolute position within the
-original uncompressed data. The position, as returned, is 'frames
-encoded to date up to and including the last whole packet on this
-page'. Partial packets begun on this page but continued to the
-following page are not included. If no packet ends on this page, the
-frame position value will be equal to the frame position value of the
-preceeding page. If none of the original uncompressed data is yet
-represented in the logical bitstream (for example, the first page of a
-bitstream consists only of a header packet; this packet encodes only
-metadata), the value shall be zero.</p>
-
-<p>The units of the framenumber are determined by media mapping. A
-vorbis audio bitstream, for example, defines one frame to be the
-channel values from a single sampling period (eg, a 16 bit stereo
-bitstream consists of two samples of two bytes for a total of four
-bytes, thus a frame would be four bytes). A video stream defines one
-frame to be a single frame of video.</p>
-
-<h3>
-int ogg_page_pageno(ogg_page *og);
-</h3>
-
-<p>Returns the sequential page number of the given Ogg page. The first
-page in a logical bitstream is numbered zero; following pages are
-numbered in increasing monotonic order.</p>
-
-<h3>
-int ogg_page_serialno(ogg_page *og);
-</h3>
-
-<p>Returns the serial number of the given Ogg page. The serial number is
-used as a handle to distinguish various logical bitstreams in a
-physical Ogg bitstresm. Every logical bitstream within a
-physical bitstream must use a unique (within the scope of the physical
-bitstream) serial number, which is stamped on all bitstream pages.</p>
-
-<h3>
-int ogg_page_version(ogg_page *og);
-</h3>
-
-<p>Returns the revision of the Ogg bitstream structure of the given page.
-Currently, the only permitted number is zero. Later revisions of the
-bitstream spec will increment this version should any changes be
-incompatable.</p>
-
-<h3>
-int ogg_stream_clear(ogg_stream_state *os);
-</h3>
-
-<p>Clears and deallocates the internal storage of the given Ogg stream.
-After clearing, the stream structure is not initialized for use;
-<tt>ogg_stream_init</tt> must be called to reinitialize for use.
-Use <tt>ogg_stream_reset</tt> to reset the stream state
-to a fresh, intiialized state.</p>
-
-<p><tt>ogg_stream_clear</tt> does not call <tt>free()</tt> on the pointer
-<tt>os</tt>, allowing use of this call on stream structures in static
-or automatic storage. <tt>ogg_stream_destroy</tt>is a complimentary
-function that frees the pointer as well.</p>
-
-<p>Returns zero on success and non-zero on failure. This function always
-succeeds.</p>
-
-<h3>
-int ogg_stream_destroy(ogg_stream_state *os);
-</h3>
-
-<p>Clears and deallocates the internal storage of the given Ogg stream,
-then frees the storage associated with the pointer <tt>os</tt>.</p>
-
-<p><tt>ogg_stream_clear</tt> does not call <tt>free()</tt> on the pointer
-<tt>os</tt>, allowing use of that call on stream structures in static
-or automatic storage.</p>
-
-<p>Returns zero on success and non-zero on failure. This function always
-succeeds.</p>
-
-<h3>
-int ogg_stream_init(ogg_stream_state *os,int serialno);
-</h3>
-
-<p>Initialize the storage associated with <tt>os</tt> for use as an Ogg
-stream. This call is used to initialize a stream for both encode and
-decode. The given serial number is the serial number that will be
-stamped on pages of the produced bitstream (during encode), or used as
-a check that pages match (during decode).</p>
-
-<p>Returns zero on success, nonzero on failure.</p>
-
-<h3>
-int ogg_stream_packetin(ogg_stream_state *os, ogg_packet *op);
-</h3>
-
-<p>Used during encoding to add the given raw packet to the given Ogg
-bitstream. The contents of <tt>op</tt> are copied;
-<tt>ogg_stream_packetin</tt> does not retain any pointers into
-<tt>op</tt>'s storage. The encoding proccess buffers incoming packets
-until enough packets have been assembled to form an entire page;
-<tt>ogg_stream_pageout</tt> is used to read complete pages.</p>
-
-<p>Returns zero on success, nonzero on failure.</p>
-
-<h3>
-int ogg_stream_packetout(ogg_stream_state *os,ogg_packet *op);
-</h3>
-
-<p>Used during decoding to read raw packets from the given logical
-bitstream. <tt>ogg_stream_packetout</tt> will only return complete
-packets for which checksumming indicates no corruption. The size and
-contents of the packet exactly match those given in the encoding
-process. </p>
-
-<p>Returns zero if the next packet is not ready to be read (not buffered
-or incomplete), positive if it returned a complete packet in
-<tt>op</tt> and negative if there is a gap, extra bytes or corruption
-at this position in the bitstream (essentially that the bitstream had
-to be recaptured). A negative value is not necessarily an error. It
-would be a common occurence when seeking, for example, which requires
-recapture of the bitstream at the position decoding continued.</p>
-
-<p>If the return value is positive, <tt>ogg_stream_packetout</tt> placed
-a packet in <tt>op</tt>. The data in <tt>op</tt> points to static
-storage that is valid until the next call to
-<tt>ogg_stream_pagein</tt>, <tt>ogg_stream_clear</tt>,
-<tt>ogg_stream_reset</tt>, or <tt>ogg_stream_destroy</tt>. The
-pointers are not invalidated by more calls to
-<tt>ogg_stream_packetout</tt>.</p>
-
-<h3>
-int ogg_stream_pagein(ogg_stream_state *os, ogg_page *og);
-</h3>
-
-<p>Used during decoding to buffer the given complete, pre-verified page
-for decoding into raw Ogg packets. The given page must be framed,
-normally produced by <tt>ogg_sync_pageout</tt>, and from the logical
-bitstream associated with <tt>os</tt> (the serial numbers must match).
-The contents of the given page are copied; <tt>ogg_stream_pagein</tt>
-retains no pointers into <tt>og</tt> storage.</p>
-
-<p>Returns zero on success and non-zero on failure.</p>
-
-<h3>
-int ogg_stream_pageout(ogg_stream_state *os, ogg_page *og);
-</h3>
-
-<p>Used during encode to read complete pages from the stream buffer. The
-returned page is ready for sending out to the real world.</p>
-
-<p>Returns zero if there is no complete page ready for reading. Returns
-nonzero when it has placed data for a complete page into
-<tt>og</tt>. Note that the storage returned in og points into internal
-storage; the pointers in <tt>og</tt> are valid until the next call to
-<tt>ogg_stream_pageout</tt>, <tt>ogg_stream_packetin</tt>,
-<tt>ogg_stream_reset</tt>, <tt>ogg_stream_clear</tt> or
-<tt>ogg_stream_destroy</tt>.</p>
-
-<h3>
-int ogg_stream_reset(ogg_stream_state *os);
-</h3>
-
-<p>Resets the given stream's state to that of a blank, unused stream;
-this may be used during encode or decode.</p>
-
-<p>Note that if used during encode, it does not alter the stream's serial
-number. In addition, the next page produced during encoding will be
-marked as the 'initial' page of the logical bitstream.</p>
-
-<p>When used during decode, this simply clears the data buffer of any
-pending pages. Beginning and end of stream cues are read from the
-bitstream and are unaffected by reset.</p>
-
-<p>Returns zero on success and non-zero on failure. This function always
-succeeds.</p>
-
-<h3>
-char *ogg_sync_buffer(ogg_sync_state *oy, long size);
-</h3>
-
-<p>This call is used to buffer a raw bitstream for framing and
-verification. <tt>ogg_sync_buffer</tt> handles stream capture and
-recapture, checksumming, and division into Ogg pages (as required by
-<tt>ogg_stream_pagein</tt>).</p>
-
-<p><tt>ogg_sync_buffer</tt> exposes a buffer area into which the decoder
-copies the next (up to) <tt>size</tt> bytes. We expose the buffer
-(rather than taking a buffer) in order to avoid an extra copy many
-uses; this way, for example, <tt>read()</tt> can transfer data
-directly into the stream buffer without first needing to place it in
-temporary storage.</p>
-
-<p>Returns a pointer into <tt>oy</tt>'s internal bitstream sync buffer;
-the remaining space in the sync buffer is at least <tt>size</tt>
-bytes. The decoder need not write all of <tt>size</tt> bytes;
-<tt>ogg_sync_wrote</tt> is used to inform the engine how many bytes
-were actually written. Use of <tt>ogg_sync_wrote</tt> after writing
-into the exposed buffer is mandantory.</p>
-
-<h3>
-int ogg_sync_clear(ogg_sync_state *oy);
-</h3>
-
-<p><tt>ogg_sync_clear</tt>
-clears and deallocates the internal storage of the given Ogg sync
-buffer. After clearing, the sync structure is not initialized for
-use; <tt>ogg_sync_init</tt> must be called to reinitialize for use.
-Use <tt>ogg_sync_reset</tt> to reset the sync state and buffer to a
-fresh, intiialized state.</p>
-
-<p><tt>ogg_sync_clear</tt> does not call <tt>free()</tt> on the pointer
-<tt>oy</tt>, allowing use of this call on sync structures in static
-or automatic storage. <tt>ogg_sync_destroy</tt>is a complimentary
-function that frees the pointer as well.</p>
-
-<p>Returns zero on success and non-zero on failure. This function always
-succeeds.</p>
-
-<h3>
-int ogg_sync_destroy(ogg_sync_state *oy);
-</h3>
-
-<p>Clears and deallocates the internal storage of the given Ogg sync
-buffer, then frees the storage associated with the pointer
-<tt>oy</tt>.</p>
-
-<p><tt>ogg_sync_clear</tt> does not call <tt>free()</tt> on the pointer
-<tt>oy</tt>, allowing use of that call on stream structures in static
-or automatic storage.</p>
-
-<p>Returns zero on success and non-zero on failure. This function always
-succeeds.</p>
-
-<h3>
-int ogg_sync_init(ogg_sync_state *oy);
-</h3>
-
-<p>Initializes the sync buffer <tt>oy</tt> for use.</p>
-
-<p>Returns zero on success and non-zero on failure. This function always
-succeeds.</p>
-
-<h3>
-int ogg_sync_pageout(ogg_sync_state *oy, ogg_page *og);
-</h3>
-
-<p>Reads complete, framed, verified Ogg pages from the sync buffer,
-placing the page data in <tt>og</tt>.</p>
-
-<p>Returns zero when there's no complete pages buffered for
-retrieval. Returns negative when a loss of sync or recapture occurred
-(this is not necessarily an error; recapture would be required after
-seeking, for example). Returns positive when a page is returned in
-<tt>og</tt>. Note that the data in <tt>og</tt> points into the sync
-buffer storage; the pointers are valid until the next call to
-<tt>ogg_sync_buffer</tt>, <tt>ogg_sync_clear</tt>,
-<tt>ogg_sync_destroy</tt> or <tt>ogg_sync_reset</tt>.</p>
-
-<h3>
-int ogg_sync_reset(ogg_sync_state *oy);
-</h3>
-
-<p><tt>ogg_sync_reset</tt> resets the sync state in <tt>oy</tt> to a
-clean, empty state. This is useful, for example, when seeking to a
-new location in a bitstream.</p>
-
-<p>Returns zero on success, nonzero on failure.</p>
-
-<h3>
-int ogg_sync_wrote(ogg_sync_state *oy, long bytes);
-</h3>
-
-<p>Used to inform the sync state as to how many bytes were actually
-written into the exposed sync buffer. It must be equal to or less
-than the size of the buffer requested.</p>
-
-<p>Returns zero on success and non-zero on failure; failure occurs only
-when the number of bytes written were larger than the buffer.</p>
-
-<div id="copyright">
- The Xiph Fish Logo is a
- trademark (™) of Xiph.Org.<br/>
-
- These pages © 1994 - 2005 Xiph.Org. All rights reserved.
-</div>
-
-</body>
-</html>
+<!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>Programming with Xiph.org <tt>libvorbis</tt></h1>
+
+<h2>Description</h2>
+
+<p>Libvorbis is the Xiph.org Foundation's portable Ogg Vorbis CODEC
+implemented as a programmatic library. Libvorbis provides primitives
+to handle framing and manipulation of Ogg bitstreams (used by the
+Vorbis for streaming), a full analysis (encoding) interface as well as
+packet decoding and synthesis for playback.</p>
+
+<p>The libvorbis library does not provide any system interface; a
+full-featured demonstration player included with the library
+distribtion provides example code for a variety of system interfaces
+as well as a working example of using libvorbis in production code.</p>
+
+<h2>Encoding Overview</h2>
+
+<h2>Decoding Overview</h2>
+
+<p>Decoding a bitstream with libvorbis follows roughly the following
+steps:</p>
+
+<ol>
+<li>Frame the incoming bitstream into pages</li>
+<li>Sort the pages by logical bitstream and buffer then into logical streams</li>
+<li>Decompose the logical streams into raw packets</li>
+<li>Reconstruct segments of the original data from each packet</li>
+<li>Glue the reconstructed segments back into a decoded stream</li>
+</ol>
+
+<h3>Framing</h3>
+
+<p>An Ogg bitstream is logically arranged into pages, but to decode
+the pages, we have to find them first. The raw bitstream is first fed
+into an <tt>ogg_sync_state</tt> buffer using <tt>ogg_sync_buffer()</tt>
+and <tt>ogg_sync_wrote()</tt>. After each block we submit to the sync
+buffer, we should check to see if we can frame and extract a complete
+page or pages using <tt>ogg_sync_pageout()</tt>. Extra pages are
+buffered; allowing them to build up in the <tt>ogg_sync_state</tt>
+buffer will eventually exhaust memory.</p>
+
+<p>The Ogg pages returned from <tt>ogg_sync_pageout</tt> need not be
+decoded further to be used as landmarks in seeking; seeking can be
+either a rough process of simply jumping to approximately intuited
+portions of the bitstream, or it can be a precise bisection process
+that captures pages and inspects data position. When seeking,
+however, sequential multiplexing (chaining) must be accounted for;
+beginning play in a new logical bitstream requires initializing a
+synthesis engine with the headers from that bitstream. Vorbis
+bitstreams do not make use of concurent multiplexing (grouping).</p>
+
+<h3>Sorting</h3>
+
+<p>The pages produced by <tt>ogg_sync_pageout</tt> are then sorted by
+serial number to seperate logical bitstreams. Initialize logical
+bitstream buffers (<tt>og_stream_state</tt>) using
+<tt>ogg_stream_init()</tt>. Pages are submitted to the matching
+logical bitstream buffer using <tt>ogg_stream_pagein</tt>; the serial
+number of the page and the stream buffer must match, or the page will
+be rejected. A page submitted out of sequence will simply be noted,
+and in the course of outputting packets, the hole will be flagged
+(<tt>ogg_sync_pageout</tt> and <tt>ogg_stream_packetout</tt> will
+return a negative value at positions where they had to recapture the
+stream).</p>
+
+<h3>Extracting packets</h3>
+
+<p>After submitting page[s] to a logical stream, read available packets
+using <tt>ogg_stream_packetout</tt>.</p>
+
+<h3>Decoding packets</h3>
+
+<h3>Reassembling data segments</h3>
+
+<h2>Ogg Bitstream Manipulation Structures</h2>
+
+<p>Two of the Ogg bitstream data structures are intended to be
+transparent to the developer; the fields should be used directly.</p>
+
+<h3>ogg_packet</h3>
+
+<pre>
+typedef struct {
+ unsigned char *packet;
+ long bytes;
+ long b_o_s;
+ long e_o_s;
+
+ size64 granulepos;
+
+} ogg_packet;
+</pre>
+
+<dl>
+<dt>packet:</dt>
+<dd>a pointer to the byte data of the raw packet</dd>
+<dt>bytes:</dt>
+<dd>the size of the packet' raw data</dd>
+<dt>b_o_s:</dt>
+<dd>beginning of stream; nonzero if this is the first packet of
+ the logical bitstream</dd>
+<dt>e_o_s:</dt>
+<dd>end of stream; nonzero if this is the last packet of the
+ logical bitstream</dd>
+<dt>granulepos:</dt>
+<dd>the absolute position of this packet in the original
+ uncompressed data stream.</dd>
+</dl>
+
+<h4>encoding notes</h4>
+
+<p>The encoder is responsible for setting all of
+the fields of the packet to appropriate values before submission to
+<tt>ogg_stream_packetin()</tt>; however, it is noted that the value in
+<tt>b_o_s</tt> is ignored; the first page produced from a given
+<tt>ogg_stream_state</tt> structure will be stamped as the initial
+page. <tt>e_o_s</tt>, however, must be set; this is the means by
+which the stream encoding primitives handle end of stream and cleanup.</p>
+
+<h4>decoding notes</h4>
+
+<p><tt>ogg_stream_packetout()</tt> sets the fields
+to appropriate values. Note that granulepos will be >= 0 only in the
+case that the given packet actually represents that position (ie, only
+the last packet completed on any page will have a meaningful
+<tt>granulepos</tt>). Intervening frames will see <tt>granulepos</tt> set
+to -1.</p>
+
+<h3>ogg_page</h3>
+
+<pre>
+typedef struct {
+ unsigned char *header;
+ long header_len;
+ unsigned char *body;
+ long body_len;
+} ogg_page;
+</pre>
+
+<dl>
+<dt>header:</dt>
+<dd>pointer to the page header data</dd>
+<dt>header_len:</dt>
+<dd>length of the page header in bytes</dd>
+<dt>body:</dt>
+<dd>pointer to the page body</dd>
+<dt>body_len:</dt>
+<dd>length of the page body</dd>
+</dl>
+
+<p>Note that although the <tt>header</tt> and <tt>body</tt> pointers do
+not necessarily point into a single contiguous page vector, the page
+body must immediately follow the header in the bitstream.</p>
+
+<h2>Ogg Bitstream Manipulation Functions</h2>
+
+<h3>
+int ogg_page_bos(ogg_page *og);
+</h3>
+
+<p>Returns the 'beginning of stream' flag for the given Ogg page. The
+beginning of stream flag is set on the initial page of a logical
+bitstream.</p>
+
+<p>Zero indicates the flag is cleared (this is not the initial page of a
+logical bitstream). Nonzero indicates the flag is set (this is the
+initial page of a logical bitstream).</p>
+
+<h3>
+int ogg_page_continued(ogg_page *og);
+</h3>
+
+<p>Returns the 'packet continued' flag for the given Ogg page. The packet
+continued flag indicates whether or not the body data of this page
+begins with packet continued from a preceeding page.</p>
+
+<p>Zero (unset) indicates that the body data begins with a new packet.
+Nonzero (set) indicates that the first packet data on the page is a
+continuation from the preceeding page.</p>
+
+<h3>
+int ogg_page_eos(ogg_page *og);
+</h3>
+
+<p>Returns the 'end of stream' flag for a give Ogg page. The end of page
+flag is set on the last (terminal) page of a logical bitstream.</p>
+
+<p>Zero (unset) indicates that this is not the last page of a logical
+bitstream. Nonzero (set) indicates that this is the last page of a
+logical bitstream and that no addiitonal pages belonging to this
+bitstream may follow.</p>
+
+<h3>
+size64 ogg_page_granulepos(ogg_page *og);
+</h3>
+
+<p>Returns the position of this page as an absolute position within the
+original uncompressed data. The position, as returned, is 'frames
+encoded to date up to and including the last whole packet on this
+page'. Partial packets begun on this page but continued to the
+following page are not included. If no packet ends on this page, the
+frame position value will be equal to the frame position value of the
+preceeding page. If none of the original uncompressed data is yet
+represented in the logical bitstream (for example, the first page of a
+bitstream consists only of a header packet; this packet encodes only
+metadata), the value shall be zero.</p>
+
+<p>The units of the framenumber are determined by media mapping. A
+vorbis audio bitstream, for example, defines one frame to be the
+channel values from a single sampling period (eg, a 16 bit stereo
+bitstream consists of two samples of two bytes for a total of four
+bytes, thus a frame would be four bytes). A video stream defines one
+frame to be a single frame of video.</p>
+
+<h3>
+int ogg_page_pageno(ogg_page *og);
+</h3>
+
+<p>Returns the sequential page number of the given Ogg page. The first
+page in a logical bitstream is numbered zero; following pages are
+numbered in increasing monotonic order.</p>
+
+<h3>
+int ogg_page_serialno(ogg_page *og);
+</h3>
+
+<p>Returns the serial number of the given Ogg page. The serial number is
+used as a handle to distinguish various logical bitstreams in a
+physical Ogg bitstresm. Every logical bitstream within a
+physical bitstream must use a unique (within the scope of the physical
+bitstream) serial number, which is stamped on all bitstream pages.</p>
+
+<h3>
+int ogg_page_version(ogg_page *og);
+</h3>
+
+<p>Returns the revision of the Ogg bitstream structure of the given page.
+Currently, the only permitted number is zero. Later revisions of the
+bitstream spec will increment this version should any changes be
+incompatable.</p>
+
+<h3>
+int ogg_stream_clear(ogg_stream_state *os);
+</h3>
+
+<p>Clears and deallocates the internal storage of the given Ogg stream.
+After clearing, the stream structure is not initialized for use;
+<tt>ogg_stream_init</tt> must be called to reinitialize for use.
+Use <tt>ogg_stream_reset</tt> to reset the stream state
+to a fresh, intiialized state.</p>
+
+<p><tt>ogg_stream_clear</tt> does not call <tt>free()</tt> on the pointer
+<tt>os</tt>, allowing use of this call on stream structures in static
+or automatic storage. <tt>ogg_stream_destroy</tt>is a complimentary
+function that frees the pointer as well.</p>
+
+<p>Returns zero on success and non-zero on failure. This function always
+succeeds.</p>
+
+<h3>
+int ogg_stream_destroy(ogg_stream_state *os);
+</h3>
+
+<p>Clears and deallocates the internal storage of the given Ogg stream,
+then frees the storage associated with the pointer <tt>os</tt>.</p>
+
+<p><tt>ogg_stream_clear</tt> does not call <tt>free()</tt> on the pointer
+<tt>os</tt>, allowing use of that call on stream structures in static
+or automatic storage.</p>
+
+<p>Returns zero on success and non-zero on failure. This function always
+succeeds.</p>
+
+<h3>
+int ogg_stream_init(ogg_stream_state *os,int serialno);
+</h3>
+
+<p>Initialize the storage associated with <tt>os</tt> for use as an Ogg
+stream. This call is used to initialize a stream for both encode and
+decode. The given serial number is the serial number that will be
+stamped on pages of the produced bitstream (during encode), or used as
+a check that pages match (during decode).</p>
+
+<p>Returns zero on success, nonzero on failure.</p>
+
+<h3>
+int ogg_stream_packetin(ogg_stream_state *os, ogg_packet *op);
+</h3>
+
+<p>Used during encoding to add the given raw packet to the given Ogg
+bitstream. The contents of <tt>op</tt> are copied;
+<tt>ogg_stream_packetin</tt> does not retain any pointers into
+<tt>op</tt>'s storage. The encoding proccess buffers incoming packets
+until enough packets have been assembled to form an entire page;
+<tt>ogg_stream_pageout</tt> is used to read complete pages.</p>
+
+<p>Returns zero on success, nonzero on failure.</p>
+
+<h3>
+int ogg_stream_packetout(ogg_stream_state *os,ogg_packet *op);
+</h3>
+
+<p>Used during decoding to read raw packets from the given logical
+bitstream. <tt>ogg_stream_packetout</tt> will only return complete
+packets for which checksumming indicates no corruption. The size and
+contents of the packet exactly match those given in the encoding
+process. </p>
+
+<p>Returns zero if the next packet is not ready to be read (not buffered
+or incomplete), positive if it returned a complete packet in
+<tt>op</tt> and negative if there is a gap, extra bytes or corruption
+at this position in the bitstream (essentially that the bitstream had
+to be recaptured). A negative value is not necessarily an error. It
+would be a common occurence when seeking, for example, which requires
+recapture of the bitstream at the position decoding continued.</p>
+
+<p>If the return value is positive, <tt>ogg_stream_packetout</tt> placed
+a packet in <tt>op</tt>. The data in <tt>op</tt> points to static
+storage that is valid until the next call to
+<tt>ogg_stream_pagein</tt>, <tt>ogg_stream_clear</tt>,
+<tt>ogg_stream_reset</tt>, or <tt>ogg_stream_destroy</tt>. The
+pointers are not invalidated by more calls to
+<tt>ogg_stream_packetout</tt>.</p>
+
+<h3>
+int ogg_stream_pagein(ogg_stream_state *os, ogg_page *og);
+</h3>
+
+<p>Used during decoding to buffer the given complete, pre-verified page
+for decoding into raw Ogg packets. The given page must be framed,
+normally produced by <tt>ogg_sync_pageout</tt>, and from the logical
+bitstream associated with <tt>os</tt> (the serial numbers must match).
+The contents of the given page are copied; <tt>ogg_stream_pagein</tt>
+retains no pointers into <tt>og</tt> storage.</p>
+
+<p>Returns zero on success and non-zero on failure.</p>
+
+<h3>
+int ogg_stream_pageout(ogg_stream_state *os, ogg_page *og);
+</h3>
+
+<p>Used during encode to read complete pages from the stream buffer. The
+returned page is ready for sending out to the real world.</p>
+
+<p>Returns zero if there is no complete page ready for reading. Returns
+nonzero when it has placed data for a complete page into
+<tt>og</tt>. Note that the storage returned in og points into internal
+storage; the pointers in <tt>og</tt> are valid until the next call to
+<tt>ogg_stream_pageout</tt>, <tt>ogg_stream_packetin</tt>,
+<tt>ogg_stream_reset</tt>, <tt>ogg_stream_clear</tt> or
+<tt>ogg_stream_destroy</tt>.</p>
+
+<h3>
+int ogg_stream_reset(ogg_stream_state *os);
+</h3>
+
+<p>Resets the given stream's state to that of a blank, unused stream;
+this may be used during encode or decode.</p>
+
+<p>Note that if used during encode, it does not alter the stream's serial
+number. In addition, the next page produced during encoding will be
+marked as the 'initial' page of the logical bitstream.</p>
+
+<p>When used during decode, this simply clears the data buffer of any
+pending pages. Beginning and end of stream cues are read from the
+bitstream and are unaffected by reset.</p>
+
+<p>Returns zero on success and non-zero on failure. This function always
+succeeds.</p>
+
+<h3>
+char *ogg_sync_buffer(ogg_sync_state *oy, long size);
+</h3>
+
+<p>This call is used to buffer a raw bitstream for framing and
+verification. <tt>ogg_sync_buffer</tt> handles stream capture and
+recapture, checksumming, and division into Ogg pages (as required by
+<tt>ogg_stream_pagein</tt>).</p>
+
+<p><tt>ogg_sync_buffer</tt> exposes a buffer area into which the decoder
+copies the next (up to) <tt>size</tt> bytes. We expose the buffer
+(rather than taking a buffer) in order to avoid an extra copy many
+uses; this way, for example, <tt>read()</tt> can transfer data
+directly into the stream buffer without first needing to place it in
+temporary storage.</p>
+
+<p>Returns a pointer into <tt>oy</tt>'s internal bitstream sync buffer;
+the remaining space in the sync buffer is at least <tt>size</tt>
+bytes. The decoder need not write all of <tt>size</tt> bytes;
+<tt>ogg_sync_wrote</tt> is used to inform the engine how many bytes
+were actually written. Use of <tt>ogg_sync_wrote</tt> after writing
+into the exposed buffer is mandantory.</p>
+
+<h3>
+int ogg_sync_clear(ogg_sync_state *oy);
+</h3>
+
+<p><tt>ogg_sync_clear</tt>
+clears and deallocates the internal storage of the given Ogg sync
+buffer. After clearing, the sync structure is not initialized for
+use; <tt>ogg_sync_init</tt> must be called to reinitialize for use.
+Use <tt>ogg_sync_reset</tt> to reset the sync state and buffer to a
+fresh, intiialized state.</p>
+
+<p><tt>ogg_sync_clear</tt> does not call <tt>free()</tt> on the pointer
+<tt>oy</tt>, allowing use of this call on sync structures in static
+or automatic storage. <tt>ogg_sync_destroy</tt>is a complimentary
+function that frees the pointer as well.</p>
+
+<p>Returns zero on success and non-zero on failure. This function always
+succeeds.</p>
+
+<h3>
+int ogg_sync_destroy(ogg_sync_state *oy);
+</h3>
+
+<p>Clears and deallocates the internal storage of the given Ogg sync
+buffer, then frees the storage associated with the pointer
+<tt>oy</tt>.</p>
+
+<p><tt>ogg_sync_clear</tt> does not call <tt>free()</tt> on the pointer
+<tt>oy</tt>, allowing use of that call on stream structures in static
+or automatic storage.</p>
+
+<p>Returns zero on success and non-zero on failure. This function always
+succeeds.</p>
+
+<h3>
+int ogg_sync_init(ogg_sync_state *oy);
+</h3>
+
+<p>Initializes the sync buffer <tt>oy</tt> for use.</p>
+
+<p>Returns zero on success and non-zero on failure. This function always
+succeeds.</p>
+
+<h3>
+int ogg_sync_pageout(ogg_sync_state *oy, ogg_page *og);
+</h3>
+
+<p>Reads complete, framed, verified Ogg pages from the sync buffer,
+placing the page data in <tt>og</tt>.</p>
+
+<p>Returns zero when there's no complete pages buffered for
+retrieval. Returns negative when a loss of sync or recapture occurred
+(this is not necessarily an error; recapture would be required after
+seeking, for example). Returns positive when a page is returned in
+<tt>og</tt>. Note that the data in <tt>og</tt> points into the sync
+buffer storage; the pointers are valid until the next call to
+<tt>ogg_sync_buffer</tt>, <tt>ogg_sync_clear</tt>,
+<tt>ogg_sync_destroy</tt> or <tt>ogg_sync_reset</tt>.</p>
+
+<h3>
+int ogg_sync_reset(ogg_sync_state *oy);
+</h3>
+
+<p><tt>ogg_sync_reset</tt> resets the sync state in <tt>oy</tt> to a
+clean, empty state. This is useful, for example, when seeking to a
+new location in a bitstream.</p>
+
+<p>Returns zero on success, nonzero on failure.</p>
+
+<h3>
+int ogg_sync_wrote(ogg_sync_state *oy, long bytes);
+</h3>
+
+<p>Used to inform the sync state as to how many bytes were actually
+written into the exposed sync buffer. It must be equal to or less
+than the size of the buffer requested.</p>
+
+<p>Returns zero on success and non-zero on failure; failure occurs only
+when the number of bytes written were larger than the buffer.</p>
+
+<div id="copyright">
+ The Xiph Fish Logo is a
+ trademark (™) of Xiph.Org.<br/>
+
+ These pages © 1994 - 2005 Xiph.Org. All rights reserved.
+</div>
+
+</body>
+</html>
Modified: branches/vorbis-aotuv/doc/stereo.html
===================================================================
--- branches/vorbis-aotuv/doc/stereo.html 2008-03-31 15:23:02 UTC (rev 14646)
+++ branches/vorbis-aotuv/doc/stereo.html 2008-04-01 10:47:58 UTC (rev 14647)
@@ -1,418 +1,418 @@
-<!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, h4, h4 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 stereo-specific channel coupling discussion</h1>
-
-<h2>Abstract</h2>
-
-<p>The Vorbis audio CODEC provides a channel coupling
-mechanisms designed to reduce effective bitrate by both eliminating
-interchannel redundancy and eliminating stereo image information
-labeled inaudible or undesirable according to spatial psychoacoustic
-models. This document describes both the mechanical coupling
-mechanisms available within the Vorbis specification, as well as the
-specific stereo coupling models used by the reference
-<tt>libvorbis</tt> codec provided by xiph.org.</p>
-
-<h2>Mechanisms</h2>
-
-<p>In encoder release beta 4 and earlier, Vorbis supported multiple
-channel encoding, but the channels were encoded entirely separately
-with no cross-analysis or redundancy elimination between channels.
-This multichannel strategy is very similar to the mp3's <em>dual
-stereo</em> mode and Vorbis uses the same name for its analogous
-uncoupled multichannel modes.</p>
-
-<p>However, the Vorbis spec provides for, and Vorbis release 1.0 rc1 and
-later implement a coupled channel strategy. Vorbis has two specific
-mechanisms that may be used alone or in conjunction to implement
-channel coupling. The first is <em>channel interleaving</em> via
-residue backend type 2, and the second is <em>square polar
-mapping</em>. These two general mechanisms are particularly well
-suited to coupling due to the structure of Vorbis encoding, as we'll
-explore below, and using both we can implement both totally
-<em>lossless stereo image coupling</em> [bit-for-bit decode-identical
-to uncoupled modes], as well as various lossy models that seek to
-eliminate inaudible or unimportant aspects of the stereo image in
-order to enhance bitrate. The exact coupling implementation is
-generalized to allow the encoder a great deal of flexibility in
-implementation of a stereo or surround model without requiring any
-significant complexity increase over the combinatorially simpler
-mid/side joint stereo of mp3 and other current audio codecs.</p>
-
-<p>A particular Vorbis bitstream may apply channel coupling directly to
-more than a pair of channels; polar mapping is hierarchical such that
-polar coupling may be extrapolated to an arbitrary number of channels
-and is not restricted to only stereo, quadraphonics, ambisonics or 5.1
-surround. However, the scope of this document restricts itself to the
-stereo coupling case.</p>
-
-<h3>Square Polar Mapping</h3>
-
-<h4>maximal correlation</h4>
-
-<p>Recall that the basic structure of a a Vorbis I stream first generates
-from input audio a spectral 'floor' function that serves as an
-MDCT-domain whitening filter. This floor is meant to represent the
-rough envelope of the frequency spectrum, using whatever metric the
-encoder cares to define. This floor is subtracted from the log
-frequency spectrum, effectively normalizing the spectrum by frequency.
-Each input channel is associated with a unique floor function.</p>
-
-<p>The basic idea behind any stereo coupling is that the left and right
-channels usually correlate. This correlation is even stronger if one
-first accounts for energy differences in any given frequency band
-across left and right; think for example of individual instruments
-mixed into different portions of the stereo image, or a stereo
-recording with a dominant feature not perfectly in the center. The
-floor functions, each specific to a channel, provide the perfect means
-of normalizing left and right energies across the spectrum to maximize
-correlation before coupling. This feature of the Vorbis format is not
-a convenient accident.</p>
-
-<p>Because we strive to maximally correlate the left and right channels
-and generally succeed in doing so, left and right residue is typically
-nearly identical. We could use channel interleaving (discussed below)
-alone to efficiently remove the redundancy between the left and right
-channels as a side effect of entropy encoding, but a polar
-representation gives benefits when left/right correlation is
-strong.</p>
-
-<h4>point and diffuse imaging</h4>
-
-<p>The first advantage of a polar representation is that it effectively
-separates the spatial audio information into a 'point image'
-(magnitude) at a given frequency and located somewhere in the sound
-field, and a 'diffuse image' (angle) that fills a large amount of
-space simultaneously. Even if we preserve only the magnitude (point)
-data, a detailed and carefully chosen floor function in each channel
-provides us with a free, fine-grained, frequency relative intensity
-stereo*. Angle information represents diffuse sound fields, such as
-reverberation that fills the entire space simultaneously.</p>
-
-<p>*<em>Because the Vorbis model supports a number of different possible
-stereo models and these models may be mixed, we do not use the term
-'intensity stereo' talking about Vorbis; instead we use the terms
-'point stereo', 'phase stereo' and subcategories of each.</em></p>
-
-<p>The majority of a stereo image is representable by polar magnitude
-alone, as strong sounds tend to be produced at near-point sources;
-even non-diffuse, fast, sharp echoes track very accurately using
-magnitude representation almost alone (for those experimenting with
-Vorbis tuning, this strategy works much better with the precise,
-piecewise control of floor 1; the continuous approximation of floor 0
-results in unstable imaging). Reverberation and diffuse sounds tend
-to contain less energy and be psychoacoustically dominated by the
-point sources embedded in them. Thus, we again tend to concentrate
-more represented energy into a predictably smaller number of numbers.
-Separating representation of point and diffuse imaging also allows us
-to model and manipulate point and diffuse qualities separately.</p>
-
-<h4>controlling bit leakage and symbol crosstalk</h4>
-
-<p>Because polar
-representation concentrates represented energy into fewer large
-values, we reduce bit 'leakage' during cascading (multistage VQ
-encoding) as a secondary benefit. A single large, monolithic VQ
-codebook is more efficient than a cascaded book due to entropy
-'crosstalk' among symbols between different stages of a multistage cascade.
-Polar representation is a way of further concentrating entropy into
-predictable locations so that codebook design can take steps to
-improve multistage codebook efficiency. It also allows us to cascade
-various elements of the stereo image independently.</p>
-
-<h4>eliminating trigonometry and rounding</h4>
-
-<p>Rounding and computational complexity are potential problems with a
-polar representation. As our encoding process involves quantization,
-mixing a polar representation and quantization makes it potentially
-impossible, depending on implementation, to construct a coupled stereo
-mechanism that results in bit-identical decompressed output compared
-to an uncoupled encoding should the encoder desire it.</p>
-
-<p>Vorbis uses a mapping that preserves the most useful qualities of
-polar representation, relies only on addition/subtraction (during
-decode; high quality encoding still requires some trig), and makes it
-trivial before or after quantization to represent an angle/magnitude
-through a one-to-one mapping from possible left/right value
-permutations. We do this by basing our polar representation on the
-unit square rather than the unit-circle.</p>
-
-<p>Given a magnitude and angle, we recover left and right using the
-following function (note that A/B may be left/right or right/left
-depending on the coupling definition used by the encoder):</p>
-
-<pre>
- if(magnitude>0)
- if(angle>0){
- A=magnitude;
- B=magnitude-angle;
- }else{
- B=magnitude;
- A=magnitude+angle;
- }
- else
- if(angle>0){
- A=magnitude;
- B=magnitude+angle;
- }else{
- B=magnitude;
- A=magnitude-angle;
- }
- }
-</pre>
-
-<p>The function is antisymmetric for positive and negative magnitudes in
-order to eliminate a redundant value when quantizing. For example, if
-we're quantizing to integer values, we can visualize a magnitude of 5
-and an angle of -2 as follows:</p>
-
-<p><img src="squarepolar.png" alt="square polar"/></p>
-
-<p>This representation loses or replicates no values; if the range of A
-and B are integral -5 through 5, the number of possible Cartesian
-permutations is 121. Represented in square polar notation, the
-possible values are:</p>
-
-<pre>
- 0, 0
-
--1,-2 -1,-1 -1, 0 -1, 1
-
- 1,-2 1,-1 1, 0 1, 1
-
--2,-4 -2,-3 -2,-2 -2,-1 -2, 0 -2, 1 -2, 2 -2, 3
-
- 2,-4 2,-3 ... following the pattern ...
-
- ... 5, 1 5, 2 5, 3 5, 4 5, 5 5, 6 5, 7 5, 8 5, 9
-
-</pre>
-
-<p>...for a grand total of 121 possible values, the same number as in
-Cartesian representation (note that, for example, <tt>5,-10</tt> is
-the same as <tt>-5,10</tt>, so there's no reason to represent
-both. 2,10 cannot happen, and there's no reason to account for it.)
-It's also obvious that this mapping is exactly reversible.</p>
-
-<h3>Channel interleaving</h3>
-
-<p>We can remap and A/B vector using polar mapping into a magnitude/angle
-vector, and it's clear that, in general, this concentrates energy in
-the magnitude vector and reduces the amount of information to encode
-in the angle vector. Encoding these vectors independently with
-residue backend #0 or residue backend #1 will result in bitrate
-savings. However, there are still implicit correlations between the
-magnitude and angle vectors. The most obvious is that the amplitude
-of the angle is bounded by its corresponding magnitude value.</p>
-
-<p>Entropy coding the results, then, further benefits from the entropy
-model being able to compress magnitude and angle simultaneously. For
-this reason, Vorbis implements residue backend #2 which pre-interleaves
-a number of input vectors (in the stereo case, two, A and B) into a
-single output vector (with the elements in the order of
-A_0, B_0, A_1, B_1, A_2 ... A_n-1, B_n-1) before entropy encoding. Thus
-each vector to be coded by the vector quantization backend consists of
-matching magnitude and angle values.</p>
-
-<p>The astute reader, at this point, will notice that in the theoretical
-case in which we can use monolithic codebooks of arbitrarily large
-size, we can directly interleave and encode left and right without
-polar mapping; in fact, the polar mapping does not appear to lend any
-benefit whatsoever to the efficiency of the entropy coding. In fact,
-it is perfectly possible and reasonable to build a Vorbis encoder that
-dispenses with polar mapping entirely and merely interleaves the
-channel. Libvorbis based encoders may configure such an encoding and
-it will work as intended.</p>
-
-<p>However, when we leave the ideal/theoretical domain, we notice that
-polar mapping does give additional practical benefits, as discussed in
-the above section on polar mapping and summarized again here:</p>
-
-<ul>
-<li>Polar mapping aids in controlling entropy 'leakage' between stages
-of a cascaded codebook.</li>
-<li>Polar mapping separates the stereo image
-into point and diffuse components which may be analyzed and handled
-differently.</li>
-</ul>
-
-<h2>Stereo Models</h2>
-
-<h3>Dual Stereo</h3>
-
-<p>Dual stereo refers to stereo encoding where the channels are entirely
-separate; they are analyzed and encoded as entirely distinct entities.
-This terminology is familiar from mp3.</p>
-
-<h3>Lossless Stereo</h3>
-
-<p>Using polar mapping and/or channel interleaving, it's possible to
-couple Vorbis channels losslessly, that is, construct a stereo
-coupling encoding that both saves space but also decodes
-bit-identically to dual stereo. OggEnc 1.0 and later uses this
-mode in all high-bitrate encoding.</p>
-
-<p>Overall, this stereo mode is overkill; however, it offers a safe
-alternative to users concerned about the slightest possible
-degradation to the stereo image or archival quality audio.</p>
-
-<h3>Phase Stereo</h3>
-
-<p>Phase stereo is the least aggressive means of gracefully dropping
-resolution from the stereo image; it affects only diffuse imaging.</p>
-
-<p>It's often quoted that the human ear is deaf to signal phase above
-about 4kHz; this is nearly true and a passable rule of thumb, but it
-can be demonstrated that even an average user can tell the difference
-between high frequency in-phase and out-of-phase noise. Obviously
-then, the statement is not entirely true. However, it's also the case
-that one must resort to nearly such an extreme demonstration before
-finding the counterexample.</p>
-
-<p>'Phase stereo' is simply a more aggressive quantization of the polar
-angle vector; above 4kHz it's generally quite safe to quantize noise
-and noisy elements to only a handful of allowed phases, or to thin the
-phase with respect to the magnitude. The phases of high amplitude
-pure tones may or may not be preserved more carefully (they are
-relatively rare and L/R tend to be in phase, so there is generally
-little reason not to spend a few more bits on them)</p>
-
-<h4>example: eight phase stereo</h4>
-
-<p>Vorbis may implement phase stereo coupling by preserving the entirety
-of the magnitude vector (essential to fine amplitude and energy
-resolution overall) and quantizing the angle vector to one of only
-four possible values. Given that the magnitude vector may be positive
-or negative, this results in left and right phase having eight
-possible permutation, thus 'eight phase stereo':</p>
-
-<p><img src="eightphase.png" alt="eight phase"/></p>
-
-<p>Left and right may be in phase (positive or negative), the most common
-case by far, or out of phase by 90 or 180 degrees.</p>
-
-<h4>example: four phase stereo</h4>
-
-<p>Similarly, four phase stereo takes the quantization one step further;
-it allows only in-phase and 180 degree out-out-phase signals:</p>
-
-<p><img src="fourphase.png" alt="four phase"/></p>
-
-<h3>example: point stereo</h3>
-
-<p>Point stereo eliminates the possibility of out-of-phase signal
-entirely. Any diffuse quality to a sound source tends to collapse
-inward to a point somewhere within the stereo image. A practical
-example would be balanced reverberations within a large, live space;
-normally the sound is diffuse and soft, giving a sonic impression of
-volume. In point-stereo, the reverberations would still exist, but
-sound fairly firmly centered within the image (assuming the
-reverberation was centered overall; if the reverberation is stronger
-to the left, then the point of localization in point stereo would be
-to the left). This effect is most noticeable at low and mid
-frequencies and using headphones (which grant perfect stereo
-separation). Point stereo is is a graceful but generally easy to
-detect degradation to the sound quality and is thus used in frequency
-ranges where it is least noticeable.</p>
-
-<h3>Mixed Stereo</h3>
-
-<p>Mixed stereo is the simultaneous use of more than one of the above
-stereo encoding models, generally using more aggressive modes in
-higher frequencies, lower amplitudes or 'nearly' in-phase sound.</p>
-
-<p>It is also the case that near-DC frequencies should be encoded using
-lossless coupling to avoid frame blocking artifacts.</p>
-
-<h3>Vorbis Stereo Modes</h3>
-
-<p>Vorbis, as of 1.0, uses lossless stereo and a number of mixed modes
-constructed out of lossless and point stereo. Phase stereo was used
-in the rc2 encoder, but is not currently used for simplicity's sake. It
-will likely be re-added to the stereo model in the future.</p>
-
-<div id="copyright">
- The Xiph Fish Logo is a
- trademark (™) of Xiph.Org.<br/>
-
- These pages © 1994 - 2005 Xiph.Org. All rights reserved.
-</div>
-
-</body>
-</html>
-
-
-
-
-
-
+<!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, h4, h4 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 stereo-specific channel coupling discussion</h1>
+
+<h2>Abstract</h2>
+
+<p>The Vorbis audio CODEC provides a channel coupling
+mechanisms designed to reduce effective bitrate by both eliminating
+interchannel redundancy and eliminating stereo image information
+labeled inaudible or undesirable according to spatial psychoacoustic
+models. This document describes both the mechanical coupling
+mechanisms available within the Vorbis specification, as well as the
+specific stereo coupling models used by the reference
+<tt>libvorbis</tt> codec provided by xiph.org.</p>
+
+<h2>Mechanisms</h2>
+
+<p>In encoder release beta 4 and earlier, Vorbis supported multiple
+channel encoding, but the channels were encoded entirely separately
+with no cross-analysis or redundancy elimination between channels.
+This multichannel strategy is very similar to the mp3's <em>dual
+stereo</em> mode and Vorbis uses the same name for its analogous
+uncoupled multichannel modes.</p>
+
+<p>However, the Vorbis spec provides for, and Vorbis release 1.0 rc1 and
+later implement a coupled channel strategy. Vorbis has two specific
+mechanisms that may be used alone or in conjunction to implement
+channel coupling. The first is <em>channel interleaving</em> via
+residue backend type 2, and the second is <em>square polar
+mapping</em>. These two general mechanisms are particularly well
+suited to coupling due to the structure of Vorbis encoding, as we'll
+explore below, and using both we can implement both totally
+<em>lossless stereo image coupling</em> [bit-for-bit decode-identical
+to uncoupled modes], as well as various lossy models that seek to
+eliminate inaudible or unimportant aspects of the stereo image in
+order to enhance bitrate. The exact coupling implementation is
+generalized to allow the encoder a great deal of flexibility in
+implementation of a stereo or surround model without requiring any
+significant complexity increase over the combinatorially simpler
+mid/side joint stereo of mp3 and other current audio codecs.</p>
+
+<p>A particular Vorbis bitstream may apply channel coupling directly to
+more than a pair of channels; polar mapping is hierarchical such that
+polar coupling may be extrapolated to an arbitrary number of channels
+and is not restricted to only stereo, quadraphonics, ambisonics or 5.1
+surround. However, the scope of this document restricts itself to the
+stereo coupling case.</p>
+
+<h3>Square Polar Mapping</h3>
+
+<h4>maximal correlation</h4>
+
+<p>Recall that the basic structure of a a Vorbis I stream first generates
+from input audio a spectral 'floor' function that serves as an
+MDCT-domain whitening filter. This floor is meant to represent the
+rough envelope of the frequency spectrum, using whatever metric the
+encoder cares to define. This floor is subtracted from the log
+frequency spectrum, effectively normalizing the spectrum by frequency.
+Each input channel is associated with a unique floor function.</p>
+
+<p>The basic idea behind any stereo coupling is that the left and right
+channels usually correlate. This correlation is even stronger if one
+first accounts for energy differences in any given frequency band
+across left and right; think for example of individual instruments
+mixed into different portions of the stereo image, or a stereo
+recording with a dominant feature not perfectly in the center. The
+floor functions, each specific to a channel, provide the perfect means
+of normalizing left and right energies across the spectrum to maximize
+correlation before coupling. This feature of the Vorbis format is not
+a convenient accident.</p>
+
+<p>Because we strive to maximally correlate the left and right channels
+and generally succeed in doing so, left and right residue is typically
+nearly identical. We could use channel interleaving (discussed below)
+alone to efficiently remove the redundancy between the left and right
+channels as a side effect of entropy encoding, but a polar
+representation gives benefits when left/right correlation is
+strong.</p>
+
+<h4>point and diffuse imaging</h4>
+
+<p>The first advantage of a polar representation is that it effectively
+separates the spatial audio information into a 'point image'
+(magnitude) at a given frequency and located somewhere in the sound
+field, and a 'diffuse image' (angle) that fills a large amount of
+space simultaneously. Even if we preserve only the magnitude (point)
+data, a detailed and carefully chosen floor function in each channel
+provides us with a free, fine-grained, frequency relative intensity
+stereo*. Angle information represents diffuse sound fields, such as
+reverberation that fills the entire space simultaneously.</p>
+
+<p>*<em>Because the Vorbis model supports a number of different possible
+stereo models and these models may be mixed, we do not use the term
+'intensity stereo' talking about Vorbis; instead we use the terms
+'point stereo', 'phase stereo' and subcategories of each.</em></p>
+
+<p>The majority of a stereo image is representable by polar magnitude
+alone, as strong sounds tend to be produced at near-point sources;
+even non-diffuse, fast, sharp echoes track very accurately using
+magnitude representation almost alone (for those experimenting with
+Vorbis tuning, this strategy works much better with the precise,
+piecewise control of floor 1; the continuous approximation of floor 0
+results in unstable imaging). Reverberation and diffuse sounds tend
+to contain less energy and be psychoacoustically dominated by the
+point sources embedded in them. Thus, we again tend to concentrate
+more represented energy into a predictably smaller number of numbers.
+Separating representation of point and diffuse imaging also allows us
+to model and manipulate point and diffuse qualities separately.</p>
+
+<h4>controlling bit leakage and symbol crosstalk</h4>
+
+<p>Because polar
+representation concentrates represented energy into fewer large
+values, we reduce bit 'leakage' during cascading (multistage VQ
+encoding) as a secondary benefit. A single large, monolithic VQ
+codebook is more efficient than a cascaded book due to entropy
+'crosstalk' among symbols between different stages of a multistage cascade.
+Polar representation is a way of further concentrating entropy into
+predictable locations so that codebook design can take steps to
+improve multistage codebook efficiency. It also allows us to cascade
+various elements of the stereo image independently.</p>
+
+<h4>eliminating trigonometry and rounding</h4>
+
+<p>Rounding and computational complexity are potential problems with a
+polar representation. As our encoding process involves quantization,
+mixing a polar representation and quantization makes it potentially
+impossible, depending on implementation, to construct a coupled stereo
+mechanism that results in bit-identical decompressed output compared
+to an uncoupled encoding should the encoder desire it.</p>
+
+<p>Vorbis uses a mapping that preserves the most useful qualities of
+polar representation, relies only on addition/subtraction (during
+decode; high quality encoding still requires some trig), and makes it
+trivial before or after quantization to represent an angle/magnitude
+through a one-to-one mapping from possible left/right value
+permutations. We do this by basing our polar representation on the
+unit square rather than the unit-circle.</p>
+
+<p>Given a magnitude and angle, we recover left and right using the
+following function (note that A/B may be left/right or right/left
+depending on the coupling definition used by the encoder):</p>
+
+<pre>
+ if(magnitude>0)
+ if(angle>0){
+ A=magnitude;
+ B=magnitude-angle;
+ }else{
+ B=magnitude;
+ A=magnitude+angle;
+ }
+ else
+ if(angle>0){
+ A=magnitude;
+ B=magnitude+angle;
+ }else{
+ B=magnitude;
+ A=magnitude-angle;
+ }
+ }
+</pre>
+
+<p>The function is antisymmetric for positive and negative magnitudes in
+order to eliminate a redundant value when quantizing. For example, if
+we're quantizing to integer values, we can visualize a magnitude of 5
+and an angle of -2 as follows:</p>
+
+<p><img src="squarepolar.png" alt="square polar"/></p>
+
+<p>This representation loses or replicates no values; if the range of A
+and B are integral -5 through 5, the number of possible Cartesian
+permutations is 121. Represented in square polar notation, the
+possible values are:</p>
+
+<pre>
+ 0, 0
+
+-1,-2 -1,-1 -1, 0 -1, 1
+
+ 1,-2 1,-1 1, 0 1, 1
+
+-2,-4 -2,-3 -2,-2 -2,-1 -2, 0 -2, 1 -2, 2 -2, 3
+
+ 2,-4 2,-3 ... following the pattern ...
+
+ ... 5, 1 5, 2 5, 3 5, 4 5, 5 5, 6 5, 7 5, 8 5, 9
+
+</pre>
+
+<p>...for a grand total of 121 possible values, the same number as in
+Cartesian representation (note that, for example, <tt>5,-10</tt> is
+the same as <tt>-5,10</tt>, so there's no reason to represent
+both. 2,10 cannot happen, and there's no reason to account for it.)
+It's also obvious that this mapping is exactly reversible.</p>
+
+<h3>Channel interleaving</h3>
+
+<p>We can remap and A/B vector using polar mapping into a magnitude/angle
+vector, and it's clear that, in general, this concentrates energy in
+the magnitude vector and reduces the amount of information to encode
+in the angle vector. Encoding these vectors independently with
+residue backend #0 or residue backend #1 will result in bitrate
+savings. However, there are still implicit correlations between the
+magnitude and angle vectors. The most obvious is that the amplitude
+of the angle is bounded by its corresponding magnitude value.</p>
+
+<p>Entropy coding the results, then, further benefits from the entropy
+model being able to compress magnitude and angle simultaneously. For
+this reason, Vorbis implements residue backend #2 which pre-interleaves
+a number of input vectors (in the stereo case, two, A and B) into a
+single output vector (with the elements in the order of
+A_0, B_0, A_1, B_1, A_2 ... A_n-1, B_n-1) before entropy encoding. Thus
+each vector to be coded by the vector quantization backend consists of
+matching magnitude and angle values.</p>
+
+<p>The astute reader, at this point, will notice that in the theoretical
+case in which we can use monolithic codebooks of arbitrarily large
+size, we can directly interleave and encode left and right without
+polar mapping; in fact, the polar mapping does not appear to lend any
+benefit whatsoever to the efficiency of the entropy coding. In fact,
+it is perfectly possible and reasonable to build a Vorbis encoder that
+dispenses with polar mapping entirely and merely interleaves the
+channel. Libvorbis based encoders may configure such an encoding and
+it will work as intended.</p>
+
+<p>However, when we leave the ideal/theoretical domain, we notice that
+polar mapping does give additional practical benefits, as discussed in
+the above section on polar mapping and summarized again here:</p>
+
+<ul>
+<li>Polar mapping aids in controlling entropy 'leakage' between stages
+of a cascaded codebook.</li>
+<li>Polar mapping separates the stereo image
+into point and diffuse components which may be analyzed and handled
+differently.</li>
+</ul>
+
+<h2>Stereo Models</h2>
+
+<h3>Dual Stereo</h3>
+
+<p>Dual stereo refers to stereo encoding where the channels are entirely
+separate; they are analyzed and encoded as entirely distinct entities.
+This terminology is familiar from mp3.</p>
+
+<h3>Lossless Stereo</h3>
+
+<p>Using polar mapping and/or channel interleaving, it's possible to
+couple Vorbis channels losslessly, that is, construct a stereo
+coupling encoding that both saves space but also decodes
+bit-identically to dual stereo. OggEnc 1.0 and later uses this
+mode in all high-bitrate encoding.</p>
+
+<p>Overall, this stereo mode is overkill; however, it offers a safe
+alternative to users concerned about the slightest possible
+degradation to the stereo image or archival quality audio.</p>
+
+<h3>Phase Stereo</h3>
+
+<p>Phase stereo is the least aggressive means of gracefully dropping
+resolution from the stereo image; it affects only diffuse imaging.</p>
+
+<p>It's often quoted that the human ear is deaf to signal phase above
+about 4kHz; this is nearly true and a passable rule of thumb, but it
+can be demonstrated that even an average user can tell the difference
+between high frequency in-phase and out-of-phase noise. Obviously
+then, the statement is not entirely true. However, it's also the case
+that one must resort to nearly such an extreme demonstration before
+finding the counterexample.</p>
+
+<p>'Phase stereo' is simply a more aggressive quantization of the polar
+angle vector; above 4kHz it's generally quite safe to quantize noise
+and noisy elements to only a handful of allowed phases, or to thin the
+phase with respect to the magnitude. The phases of high amplitude
+pure tones may or may not be preserved more carefully (they are
+relatively rare and L/R tend to be in phase, so there is generally
+little reason not to spend a few more bits on them)</p>
+
+<h4>example: eight phase stereo</h4>
+
+<p>Vorbis may implement phase stereo coupling by preserving the entirety
+of the magnitude vector (essential to fine amplitude and energy
+resolution overall) and quantizing the angle vector to one of only
+four possible values. Given that the magnitude vector may be positive
+or negative, this results in left and right phase having eight
+possible permutation, thus 'eight phase stereo':</p>
+
+<p><img src="eightphase.png" alt="eight phase"/></p>
+
+<p>Left and right may be in phase (positive or negative), the most common
+case by far, or out of phase by 90 or 180 degrees.</p>
+
+<h4>example: four phase stereo</h4>
+
+<p>Similarly, four phase stereo takes the quantization one step further;
+it allows only in-phase and 180 degree out-out-phase signals:</p>
+
+<p><img src="fourphase.png" alt="four phase"/></p>
+
+<h3>example: point stereo</h3>
+
+<p>Point stereo eliminates the possibility of out-of-phase signal
+entirely. Any diffuse quality to a sound source tends to collapse
+inward to a point somewhere within the stereo image. A practical
+example would be balanced reverberations within a large, live space;
+normally the sound is diffuse and soft, giving a sonic impression of
+volume. In point-stereo, the reverberations would still exist, but
+sound fairly firmly centered within the image (assuming the
+reverberation was centered overall; if the reverberation is stronger
+to the left, then the point of localization in point stereo would be
+to the left). This effect is most noticeable at low and mid
+frequencies and using headphones (which grant perfect stereo
+separation). Point stereo is is a graceful but generally easy to
+detect degradation to the sound quality and is thus used in frequency
+ranges where it is least noticeable.</p>
+
+<h3>Mixed Stereo</h3>
+
+<p>Mixed stereo is the simultaneous use of more than one of the above
+stereo encoding models, generally using more aggressive modes in
+higher frequencies, lower amplitudes or 'nearly' in-phase sound.</p>
+
+<p>It is also the case that near-DC frequencies should be encoded using
+lossless coupling to avoid frame blocking artifacts.</p>
+
+<h3>Vorbis Stereo Modes</h3>
+
+<p>Vorbis, as of 1.0, uses lossless stereo and a number of mixed modes
+constructed out of lossless and point stereo. Phase stereo was used
+in the rc2 encoder, but is not currently used for simplicity's sake. It
+will likely be re-added to the stereo model in the future.</p>
+
+<div id="copyright">
+ The Xiph Fish Logo is a
+ trademark (™) of Xiph.Org.<br/>
+
+ These pages © 1994 - 2005 Xiph.Org. All rights reserved.
+</div>
+
+</body>
+</html>
+
+
+
+
+
+
Modified: branches/vorbis-aotuv/doc/v-comment.html
===================================================================
--- branches/vorbis-aotuv/doc/v-comment.html 2008-03-31 15:23:02 UTC (rev 14646)
+++ branches/vorbis-aotuv/doc/v-comment.html 2008-04-01 10:47:58 UTC (rev 14647)
@@ -1,285 +1,285 @@
-<!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: comment field and header specification</h1>
-
-<h1>Overview</h1>
-
-<p>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.</p>
-
-<p>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:</p>
-
-<blockquote><p>
-"Honest Bob and the Factory-to-Dealer-Incentives, _I'm Still Around_,
-opening for Moxy Früvous, 1997"
-</p></blockquote>
-
-<h1>Comment encoding</h1>
-
-<h2>Structure</h2>
-
-<p>The comment header logically is 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".</p>
-
-<p>The comment header is decoded as follows:</p>
-
-<pre>
- 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.
-</pre>
-
-<h2>Content vector format</h2>
-
-<p>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:</p>
-
-<pre>
-comment[0]="ARTIST=me";
-comment[1]="TITLE=the sound of Vorbis";
-</pre>
-
-<ul>
-<li>A case-insensitive field name that may consist of ASCII 0x20 through
-0x7D, 0x3D ('=') excluded. ASCII 0x41 through 0x5A inclusive (A-Z) is
-to be considered equivalent to ASCII 0x61 through 0x7A inclusive
-(a-z).</li>
-<li>The field name is immediately followed by ASCII 0x3D ('=');
-this equals sign is used to terminate the field name.</li>
-<li>0x3D is followed by the 8 bit clean UTF-8 encoded value of the
-field contents to the end of the field.</li>
-</ul>
-
-<h3>Field names</h3>
-
-<p>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.</p>
-
-<dl>
-
-<dt>TITLE</dt>
-<dd>Track/Work name</dd>
-
-<dt>VERSION</dt>
-<dd>The version field may be used to differentiate multiple
-versions of the same track title in a single collection.
-(e.g. remix info)</dd>
-
-<dt>ALBUM</dt>
-<dd>The collection name to which this track belongs</dd>
-
-<dt>TRACKNUMBER</dt>
-<dd>The track number of this piece if part of a specific larger collection or album</dd>
-
-<dt>ARTIST</dt>
-<dd>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.</dd>
-
-<dt>PERFORMER</dt>
-<dd>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.</dd>
-
-<dt>COPYRIGHT</dt>
-<dd>Copyright attribution, e.g., '2001 Nobody's Band' or '1999 Jack Moffitt'</dd>
-
-<dt>LICENSE</dt>
-<dd>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.</dd>
-
-<dt>ORGANIZATION</dt>
-<dd>Name of the organization producing the track (i.e.
-the 'record label')</dd>
-
-<dt>DESCRIPTION</dt>
-<dd>A short text description of the contents</dd>
-
-<dt>GENRE</dt>
-<dd>A short text indication of music genre</dd>
-
-<dt>DATE</dt>
-<dd>Date the track was recorded</dd>
-
-<dt>LOCATION</dt>
-<dd>Location where track was recorded</dd>
-
-<dt>CONTACT</dt>
-<dd>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.</dd>
-
-<dt>ISRC</dt>
-<dd>ISRC number for the track; see <a href="http://www.ifpi.org/site-content/online/isrc_intro.html">the
-ISRC intro page</a> for more information on ISRC numbers.</dd>
-
-</dl>
-
-<h3>Implications</h3>
-
-<ul>
-<li>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</emph>,
-however, use the UTF-8 character encoding to allow easy representation
-of any language.</li>
-<li>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.</li>
-<li>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.</li>
-<li>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.</li>
-<li>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:
-<pre>
- ARTIST=Dizzy Gillespie
- ARTIST=Sonny Rollins
- ARTIST=Sonny Stitt
-</pre></li>
-</ul>
-
-<h2>Encoding</h2>
-
-<p>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.</p>
-
-<p>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):</p>
-
-<ol>
-<li>Vendor string length (32 bit unsigned quantity specifying number of octets)</li>
-<li>Vendor string ([vendor string length] octets coded from beginning of string
-to end of string, not null terminated)</li>
-<li>Number of comment fields (32 bit unsigned quantity specifying number of fields)</li>
-<li>Comment field 0 length (if [Number of comment fields]>0; 32 bit unsigned
-quantity specifying number of octets)</li>
-<li>Comment field 0 ([Comment field 0 length] octets coded from beginning of
-string to end of string, not null terminated)</li>
-<li>Comment field 1 length (if [Number of comment fields]>1...)...</li>
-</ol>
-
-<p>This is actually somewhat easier to describe in code; implementation of the above
-can be found in vorbis/lib/info.c:_vorbis_pack_comment(),_vorbis_unpack_comment()</p>
-
-<div id="copyright">
- The Xiph Fish Logo is a
- trademark (™) of Xiph.Org.<br/>
-
- These pages © 1994 - 2005 Xiph.Org. All rights reserved.
-</div>
-
-</body>
-</html>
+<!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: comment field and header specification</h1>
+
+<h1>Overview</h1>
+
+<p>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.</p>
+
+<p>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:</p>
+
+<blockquote><p>
+"Honest Bob and the Factory-to-Dealer-Incentives, _I'm Still Around_,
+opening for Moxy Früvous, 1997"
+</p></blockquote>
+
+<h1>Comment encoding</h1>
+
+<h2>Structure</h2>
+
+<p>The comment header logically is 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".</p>
+
+<p>The comment header is decoded as follows:</p>
+
+<pre>
+ 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.
+</pre>
+
+<h2>Content vector format</h2>
+
+<p>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:</p>
+
+<pre>
+comment[0]="ARTIST=me";
+comment[1]="TITLE=the sound of Vorbis";
+</pre>
+
+<ul>
+<li>A case-insensitive field name that may consist of ASCII 0x20 through
+0x7D, 0x3D ('=') excluded. ASCII 0x41 through 0x5A inclusive (A-Z) is
+to be considered equivalent to ASCII 0x61 through 0x7A inclusive
+(a-z).</li>
+<li>The field name is immediately followed by ASCII 0x3D ('=');
+this equals sign is used to terminate the field name.</li>
+<li>0x3D is followed by the 8 bit clean UTF-8 encoded value of the
+field contents to the end of the field.</li>
+</ul>
+
+<h3>Field names</h3>
+
+<p>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.</p>
+
+<dl>
+
+<dt>TITLE</dt>
+<dd>Track/Work name</dd>
+
+<dt>VERSION</dt>
+<dd>The version field may be used to differentiate multiple
+versions of the same track title in a single collection.
+(e.g. remix info)</dd>
+
+<dt>ALBUM</dt>
+<dd>The collection name to which this track belongs</dd>
+
+<dt>TRACKNUMBER</dt>
+<dd>The track number of this piece if part of a specific larger collection or album</dd>
+
+<dt>ARTIST</dt>
+<dd>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.</dd>
+
+<dt>PERFORMER</dt>
+<dd>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.</dd>
+
+<dt>COPYRIGHT</dt>
+<dd>Copyright attribution, e.g., '2001 Nobody's Band' or '1999 Jack Moffitt'</dd>
+
+<dt>LICENSE</dt>
+<dd>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.</dd>
+
+<dt>ORGANIZATION</dt>
+<dd>Name of the organization producing the track (i.e.
+the 'record label')</dd>
+
+<dt>DESCRIPTION</dt>
+<dd>A short text description of the contents</dd>
+
+<dt>GENRE</dt>
+<dd>A short text indication of music genre</dd>
+
+<dt>DATE</dt>
+<dd>Date the track was recorded</dd>
+
+<dt>LOCATION</dt>
+<dd>Location where track was recorded</dd>
+
+<dt>CONTACT</dt>
+<dd>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.</dd>
+
+<dt>ISRC</dt>
+<dd>ISRC number for the track; see <a href="http://www.ifpi.org/isrc/">the
+ISRC intro page</a> for more information on ISRC numbers.</dd>
+
+</dl>
+
+<h3>Implications</h3>
+
+<ul>
+<li>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</emph>,
+however, use the UTF-8 character encoding to allow easy representation
+of any language.</li>
+<li>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.</li>
+<li>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.</li>
+<li>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.</li>
+<li>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:
+<pre>
+ ARTIST=Dizzy Gillespie
+ ARTIST=Sonny Rollins
+ ARTIST=Sonny Stitt
+</pre></li>
+</ul>
+
+<h2>Encoding</h2>
+
+<p>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.</p>
+
+<p>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):</p>
+
+<ol>
+<li>Vendor string length (32 bit unsigned quantity specifying number of octets)</li>
+<li>Vendor string ([vendor string length] octets coded from beginning of string
+to end of string, not null terminated)</li>
+<li>Number of comment fields (32 bit unsigned quantity specifying number of fields)</li>
+<li>Comment field 0 length (if [Number of comment fields]>0; 32 bit unsigned
+quantity specifying number of octets)</li>
+<li>Comment field 0 ([Comment field 0 length] octets coded from beginning of
+string to end of string, not null terminated)</li>
+<li>Comment field 1 length (if [Number of comment fields]>1...)...</li>
+</ol>
+
+<p>This is actually somewhat easier to describe in code; implementation of the above
+can be found in vorbis/lib/info.c:_vorbis_pack_comment(),_vorbis_unpack_comment()</p>
+
+<div id="copyright">
+ The Xiph Fish Logo is a
+ trademark (™) of Xiph.Org.<br/>
+
+ These pages © 1994 - 2005 Xiph.Org. All rights reserved.
+</div>
+
+</body>
+</html>
Modified: branches/vorbis-aotuv/doc/vorbis-fidelity.html
===================================================================
--- branches/vorbis-aotuv/doc/vorbis-fidelity.html 2008-03-31 15:23:02 UTC (rev 14646)
+++ branches/vorbis-aotuv/doc/vorbis-fidelity.html 2008-04-01 10:47:58 UTC (rev 14647)
@@ -1,180 +1,180 @@
-<!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: Fidelity measurement and terminology discussion</h1>
-
-<p>Terminology discussed in this document is based on common terminology
-associated with contemporary codecs such as MPEG I audio layer 3
-(mp3). However, some differences in terminology are useful in the
-context of Vorbis as Vorbis functions somewhat differently than most
-current formats. For clarity, then, we describe a common terminology
-for discussion of Vorbis's and other formats' audio quality.</p>
-
-<h2>Subjective and Objective</h2>
-
-<p><em>Objective</em> fidelity is a measure, based on a computable,
-mechanical metric, of how carefully an output matches an input. For
-example, a stereo amplifier may claim to introduce less that .01%
-total harmonic distortion when amplifying an input signal; this claim
-is easy to verify given proper equipment, and any number of testers are
-likely to arrive at the same, exact results. One need not listen to
-the equipment to make this measurement.</p>
-
-<p>However, given two amplifiers with identical, verifiable objective
-specifications, listeners may strongly prefer the sound quality of one
-over the other. This is actually the case in the decades old debate
-[some would say jihad] among audiophiles involving vacuum tube versus
-solid state amplifiers. There are people who can tell the difference,
-and strongly prefer one over the other despite seemingly identical,
-measurable quality. This preference is <em>subjective</em> and
-difficult to measure but nonetheless real.</p>
-
-<p>Individual elements of subjective differences often can be qualified,
-but overall subjective quality generally is not measurable. Different
-observers are likely to disagree on the exact results of a subjective
-test as each observer's perspective differs. When measuring
-subjective qualities, the best one can hope for is average, empirical
-results that show statistical significance across a group.</p>
-
-<p>Perceptual codecs are most concerned with subjective, not objective,
-quality. This is why evaluating a perceptual codec via distortion
-measures and sonograms alone is useless; these objective measures may
-provide insight into the quality or functioning of a codec, but cannot
-answer the much squishier subjective question, "Does it sound
-good?". The tube amplifier example is perhaps not the best as very few
-people can hear, or care to hear, the minute differences between tubes
-and transistors, whereas the subjective differences in perceptual
-codecs tend to be quite large even when objective differences are
-not.</p>
-
-<h2>Fidelity, Artifacts and Differences</h2>
-
-<p>Audio <em>artifacts</em> and loss of fidelity or more simply
-put, audio <em>differences</em> are not the same thing.</p>
-
-<p>A loss of fidelity implies differences between the perceived input and
-output signal; it does not necessarily imply that the differences in
-output are displeasing or that the output sounds poor (although this
-is often the case). Tube amplifiers are <em>not</em> higher fidelity
-than modern solid state and digital systems. They simply produce a
-form of distortion and coloring that is either unnoticeable or actually
-pleasing to many ears.</p>
-
-<p>As compared to an original signal using hard metrics, all perceptual
-codecs [ASPEC, ATRAC, MP3, WMA, AAC, TwinVQ, AC3 and Vorbis included]
-lose objective fidelity in order to reduce bitrate. This is fact. The
-idea is to lose fidelity in ways that cannot be perceived. However,
-most current streaming applications demand bitrates lower than what
-can be achieved by sacrificing only objective fidelity; this is also
-fact, despite whatever various company press releases might claim.
-Subjective fidelity eventually must suffer in one way or another.</p>
-
-<p>The goal is to choose the best possible tradeoff such that the
-fidelity loss is graceful and not obviously noticeable. Most listeners
-of FM radio do not realize how much lower fidelity that medium is as
-compared to compact discs or DAT. However, when compared directly to
-source material, the difference is obvious. A cassette tape is lower
-fidelity still, and yet the degradation, relatively speaking, is
-graceful and generally easy not to notice. Compare this graceful loss
-of quality to an average 44.1kHz stereo mp3 encoded at 80 or 96kbps.
-The mp3 might actually be higher objective fidelity but subjectively
-sounds much worse.</p>
-
-<p>Thus, when a CODEC <em>must</em> sacrifice subjective quality in order
-to satisfy a user's requirements, the result should be a
-<em>difference</em> that is generally either difficult to notice
-without comparison, or easy to ignore. An <em>artifact</em>, on the
-other hand, is an element introduced into the output that is
-immediately noticeable, obviously foreign, and undesired. The famous
-'underwater' or 'twinkling' effect synonymous with low bitrate (or
-poorly encoded) mp3 is an example of an <em>artifact</em>. This
-working definition differs slightly from common usage, but the coined
-distinction between differences and artifacts is useful for our
-discussion.</p>
-
-<p>The goal, when it is absolutely necessary to sacrifice subjective
-fidelity, is obviously to strive for differences and not artifacts.
-The vast majority of codecs today fail at this task miserably,
-predictably, and regularly in one way or another. Avoiding such
-failures when it is necessary to sacrifice subjective quality is a
-fundamental design objective of Vorbis and that objective is reflected
-in Vorbis's design and tuning.</p>
-
-<div id="copyright">
- The Xiph Fish Logo is a
- trademark (™) of Xiph.Org.<br/>
-
- These pages © 1994 - 2005 Xiph.Org. All rights reserved.
-</div>
-
-</body>
-</html>
+<!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: Fidelity measurement and terminology discussion</h1>
+
+<p>Terminology discussed in this document is based on common terminology
+associated with contemporary codecs such as MPEG I audio layer 3
+(mp3). However, some differences in terminology are useful in the
+context of Vorbis as Vorbis functions somewhat differently than most
+current formats. For clarity, then, we describe a common terminology
+for discussion of Vorbis's and other formats' audio quality.</p>
+
+<h2>Subjective and Objective</h2>
+
+<p><em>Objective</em> fidelity is a measure, based on a computable,
+mechanical metric, of how carefully an output matches an input. For
+example, a stereo amplifier may claim to introduce less that .01%
+total harmonic distortion when amplifying an input signal; this claim
+is easy to verify given proper equipment, and any number of testers are
+likely to arrive at the same, exact results. One need not listen to
+the equipment to make this measurement.</p>
+
+<p>However, given two amplifiers with identical, verifiable objective
+specifications, listeners may strongly prefer the sound quality of one
+over the other. This is actually the case in the decades old debate
+[some would say jihad] among audiophiles involving vacuum tube versus
+solid state amplifiers. There are people who can tell the difference,
+and strongly prefer one over the other despite seemingly identical,
+measurable quality. This preference is <em>subjective</em> and
+difficult to measure but nonetheless real.</p>
+
+<p>Individual elements of subjective differences often can be qualified,
+but overall subjective quality generally is not measurable. Different
+observers are likely to disagree on the exact results of a subjective
+test as each observer's perspective differs. When measuring
+subjective qualities, the best one can hope for is average, empirical
+results that show statistical significance across a group.</p>
+
+<p>Perceptual codecs are most concerned with subjective, not objective,
+quality. This is why evaluating a perceptual codec via distortion
+measures and sonograms alone is useless; these objective measures may
+provide insight into the quality or functioning of a codec, but cannot
+answer the much squishier subjective question, "Does it sound
+good?". The tube amplifier example is perhaps not the best as very few
+people can hear, or care to hear, the minute differences between tubes
+and transistors, whereas the subjective differences in perceptual
+codecs tend to be quite large even when objective differences are
+not.</p>
+
+<h2>Fidelity, Artifacts and Differences</h2>
+
+<p>Audio <em>artifacts</em> and loss of fidelity or more simply
+put, audio <em>differences</em> are not the same thing.</p>
+
+<p>A loss of fidelity implies differences between the perceived input and
+output signal; it does not necessarily imply that the differences in
+output are displeasing or that the output sounds poor (although this
+is often the case). Tube amplifiers are <em>not</em> higher fidelity
+than modern solid state and digital systems. They simply produce a
+form of distortion and coloring that is either unnoticeable or actually
+pleasing to many ears.</p>
+
+<p>As compared to an original signal using hard metrics, all perceptual
+codecs [ASPEC, ATRAC, MP3, WMA, AAC, TwinVQ, AC3 and Vorbis included]
+lose objective fidelity in order to reduce bitrate. This is fact. The
+idea is to lose fidelity in ways that cannot be perceived. However,
+most current streaming applications demand bitrates lower than what
+can be achieved by sacrificing only objective fidelity; this is also
+fact, despite whatever various company press releases might claim.
+Subjective fidelity eventually must suffer in one way or another.</p>
+
+<p>The goal is to choose the best possible tradeoff such that the
+fidelity loss is graceful and not obviously noticeable. Most listeners
+of FM radio do not realize how much lower fidelity that medium is as
+compared to compact discs or DAT. However, when compared directly to
+source material, the difference is obvious. A cassette tape is lower
+fidelity still, and yet the degradation, relatively speaking, is
+graceful and generally easy not to notice. Compare this graceful loss
+of quality to an average 44.1kHz stereo mp3 encoded at 80 or 96kbps.
+The mp3 might actually be higher objective fidelity but subjectively
+sounds much worse.</p>
+
+<p>Thus, when a CODEC <em>must</em> sacrifice subjective quality in order
+to satisfy a user's requirements, the result should be a
+<em>difference</em> that is generally either difficult to notice
+without comparison, or easy to ignore. An <em>artifact</em>, on the
+other hand, is an element introduced into the output that is
+immediately noticeable, obviously foreign, and undesired. The famous
+'underwater' or 'twinkling' effect synonymous with low bitrate (or
+poorly encoded) mp3 is an example of an <em>artifact</em>. This
+working definition differs slightly from common usage, but the coined
+distinction between differences and artifacts is useful for our
+discussion.</p>
+
+<p>The goal, when it is absolutely necessary to sacrifice subjective
+fidelity, is obviously to strive for differences and not artifacts.
+The vast majority of codecs today fail at this task miserably,
+predictably, and regularly in one way or another. Avoiding such
+failures when it is necessary to sacrifice subjective quality is a
+fundamental design objective of Vorbis and that objective is reflected
+in Vorbis's design and tuning.</p>
+
+<div id="copyright">
+ The Xiph Fish Logo is a
+ trademark (™) of Xiph.Org.<br/>
+
+ These pages © 1994 - 2005 Xiph.Org. All rights reserved.
+</div>
+
+</body>
+</html>
Modified: branches/vorbis-aotuv/doc/vorbis.html
===================================================================
--- branches/vorbis-aotuv/doc/vorbis.html 2008-03-31 15:23:02 UTC (rev 14646)
+++ branches/vorbis-aotuv/doc/vorbis.html 2008-04-01 10:47:58 UTC (rev 14647)
@@ -1,234 +1,234 @@
-<!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 encoding format documentation</h1>
-
-<p><img src="wait.png" alt="wait"/>As of writing, not all the below document
-links are live. They will be populated as we complete the documents.</p>
-
-<h2>Documents</h2>
-
-<ul>
-<li><a href="packet.html">Vorbis packet structure</a></li>
-<li><a href="envelope.html">Temporal envelope shaping and blocksize</a></li>
-<li><a href="mdct.html">Time domain segmentation and MDCT transform</a></li>
-<li><a href="resolution.html">The resolution floor</a></li>
-<li><a href="residuals.html">MDCT-domain fine structure</a></li>
-</ul>
-
-<ul>
-<li><a href="probmodel.html">The Vorbis probability model</a></li>
-<li><a href="bitpack.html">The Vorbis bitpacker</a></li>
-</ul>
-
-<ul>
-<li><a href="oggstream.html">Ogg bitstream overview</a></li>
-<li><a href="framing.html">Ogg logical bitstream and framing spec</a></li>
-<li><a href="vorbis-stream.html">Vorbis packet->Ogg bitstream mapping</a></li>
-</ul>
-
-<ul>
-<li><a href="programming.html">Programming with libvorbis</a></li>
-</ul>
-
-<h2>Description</h2>
-
-<p>Ogg Vorbis is a general purpose compressed audio format
-for high quality (44.1-48.0kHz, 16+ bit, polyphonic) audio and music
-at moderate fixed and variable bitrates (40-80 kb/s/channel). This
-places Vorbis in the same class as audio representations including
-MPEG-1 audio layer 3, MPEG-4 audio (AAC and TwinVQ), and PAC.</p>
-
-<p>Vorbis is the first of a planned family of Ogg multimedia coding
-formats being developed as part of the Xiph.org Foundation's Ogg multimedia
-project. See <a href="http://www.xiph.org/">http://www.xiph.org/</a>
-for more information.</p>
-
-<h2>Vorbis technical documents</h2>
-
-<p>A Vorbis encoder takes in overlapping (but contiguous) short-time
-segments of audio data. The encoder analyzes the content of the audio
-to determine an optimal compact representation; this phase of encoding
-is known as <em>analysis</em>. For each short-time block of sound,
-the encoder then packs an efficient representation of the signal, as
-determined by analysis, into a raw packet much smaller than the size
-required by the original signal; this phase is <em>coding</em>.
-Lastly, in a streaming environment, the raw packets are then
-structured into a continuous stream of octets; this last phase is
-<em>streaming</em>. Note that the stream of octets is referred to both
-as a 'byte-' and 'bit-'stream; the latter usage is acceptible as the
-stream of octets is a physical representation of a true logical
-bit-by-bit stream.</p>
-
-<p>A Vorbis decoder performs a mirror image process of extracting the
-original sequence of raw packets from an Ogg stream (<em>stream
-decomposition</em>), reconstructing the signal representation from the
-raw data in the packet (<em>decoding</em>) and them reconstituting an
-audio signal from the decoded representation (<em>synthesis</em>).</p>
-
-<p>The <a href="programming.html">Programming with libvorbis</a>
-documents discuss use of the reference Vorbis codec library
-(libvorbis) produced by the Xiph.org Foundation.</p>
-
-<p>The data representations and algorithms necessary at each step to
-encode and decode Ogg Vorbis bitstreams are described by the below
-documents in sufficient detail to construct a complete Vorbis codec.
-Note that at the time of writing, Vorbis is still in a 'Request For
-Comments' stage of development; despite being in advanced stages of
-development, input from the multimedia community is welcome.</p>
-
-<h3>Vorbis analysis and synthesis</h3>
-
-<p>Analysis begins by seperating an input audio stream into individual,
-overlapping short-time segments of audio data. These segments are
-then transformed into an alternate representation, seeking to
-represent the original signal in a more efficient form that codes into
-a smaller number of bytes. The analysis and transformation stage is
-the most complex element of producing a Vorbis bitstream.</p>
-
-<p>The corresponding synthesis step in the decoder is simpler; there is
-no analysis to perform, merely a mechanical, deterministic
-reconstruction of the original audio data from the transform-domain
-representation.</p>
-
-<ul>
-<li><a href="packet.html">Vorbis packet structure</a>:
-Describes the basic analysis components necessary to produce Vorbis
-packets and the structure of the packet itself.</li>
-<li><a href="envelope.html">Temporal envelope shaping and blocksize</a>:
-Use of temporal envelope shaping and variable blocksize to minimize
-time-domain energy leakage during wide dynamic range and spectral energy
-swings. Also discusses time-related principles of psychoacoustics.</li>
-<li><a href="mdct.html">Time domain segmentation and MDCT transform</a>:
-Division of time domain data into individual overlapped, windowed
-short-time vectors and transformation using the MDCT</li>
-<