From 74f4b1bc3b627ba4c7e03498234d88cacdfbe97b Mon Sep 17 00:00:00 2001 From: Aki Date: Wed, 29 Sep 2021 22:52:49 +0200 Subject: Squashed 'vorbis/' content from commit d22c3ab5f git-subtree-dir: vorbis git-subtree-split: d22c3ab5f633460abc2532feee60ca0892134cbf --- doc/01-introduction.tex | 528 + doc/02-bitpacking.tex | 246 + doc/03-codebook.tex | 456 + doc/04-codec.tex | 660 ++ doc/05-comment.tex | 239 + doc/06-floor0.tex | 201 + doc/07-floor1.tex | 404 + doc/08-residue.tex | 451 + doc/09-helper.tex | 180 + doc/10-tables.tex | 76 + doc/Doxyfile.in | 1142 ++ doc/Makefile.am | 148 + doc/Vorbis_I_spec.cfg | 4 + doc/Vorbis_I_spec.css | 144 + doc/Vorbis_I_spec.html | 13243 +++++++++++++++++++++++ doc/Vorbis_I_spec.pdf | Bin 0 -> 418532 bytes doc/Vorbis_I_spec.tex | 141 + doc/Vorbis_I_spec0x.png | Bin 0 -> 1341 bytes doc/Vorbis_I_spec10x.png | Bin 0 -> 3781 bytes doc/Vorbis_I_spec11x.png | Bin 0 -> 3825 bytes doc/Vorbis_I_spec12x.png | Bin 0 -> 3371 bytes doc/Vorbis_I_spec13x.png | Bin 0 -> 1768 bytes doc/Vorbis_I_spec14x.png | Bin 0 -> 1792 bytes doc/Vorbis_I_spec1x.png | Bin 0 -> 556 bytes doc/Vorbis_I_spec2x.png | Bin 0 -> 556 bytes doc/Vorbis_I_spec3x.png | Bin 0 -> 556 bytes doc/Vorbis_I_spec4x.png | Bin 0 -> 556 bytes doc/Vorbis_I_spec5x.png | Bin 0 -> 556 bytes doc/Vorbis_I_spec6x.png | Bin 0 -> 557 bytes doc/Vorbis_I_spec7x.png | Bin 0 -> 2436 bytes doc/Vorbis_I_spec8x.png | Bin 0 -> 2569 bytes doc/Vorbis_I_spec9x.png | Bin 0 -> 1819 bytes doc/a1-encapsulation-ogg.tex | 184 + doc/a2-encapsulation-rtp.tex | 8 + doc/components.png | Bin 0 -> 9741 bytes doc/eightphase.png | Bin 0 -> 11130 bytes doc/fish_xiph_org.png | Bin 0 -> 2503 bytes doc/floor1-1.png | Bin 0 -> 3420 bytes doc/floor1-2.png | Bin 0 -> 3752 bytes doc/floor1-3.png | Bin 0 -> 4627 bytes doc/floor1-4.png | Bin 0 -> 4163 bytes doc/floor1_inverse_dB_table.html | 154 + doc/floorval.png | Bin 0 -> 2545 bytes doc/footer.tex | 31 + doc/fourphase.png | Bin 0 -> 9992 bytes doc/framing.html | 431 + doc/helper.html | 239 + doc/hufftree-under.png | Bin 0 -> 1206 bytes doc/hufftree.png | Bin 0 -> 1228 bytes doc/index.html | 114 + doc/libvorbis/Makefile.am | 24 + doc/libvorbis/index.html | 44 + doc/libvorbis/overview.html | 136 + doc/libvorbis/reference.html | 86 + doc/libvorbis/return.html | 79 + doc/libvorbis/style.css | 7 + doc/libvorbis/vorbis_analysis.html | 86 + doc/libvorbis/vorbis_analysis_blockout.html | 79 + doc/libvorbis/vorbis_analysis_buffer.html | 74 + doc/libvorbis/vorbis_analysis_headerout.html | 83 + doc/libvorbis/vorbis_analysis_init.html | 66 + doc/libvorbis/vorbis_analysis_wrote.html | 80 + doc/libvorbis/vorbis_bitrate_addblock.html | 74 + doc/libvorbis/vorbis_bitrate_flushpacket.html | 80 + doc/libvorbis/vorbis_block.html | 60 + doc/libvorbis/vorbis_block_clear.html | 61 + doc/libvorbis/vorbis_block_init.html | 66 + doc/libvorbis/vorbis_comment.html | 80 + doc/libvorbis/vorbis_comment_add.html | 70 + doc/libvorbis/vorbis_comment_add_tag.html | 74 + doc/libvorbis/vorbis_comment_clear.html | 69 + doc/libvorbis/vorbis_comment_init.html | 72 + doc/libvorbis/vorbis_comment_query.html | 72 + doc/libvorbis/vorbis_comment_query_count.html | 66 + doc/libvorbis/vorbis_commentheader_out.html | 65 + doc/libvorbis/vorbis_dsp_clear.html | 63 + doc/libvorbis/vorbis_dsp_state.html | 57 + doc/libvorbis/vorbis_granule_time.html | 65 + doc/libvorbis/vorbis_info.html | 80 + doc/libvorbis/vorbis_info_blocksize.html | 66 + doc/libvorbis/vorbis_info_clear.html | 61 + doc/libvorbis/vorbis_info_init.html | 62 + doc/libvorbis/vorbis_packet_blocksize.html | 66 + doc/libvorbis/vorbis_synthesis.html | 70 + doc/libvorbis/vorbis_synthesis_blockin.html | 69 + doc/libvorbis/vorbis_synthesis_halfrate.html | 68 + doc/libvorbis/vorbis_synthesis_halfrate_p.html | 64 + doc/libvorbis/vorbis_synthesis_headerin.html | 80 + doc/libvorbis/vorbis_synthesis_idheader.html | 63 + doc/libvorbis/vorbis_synthesis_init.html | 69 + doc/libvorbis/vorbis_synthesis_lapout.html | 74 + doc/libvorbis/vorbis_synthesis_pcmout.html | 75 + doc/libvorbis/vorbis_synthesis_read.html | 67 + doc/libvorbis/vorbis_synthesis_restart.html | 64 + doc/libvorbis/vorbis_synthesis_trackonly.html | 71 + doc/libvorbis/vorbis_version_string.html | 56 + doc/oggstream.html | 234 + doc/programming.html | 554 + doc/release.txt | 16 + doc/residue-pack.png | Bin 0 -> 32318 bytes doc/residue2.png | Bin 0 -> 20427 bytes doc/rfc5215.txt | 1459 +++ doc/rfc5215.xml | 1176 ++ doc/squarepolar.png | Bin 0 -> 8406 bytes doc/stereo.html | 419 + doc/stream.png | Bin 0 -> 2171 bytes doc/v-comment.html | 285 + doc/vorbis-clip.txt | 139 + doc/vorbis-errors.txt | 103 + doc/vorbis-fidelity.html | 180 + doc/vorbisenc/Makefile.am | 11 + doc/vorbisenc/changes.html | 104 + doc/vorbisenc/examples.html | 133 + doc/vorbisenc/index.html | 40 + doc/vorbisenc/ovectl_ratemanage2_arg.html | 92 + doc/vorbisenc/ovectl_ratemanage_arg.html | 92 + doc/vorbisenc/overview.html | 382 + doc/vorbisenc/reference.html | 54 + doc/vorbisenc/style.css | 7 + doc/vorbisenc/vorbis_encode_ctl.html | 183 + doc/vorbisenc/vorbis_encode_init.html | 88 + doc/vorbisenc/vorbis_encode_init_vbr.html | 81 + doc/vorbisenc/vorbis_encode_setup_init.html | 88 + doc/vorbisenc/vorbis_encode_setup_managed.html | 102 + doc/vorbisenc/vorbis_encode_setup_vbr.html | 90 + doc/vorbisfile/Makefile.am | 25 + doc/vorbisfile/OggVorbis_File.html | 137 + doc/vorbisfile/callbacks.html | 121 + doc/vorbisfile/chaining_example_c.html | 90 + doc/vorbisfile/chainingexample.html | 175 + doc/vorbisfile/crosslap.html | 121 + doc/vorbisfile/datastructures.html | 61 + doc/vorbisfile/decoding.html | 92 + doc/vorbisfile/example.html | 208 + doc/vorbisfile/exampleindex.html | 39 + doc/vorbisfile/fileinfo.html | 95 + doc/vorbisfile/index.html | 49 + doc/vorbisfile/initialization.html | 118 + doc/vorbisfile/ov_bitrate.html | 72 + doc/vorbisfile/ov_bitrate_instant.html | 65 + doc/vorbisfile/ov_callbacks.html | 117 + doc/vorbisfile/ov_clear.html | 64 + doc/vorbisfile/ov_comment.html | 66 + doc/vorbisfile/ov_crosslap.html | 100 + doc/vorbisfile/ov_fopen.html | 124 + doc/vorbisfile/ov_info.html | 64 + doc/vorbisfile/ov_open.html | 183 + doc/vorbisfile/ov_open_callbacks.html | 147 + doc/vorbisfile/ov_pcm_seek.html | 83 + doc/vorbisfile/ov_pcm_seek_lap.html | 103 + doc/vorbisfile/ov_pcm_seek_page.html | 84 + doc/vorbisfile/ov_pcm_seek_page_lap.html | 112 + doc/vorbisfile/ov_pcm_tell.html | 63 + doc/vorbisfile/ov_pcm_total.html | 67 + doc/vorbisfile/ov_raw_seek.html | 83 + doc/vorbisfile/ov_raw_seek_lap.html | 110 + doc/vorbisfile/ov_raw_tell.html | 65 + doc/vorbisfile/ov_raw_total.html | 68 + doc/vorbisfile/ov_read.html | 148 + doc/vorbisfile/ov_read_filter.html | 114 + doc/vorbisfile/ov_read_float.html | 105 + doc/vorbisfile/ov_seekable.html | 63 + doc/vorbisfile/ov_serialnumber.html | 67 + doc/vorbisfile/ov_streams.html | 64 + doc/vorbisfile/ov_test.html | 104 + doc/vorbisfile/ov_test_callbacks.html | 111 + doc/vorbisfile/ov_test_open.html | 82 + doc/vorbisfile/ov_time_seek.html | 82 + doc/vorbisfile/ov_time_seek_lap.html | 105 + doc/vorbisfile/ov_time_seek_page.html | 83 + doc/vorbisfile/ov_time_seek_page_lap.html | 112 + doc/vorbisfile/ov_time_tell.html | 63 + doc/vorbisfile/ov_time_total.html | 67 + doc/vorbisfile/overview.html | 61 + doc/vorbisfile/reference.html | 86 + doc/vorbisfile/seekexample.html | 152 + doc/vorbisfile/seeking.html | 107 + doc/vorbisfile/seeking_example_c.html | 86 + doc/vorbisfile/seeking_test_c.html | 86 + doc/vorbisfile/seekingexample.html | 203 + doc/vorbisfile/style.css | 7 + doc/vorbisfile/threads.html | 50 + doc/vorbisfile/vorbisfile_example_c.html | 106 + doc/window1.png | Bin 0 -> 1703 bytes doc/window2.png | Bin 0 -> 1601 bytes 185 files changed, 34184 insertions(+) create mode 100644 doc/01-introduction.tex create mode 100644 doc/02-bitpacking.tex create mode 100644 doc/03-codebook.tex create mode 100644 doc/04-codec.tex create mode 100644 doc/05-comment.tex create mode 100644 doc/06-floor0.tex create mode 100644 doc/07-floor1.tex create mode 100644 doc/08-residue.tex create mode 100644 doc/09-helper.tex create mode 100644 doc/10-tables.tex create mode 100644 doc/Doxyfile.in create mode 100644 doc/Makefile.am create mode 100644 doc/Vorbis_I_spec.cfg create mode 100644 doc/Vorbis_I_spec.css create mode 100644 doc/Vorbis_I_spec.html create mode 100644 doc/Vorbis_I_spec.pdf create mode 100644 doc/Vorbis_I_spec.tex create mode 100644 doc/Vorbis_I_spec0x.png create mode 100644 doc/Vorbis_I_spec10x.png create mode 100644 doc/Vorbis_I_spec11x.png create mode 100644 doc/Vorbis_I_spec12x.png create mode 100644 doc/Vorbis_I_spec13x.png create mode 100644 doc/Vorbis_I_spec14x.png create mode 100644 doc/Vorbis_I_spec1x.png create mode 100644 doc/Vorbis_I_spec2x.png create mode 100644 doc/Vorbis_I_spec3x.png create mode 100644 doc/Vorbis_I_spec4x.png create mode 100644 doc/Vorbis_I_spec5x.png create mode 100644 doc/Vorbis_I_spec6x.png create mode 100644 doc/Vorbis_I_spec7x.png create mode 100644 doc/Vorbis_I_spec8x.png create mode 100644 doc/Vorbis_I_spec9x.png create mode 100644 doc/a1-encapsulation-ogg.tex create mode 100644 doc/a2-encapsulation-rtp.tex create mode 100644 doc/components.png create mode 100644 doc/eightphase.png create mode 100644 doc/fish_xiph_org.png create mode 100644 doc/floor1-1.png create mode 100644 doc/floor1-2.png create mode 100644 doc/floor1-3.png create mode 100644 doc/floor1-4.png create mode 100644 doc/floor1_inverse_dB_table.html create mode 100644 doc/floorval.png create mode 100644 doc/footer.tex create mode 100644 doc/fourphase.png create mode 100644 doc/framing.html create mode 100644 doc/helper.html create mode 100644 doc/hufftree-under.png create mode 100644 doc/hufftree.png create mode 100644 doc/index.html create mode 100644 doc/libvorbis/Makefile.am create mode 100644 doc/libvorbis/index.html create mode 100644 doc/libvorbis/overview.html create mode 100644 doc/libvorbis/reference.html create mode 100644 doc/libvorbis/return.html create mode 100644 doc/libvorbis/style.css create mode 100644 doc/libvorbis/vorbis_analysis.html create mode 100644 doc/libvorbis/vorbis_analysis_blockout.html create mode 100644 doc/libvorbis/vorbis_analysis_buffer.html create mode 100644 doc/libvorbis/vorbis_analysis_headerout.html create mode 100644 doc/libvorbis/vorbis_analysis_init.html create mode 100644 doc/libvorbis/vorbis_analysis_wrote.html create mode 100644 doc/libvorbis/vorbis_bitrate_addblock.html create mode 100644 doc/libvorbis/vorbis_bitrate_flushpacket.html create mode 100644 doc/libvorbis/vorbis_block.html create mode 100644 doc/libvorbis/vorbis_block_clear.html create mode 100644 doc/libvorbis/vorbis_block_init.html create mode 100644 doc/libvorbis/vorbis_comment.html create mode 100644 doc/libvorbis/vorbis_comment_add.html create mode 100644 doc/libvorbis/vorbis_comment_add_tag.html create mode 100644 doc/libvorbis/vorbis_comment_clear.html create mode 100644 doc/libvorbis/vorbis_comment_init.html create mode 100644 doc/libvorbis/vorbis_comment_query.html create mode 100644 doc/libvorbis/vorbis_comment_query_count.html create mode 100644 doc/libvorbis/vorbis_commentheader_out.html create mode 100644 doc/libvorbis/vorbis_dsp_clear.html create mode 100644 doc/libvorbis/vorbis_dsp_state.html create mode 100644 doc/libvorbis/vorbis_granule_time.html create mode 100644 doc/libvorbis/vorbis_info.html create mode 100644 doc/libvorbis/vorbis_info_blocksize.html create mode 100644 doc/libvorbis/vorbis_info_clear.html create mode 100644 doc/libvorbis/vorbis_info_init.html create mode 100644 doc/libvorbis/vorbis_packet_blocksize.html create mode 100644 doc/libvorbis/vorbis_synthesis.html create mode 100644 doc/libvorbis/vorbis_synthesis_blockin.html create mode 100644 doc/libvorbis/vorbis_synthesis_halfrate.html create mode 100644 doc/libvorbis/vorbis_synthesis_halfrate_p.html create mode 100644 doc/libvorbis/vorbis_synthesis_headerin.html create mode 100644 doc/libvorbis/vorbis_synthesis_idheader.html create mode 100644 doc/libvorbis/vorbis_synthesis_init.html create mode 100644 doc/libvorbis/vorbis_synthesis_lapout.html create mode 100644 doc/libvorbis/vorbis_synthesis_pcmout.html create mode 100644 doc/libvorbis/vorbis_synthesis_read.html create mode 100644 doc/libvorbis/vorbis_synthesis_restart.html create mode 100644 doc/libvorbis/vorbis_synthesis_trackonly.html create mode 100644 doc/libvorbis/vorbis_version_string.html create mode 100644 doc/oggstream.html create mode 100644 doc/programming.html create mode 100644 doc/release.txt create mode 100644 doc/residue-pack.png create mode 100644 doc/residue2.png create mode 100755 doc/rfc5215.txt create mode 100755 doc/rfc5215.xml create mode 100644 doc/squarepolar.png create mode 100644 doc/stereo.html create mode 100644 doc/stream.png create mode 100644 doc/v-comment.html create mode 100644 doc/vorbis-clip.txt create mode 100644 doc/vorbis-errors.txt create mode 100644 doc/vorbis-fidelity.html create mode 100644 doc/vorbisenc/Makefile.am create mode 100644 doc/vorbisenc/changes.html create mode 100644 doc/vorbisenc/examples.html create mode 100644 doc/vorbisenc/index.html create mode 100644 doc/vorbisenc/ovectl_ratemanage2_arg.html create mode 100644 doc/vorbisenc/ovectl_ratemanage_arg.html create mode 100644 doc/vorbisenc/overview.html create mode 100644 doc/vorbisenc/reference.html create mode 100644 doc/vorbisenc/style.css create mode 100644 doc/vorbisenc/vorbis_encode_ctl.html create mode 100644 doc/vorbisenc/vorbis_encode_init.html create mode 100644 doc/vorbisenc/vorbis_encode_init_vbr.html create mode 100644 doc/vorbisenc/vorbis_encode_setup_init.html create mode 100644 doc/vorbisenc/vorbis_encode_setup_managed.html create mode 100644 doc/vorbisenc/vorbis_encode_setup_vbr.html create mode 100644 doc/vorbisfile/Makefile.am create mode 100644 doc/vorbisfile/OggVorbis_File.html create mode 100644 doc/vorbisfile/callbacks.html create mode 100644 doc/vorbisfile/chaining_example_c.html create mode 100644 doc/vorbisfile/chainingexample.html create mode 100644 doc/vorbisfile/crosslap.html create mode 100644 doc/vorbisfile/datastructures.html create mode 100644 doc/vorbisfile/decoding.html create mode 100644 doc/vorbisfile/example.html create mode 100644 doc/vorbisfile/exampleindex.html create mode 100644 doc/vorbisfile/fileinfo.html create mode 100644 doc/vorbisfile/index.html create mode 100644 doc/vorbisfile/initialization.html create mode 100644 doc/vorbisfile/ov_bitrate.html create mode 100644 doc/vorbisfile/ov_bitrate_instant.html create mode 100644 doc/vorbisfile/ov_callbacks.html create mode 100644 doc/vorbisfile/ov_clear.html create mode 100644 doc/vorbisfile/ov_comment.html create mode 100644 doc/vorbisfile/ov_crosslap.html create mode 100644 doc/vorbisfile/ov_fopen.html create mode 100644 doc/vorbisfile/ov_info.html create mode 100644 doc/vorbisfile/ov_open.html create mode 100644 doc/vorbisfile/ov_open_callbacks.html create mode 100644 doc/vorbisfile/ov_pcm_seek.html create mode 100644 doc/vorbisfile/ov_pcm_seek_lap.html create mode 100644 doc/vorbisfile/ov_pcm_seek_page.html create mode 100644 doc/vorbisfile/ov_pcm_seek_page_lap.html create mode 100644 doc/vorbisfile/ov_pcm_tell.html create mode 100644 doc/vorbisfile/ov_pcm_total.html create mode 100644 doc/vorbisfile/ov_raw_seek.html create mode 100644 doc/vorbisfile/ov_raw_seek_lap.html create mode 100644 doc/vorbisfile/ov_raw_tell.html create mode 100644 doc/vorbisfile/ov_raw_total.html create mode 100644 doc/vorbisfile/ov_read.html create mode 100644 doc/vorbisfile/ov_read_filter.html create mode 100644 doc/vorbisfile/ov_read_float.html create mode 100644 doc/vorbisfile/ov_seekable.html create mode 100644 doc/vorbisfile/ov_serialnumber.html create mode 100644 doc/vorbisfile/ov_streams.html create mode 100644 doc/vorbisfile/ov_test.html create mode 100644 doc/vorbisfile/ov_test_callbacks.html create mode 100644 doc/vorbisfile/ov_test_open.html create mode 100644 doc/vorbisfile/ov_time_seek.html create mode 100644 doc/vorbisfile/ov_time_seek_lap.html create mode 100644 doc/vorbisfile/ov_time_seek_page.html create mode 100644 doc/vorbisfile/ov_time_seek_page_lap.html create mode 100644 doc/vorbisfile/ov_time_tell.html create mode 100644 doc/vorbisfile/ov_time_total.html create mode 100644 doc/vorbisfile/overview.html create mode 100644 doc/vorbisfile/reference.html create mode 100644 doc/vorbisfile/seekexample.html create mode 100644 doc/vorbisfile/seeking.html create mode 100644 doc/vorbisfile/seeking_example_c.html create mode 100644 doc/vorbisfile/seeking_test_c.html create mode 100644 doc/vorbisfile/seekingexample.html create mode 100644 doc/vorbisfile/style.css create mode 100644 doc/vorbisfile/threads.html create mode 100644 doc/vorbisfile/vorbisfile_example_c.html create mode 100644 doc/window1.png create mode 100644 doc/window2.png (limited to 'doc') diff --git a/doc/01-introduction.tex b/doc/01-introduction.tex new file mode 100644 index 0000000..d7767df --- /dev/null +++ b/doc/01-introduction.tex @@ -0,0 +1,528 @@ +% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*- +%!TEX root = Vorbis_I_spec.tex +\section{Introduction and Description} \label{vorbis:spec:intro} + +\subsection{Overview} + +This document provides a high level description of the Vorbis codec's +construction. A bit-by-bit specification appears beginning in +\xref{vorbis:spec:codec}. +The later sections assume a high-level +understanding of the Vorbis decode process, which is +provided here. + +\subsubsection{Application} +Vorbis is a general purpose perceptual audio CODEC intended to allow +maximum encoder flexibility, thus allowing it to scale competitively +over an exceptionally wide range of bitrates. At the high +quality/bitrate end of the scale (CD or DAT rate stereo, 16/24 bits) +it is in the same league as MPEG-2 and MPC. Similarly, the 1.0 +encoder can encode high-quality CD and DAT rate stereo at below 48kbps +without resampling to a lower rate. Vorbis is also intended for +lower and higher sample rates (from 8kHz telephony to 192kHz digital +masters) and a range of channel representations (monaural, +polyphonic, stereo, quadraphonic, 5.1, ambisonic, or up to 255 +discrete channels). + + +\subsubsection{Classification} +Vorbis I is a forward-adaptive monolithic transform CODEC based on the +Modified Discrete Cosine Transform. The codec is structured to allow +addition of a hybrid wavelet filterbank in Vorbis II to offer better +transient response and reproduction using a transform better suited to +localized time events. + + +\subsubsection{Assumptions} + +The Vorbis CODEC design assumes a complex, psychoacoustically-aware +encoder and simple, low-complexity decoder. Vorbis decode is +computationally simpler than mp3, although it does require more +working memory as Vorbis has no static probability model; the vector +codebooks used in the first stage of decoding from the bitstream are +packed in their entirety into the Vorbis bitstream headers. In +packed form, these codebooks occupy only a few kilobytes; the extent +to which they are pre-decoded into a cache is the dominant factor in +decoder memory usage. + + +Vorbis provides none of its own framing, synchronization or protection +against errors; it is solely a method of accepting input audio, +dividing it into individual frames and compressing these frames into +raw, unformatted 'packets'. The decoder then accepts these raw +packets in sequence, decodes them, synthesizes audio frames from +them, and reassembles the frames into a facsimile of the original +audio stream. Vorbis is a free-form variable bit rate (VBR) codec and packets have no +minimum size, maximum size, or fixed/expected size. Packets +are designed that they may be truncated (or padded) and remain +decodable; this is not to be considered an error condition and is used +extensively in bitrate management in peeling. Both the transport +mechanism and decoder must allow that a packet may be any size, or +end before or after packet decode expects. + +Vorbis packets are thus intended to be used with a transport mechanism +that provides free-form framing, sync, positioning and error correction +in accordance with these design assumptions, such as Ogg (for file +transport) or RTP (for network multicast). For purposes of a few +examples in this document, we will assume that Vorbis is to be +embedded in an Ogg stream specifically, although this is by no means a +requirement or fundamental assumption in the Vorbis design. + +The specification for embedding Vorbis into +an Ogg transport stream is in \xref{vorbis:over:ogg}. + + + +\subsubsection{Codec Setup and Probability Model} + +Vorbis' heritage is as a research CODEC and its current design +reflects a desire to allow multiple decades of continuous encoder +improvement before running out of room within the codec specification. +For these reasons, configurable aspects of codec setup intentionally +lean toward the extreme of forward adaptive. + +The single most controversial design decision in Vorbis (and the most +unusual for a Vorbis developer to keep in mind) is that the entire +probability model of the codec, the Huffman and VQ codebooks, is +packed into the bitstream header along with extensive CODEC setup +parameters (often several hundred fields). This makes it impossible, +as it would be with MPEG audio layers, to embed a simple frame type +flag in each audio packet, or begin decode at any frame in the stream +without having previously fetched the codec setup header. + + +\begin{note} +Vorbis \emph{can} initiate decode at any arbitrary packet within a +bitstream so long as the codec has been initialized/setup with the +setup headers. +\end{note} + +Thus, Vorbis headers are both required for decode to begin and +relatively large as bitstream headers go. The header size is +unbounded, although for streaming a rule-of-thumb of 4kB or less is +recommended (and Xiph.Org's Vorbis encoder follows this suggestion). + +Our own design work indicates the primary liability of the +required header is in mindshare; it is an unusual design and thus +causes some amount of complaint among engineers as this runs against +current design trends (and also points out limitations in some +existing software/interface designs, such as Windows' ACM codec +framework). However, we find that it does not fundamentally limit +Vorbis' suitable application space. + + +\subsubsection{Format Specification} +The Vorbis format is well-defined by its decode specification; any +encoder that produces packets that are correctly decoded by the +reference Vorbis decoder described below may be considered a proper +Vorbis encoder. A decoder must faithfully and completely implement +the specification defined below (except where noted) to be considered +a proper Vorbis decoder. + +\subsubsection{Hardware Profile} +Although Vorbis decode is computationally simple, it may still run +into specific limitations of an embedded design. For this reason, +embedded designs are allowed to deviate in limited ways from the +`full' decode specification yet still be certified compliant. These +optional omissions are labelled in the spec where relevant. + + +\subsection{Decoder Configuration} + +Decoder setup consists of configuration of multiple, self-contained +component abstractions that perform specific functions in the decode +pipeline. Each different component instance of a specific type is +semantically interchangeable; decoder configuration consists both of +internal component configuration, as well as arrangement of specific +instances into a decode pipeline. Componentry arrangement is roughly +as follows: + +\begin{center} +\includegraphics[width=\textwidth]{components} +\captionof{figure}{decoder pipeline configuration} +\end{center} + +\subsubsection{Global Config} +Global codec configuration consists of a few audio related fields +(sample rate, channels), Vorbis version (always '0' in Vorbis I), +bitrate hints, and the lists of component instances. All other +configuration is in the context of specific components. + +\subsubsection{Mode} + +Each Vorbis frame is coded according to a master 'mode'. A bitstream +may use one or many modes. + +The mode mechanism is used to encode a frame according to one of +multiple possible methods with the intention of choosing a method best +suited to that frame. Different modes are, e.g. how frame size +is changed from frame to frame. The mode number of a frame serves as a +top level configuration switch for all other specific aspects of frame +decode. + +A 'mode' configuration consists of a frame size setting, window type +(always 0, the Vorbis window, in Vorbis I), transform type (always +type 0, the MDCT, in Vorbis I) and a mapping number. The mapping +number specifies which mapping configuration instance to use for +low-level packet decode and synthesis. + + +\subsubsection{Mapping} + +A mapping contains a channel coupling description and a list of +'submaps' that bundle sets of channel vectors together for grouped +encoding and decoding. These submaps are not references to external +components; the submap list is internal and specific to a mapping. + +A 'submap' is a configuration/grouping that applies to a subset of +floor and residue vectors within a mapping. The submap functions as a +last layer of indirection such that specific special floor or residue +settings can be applied not only to all the vectors in a given mode, +but also specific vectors in a specific mode. Each submap specifies +the proper floor and residue instance number to use for decoding that +submap's spectral floor and spectral residue vectors. + +As an example: + +Assume a Vorbis stream that contains six channels in the standard 5.1 +format. The sixth channel, as is normal in 5.1, is bass only. +Therefore it would be wasteful to encode a full-spectrum version of it +as with the other channels. The submapping mechanism can be used to +apply a full range floor and residue encoding to channels 0 through 4, +and a bass-only representation to the bass channel, thus saving space. +In this example, channels 0-4 belong to submap 0 (which indicates use +of a full-range floor) and channel 5 belongs to submap 1, which uses a +bass-only representation. + + +\subsubsection{Floor} + +Vorbis encodes a spectral 'floor' vector for each PCM channel. This +vector is a low-resolution representation of the audio spectrum for +the given channel in the current frame, generally used akin to a +whitening filter. It is named a 'floor' because the Xiph.Org +reference encoder has historically used it as a unit-baseline for +spectral resolution. + +A floor encoding may be of two types. Floor 0 uses a packed LSP +representation on a dB amplitude scale and Bark frequency scale. +Floor 1 represents the curve as a piecewise linear interpolated +representation on a dB amplitude scale and linear frequency scale. +The two floors are semantically interchangeable in +encoding/decoding. However, floor type 1 provides more stable +inter-frame behavior, and so is the preferred choice in all +coupled-stereo and high bitrate modes. Floor 1 is also considerably +less expensive to decode than floor 0. + +Floor 0 is not to be considered deprecated, but it is of limited +modern use. No known Vorbis encoder past Xiph.Org's own beta 4 makes +use of floor 0. + +The values coded/decoded by a floor are both compactly formatted and +make use of entropy coding to save space. For this reason, a floor +configuration generally refers to multiple codebooks in the codebook +component list. Entropy coding is thus provided as an abstraction, +and each floor instance may choose from any and all available +codebooks when coding/decoding. + + +\subsubsection{Residue} +The spectral residue is the fine structure of the audio spectrum +once the floor curve has been subtracted out. In simplest terms, it +is coded in the bitstream using cascaded (multi-pass) vector +quantization according to one of three specific packing/coding +algorithms numbered 0 through 2. The packing algorithm details are +configured by residue instance. As with the floor components, the +final VQ/entropy encoding is provided by external codebook instances +and each residue instance may choose from any and all available +codebooks. + +\subsubsection{Codebooks} + +Codebooks are a self-contained abstraction that perform entropy +decoding and, optionally, use the entropy-decoded integer value as an +offset into an index of output value vectors, returning the indicated +vector of values. + +The entropy coding in a Vorbis I codebook is provided by a standard +Huffman binary tree representation. This tree is tightly packed using +one of several methods, depending on whether codeword lengths are +ordered or unordered, or the tree is sparse. + +The codebook vector index is similarly packed according to index +characteristic. Most commonly, the vector index is encoded as a +single list of values of possible values that are then permuted into +a list of n-dimensional rows (lattice VQ). + + + +\subsection{High-level Decode Process} + +\subsubsection{Decode Setup} + +Before decoding can begin, a decoder must initialize using the +bitstream headers matching the stream to be decoded. Vorbis uses +three header packets; all are required, in-order, by this +specification. Once set up, decode may begin at any audio packet +belonging to the Vorbis stream. In Vorbis I, all packets after the +three initial headers are audio packets. + +The header packets are, in order, the identification +header, the comments header, and the setup header. + +\paragraph{Identification Header} +The identification header identifies the bitstream as Vorbis, Vorbis +version, and the simple audio characteristics of the stream such as +sample rate and number of channels. + +\paragraph{Comment Header} +The comment header includes user text comments (``tags'') and a vendor +string for the application/library that produced the bitstream. The +encoding and proper use of the comment header is described in \xref{vorbis:spec:comment}. + +\paragraph{Setup Header} +The setup header includes extensive CODEC setup information as well as +the complete VQ and Huffman codebooks needed for decode. + + +\subsubsection{Decode Procedure} + +The decoding and synthesis procedure for all audio packets is +fundamentally the same. +\begin{enumerate} +\item decode packet type flag +\item decode mode number +\item decode window shape (long windows only) +\item decode floor +\item decode residue into residue vectors +\item inverse channel coupling of residue vectors +\item generate floor curve from decoded floor data +\item compute dot product of floor and residue, producing audio spectrum vector +\item inverse monolithic transform of audio spectrum vector, always an MDCT in Vorbis I +\item overlap/add left-hand output of transform with right-hand output of previous frame +\item store right hand-data from transform of current frame for future lapping +\item if not first frame, return results of overlap/add as audio result of current frame +\end{enumerate} + +Note that clever rearrangement of the synthesis arithmetic is +possible; as an example, one can take advantage of symmetries in the +MDCT to store the right-hand transform data of a partial MDCT for a +50\% inter-frame buffer space savings, and then complete the transform +later before overlap/add with the next frame. This optimization +produces entirely equivalent output and is naturally perfectly legal. +The decoder must be \emph{entirely mathematically equivalent} to the +specification, it need not be a literal semantic implementation. + +\paragraph{Packet type decode} + +Vorbis I uses four packet types. The first three packet types mark each +of the three Vorbis headers described above. The fourth packet type +marks an audio packet. All other packet types are reserved; packets +marked with a reserved type should be ignored. + +Following the three header packets, all packets in a Vorbis I stream +are audio. The first step of audio packet decode is to read and +verify the packet type; \emph{a non-audio packet when audio is expected +indicates stream corruption or a non-compliant stream. The decoder +must ignore the packet and not attempt decoding it to +audio}. + + + + +\paragraph{Mode decode} +Vorbis allows an encoder to set up multiple, numbered packet 'modes', +as described earlier, all of which may be used in a given Vorbis +stream. The mode is encoded as an integer used as a direct offset into +the mode instance index. + + +\paragraph{Window shape decode (long windows only)} \label{vorbis:spec:window} + +Vorbis frames may be one of two PCM sample sizes specified during +codec setup. In Vorbis I, legal frame sizes are powers of two from 64 +to 8192 samples. Aside from coupling, Vorbis handles channels as +independent vectors and these frame sizes are in samples per channel. + +Vorbis uses an overlapping transform, namely the MDCT, to blend one +frame into the next, avoiding most inter-frame block boundary +artifacts. The MDCT output of one frame is windowed according to MDCT +requirements, overlapped 50\% with the output of the previous frame and +added. The window shape assures seamless reconstruction. + +This is easy to visualize in the case of equal sized-windows: + +\begin{center} +\includegraphics[width=\textwidth]{window1} +\captionof{figure}{overlap of two equal-sized windows} +\end{center} + +And slightly more complex in the case of overlapping unequal sized +windows: + +\begin{center} +\includegraphics[width=\textwidth]{window2} +\captionof{figure}{overlap of a long and a short window} +\end{center} + +In the unequal-sized window case, the window shape of the long window +must be modified for seamless lapping as above. It is possible to +correctly infer window shape to be applied to the current window from +knowing the sizes of the current, previous and next window. It is +legal for a decoder to use this method. However, in the case of a long +window (short windows require no modification), Vorbis also codes two +flag bits to specify pre- and post- window shape. Although not +strictly necessary for function, this minor redundancy allows a packet +to be fully decoded to the point of lapping entirely independently of +any other packet, allowing easier abstraction of decode layers as well +as allowing a greater level of easy parallelism in encode and +decode. + +A description of valid window functions for use with an inverse MDCT +can be found in \cite{Sporer/Brandenburg/Edler}. Vorbis windows +all use the slope function +\[ y = \sin(.5*\pi \, \sin^2((x+.5)/n*\pi)) . \] + + + +\paragraph{floor decode} +Each floor is encoded/decoded in channel order, however each floor +belongs to a 'submap' that specifies which floor configuration to +use. All floors are decoded before residue decode begins. + + +\paragraph{residue decode} + +Although the number of residue vectors equals the number of channels, +channel coupling may mean that the raw residue vectors extracted +during decode do not map directly to specific channels. When channel +coupling is in use, some vectors will correspond to coupled magnitude +or angle. The coupling relationships are described in the codec setup +and may differ from frame to frame, due to different mode numbers. + +Vorbis codes residue vectors in groups by submap; the coding is done +in submap order from submap 0 through n-1. This differs from floors +which are coded using a configuration provided by submap number, but +are coded individually in channel order. + + + +\paragraph{inverse channel coupling} + +A detailed discussion of stereo in the Vorbis codec can be found in +the document \href{stereo.html}{Stereo Channel Coupling in the +Vorbis CODEC}. Vorbis is not limited to only stereo coupling, but +the stereo document also gives a good overview of the generic coupling +mechanism. + +Vorbis coupling applies to pairs of residue vectors at a time; +decoupling is done in-place a pair at a time in the order and using +the vectors specified in the current mapping configuration. The +decoupling operation is the same for all pairs, converting square +polar representation (where one vector is magnitude and the second +angle) back to Cartesian representation. + +After decoupling, in order, each pair of vectors on the coupling list, +the resulting residue vectors represent the fine spectral detail +of each output channel. + + + +\paragraph{generate floor curve} + +The decoder may choose to generate the floor curve at any appropriate +time. It is reasonable to generate the output curve when the floor +data is decoded from the raw packet, or it can be generated after +inverse coupling and applied to the spectral residue directly, +combining generation and the dot product into one step and eliminating +some working space. + +Both floor 0 and floor 1 generate a linear-range, linear-domain output +vector to be multiplied (dot product) by the linear-range, +linear-domain spectral residue. + + + +\paragraph{compute floor/residue dot product} + +This step is straightforward; for each output channel, the decoder +multiplies the floor curve and residue vectors element by element, +producing the finished audio spectrum of each channel. + +% TODO/FIXME: The following two paragraphs have identical twins +% in section 4 (under "dot product") +One point is worth mentioning about this dot product; a common mistake +in a fixed point implementation might be to assume that a 32 bit +fixed-point representation for floor and residue and direct +multiplication of the vectors is sufficient for acceptable spectral +depth in all cases because it happens to mostly work with the current +Xiph.Org reference encoder. + +However, floor vector values can span \~{}140dB (\~{}24 bits unsigned), and +the audio spectrum vector should represent a minimum of 120dB (\~{}21 +bits with sign), even when output is to a 16 bit PCM device. For the +residue vector to represent full scale if the floor is nailed to +$-140$dB, it must be able to span 0 to $+140$dB. For the residue vector +to reach full scale if the floor is nailed at 0dB, it must be able to +represent $-140$dB to $+0$dB. Thus, in order to handle full range +dynamics, a residue vector may span $-140$dB to $+140$dB entirely within +spec. A 280dB range is approximately 48 bits with sign; thus the +residue vector must be able to represent a 48 bit range and the dot +product must be able to handle an effective 48 bit times 24 bit +multiplication. This range may be achieved using large (64 bit or +larger) integers, or implementing a movable binary point +representation. + + + +\paragraph{inverse monolithic transform (MDCT)} + +The audio spectrum is converted back into time domain PCM audio via an +inverse Modified Discrete Cosine Transform (MDCT). A detailed +description of the MDCT is available in \cite{Sporer/Brandenburg/Edler}. + +Note that the PCM produced directly from the MDCT is not yet finished +audio; it must be lapped with surrounding frames using an appropriate +window (such as the Vorbis window) before the MDCT can be considered +orthogonal. + + + +\paragraph{overlap/add data} +Windowed MDCT output is overlapped and added with the right hand data +of the previous window such that the 3/4 point of the previous window +is aligned with the 1/4 point of the current window (as illustrated in +the window overlap diagram). At this point, the audio data between the +center of the previous frame and the center of the current frame is +now finished and ready to be returned. + + +\paragraph{cache right hand data} +The decoder must cache the right hand portion of the current frame to +be lapped with the left hand portion of the next frame. + + + +\paragraph{return finished audio data} + +The overlapped portion produced from overlapping the previous and +current frame data is finished data to be returned by the decoder. +This data spans from the center of the previous window to the center +of the current window. In the case of same-sized windows, the amount +of data to return is one-half block consisting of and only of the +overlapped portions. When overlapping a short and long window, much of +the returned range is not actually overlap. This does not damage +transform orthogonality. Pay attention however to returning the +correct data range; the amount of data to be returned is: + +\begin{Verbatim}[commandchars=\\\{\}] +window\_blocksize(previous\_window)/4+window\_blocksize(current\_window)/4 +\end{Verbatim} + +from the center of the previous window to the center of the current +window. + +Data is not returned from the first frame; it must be used to 'prime' +the decode engine. The encoder accounts for this priming when +calculating PCM offsets; after the first frame, the proper PCM output +offset is '0' (as no data has been returned yet). diff --git a/doc/02-bitpacking.tex b/doc/02-bitpacking.tex new file mode 100644 index 0000000..905dcaf --- /dev/null +++ b/doc/02-bitpacking.tex @@ -0,0 +1,246 @@ +% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*- +%!TEX root = Vorbis_I_spec.tex +\section{Bitpacking Convention} \label{vorbis:spec:bitpacking} + +\subsection{Overview} + +The Vorbis codec uses relatively unstructured raw packets containing +arbitrary-width binary integer fields. Logically, these packets are a +bitstream in which bits are coded one-by-one by the encoder and then +read one-by-one in the same monotonically increasing order by the +decoder. Most current binary storage arrangements group bits into a +native word size of eight bits (octets), sixteen bits, thirty-two bits +or, less commonly other fixed word sizes. The Vorbis bitpacking +convention specifies the correct mapping of the logical packet +bitstream into an actual representation in fixed-width words. + + +\subsubsection{octets, bytes and words} + +In most contemporary architectures, a 'byte' is synonymous with an +'octet', that is, eight bits. This has not always been the case; +seven, ten, eleven and sixteen bit 'bytes' have been used. For +purposes of the bitpacking convention, a byte implies the native, +smallest integer storage representation offered by a platform. On +modern platforms, this is generally assumed to be eight bits (not +necessarily because of the processor but because of the +filesystem/memory architecture. Modern filesystems invariably offer +bytes as the fundamental atom of storage). A 'word' is an integer +size that is a grouped multiple of this smallest size. + +The most ubiquitous architectures today consider a 'byte' to be an +octet (eight bits) and a word to be a group of two, four or eight +bytes (16, 32 or 64 bits). Note however that the Vorbis bitpacking +convention is still well defined for any native byte size; Vorbis uses +the native bit-width of a given storage system. This document assumes +that a byte is one octet for purposes of example. + +\subsubsection{bit order} + +A byte has a well-defined 'least significant' bit (LSb), which is the +only bit set when the byte is storing the two's complement integer +value +1. A byte's 'most significant' bit (MSb) is at the opposite +end of the byte. Bits in a byte are numbered from zero at the LSb to +$n$ ($n=7$ in an octet) for the +MSb. + + + +\subsubsection{byte order} + +Words are native groupings of multiple bytes. Several byte orderings +are possible in a word; the common ones are 3-2-1-0 ('big endian' or +'most significant byte first' in which the highest-valued byte comes +first), 0-1-2-3 ('little endian' or 'least significant byte first' in +which the lowest value byte comes first) and less commonly 3-1-2-0 and +0-2-1-3 ('mixed endian'). + +The Vorbis bitpacking convention specifies storage and bitstream +manipulation at the byte, not word, level, thus host word ordering is +of a concern only during optimization when writing high performance +code that operates on a word of storage at a time rather than by byte. +Logically, bytes are always coded and decoded in order from byte zero +through byte $n$. + + + +\subsubsection{coding bits into byte sequences} + +The Vorbis codec has need to code arbitrary bit-width integers, from +zero to 32 bits wide, into packets. These integer fields are not +aligned to the boundaries of the byte representation; the next field +is written at the bit position at which the previous field ends. + +The encoder logically packs integers by writing the LSb of a binary +integer to the logical bitstream first, followed by next least +significant bit, etc, until the requested number of bits have been +coded. When packing the bits into bytes, the encoder begins by +placing the LSb of the integer to be written into the least +significant unused bit position of the destination byte, followed by +the next-least significant bit of the source integer and so on up to +the requested number of bits. When all bits of the destination byte +have been filled, encoding continues by zeroing all bits of the next +byte and writing the next bit into the bit position 0 of that byte. +Decoding follows the same process as encoding, but by reading bits +from the byte stream and reassembling them into integers. + + + +\subsubsection{signedness} + +The signedness of a specific number resulting from decode is to be +interpreted by the decoder given decode context. That is, the three +bit binary pattern 'b111' can be taken to represent either 'seven' as +an unsigned integer, or '-1' as a signed, two's complement integer. +The encoder and decoder are responsible for knowing if fields are to +be treated as signed or unsigned. + + + +\subsubsection{coding example} + +Code the 4 bit integer value '12' [b1100] into an empty bytestream. +Bytestream result: + +\begin{Verbatim}[commandchars=\\\{\}] + | + V + + 7 6 5 4 3 2 1 0 +byte 0 [0 0 0 0 1 1 0 0] <- +byte 1 [ ] +byte 2 [ ] +byte 3 [ ] + ... +byte n [ ] bytestream length == 1 byte + +\end{Verbatim} + + +Continue by coding the 3 bit integer value '-1' [b111]: + +\begin{Verbatim}[commandchars=\\\{\}] + | + V + + 7 6 5 4 3 2 1 0 +byte 0 [0 1 1 1 1 1 0 0] <- +byte 1 [ ] +byte 2 [ ] +byte 3 [ ] + ... +byte n [ ] bytestream length == 1 byte +\end{Verbatim} + + +Continue by coding the 7 bit integer value '17' [b0010001]: + +\begin{Verbatim}[commandchars=\\\{\}] + | + V + + 7 6 5 4 3 2 1 0 +byte 0 [1 1 1 1 1 1 0 0] +byte 1 [0 0 0 0 1 0 0 0] <- +byte 2 [ ] +byte 3 [ ] + ... +byte n [ ] bytestream length == 2 bytes + bit cursor == 6 +\end{Verbatim} + + +Continue by coding the 13 bit integer value '6969' [b110 11001110 01]: + +\begin{Verbatim}[commandchars=\\\{\}] + | + V + + 7 6 5 4 3 2 1 0 +byte 0 [1 1 1 1 1 1 0 0] +byte 1 [0 1 0 0 1 0 0 0] +byte 2 [1 1 0 0 1 1 1 0] +byte 3 [0 0 0 0 0 1 1 0] <- + ... +byte n [ ] bytestream length == 4 bytes + +\end{Verbatim} + + + + +\subsubsection{decoding example} + +Reading from the beginning of the bytestream encoded in the above example: + +\begin{Verbatim}[commandchars=\\\{\}] + | + V + + 7 6 5 4 3 2 1 0 +byte 0 [1 1 1 1 1 1 0 0] <- +byte 1 [0 1 0 0 1 0 0 0] +byte 2 [1 1 0 0 1 1 1 0] +byte 3 [0 0 0 0 0 1 1 0] bytestream length == 4 bytes + +\end{Verbatim} + + +We read two, two-bit integer fields, resulting in the returned numbers +'b00' and 'b11'. Two things are worth noting here: + +\begin{itemize} +\item Although these four bits were originally written as a single +four-bit integer, reading some other combination of bit-widths from the +bitstream is well defined. There are no artificial alignment +boundaries maintained in the bitstream. + +\item The second value is the +two-bit-wide integer 'b11'. This value may be interpreted either as +the unsigned value '3', or the signed value '-1'. Signedness is +dependent on decode context. +\end{itemize} + + + + +\subsubsection{end-of-packet alignment} + +The typical use of bitpacking is to produce many independent +byte-aligned packets which are embedded into a larger byte-aligned +container structure, such as an Ogg transport bitstream. Externally, +each bytestream (encoded bitstream) must begin and end on a byte +boundary. Often, the encoded bitstream is not an integer number of +bytes, and so there is unused (uncoded) space in the last byte of a +packet. + +Unused space in the last byte of a bytestream is always zeroed during +the coding process. Thus, should this unused space be read, it will +return binary zeroes. + +Attempting to read past the end of an encoded packet results in an +'end-of-packet' condition. End-of-packet is not to be considered an +error; it is merely a state indicating that there is insufficient +remaining data to fulfill the desired read size. Vorbis uses truncated +packets as a normal mode of operation, and as such, decoders must +handle reading past the end of a packet as a typical mode of +operation. Any further read operations after an 'end-of-packet' +condition shall also return 'end-of-packet'. + + + +\subsubsection{reading zero bits} + +Reading a zero-bit-wide integer returns the value '0' and does not +increment the stream cursor. Reading to the end of the packet (but +not past, such that an 'end-of-packet' condition has not triggered) +and then reading a zero bit integer shall succeed, returning 0, and +not trigger an end-of-packet condition. Reading a zero-bit-wide +integer after a previous read sets 'end-of-packet' shall also fail +with 'end-of-packet'. + + + + + + diff --git a/doc/03-codebook.tex b/doc/03-codebook.tex new file mode 100644 index 0000000..11516a3 --- /dev/null +++ b/doc/03-codebook.tex @@ -0,0 +1,456 @@ +% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*- +%!TEX root = Vorbis_I_spec.tex +\section{Probability Model and Codebooks} \label{vorbis:spec:codebook} + +\subsection{Overview} + +Unlike practically every other mainstream audio codec, Vorbis has no +statically configured probability model, instead packing all entropy +decoding configuration, VQ and Huffman, into the bitstream itself in +the third header, the codec setup header. This packed configuration +consists of multiple 'codebooks', each containing a specific +Huffman-equivalent representation for decoding compressed codewords as +well as an optional lookup table of output vector values to which a +decoded Huffman value is applied as an offset, generating the final +decoded output corresponding to a given compressed codeword. + +\subsubsection{Bitwise operation} +The codebook mechanism is built on top of the vorbis bitpacker. Both +the codebooks themselves and the codewords they decode are unrolled +from a packet as a series of arbitrary-width values read from the +stream according to \xref{vorbis:spec:bitpacking}. + + + + +\subsection{Packed codebook format} + +For purposes of the examples below, we assume that the storage +system's native byte width is eight bits. This is not universally +true; see \xref{vorbis:spec:bitpacking} for discussion +relating to non-eight-bit bytes. + +\subsubsection{codebook decode} + +A codebook begins with a 24 bit sync pattern, 0x564342: + +\begin{Verbatim}[commandchars=\\\{\}] +byte 0: [ 0 1 0 0 0 0 1 0 ] (0x42) +byte 1: [ 0 1 0 0 0 0 1 1 ] (0x43) +byte 2: [ 0 1 0 1 0 1 1 0 ] (0x56) +\end{Verbatim} + +16 bit \varname{[codebook\_dimensions]} and 24 bit \varname{[codebook\_entries]} fields: + +\begin{Verbatim}[commandchars=\\\{\}] + +byte 3: [ X X X X X X X X ] +byte 4: [ X X X X X X X X ] [codebook\_dimensions] (16 bit unsigned) + +byte 5: [ X X X X X X X X ] +byte 6: [ X X X X X X X X ] +byte 7: [ X X X X X X X X ] [codebook\_entries] (24 bit unsigned) + +\end{Verbatim} + +Next is the \varname{[ordered]} bit flag: + +\begin{Verbatim}[commandchars=\\\{\}] + +byte 8: [ X ] [ordered] (1 bit) + +\end{Verbatim} + +Each entry, numbering a +total of \varname{[codebook\_entries]}, is assigned a codeword length. +We now read the list of codeword lengths and store these lengths in +the array \varname{[codebook\_codeword\_lengths]}. Decode of lengths is +according to whether the \varname{[ordered]} flag is set or unset. + +\begin{itemize} +\item + If the \varname{[ordered]} flag is unset, the codeword list is not + length ordered and the decoder needs to read each codeword length + one-by-one. + + The decoder first reads one additional bit flag, the + \varname{[sparse]} flag. This flag determines whether or not the + codebook contains unused entries that are not to be included in the + codeword decode tree: + +\begin{Verbatim}[commandchars=\\\{\}] +byte 8: [ X 1 ] [sparse] flag (1 bit) +\end{Verbatim} + + The decoder now performs for each of the \varname{[codebook\_entries]} + codebook entries: + +\begin{Verbatim}[commandchars=\\\{\}] + + 1) if([sparse] is set) \{ + + 2) [flag] = read one bit; + 3) if([flag] is set) \{ + + 4) [length] = read a five bit unsigned integer; + 5) codeword length for this entry is [length]+1; + + \} else \{ + + 6) this entry is unused. mark it as such. + + \} + + \} else the sparse flag is not set \{ + + 7) [length] = read a five bit unsigned integer; + 8) the codeword length for this entry is [length]+1; + + \} + +\end{Verbatim} + +\item + If the \varname{[ordered]} flag is set, the codeword list for this + codebook is encoded in ascending length order. Rather than reading + a length for every codeword, the encoder reads the number of + codewords per length. That is, beginning at entry zero: + +\begin{Verbatim}[commandchars=\\\{\}] + 1) [current\_entry] = 0; + 2) [current\_length] = read a five bit unsigned integer and add 1; + 3) [number] = read \link{vorbis:spec:ilog}{ilog}([codebook\_entries] - [current\_entry]) bits as an unsigned integer + 4) set the entries [current\_entry] through [current\_entry]+[number]-1, inclusive, + of the [codebook\_codeword\_lengths] array to [current\_length] + 5) set [current\_entry] to [number] + [current\_entry] + 6) increment [current\_length] by 1 + 7) if [current\_entry] is greater than [codebook\_entries] ERROR CONDITION; + the decoder will not be able to read this stream. + 8) if [current\_entry] is less than [codebook\_entries], repeat process starting at 3) + 9) done. +\end{Verbatim} + +\end{itemize} + +After all codeword lengths have been decoded, the decoder reads the +vector lookup table. Vorbis I supports three lookup types: +\begin{enumerate} +\item +No lookup +\item +Implicitly populated value mapping (lattice VQ) +\item +Explicitly populated value mapping (tessellated or 'foam' +VQ) +\end{enumerate} + + +The lookup table type is read as a four bit unsigned integer: +\begin{Verbatim}[commandchars=\\\{\}] + 1) [codebook\_lookup\_type] = read four bits as an unsigned integer +\end{Verbatim} + +Codebook decode precedes according to \varname{[codebook\_lookup\_type]}: +\begin{itemize} +\item +Lookup type zero indicates no lookup to be read. Proceed past +lookup decode. +\item +Lookup types one and two are similar, differing only in the +number of lookup values to be read. Lookup type one reads a list of +values that are permuted in a set pattern to build a list of vectors, +each vector of order \varname{[codebook\_dimensions]} scalars. Lookup +type two builds the same vector list, but reads each scalar for each +vector explicitly, rather than building vectors from a smaller list of +possible scalar values. Lookup decode proceeds as follows: + +\begin{Verbatim}[commandchars=\\\{\}] + 1) [codebook\_minimum\_value] = \link{vorbis:spec:float32:unpack}{float32\_unpack}( read 32 bits as an unsigned integer) + 2) [codebook\_delta\_value] = \link{vorbis:spec:float32:unpack}{float32\_unpack}( read 32 bits as an unsigned integer) + 3) [codebook\_value\_bits] = read 4 bits as an unsigned integer and add 1 + 4) [codebook\_sequence\_p] = read 1 bit as a boolean flag + + if ( [codebook\_lookup\_type] is 1 ) \{ + + 5) [codebook\_lookup\_values] = \link{vorbis:spec:lookup1:values}{lookup1\_values}(\varname{[codebook\_entries]}, \varname{[codebook\_dimensions]} ) + + \} else \{ + + 6) [codebook\_lookup\_values] = \varname{[codebook\_entries]} * \varname{[codebook\_dimensions]} + + \} + + 7) read a total of [codebook\_lookup\_values] unsigned integers of [codebook\_value\_bits] each; + store these in order in the array [codebook\_multiplicands] +\end{Verbatim} +\item +A \varname{[codebook\_lookup\_type]} of greater than two is reserved +and indicates a stream that is not decodable by the specification in this +document. + +\end{itemize} + + +An 'end of packet' during any read operation in the above steps is +considered an error condition rendering the stream undecodable. + +\paragraph{Huffman decision tree representation} + +The \varname{[codebook\_codeword\_lengths]} array and +\varname{[codebook\_entries]} value uniquely define the Huffman decision +tree used for entropy decoding. + +Briefly, each used codebook entry (recall that length-unordered +codebooks support unused codeword entries) is assigned, in order, the +lowest valued unused binary Huffman codeword possible. Assume the +following codeword length list: + +\begin{Verbatim}[commandchars=\\\{\}] +entry 0: length 2 +entry 1: length 4 +entry 2: length 4 +entry 3: length 4 +entry 4: length 4 +entry 5: length 2 +entry 6: length 3 +entry 7: length 3 +\end{Verbatim} + +Assigning codewords in order (lowest possible value of the appropriate +length to highest) results in the following codeword list: + +\begin{Verbatim}[commandchars=\\\{\}] +entry 0: length 2 codeword 00 +entry 1: length 4 codeword 0100 +entry 2: length 4 codeword 0101 +entry 3: length 4 codeword 0110 +entry 4: length 4 codeword 0111 +entry 5: length 2 codeword 10 +entry 6: length 3 codeword 110 +entry 7: length 3 codeword 111 +\end{Verbatim} + + +\begin{note} +Unlike most binary numerical values in this document, we +intend the above codewords to be read and used bit by bit from left to +right, thus the codeword '001' is the bit string 'zero, zero, one'. +When determining 'lowest possible value' in the assignment definition +above, the leftmost bit is the MSb. +\end{note} + +It is clear that the codeword length list represents a Huffman +decision tree with the entry numbers equivalent to the leaves numbered +left-to-right: + +\begin{center} +\includegraphics[width=10cm]{hufftree} +\captionof{figure}{huffman tree illustration} +\end{center} + + +As we assign codewords in order, we see that each choice constructs a +new leaf in the leftmost possible position. + +Note that it's possible to underspecify or overspecify a Huffman tree +via the length list. In the above example, if codeword seven were +eliminated, it's clear that the tree is unfinished: + +\begin{center} +\includegraphics[width=10cm]{hufftree-under} +\captionof{figure}{underspecified huffman tree illustration} +\end{center} + + +Similarly, in the original codebook, it's clear that the tree is fully +populated and a ninth codeword is impossible. Both underspecified and +overspecified trees are an error condition rendering the stream +undecodable. + +Codebook entries marked 'unused' are simply skipped in the assigning +process. They have no codeword and do not appear in the decision +tree, thus it's impossible for any bit pattern read from the stream to +decode to that entry number. + +\paragraph{Errata 20150226: Single entry codebooks} + +A 'single-entry codebook' is a codebook with one active codeword +entry. A single-entry codebook may be either a fully populated +codebook with only one declared entry, or a sparse codebook with only +one entry marked used. The Vorbis I spec provides no means to specify +a codeword length of zero, and as a result, a single-entry codebook is +inherently malformed because it is underpopulated. The original +specification did not address directly the matter of single-entry +codebooks; they were implicitly illegal as it was not possible to +write such a codebook with a valid tree structure. + +In r14811 of the libvorbis reference implementation, Xiph added an +additional check to the codebook implementation to reject +underpopulated Huffman trees. This change led to the discovery of +single-entry books used 'in the wild' when the new, stricter checks +rejected a number of apparently working streams. + +In order to minimize breakage of deployed (if technically erroneous) +streams, r16073 of the reference implementation explicitly +special-cased single-entry codebooks to tolerate the single-entry +case. Commit r16073 also added the following to the specification: + +\blockquote{\sout{Take special care that a codebook with a single used + entry is handled properly; it consists of a single codework of + zero bits and ’reading’ a value out of such a codebook always + returns the single used value and sinks zero bits. +}} + +The intent was to clarify the spec and codify current practice. +However, this addition is erroneously at odds with the intent of preserving +usability of existing streams using single-entry codebooks, disagrees +with the code changes that reinstated decoding, and does not address how +single-entry codebooks should be encoded. + +As such, the above addition made in r16037 is struck from the +specification and replaced by the following: + +\blockquote{It is possible to declare a Vorbis codebook containing a + single codework entry. A single-entry codebook may be either a + fully populated codebook with \varname{[codebook\_entries]} set to + 1, or a sparse codebook marking only one entry used. Note that it + is not possible to also encode a \varname{[codeword\_length]} of + zero for the single used codeword, as the unsigned value written to + the stream is \varname{[codeword\_length]-1}. Instead, encoder + implementations should indicate a \varname{[codeword\_length]} of 1 + and 'write' the codeword to a stream during audio encoding by + writing a single zero bit. + + Decoder implementations shall reject a codebook if it contains only + one used entry and the encoded \varname{[codeword\_length]} of that + entry is not 1. 'Reading' a value from single-entry codebook always + returns the single used codeword value and sinks one bit. Decoders + should tolerate that the bit read from the stream be '1' instead of + '0'; both values shall return the single used codeword.} + +\paragraph{VQ lookup table vector representation} + +Unpacking the VQ lookup table vectors relies on the following values: +\begin{programlisting} +the [codebook\_multiplicands] array +[codebook\_minimum\_value] +[codebook\_delta\_value] +[codebook\_sequence\_p] +[codebook\_lookup\_type] +[codebook\_entries] +[codebook\_dimensions] +[codebook\_lookup\_values] +\end{programlisting} + +\bigskip + +Decoding (unpacking) a specific vector in the vector lookup table +proceeds according to \varname{[codebook\_lookup\_type]}. The unpacked +vector values are what a codebook would return during audio packet +decode in a VQ context. + +\paragraph{Vector value decode: Lookup type 1} + +Lookup type one specifies a lattice VQ lookup table built +algorithmically from a list of scalar values. Calculate (unpack) the +final values of a codebook entry vector from the entries in +\varname{[codebook\_multiplicands]} as follows (\varname{[value\_vector]} +is the output vector representing the vector of values for entry number +\varname{[lookup\_offset]} in this codebook): + +\begin{Verbatim}[commandchars=\\\{\}] + 1) [last] = 0; + 2) [index\_divisor] = 1; + 3) iterate [i] over the range 0 ... [codebook\_dimensions]-1 (once for each scalar value in the value vector) \{ + + 4) [multiplicand\_offset] = ( [lookup\_offset] divided by [index\_divisor] using integer + division ) integer modulo [codebook\_lookup\_values] + + 5) vector [value\_vector] element [i] = + ( [codebook\_multiplicands] array element number [multiplicand\_offset] ) * + [codebook\_delta\_value] + [codebook\_minimum\_value] + [last]; + + 6) if ( [codebook\_sequence\_p] is set ) then set [last] = vector [value\_vector] element [i] + + 7) [index\_divisor] = [index\_divisor] * [codebook\_lookup\_values] + + \} + + 8) vector calculation completed. +\end{Verbatim} + + + +\paragraph{Vector value decode: Lookup type 2} + +Lookup type two specifies a VQ lookup table in which each scalar in +each vector is explicitly set by the \varname{[codebook\_multiplicands]} +array in a one-to-one mapping. Calculate [unpack] the +final values of a codebook entry vector from the entries in +\varname{[codebook\_multiplicands]} as follows (\varname{[value\_vector]} +is the output vector representing the vector of values for entry number +\varname{[lookup\_offset]} in this codebook): + +\begin{Verbatim}[commandchars=\\\{\}] + 1) [last] = 0; + 2) [multiplicand\_offset] = [lookup\_offset] * [codebook\_dimensions] + 3) iterate [i] over the range 0 ... [codebook\_dimensions]-1 (once for each scalar value in the value vector) \{ + + 4) vector [value\_vector] element [i] = + ( [codebook\_multiplicands] array element number [multiplicand\_offset] ) * + [codebook\_delta\_value] + [codebook\_minimum\_value] + [last]; + + 5) if ( [codebook\_sequence\_p] is set ) then set [last] = vector [value\_vector] element [i] + + 6) increment [multiplicand\_offset] + + \} + + 7) vector calculation completed. +\end{Verbatim} + + + + + + + + + +\subsection{Use of the codebook abstraction} + +The decoder uses the codebook abstraction much as it does the +bit-unpacking convention; a specific codebook reads a +codeword from the bitstream, decoding it into an entry number, and then +returns that entry number to the decoder (when used in a scalar +entropy coding context), or uses that entry number as an offset into +the VQ lookup table, returning a vector of values (when used in a context +desiring a VQ value). Scalar or VQ context is always explicit; any call +to the codebook mechanism requests either a scalar entry number or a +lookup vector. + +Note that VQ lookup type zero indicates that there is no lookup table; +requesting decode using a codebook of lookup type 0 in any context +expecting a vector return value (even in a case where a vector of +dimension one) is forbidden. If decoder setup or decode requests such +an action, that is an error condition rendering the packet +undecodable. + +Using a codebook to read from the packet bitstream consists first of +reading and decoding the next codeword in the bitstream. The decoder +reads bits until the accumulated bits match a codeword in the +codebook. This process can be though of as logically walking the +Huffman decode tree by reading one bit at a time from the bitstream, +and using the bit as a decision boolean to take the 0 branch (left in +the above examples) or the 1 branch (right in the above examples). +Walking the tree finishes when the decode process hits a leaf in the +decision tree; the result is the entry number corresponding to that +leaf. Reading past the end of a packet propagates the 'end-of-stream' +condition to the decoder. + +When used in a scalar context, the resulting codeword entry is the +desired return value. + +When used in a VQ context, the codeword entry number is used as an +offset into the VQ lookup table. The value returned to the decoder is +the vector of scalars corresponding to this offset. diff --git a/doc/04-codec.tex b/doc/04-codec.tex new file mode 100644 index 0000000..333c227 --- /dev/null +++ b/doc/04-codec.tex @@ -0,0 +1,660 @@ + +% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*- +%!TEX root = Vorbis_I_spec.tex +\section{Codec Setup and Packet Decode} \label{vorbis:spec:codec} + +\subsection{Overview} + +This document serves as the top-level reference document for the +bit-by-bit decode specification of Vorbis I. This document assumes a +high-level understanding of the Vorbis decode process, which is +provided in \xref{vorbis:spec:intro}. \xref{vorbis:spec:bitpacking} covers reading and writing bit fields from +and to bitstream packets. + + + +\subsection{Header decode and decode setup} + +A Vorbis bitstream begins with three header packets. The header +packets are, in order, the identification header, the comments header, +and the setup header. All are required for decode compliance. An +end-of-packet condition during decoding the first or third header +packet renders the stream undecodable. End-of-packet decoding the +comment header is a non-fatal error condition. + +\subsubsection{Common header decode} + +Each header packet begins with the same header fields. + + +\begin{Verbatim}[commandchars=\\\{\}] + 1) [packet\_type] : 8 bit value + 2) 0x76, 0x6f, 0x72, 0x62, 0x69, 0x73: the characters 'v','o','r','b','i','s' as six octets +\end{Verbatim} + +Decode continues according to packet type; the identification header +is type 1, the comment header type 3 and the setup header type 5 +(these types are all odd as a packet with a leading single bit of '0' +is an audio packet). The packets must occur in the order of +identification, comment, setup. + + + +\subsubsection{Identification header} + +The identification header is a short header of only a few fields used +to declare the stream definitively as Vorbis, and provide a few externally +relevant pieces of information about the audio stream. The +identification header is coded as follows: + +\begin{Verbatim}[commandchars=\\\{\}] + 1) [vorbis\_version] = read 32 bits as unsigned integer + 2) [audio\_channels] = read 8 bit integer as unsigned + 3) [audio\_sample\_rate] = read 32 bits as unsigned integer + 4) [bitrate\_maximum] = read 32 bits as signed integer + 5) [bitrate\_nominal] = read 32 bits as signed integer + 6) [bitrate\_minimum] = read 32 bits as signed integer + 7) [blocksize\_0] = 2 exponent (read 4 bits as unsigned integer) + 8) [blocksize\_1] = 2 exponent (read 4 bits as unsigned integer) + 9) [framing\_flag] = read one bit +\end{Verbatim} + +\varname{[vorbis\_version]} is to read '0' in order to be compatible +with this document. Both \varname{[audio\_channels]} and +\varname{[audio\_sample\_rate]} must read greater than zero. Allowed final +blocksize values are 64, 128, 256, 512, 1024, 2048, 4096 and 8192 in +Vorbis I. \varname{[blocksize\_0]} must be less than or equal to +\varname{[blocksize\_1]}. The framing bit must be nonzero. Failure to +meet any of these conditions renders a stream undecodable. + +The bitrate fields above are used only as hints. The nominal bitrate +field especially may be considerably off in purely VBR streams. The +fields are meaningful only when greater than zero. + +\begin{itemize} + \item All three fields set to the same value implies a fixed rate, or tightly bounded, nearly fixed-rate bitstream + \item Only nominal set implies a VBR or ABR stream that averages the nominal bitrate + \item Maximum and or minimum set implies a VBR bitstream that obeys the bitrate limits + \item None set indicates the encoder does not care to speculate. +\end{itemize} + + + + +\subsubsection{Comment header} +Comment header decode and data specification is covered in +\xref{vorbis:spec:comment}. + + +\subsubsection{Setup header} + +Vorbis codec setup is configurable to an extreme degree: + +\begin{center} +\includegraphics[width=\textwidth]{components} +\captionof{figure}{decoder pipeline configuration} +\end{center} + + +The setup header contains the bulk of the codec setup information +needed for decode. The setup header contains, in order, the lists of +codebook configurations, time-domain transform configurations +(placeholders in Vorbis I), floor configurations, residue +configurations, channel mapping configurations and mode +configurations. It finishes with a framing bit of '1'. Header decode +proceeds in the following order: + +\paragraph{Codebooks} + +\begin{enumerate} +\item \varname{[vorbis\_codebook\_count]} = read eight bits as unsigned integer and add one +\item Decode \varname{[vorbis\_codebook\_count]} codebooks in order as defined +in \xref{vorbis:spec:codebook}. Save each configuration, in +order, in an array of +codebook configurations \varname{[vorbis\_codebook\_configurations]}. +\end{enumerate} + + + +\paragraph{Time domain transforms} + +These hooks are placeholders in Vorbis I. Nevertheless, the +configuration placeholder values must be read to maintain bitstream +sync. + +\begin{enumerate} +\item \varname{[vorbis\_time\_count]} = read 6 bits as unsigned integer and add one +\item read \varname{[vorbis\_time\_count]} 16 bit values; each value should be zero. If any value is nonzero, this is an error condition and the stream is undecodable. +\end{enumerate} + + + +\paragraph{Floors} + +Vorbis uses two floor types; header decode is handed to the decode +abstraction of the appropriate type. + +\begin{enumerate} + \item \varname{[vorbis\_floor\_count]} = read 6 bits as unsigned integer and add one + \item For each \varname{[i]} of \varname{[vorbis\_floor\_count]} floor numbers: + \begin{enumerate} + \item read the floor type: vector \varname{[vorbis\_floor\_types]} element \varname{[i]} = +read 16 bits as unsigned integer + \item If the floor type is zero, decode the floor +configuration as defined in \xref{vorbis:spec:floor0}; save +this +configuration in slot \varname{[i]} of the floor configuration array \varname{[vorbis\_floor\_configurations]}. + \item If the floor type is one, +decode the floor configuration as defined in \xref{vorbis:spec:floor1}; save this configuration in slot \varname{[i]} of the floor configuration array \varname{[vorbis\_floor\_configurations]}. + \item If the the floor type is greater than one, this stream is undecodable; ERROR CONDITION + \end{enumerate} + +\end{enumerate} + + + +\paragraph{Residues} + +Vorbis uses three residue types; header decode of each type is identical. + + +\begin{enumerate} +\item \varname{[vorbis\_residue\_count]} = read 6 bits as unsigned integer and add one + +\item For each of \varname{[vorbis\_residue\_count]} residue numbers: + \begin{enumerate} + \item read the residue type; vector \varname{[vorbis\_residue\_types]} element \varname{[i]} = read 16 bits as unsigned integer + \item If the residue type is zero, +one or two, decode the residue configuration as defined in \xref{vorbis:spec:residue}; save this configuration in slot \varname{[i]} of the residue configuration array \varname{[vorbis\_residue\_configurations]}. + \item If the the residue type is greater than two, this stream is undecodable; ERROR CONDITION + \end{enumerate} + +\end{enumerate} + + + +\paragraph{Mappings} + +Mappings are used to set up specific pipelines for encoding +multichannel audio with varying channel mapping applications. Vorbis I +uses a single mapping type (0), with implicit PCM channel mappings. + +% FIXME/TODO: LaTeX cannot nest enumerate that deeply, so I have to use +% itemize at the innermost level. However, it would be much better to +% rewrite this pseudocode using listings or algoritmicx or some other +% package geared towards this. +\begin{enumerate} + \item \varname{[vorbis\_mapping\_count]} = read 6 bits as unsigned integer and add one + \item For each \varname{[i]} of \varname{[vorbis\_mapping\_count]} mapping numbers: + \begin{enumerate} + \item read the mapping type: 16 bits as unsigned integer. There's no reason to save the mapping type in Vorbis I. + \item If the mapping type is nonzero, the stream is undecodable + \item If the mapping type is zero: + \begin{enumerate} + \item read 1 bit as a boolean flag + \begin{enumerate} + \item if set, \varname{[vorbis\_mapping\_submaps]} = read 4 bits as unsigned integer and add one + \item if unset, \varname{[vorbis\_mapping\_submaps]} = 1 + \end{enumerate} + + + \item read 1 bit as a boolean flag + \begin{enumerate} + \item if set, square polar channel mapping is in use: + \begin{itemize} + \item \varname{[vorbis\_mapping\_coupling\_steps]} = read 8 bits as unsigned integer and add one + \item for \varname{[j]} each of \varname{[vorbis\_mapping\_coupling\_steps]} steps: + \begin{itemize} + \item vector \varname{[vorbis\_mapping\_magnitude]} element \varname{[j]}= read \link{vorbis:spec:ilog}{ilog}(\varname{[audio\_channels]} - 1) bits as unsigned integer + \item vector \varname{[vorbis\_mapping\_angle]} element \varname{[j]}= read \link{vorbis:spec:ilog}{ilog}(\varname{[audio\_channels]} - 1) bits as unsigned integer + \item the numbers read in the above two steps are channel numbers representing the channel to treat as magnitude and the channel to treat as angle, respectively. If for any coupling step the angle channel number equals the magnitude channel number, the magnitude channel number is greater than \varname{[audio\_channels]}-1, or the angle channel is greater than \varname{[audio\_channels]}-1, the stream is undecodable. + \end{itemize} + + + \end{itemize} + + + \item if unset, \varname{[vorbis\_mapping\_coupling\_steps]} = 0 + \end{enumerate} + + + \item read 2 bits (reserved field); if the value is nonzero, the stream is undecodable + \item if \varname{[vorbis\_mapping\_submaps]} is greater than one, we read channel multiplex settings. For each \varname{[j]} of \varname{[audio\_channels]} channels: + \begin{enumerate} + \item vector \varname{[vorbis\_mapping\_mux]} element \varname{[j]} = read 4 bits as unsigned integer + \item if the value is greater than the highest numbered submap (\varname{[vorbis\_mapping\_submaps]} - 1), this in an error condition rendering the stream undecodable + \end{enumerate} + + \item for each submap \varname{[j]} of \varname{[vorbis\_mapping\_submaps]} submaps, read the floor and residue numbers for use in decoding that submap: + \begin{enumerate} + \item read and discard 8 bits (the unused time configuration placeholder) + \item read 8 bits as unsigned integer for the floor number; save in vector \varname{[vorbis\_mapping\_submap\_floor]} element \varname{[j]} + \item verify the floor number is not greater than the highest number floor configured for the bitstream. If it is, the bitstream is undecodable + \item read 8 bits as unsigned integer for the residue number; save in vector \varname{[vorbis\_mapping\_submap\_residue]} element \varname{[j]} + \item verify the residue number is not greater than the highest number residue configured for the bitstream. If it is, the bitstream is undecodable + \end{enumerate} + + \item save this mapping configuration in slot \varname{[i]} of the mapping configuration array \varname{[vorbis\_mapping\_configurations]}. + \end{enumerate} + + \end{enumerate} + +\end{enumerate} + + + +\paragraph{Modes} + +\begin{enumerate} + \item \varname{[vorbis\_mode\_count]} = read 6 bits as unsigned integer and add one + \item For each of \varname{[vorbis\_mode\_count]} mode numbers: + \begin{enumerate} + \item \varname{[vorbis\_mode\_blockflag]} = read 1 bit + \item \varname{[vorbis\_mode\_windowtype]} = read 16 bits as unsigned integer + \item \varname{[vorbis\_mode\_transformtype]} = read 16 bits as unsigned integer + \item \varname{[vorbis\_mode\_mapping]} = read 8 bits as unsigned integer + \item verify ranges; zero is the only legal value in Vorbis I for +\varname{[vorbis\_mode\_windowtype]} +and \varname{[vorbis\_mode\_transformtype]}. \varname{[vorbis\_mode\_mapping]} must not be greater than the highest number mapping in use. Any illegal values render the stream undecodable. + \item save this mode configuration in slot \varname{[i]} of the mode configuration array +\varname{[vorbis\_mode\_configurations]}. + \end{enumerate} + +\item read 1 bit as a framing flag. If unset, a framing error occurred and the stream is not +decodable. +\end{enumerate} + +After reading mode descriptions, setup header decode is complete. + + + + + + + + +\subsection{Audio packet decode and synthesis} + +Following the three header packets, all packets in a Vorbis I stream +are audio. The first step of audio packet decode is to read and +verify the packet type. \emph{A non-audio packet when audio is expected +indicates stream corruption or a non-compliant stream. The decoder +must ignore the packet and not attempt decoding it to audio}. + + +\subsubsection{packet type, mode and window decode} + +\begin{enumerate} + \item read 1 bit \varname{[packet\_type]}; check that packet type is 0 (audio) + \item read \link{vorbis:spec:ilog}{ilog}([vorbis\_mode\_count]-1) bits +\varname{[mode\_number]} + \item decode blocksize \varname{[n]} is equal to \varname{[blocksize\_0]} if +\varname{[vorbis\_mode\_blockflag]} is 0, else \varname{[n]} is equal to \varname{[blocksize\_1]}. + \item perform window selection and setup; this window is used later by the inverse MDCT: + \begin{enumerate} + \item if this is a long window (the \varname{[vorbis\_mode\_blockflag]} flag of this mode is +set): + \begin{enumerate} + \item read 1 bit for \varname{[previous\_window\_flag]} + \item read 1 bit for \varname{[next\_window\_flag]} + \item if \varname{[previous\_window\_flag]} is not set, the left half + of the window will be a hybrid window for lapping with a + short block. See \xref{vorbis:spec:window} for an illustration of overlapping +dissimilar + windows. Else, the left half window will have normal long + shape. + \item if \varname{[next\_window\_flag]} is not set, the right half of + the window will be a hybrid window for lapping with a short + block. See \xref{vorbis:spec:window} for an +illustration of overlapping dissimilar + windows. Else, the left right window will have normal long + shape. + \end{enumerate} + + \item if this is a short window, the window is always the same + short-window shape. + \end{enumerate} + +\end{enumerate} + +Vorbis windows all use the slope function $y=\sin(\frac{\pi}{2} * \sin^2((x+0.5)/n * \pi))$, +where $n$ is window size and $x$ ranges $0 \ldots n-1$, but dissimilar +lapping requirements can affect overall shape. Window generation +proceeds as follows: + +\begin{enumerate} + \item \varname{[window\_center]} = \varname{[n]} / 2 + \item if (\varname{[vorbis\_mode\_blockflag]} is set and \varname{[previous\_window\_flag]} is +not set) then + \begin{enumerate} + \item \varname{[left\_window\_start]} = \varname{[n]}/4 - +\varname{[blocksize\_0]}/4 + \item \varname{[left\_window\_end]} = \varname{[n]}/4 + \varname{[blocksize\_0]}/4 + \item \varname{[left\_n]} = \varname{[blocksize\_0]}/2 + \end{enumerate} + else + \begin{enumerate} + \item \varname{[left\_window\_start]} = 0 + \item \varname{[left\_window\_end]} = \varname{[window\_center]} + \item \varname{[left\_n]} = \varname{[n]}/2 + \end{enumerate} + + \item if (\varname{[vorbis\_mode\_blockflag]} is set and \varname{[next\_window\_flag]} is not +set) then + \begin{enumerate} + \item \varname{[right\_window\_start]} = \varname{[n]*3}/4 - +\varname{[blocksize\_0]}/4 + \item \varname{[right\_window\_end]} = \varname{[n]*3}/4 + +\varname{[blocksize\_0]}/4 + \item \varname{[right\_n]} = \varname{[blocksize\_0]}/2 + \end{enumerate} + else + \begin{enumerate} + \item \varname{[right\_window\_start]} = \varname{[window\_center]} + \item \varname{[right\_window\_end]} = \varname{[n]} + \item \varname{[right\_n]} = \varname{[n]}/2 + \end{enumerate} + + \item window from range 0 ... \varname{[left\_window\_start]}-1 inclusive is zero + \item for \varname{[i]} in range \varname{[left\_window\_start]} ... +\varname{[left\_window\_end]}-1, window(\varname{[i]}) = $\sin(\frac{\pi}{2} * \sin^2($ (\varname{[i]}-\varname{[left\_window\_start]}+0.5) / \varname{[left\_n]} $* \frac{\pi}{2})$ ) + \item window from range \varname{[left\_window\_end]} ... \varname{[right\_window\_start]}-1 +inclusive is one\item for \varname{[i]} in range \varname{[right\_window\_start]} ... \varname{[right\_window\_end]}-1, window(\varname{[i]}) = $\sin(\frac{\pi}{2} * \sin^2($ (\varname{[i]}-\varname{[right\_window\_start]}+0.5) / \varname{[right\_n]} $ * \frac{\pi}{2} + \frac{\pi}{2})$ ) +\item window from range \varname{[right\_window\_start]} ... \varname{[n]}-1 is +zero +\end{enumerate} + +An end-of-packet condition up to this point should be considered an +error that discards this packet from the stream. An end of packet +condition past this point is to be considered a possible nominal +occurrence. + + + +\subsubsection{floor curve decode} + +From this point on, we assume out decode context is using mode number +\varname{[mode\_number]} from configuration array +\varname{[vorbis\_mode\_configurations]} and the map number +\varname{[vorbis\_mode\_mapping]} (specified by the current mode) taken +from the mapping configuration array +\varname{[vorbis\_mapping\_configurations]}. + +Floor curves are decoded one-by-one in channel order. + +For each floor \varname{[i]} of \varname{[audio\_channels]} + \begin{enumerate} + \item \varname{[submap\_number]} = element \varname{[i]} of vector [vorbis\_mapping\_mux] + \item \varname{[floor\_number]} = element \varname{[submap\_number]} of vector +[vorbis\_submap\_floor] + \item if the floor type of this +floor (vector \varname{[vorbis\_floor\_types]} element +\varname{[floor\_number]}) is zero then decode the floor for +channel \varname{[i]} according to the +\xref{vorbis:spec:floor0-decode} + \item if the type of this floor +is one then decode the floor for channel \varname{[i]} according +to the \xref{vorbis:spec:floor1-decode} + \item save the needed decoded floor information for channel for later synthesis + \item if the decoded floor returned 'unused', set vector \varname{[no\_residue]} element +\varname{[i]} to true, else set vector \varname{[no\_residue]} element \varname{[i]} to +false + \end{enumerate} + + +An end-of-packet condition during floor decode shall result in packet +decode zeroing all channel output vectors and skipping to the +add/overlap output stage. + + + +\subsubsection{nonzero vector propagate} + +A possible result of floor decode is that a specific vector is marked +'unused' which indicates that that final output vector is all-zero +values (and the floor is zero). The residue for that vector is not +coded in the stream, save for one complication. If some vectors are +used and some are not, channel coupling could result in mixing a +zeroed and nonzeroed vector to produce two nonzeroed vectors. + +for each \varname{[i]} from 0 ... \varname{[vorbis\_mapping\_coupling\_steps]}-1 + +\begin{enumerate} + \item if either \varname{[no\_residue]} entry for channel +(\varname{[vorbis\_mapping\_magnitude]} element \varname{[i]}) +or channel +(\varname{[vorbis\_mapping\_angle]} element \varname{[i]}) +are set to false, then both must be set to false. Note that an 'unused' +floor has no decoded floor information; it is important that this is +remembered at floor curve synthesis time. +\end{enumerate} + + + + +\subsubsection{residue decode} + +Unlike floors, which are decoded in channel order, the residue vectors +are decoded in submap order. + +for each submap \varname{[i]} in order from 0 ... \varname{[vorbis\_mapping\_submaps]}-1 + +\begin{enumerate} + \item \varname{[ch]} = 0 + \item for each channel \varname{[j]} in order from 0 ... \varname{[audio\_channels]} - 1 + \begin{enumerate} + \item if channel \varname{[j]} in submap \varname{[i]} (vector \varname{[vorbis\_mapping\_mux]} element \varname{[j]} is equal to \varname{[i]}) + \begin{enumerate} + \item if vector \varname{[no\_residue]} element \varname{[j]} is true + \begin{enumerate} + \item vector \varname{[do\_not\_decode\_flag]} element \varname{[ch]} is set + \end{enumerate} + else + \begin{enumerate} + \item vector \varname{[do\_not\_decode\_flag]} element \varname{[ch]} is unset + \end{enumerate} + + \item increment \varname{[ch]} + \end{enumerate} + + \end{enumerate} + \item \varname{[residue\_number]} = vector \varname{[vorbis\_mapping\_submap\_residue]} element \varname{[i]} + \item \varname{[residue\_type]} = vector \varname{[vorbis\_residue\_types]} element \varname{[residue\_number]} + \item decode \varname{[ch]} vectors using residue \varname{[residue\_number]}, according to type \varname{[residue\_type]}, also passing vector \varname{[do\_not\_decode\_flag]} to indicate which vectors in the bundle should not be decoded. Correct per-vector decode length is \varname{[n]}/2. + \item \varname{[ch]} = 0 + \item for each channel \varname{[j]} in order from 0 ... \varname{[audio\_channels]} + \begin{enumerate} + \item if channel \varname{[j]} is in submap \varname{[i]} (vector \varname{[vorbis\_mapping\_mux]} element \varname{[j]} is equal to \varname{[i]}) + \begin{enumerate} + \item residue vector for channel \varname{[j]} is set to decoded residue vector \varname{[ch]} + \item increment \varname{[ch]} + \end{enumerate} + + \end{enumerate} + +\end{enumerate} + + + +\subsubsection{inverse coupling} + +for each \varname{[i]} from \varname{[vorbis\_mapping\_coupling\_steps]}-1 descending to 0 + +\begin{enumerate} + \item \varname{[magnitude\_vector]} = the residue vector for channel +(vector \varname{[vorbis\_mapping\_magnitude]} element \varname{[i]}) + \item \varname{[angle\_vector]} = the residue vector for channel (vector +\varname{[vorbis\_mapping\_angle]} element \varname{[i]}) + \item for each scalar value \varname{[M]} in vector \varname{[magnitude\_vector]} and the corresponding scalar value \varname{[A]} in vector \varname{[angle\_vector]}: + \begin{enumerate} + \item if (\varname{[M]} is greater than zero) + \begin{enumerate} + \item if (\varname{[A]} is greater than zero) + \begin{enumerate} + \item \varname{[new\_M]} = \varname{[M]} + \item \varname{[new\_A]} = \varname{[M]}-\varname{[A]} + \end{enumerate} + else + \begin{enumerate} + \item \varname{[new\_A]} = \varname{[M]} + \item \varname{[new\_M]} = \varname{[M]}+\varname{[A]} + \end{enumerate} + + \end{enumerate} + else + \begin{enumerate} + \item if (\varname{[A]} is greater than zero) + \begin{enumerate} + \item \varname{[new\_M]} = \varname{[M]} + \item \varname{[new\_A]} = \varname{[M]}+\varname{[A]} + \end{enumerate} + else + \begin{enumerate} + \item \varname{[new\_A]} = \varname{[M]} + \item \varname{[new\_M]} = \varname{[M]}-\varname{[A]} + \end{enumerate} + + \end{enumerate} + + \item set scalar value \varname{[M]} in vector \varname{[magnitude\_vector]} to \varname{[new\_M]} + \item set scalar value \varname{[A]} in vector \varname{[angle\_vector]} to \varname{[new\_A]} + \end{enumerate} + +\end{enumerate} + + + + +\subsubsection{dot product} + +For each channel, synthesize the floor curve from the decoded floor +information, according to packet type. Note that the vector synthesis +length for floor computation is \varname{[n]}/2. + +For each channel, multiply each element of the floor curve by each +element of that channel's residue vector. The result is the dot +product of the floor and residue vectors for each channel; the produced +vectors are the length \varname{[n]}/2 audio spectrum for each +channel. + +% TODO/FIXME: The following two paragraphs have identical twins +% in section 1 (under "compute floor/residue dot product") +One point is worth mentioning about this dot product; a common mistake +in a fixed point implementation might be to assume that a 32 bit +fixed-point representation for floor and residue and direct +multiplication of the vectors is sufficient for acceptable spectral +depth in all cases because it happens to mostly work with the current +Xiph.Org reference encoder. + +However, floor vector values can span \~140dB (\~24 bits unsigned), and +the audio spectrum vector should represent a minimum of 120dB (\~21 +bits with sign), even when output is to a 16 bit PCM device. For the +residue vector to represent full scale if the floor is nailed to +$-140$dB, it must be able to span 0 to $+140$dB. For the residue vector +to reach full scale if the floor is nailed at 0dB, it must be able to +represent $-140$dB to $+0$dB. Thus, in order to handle full range +dynamics, a residue vector may span $-140$dB to $+140$dB entirely within +spec. A 280dB range is approximately 48 bits with sign; thus the +residue vector must be able to represent a 48 bit range and the dot +product must be able to handle an effective 48 bit times 24 bit +multiplication. This range may be achieved using large (64 bit or +larger) integers, or implementing a movable binary point +representation. + + + +\subsubsection{inverse MDCT} + +Convert the audio spectrum vector of each channel back into time +domain PCM audio via an inverse Modified Discrete Cosine Transform +(MDCT). A detailed description of the MDCT is available in \cite{Sporer/Brandenburg/Edler}. The window +function used for the MDCT is the function described earlier. + + + +\subsubsection{overlap\_add} + +Windowed MDCT output is overlapped and added with the right hand data +of the previous window such that the 3/4 point of the previous window +is aligned with the 1/4 point of the current window (as illustrated in +\xref{vorbis:spec:window}). The overlapped portion +produced from overlapping the previous and current frame data is +finished data to be returned by the decoder. This data spans from the +center of the previous window to the center of the current window. In +the case of same-sized windows, the amount of data to return is +one-half block consisting of and only of the overlapped portions. When +overlapping a short and long window, much of the returned range does not +actually overlap. This does not damage transform orthogonality. Pay +attention however to returning the correct data range; the amount of +data to be returned is: + +\begin{programlisting} +window_blocksize(previous_window)/4+window_blocksize(current_window)/4 +\end{programlisting} + +from the center (element windowsize/2) of the previous window to the +center (element windowsize/2-1, inclusive) of the current window. + +Data is not returned from the first frame; it must be used to 'prime' +the decode engine. The encoder accounts for this priming when +calculating PCM offsets; after the first frame, the proper PCM output +offset is '0' (as no data has been returned yet). + + + +\subsubsection{output channel order} + +Vorbis I specifies only a channel mapping type 0. In mapping type 0, +channel mapping is implicitly defined as follows for standard audio +applications. As of revision 16781 (20100113), the specification adds +defined channel locations for 6.1 and 7.1 surround. Ordering/location +for greater-than-eight channels remains 'left to the implementation'. + +These channel orderings refer to order within the encoded stream. It +is naturally possible for a decoder to produce output with channels in +any order. Any such decoder should explicitly document channel +reordering behavior. + +\begin{description} %[style=nextline] + \item[one channel] + the stream is monophonic + +\item[two channels] + the stream is stereo. channel order: left, right + +\item[three channels] + the stream is a 1d-surround encoding. channel order: left, +center, right + +\item[four channels] + the stream is quadraphonic surround. channel order: front left, +front right, rear left, rear right + +\item[five channels] + the stream is five-channel surround. channel order: front left, +center, front right, rear left, rear right + +\item[six channels] + the stream is 5.1 surround. channel order: front left, center, +front right, rear left, rear right, LFE + +\item[seven channels] + the stream is 6.1 surround. channel order: front left, center, +front right, side left, side right, rear center, LFE + +\item[eight channels] + the stream is 7.1 surround. channel order: front left, center, +front right, side left, side right, rear left, rear right, +LFE + +\item[greater than eight channels] + channel use and order is defined by the application + +\end{description} + +Applications using Vorbis for dedicated purposes may define channel +mapping as seen fit. Future channel mappings (such as three and four +channel \href{http://www.ambisonic.net/}{Ambisonics}) will +make use of channel mappings other than mapping 0. + + diff --git a/doc/05-comment.tex b/doc/05-comment.tex new file mode 100644 index 0000000..8c804d7 --- /dev/null +++ b/doc/05-comment.tex @@ -0,0 +1,239 @@ +% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*- +%!TEX root = Vorbis_I_spec.tex +\section{comment field and header specification} \label{vorbis:spec:comment} + +\subsection{Overview} + +The Vorbis text comment header is the second (of three) header +packets that begin a Vorbis bitstream. It is meant for short text +comments, not arbitrary metadata; arbitrary metadata belongs in a +separate logical bitstream (usually an XML stream type) that provides +greater structure and machine parseability. + +The comment field is meant to be used much like someone jotting a +quick note on the bottom of a CDR. It should be a little information to +remember the disc by and explain it to others; a short, to-the-point +text note that need not only be a couple words, but isn't going to be +more than a short paragraph. The essentials, in other words, whatever +they turn out to be, eg: + +\begin{quote} +Honest Bob and the Factory-to-Dealer-Incentives, \textit{``I'm Still +Around''}, opening for Moxy Fr\"{u}vous, 1997. +\end{quote} + + + + +\subsection{Comment encoding} + +\subsubsection{Structure} + +The comment header is logically a list of eight-bit-clean vectors; the +number of vectors is bounded to $2^{32}-1$ and the length of each vector +is limited to $2^{32}-1$ bytes. The vector length is encoded; the vector +contents themselves are not null terminated. In addition to the vector +list, there is a single vector for vendor name (also 8 bit clean, +length encoded in 32 bits). For example, the 1.0 release of libvorbis +set the vendor string to ``Xiph.Org libVorbis I 20020717''. + +The vector lengths and number of vectors are stored lsb first, according +to the bit packing conventions of the vorbis codec. However, since data +in the comment header is octet-aligned, they can simply be read as +unaligned 32 bit little endian unsigned integers. + +The comment header is decoded as follows: + +\begin{programlisting} + 1) [vendor\_length] = read an unsigned integer of 32 bits + 2) [vendor\_string] = read a UTF-8 vector as [vendor\_length] octets + 3) [user\_comment\_list\_length] = read an unsigned integer of 32 bits + 4) iterate [user\_comment\_list\_length] times { + 5) [length] = read an unsigned integer of 32 bits + 6) this iteration's user comment = read a UTF-8 vector as [length] octets + } + 7) [framing\_bit] = read a single bit as boolean + 8) if ( [framing\_bit] unset or end-of-packet ) then ERROR + 9) done. +\end{programlisting} + + + + +\subsubsection{Content vector format} + +The comment vectors are structured similarly to a UNIX environment variable. +That is, comment fields consist of a field name and a corresponding value and +look like: + +\begin{quote} +\begin{programlisting} +comment[0]="ARTIST=me"; +comment[1]="TITLE=the sound of Vorbis"; +\end{programlisting} +\end{quote} + +The field name is case-insensitive and may consist of ASCII 0x20 +through 0x7D, 0x3D ('=') excluded. ASCII 0x41 through 0x5A inclusive +(characters A-Z) is to be considered equivalent to ASCII 0x61 through +0x7A inclusive (characters a-z). + + +The field name is immediately followed by ASCII 0x3D ('='); +this equals sign is used to terminate the field name. + + +0x3D is followed by 8 bit clean UTF-8 encoded value of the +field contents to the end of the field. + + +\paragraph{Field names} + +Below is a proposed, minimal list of standard field names with a +description of intended use. No single or group of field names is +mandatory; a comment header may contain one, all or none of the names +in this list. + +\begin{description} %[style=nextline] +\item[TITLE] + Track/Work name + +\item[VERSION] + The version field may be used to differentiate multiple +versions of the same track title in a single collection. (e.g. remix +info) + +\item[ALBUM] + The collection name to which this track belongs + +\item[TRACKNUMBER] + The track number of this piece if part of a specific larger collection or album + +\item[ARTIST] + The artist generally considered responsible for the work. In popular music this is usually the performing band or singer. For classical music it would be the composer. For an audio book it would be the author of the original text. + +\item[PERFORMER] + The artist(s) who performed the work. In classical music this would be the conductor, orchestra, soloists. In an audio book it would be the actor who did the reading. In popular music this is typically the same as the ARTIST and is omitted. + +\item[COPYRIGHT] + Copyright attribution, e.g., '2001 Nobody's Band' or '1999 Jack Moffitt' + +\item[LICENSE] + License information, eg, 'All Rights Reserved', 'Any +Use Permitted', a URL to a license such as a Creative Commons license +("www.creativecommons.org/blahblah/license.html") or the EFF Open +Audio License ('distributed under the terms of the Open Audio +License. see http://www.eff.org/IP/Open\_licenses/eff\_oal.html for +details'), etc. + +\item[ORGANIZATION] + Name of the organization producing the track (i.e. +the 'record label') + +\item[DESCRIPTION] + A short text description of the contents + +\item[GENRE] + A short text indication of music genre + +\item[DATE] + Date the track was recorded + +\item[LOCATION] + Location where track was recorded + +\item[CONTACT] + Contact information for the creators or distributors of the track. This could be a URL, an email address, the physical address of the producing label. + +\item[ISRC] + International Standard Recording Code for the +track; see \href{http://www.ifpi.org/isrc/}{the ISRC +intro page} for more information on ISRC numbers. + +\end{description} + + + +\paragraph{Implications} + +Field names should not be 'internationalized'; this is a +concession to simplicity not an attempt to exclude the majority of +the world that doesn't speak English. Field \emph{contents}, +however, use the UTF-8 character encoding to allow easy representation +of any language. + +We have the length of the entirety of the field and restrictions on +the field name so that the field name is bounded in a known way. Thus +we also have the length of the field contents. + +Individual 'vendors' may use non-standard field names within +reason. The proper use of comment fields should be clear through +context at this point. Abuse will be discouraged. + +There is no vendor-specific prefix to 'nonstandard' field names. +Vendors should make some effort to avoid arbitrarily polluting the +common namespace. We will generally collect the more useful tags +here to help with standardization. + +Field names are not required to be unique (occur once) within a +comment header. As an example, assume a track was recorded by three +well know artists; the following is permissible, and encouraged: + +\begin{quote} +\begin{programlisting} +ARTIST=Dizzy Gillespie +ARTIST=Sonny Rollins +ARTIST=Sonny Stitt +\end{programlisting} +\end{quote} + + + + + + + +\subsubsection{Encoding} + +The comment header comprises the entirety of the second bitstream +header packet. Unlike the first bitstream header packet, it is not +generally the only packet on the second page and may not be restricted +to within the second bitstream page. The length of the comment header +packet is (practically) unbounded. The comment header packet is not +optional; it must be present in the bitstream even if it is +effectively empty. + +The comment header is encoded as follows (as per Ogg's standard +bitstream mapping which renders least-significant-bit of the word to be +coded into the least significant available bit of the current +bitstream octet first): + +\begin{enumerate} + \item + Vendor string length (32 bit unsigned quantity specifying number of octets) + + \item + Vendor string ([vendor string length] octets coded from beginning of string to end of string, not null terminated) + + \item + Number of comment fields (32 bit unsigned quantity specifying number of fields) + + \item + Comment field 0 length (if [Number of comment fields] $>0$; 32 bit unsigned quantity specifying number of octets) + + \item + Comment field 0 ([Comment field 0 length] octets coded from beginning of string to end of string, not null terminated) + + \item + Comment field 1 length (if [Number of comment fields] $>1$...)... + +\end{enumerate} + + +This is actually somewhat easier to describe in code; implementation of the above can be found in \filename{vorbis/lib/info.c}, \function{\_vorbis\_pack\_comment()} and \function{\_vorbis\_unpack\_comment()}. + + + + + + diff --git a/doc/06-floor0.tex b/doc/06-floor0.tex new file mode 100644 index 0000000..f3042a6 --- /dev/null +++ b/doc/06-floor0.tex @@ -0,0 +1,201 @@ +% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*- +%!TEX root = Vorbis_I_spec.tex +\section{Floor type 0 setup and decode} \label{vorbis:spec:floor0} + +\subsection{Overview} + +Vorbis floor type zero uses Line Spectral Pair (LSP, also alternately +known as Line Spectral Frequency or LSF) representation to encode a +smooth spectral envelope curve as the frequency response of the LSP +filter. This representation is equivalent to a traditional all-pole +infinite impulse response filter as would be used in linear predictive +coding; LSP representation may be converted to LPC representation and +vice-versa. + + + +\subsection{Floor 0 format} + +Floor zero configuration consists of six integer fields and a list of +VQ codebooks for use in coding/decoding the LSP filter coefficient +values used by each frame. + +\subsubsection{header decode} + +Configuration information for instances of floor zero decodes from the +codec setup header (third packet). configuration decode proceeds as +follows: + +\begin{Verbatim}[commandchars=\\\{\}] + 1) [floor0\_order] = read an unsigned integer of 8 bits + 2) [floor0\_rate] = read an unsigned integer of 16 bits + 3) [floor0\_bark\_map\_size] = read an unsigned integer of 16 bits + 4) [floor0\_amplitude\_bits] = read an unsigned integer of six bits + 5) [floor0\_amplitude\_offset] = read an unsigned integer of eight bits + 6) [floor0\_number\_of\_books] = read an unsigned integer of four bits and add 1 + 7) array [floor0\_book\_list] = read a list of [floor0\_number\_of\_books] unsigned integers of eight bits each; +\end{Verbatim} + +An end-of-packet condition during any of these bitstream reads renders +this stream undecodable. In addition, any element of the array +\varname{[floor0\_book\_list]} that is greater than the maximum codebook +number for this bitstream is an error condition that also renders the +stream undecodable. + + + +\subsubsection{packet decode} \label{vorbis:spec:floor0-decode} + +Extracting a floor0 curve from an audio packet consists of first +decoding the curve amplitude and \varname{[floor0\_order]} LSP +coefficient values from the bitstream, and then computing the floor +curve, which is defined as the frequency response of the decoded LSP +filter. + +Packet decode proceeds as follows: +\begin{Verbatim}[commandchars=\\\{\}] + 1) [amplitude] = read an unsigned integer of [floor0\_amplitude\_bits] bits + 2) if ( [amplitude] is greater than zero ) \{ + 3) [coefficients] is an empty, zero length vector + 4) [booknumber] = read an unsigned integer of \link{vorbis:spec:ilog}{ilog}( [floor0\_number\_of\_books] ) bits + 5) if ( [booknumber] is greater than the highest number decode codebook ) then packet is undecodable + 6) [last] = zero; + 7) vector [temp\_vector] = read vector from bitstream using codebook number [floor0\_book\_list] element [booknumber] in VQ context. + 8) add the scalar value [last] to each scalar in vector [temp\_vector] + 9) [last] = the value of the last scalar in vector [temp\_vector] + 10) concatenate [temp\_vector] onto the end of the [coefficients] vector + 11) if (length of vector [coefficients] is less than [floor0\_order], continue at step 6 + + \} + + 12) done. + +\end{Verbatim} + +Take note of the following properties of decode: +\begin{itemize} + \item An \varname{[amplitude]} value of zero must result in a return code that indicates this channel is unused in this frame (the output of the channel will be all-zeroes in synthesis). Several later stages of decode don't occur for an unused channel. + \item An end-of-packet condition during decode should be considered a +nominal occruence; if end-of-packet is reached during any read +operation above, floor decode is to return 'unused' status as if the +\varname{[amplitude]} value had read zero at the beginning of decode. + + \item The book number used for decode +can, in fact, be stored in the bitstream in \link{vorbis:spec:ilog}{ilog}( \varname{[floor0\_number\_of\_books]} - +1 ) bits. Nevertheless, the above specification is correct and values +greater than the maximum possible book value are reserved. + + \item The number of scalars read into the vector \varname{[coefficients]} +may be greater than \varname{[floor0\_order]}, the number actually +required for curve computation. For example, if the VQ codebook used +for the floor currently being decoded has a +\varname{[codebook\_dimensions]} value of three and +\varname{[floor0\_order]} is ten, the only way to fill all the needed +scalars in \varname{[coefficients]} is to to read a total of twelve +scalars as four vectors of three scalars each. This is not an error +condition, and care must be taken not to allow a buffer overflow in +decode. The extra values are not used and may be ignored or discarded. +\end{itemize} + + + + +\subsubsection{curve computation} \label{vorbis:spec:floor0-synth} + +Given an \varname{[amplitude]} integer and \varname{[coefficients]} +vector from packet decode as well as the [floor0\_order], +[floor0\_rate], [floor0\_bark\_map\_size], [floor0\_amplitude\_bits] and +[floor0\_amplitude\_offset] values from floor setup, and an output +vector size \varname{[n]} specified by the decode process, we compute a +floor output vector. + +If the value \varname{[amplitude]} is zero, the return value is a +length \varname{[n]} vector with all-zero scalars. Otherwise, begin by +assuming the following definitions for the given vector to be +synthesized: + + \begin{displaymath} + \mathrm{map}_i = \left\{ + \begin{array}{ll} + \min ( + \mathtt{floor0\texttt{\_}bark\texttt{\_}map\texttt{\_}size} - 1, + foobar + ) & \textrm{for } i \in [0,n-1] \\ + -1 & \textrm{for } i = n + \end{array} + \right. + \end{displaymath} + + where + + \begin{displaymath} + foobar = + \left\lfloor + \mathrm{bark}\left(\frac{\mathtt{floor0\texttt{\_}rate} \cdot i}{2n}\right) \cdot \frac{\mathtt{floor0\texttt{\_}bark\texttt{\_}map\texttt{\_}size}} {\mathrm{bark}(.5 \cdot \mathtt{floor0\texttt{\_}rate})} + \right\rfloor + \end{displaymath} + + and + + \begin{displaymath} + \mathrm{bark}(x) = 13.1 \arctan (.00074x) + 2.24 \arctan (.0000000185x^2) + .0001x + \end{displaymath} + +The above is used to synthesize the LSP curve on a Bark-scale frequency +axis, then map the result to a linear-scale frequency axis. +Similarly, the below calculation synthesizes the output LSP curve \varname{[output]} on a log +(dB) amplitude scale, mapping it to linear amplitude in the last step: + +\begin{enumerate} + \item \varname{[i]} = 0 + \item \varname{[$\omega$]} = $\pi$ * map element \varname{[i]} / \varname{[floor0\_bark\_map\_size]} + \item if ( \varname{[floor0\_order]} is odd ) { + \begin{enumerate} + \item calculate \varname{[p]} and \varname{[q]} according to: + \begin{eqnarray*} + p & = & (1 - \cos^2\omega)\prod_{j=0}^{\frac{\mathtt{floor0\texttt{\_}order}-3}{2}} 4 (\cos([\mathtt{coefficients}]_{2j+1}) - \cos \omega)^2 \\ + q & = & \frac{1}{4} \prod_{j=0}^{\frac{\mathtt{floor0\texttt{\_}order}-1}{2}} 4 (\cos([\mathtt{coefficients}]_{2j}) - \cos \omega)^2 + \end{eqnarray*} + + \end{enumerate} + } else \varname{[floor0\_order]} is even { + \begin{enumerate}[resume] + \item calculate \varname{[p]} and \varname{[q]} according to: + \begin{eqnarray*} + p & = & \frac{(1 - \cos\omega)}{2} \prod_{j=0}^{\frac{\mathtt{floor0\texttt{\_}order}-2}{2}} 4 (\cos([\mathtt{coefficients}]_{2j+1}) - \cos \omega)^2 \\ + q & = & \frac{(1 + \cos\omega)}{2} \prod_{j=0}^{\frac{\mathtt{floor0\texttt{\_}order}-2}{2}} 4 (\cos([\mathtt{coefficients}]_{2j}) - \cos \omega)^2 + \end{eqnarray*} + + \end{enumerate} + } + + \item calculate \varname{[linear\_floor\_value]} according to: + \begin{displaymath} + \exp \left( .11512925 \left(\frac{\mathtt{amplitude} \cdot \mathtt{floor0\texttt{\_}amplitute\texttt{\_}offset}}{(2^{\mathtt{floor0\texttt{\_}amplitude\texttt{\_}bits}}-1)\sqrt{p+q}} + - \mathtt{floor0\texttt{\_}amplitude\texttt{\_}offset} \right) \right) + \end{displaymath} + + \item \varname{[iteration\_condition]} = map element \varname{[i]} + \item \varname{[output]} element \varname{[i]} = \varname{[linear\_floor\_value]} + \item increment \varname{[i]} + \item if ( map element \varname{[i]} is equal to \varname{[iteration\_condition]} ) continue at step 5 + \item if ( \varname{[i]} is less than \varname{[n]} ) continue at step 2 + \item done +\end{enumerate} + +\paragraph{Errata 20150227: Bark scale computation} + +Due to a typo when typesetting this version of the specification from the original HTML document, the Bark scale computation previously erroneously read: + + \begin{displaymath} + \hbox{\sout{$ + \mathrm{bark}(x) = 13.1 \arctan (.00074x) + 2.24 \arctan (.0000000185x^2 + .0001x) + $}} + \end{displaymath} + +Note that the last parenthesis is misplaced. This document now uses the correct equation as it appeared in the original HTML spec document: + + \begin{displaymath} + \mathrm{bark}(x) = 13.1 \arctan (.00074x) + 2.24 \arctan (.0000000185x^2) + .0001x + \end{displaymath} + diff --git a/doc/07-floor1.tex b/doc/07-floor1.tex new file mode 100644 index 0000000..47ad798 --- /dev/null +++ b/doc/07-floor1.tex @@ -0,0 +1,404 @@ +% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*- +%!TEX root = Vorbis_I_spec.tex +\section{Floor type 1 setup and decode} \label{vorbis:spec:floor1} + +\subsection{Overview} + +Vorbis floor type one uses a piecewise straight-line representation to +encode a spectral envelope curve. The representation plots this curve +mechanically on a linear frequency axis and a logarithmic (dB) +amplitude axis. The integer plotting algorithm used is similar to +Bresenham's algorithm. + + + +\subsection{Floor 1 format} + +\subsubsection{model} + +Floor type one represents a spectral curve as a series of +line segments. Synthesis constructs a floor curve using iterative +prediction in a process roughly equivalent to the following simplified +description: + +\begin{itemize} + \item the first line segment (base case) is a logical line spanning +from x_0,y_0 to x_1,y_1 where in the base case x_0=0 and x_1=[n], the +full range of the spectral floor to be computed. + +\item the induction step chooses a point x_new within an existing +logical line segment and produces a y_new value at that point computed +from the existing line's y value at x_new (as plotted by the line) and +a difference value decoded from the bitstream packet. + +\item floor computation produces two new line segments, one running from +x_0,y_0 to x_new,y_new and from x_new,y_new to x_1,y_1. This step is +performed logically even if y_new represents no change to the +amplitude value at x_new so that later refinement is additionally +bounded at x_new. + +\item the induction step repeats, using a list of x values specified in +the codec setup header at floor 1 initialization time. Computation +is completed at the end of the x value list. + +\end{itemize} + + +Consider the following example, with values chosen for ease of +understanding rather than representing typical configuration: + +For the below example, we assume a floor setup with an [n] of 128. +The list of selected X values in increasing order is +0,16,32,48,64,80,96,112 and 128. In list order, the values interleave +as 0, 128, 64, 32, 96, 16, 48, 80 and 112. The corresponding +list-order Y values as decoded from an example packet are 110, 20, -5, +-45, 0, -25, -10, 30 and -10. We compute the floor in the following +way, beginning with the first line: + +\begin{center} +\includegraphics[width=8cm]{floor1-1} +\captionof{figure}{graph of example floor} +\end{center} + +We now draw new logical lines to reflect the correction to new_Y, and +iterate for X positions 32 and 96: + +\begin{center} +\includegraphics[width=8cm]{floor1-2} +\captionof{figure}{graph of example floor} +\end{center} + +Although the new Y value at X position 96 is unchanged, it is still +used later as an endpoint for further refinement. From here on, the +pattern should be clear; we complete the floor computation as follows: + +\begin{center} +\includegraphics[width=8cm]{floor1-3} +\captionof{figure}{graph of example floor} +\end{center} + +\begin{center} +\includegraphics[width=8cm]{floor1-4} +\captionof{figure}{graph of example floor} +\end{center} + +A more efficient algorithm with carefully defined integer rounding +behavior is used for actual decode, as described later. The actual +algorithm splits Y value computation and line plotting into two steps +with modifications to the above algorithm to eliminate noise +accumulation through integer roundoff/truncation. + + + +\subsubsection{header decode} + +A list of floor X values is stored in the packet header in interleaved +format (used in list order during packet decode and synthesis). This +list is split into partitions, and each partition is assigned to a +partition class. X positions 0 and [n] are implicit and do not belong +to an explicit partition or partition class. + +A partition class consists of a representation vector width (the +number of Y values which the partition class encodes at once), a +'subclass' value representing the number of alternate entropy books +the partition class may use in representing Y values, the list of +[subclass] books and a master book used to encode which alternate +books were chosen for representation in a given packet. The +master/subclass mechanism is meant to be used as a flexible +representation cascade while still using codebooks only in a scalar +context. + +\begin{Verbatim}[commandchars=\\\{\}] + + 1) [floor1\_partitions] = read 5 bits as unsigned integer + 2) [maximum\_class] = -1 + 3) iterate [i] over the range 0 ... [floor1\_partitions]-1 \{ + + 4) vector [floor1\_partition\_class\_list] element [i] = read 4 bits as unsigned integer + + \} + + 5) [maximum\_class] = largest integer scalar value in vector [floor1\_partition\_class\_list] + 6) iterate [i] over the range 0 ... [maximum\_class] \{ + + 7) vector [floor1\_class\_dimensions] element [i] = read 3 bits as unsigned integer and add 1 + 8) vector [floor1\_class\_subclasses] element [i] = read 2 bits as unsigned integer + 9) if ( vector [floor1\_class\_subclasses] element [i] is nonzero ) \{ + + 10) vector [floor1\_class\_masterbooks] element [i] = read 8 bits as unsigned integer + + \} + + 11) iterate [j] over the range 0 ... (2 exponent [floor1\_class\_subclasses] element [i]) - 1 \{ + + 12) array [floor1\_subclass\_books] element [i],[j] = + read 8 bits as unsigned integer and subtract one + \} + \} + + 13) [floor1\_multiplier] = read 2 bits as unsigned integer and add one + 14) [rangebits] = read 4 bits as unsigned integer + 15) vector [floor1\_X\_list] element [0] = 0 + 16) vector [floor1\_X\_list] element [1] = 2 exponent [rangebits]; + 17) [floor1\_values] = 2 + 18) iterate [i] over the range 0 ... [floor1\_partitions]-1 \{ + + 19) [current\_class\_number] = vector [floor1\_partition\_class\_list] element [i] + 20) iterate [j] over the range 0 ... ([floor1\_class\_dimensions] element [current\_class\_number])-1 \{ + 21) vector [floor1\_X\_list] element ([floor1\_values]) = + read [rangebits] bits as unsigned integer + 22) increment [floor1\_values] by one + \} + \} + + 23) done +\end{Verbatim} + +An end-of-packet condition while reading any aspect of a floor 1 +configuration during setup renders a stream undecodable. In addition, +a \varname{[floor1\_class\_masterbooks]} or +\varname{[floor1\_subclass\_books]} scalar element greater than the +highest numbered codebook configured in this stream is an error +condition that renders the stream undecodable. Vector +[floor1\_x\_list] is limited to a maximum length of 65 elements; a +setup indicating more than 65 total elements (including elements 0 and +1 set prior to the read loop) renders the stream undecodable. All +vector [floor1\_x\_list] element values must be unique within the +vector; a non-unique value renders the stream undecodable. + +\subsubsection{packet decode} \label{vorbis:spec:floor1-decode} + +Packet decode begins by checking the \varname{[nonzero]} flag: + +\begin{Verbatim}[commandchars=\\\{\}] + 1) [nonzero] = read 1 bit as boolean +\end{Verbatim} + +If \varname{[nonzero]} is unset, that indicates this channel contained +no audio energy in this frame. Decode immediately returns a status +indicating this floor curve (and thus this channel) is unused this +frame. (A return status of 'unused' is different from decoding a +floor that has all points set to minimum representation amplitude, +which happens to be approximately -140dB). + + +Assuming \varname{[nonzero]} is set, decode proceeds as follows: + +\begin{Verbatim}[commandchars=\\\{\}] + 1) [range] = vector \{ 256, 128, 86, 64 \} element ([floor1\_multiplier]-1) + 2) vector [floor1\_Y] element [0] = read \link{vorbis:spec:ilog}{ilog}([range]-1) bits as unsigned integer + 3) vector [floor1\_Y] element [1] = read \link{vorbis:spec:ilog}{ilog}([range]-1) bits as unsigned integer + 4) [offset] = 2; + 5) iterate [i] over the range 0 ... [floor1\_partitions]-1 \{ + + 6) [class] = vector [floor1\_partition\_class] element [i] + 7) [cdim] = vector [floor1\_class\_dimensions] element [class] + 8) [cbits] = vector [floor1\_class\_subclasses] element [class] + 9) [csub] = (2 exponent [cbits])-1 + 10) [cval] = 0 + 11) if ( [cbits] is greater than zero ) \{ + + 12) [cval] = read from packet using codebook number + (vector [floor1\_class\_masterbooks] element [class]) in scalar context + \} + + 13) iterate [j] over the range 0 ... [cdim]-1 \{ + + 14) [book] = array [floor1\_subclass\_books] element [class],([cval] bitwise AND [csub]) + 15) [cval] = [cval] right shifted [cbits] bits + 16) if ( [book] is not less than zero ) \{ + + 17) vector [floor1\_Y] element ([j]+[offset]) = read from packet using codebook + [book] in scalar context + + \} else [book] is less than zero \{ + + 18) vector [floor1\_Y] element ([j]+[offset]) = 0 + + \} + \} + + 19) [offset] = [offset] + [cdim] + + \} + + 20) done +\end{Verbatim} + +An end-of-packet condition during curve decode should be considered a +nominal occurrence; if end-of-packet is reached during any read +operation above, floor decode is to return 'unused' status as if the +\varname{[nonzero]} flag had been unset at the beginning of decode. + + +Vector \varname{[floor1\_Y]} contains the values from packet decode +needed for floor 1 synthesis. + + + +\subsubsection{curve computation} \label{vorbis:spec:floor1-synth} + +Curve computation is split into two logical steps; the first step +derives final Y amplitude values from the encoded, wrapped difference +values taken from the bitstream. The second step plots the curve +lines. Also, although zero-difference values are used in the +iterative prediction to find final Y values, these points are +conditionally skipped during final line computation in step two. +Skipping zero-difference values allows a smoother line fit. + +Although some aspects of the below algorithm look like inconsequential +optimizations, implementors are warned to follow the details closely. +Deviation from implementing a strictly equivalent algorithm can result +in serious decoding errors. + +{\em Additional note:} Although \varname{[floor1\_final\_Y]} values in +the prediction loop and at the end of step 1 are inherently limited by +the prediction algorithm to [0, \varname{[range]}), it is possible to + abuse the setup and codebook machinery to produce negative or + over-range results. We suggest that decoder implementations guard + the values in vector \varname{[floor1\_final\_Y]} by clamping each + element to [0, \varname{[range]}) after step 1. Variants of this + suggestion are acceptable as valid floor1 setups cannot produce + out of range values. + +\begin{description} +\item[step 1: amplitude value synthesis] + +Unwrap the always-positive-or-zero values read from the packet into ++/- difference values, then apply to line prediction. + +\begin{Verbatim}[commandchars=\\\{\}] + 1) [range] = vector \{ 256, 128, 86, 64 \} element ([floor1\_multiplier]-1) + 2) vector [floor1\_step2\_flag] element [0] = set + 3) vector [floor1\_step2\_flag] element [1] = set + 4) vector [floor1\_final\_Y] element [0] = vector [floor1\_Y] element [0] + 5) vector [floor1\_final\_Y] element [1] = vector [floor1\_Y] element [1] + 6) iterate [i] over the range 2 ... [floor1\_values]-1 \{ + + 7) [low\_neighbor\_offset] = \link{vorbis:spec:low:neighbor}{low\_neighbor}([floor1\_X\_list],[i]) + 8) [high\_neighbor\_offset] = \link{vorbis:spec:high:neighbor}{high\_neighbor}([floor1\_X\_list],[i]) + + 9) [predicted] = \link{vorbis:spec:render:point}{render\_point}( vector [floor1\_X\_list] element [low\_neighbor\_offset], + vector [floor1\_final\_Y] element [low\_neighbor\_offset], + vector [floor1\_X\_list] element [high\_neighbor\_offset], + vector [floor1\_final\_Y] element [high\_neighbor\_offset], + vector [floor1\_X\_list] element [i] ) + + 10) [val] = vector [floor1\_Y] element [i] + 11) [highroom] = [range] - [predicted] + 12) [lowroom] = [predicted] + 13) if ( [highroom] is less than [lowroom] ) \{ + + 14) [room] = [highroom] * 2 + + \} else [highroom] is not less than [lowroom] \{ + + 15) [room] = [lowroom] * 2 + + \} + + 16) if ( [val] is nonzero ) \{ + + 17) vector [floor1\_step2\_flag] element [low\_neighbor\_offset] = set + 18) vector [floor1\_step2\_flag] element [high\_neighbor\_offset] = set + 19) vector [floor1\_step2\_flag] element [i] = set + 20) if ( [val] is greater than or equal to [room] ) \{ + + 21) if ( [highroom] is greater than [lowroom] ) \{ + + 22) vector [floor1\_final\_Y] element [i] = [val] - [lowroom] + [predicted] + + \} else [highroom] is not greater than [lowroom] \{ + + 23) vector [floor1\_final\_Y] element [i] = [predicted] - [val] + [highroom] - 1 + + \} + + \} else [val] is less than [room] \{ + + 24) if ([val] is odd) \{ + + 25) vector [floor1\_final\_Y] element [i] = + [predicted] - (([val] + 1) divided by 2 using integer division) + + \} else [val] is even \{ + + 26) vector [floor1\_final\_Y] element [i] = + [predicted] + ([val] / 2 using integer division) + + \} + + \} + + \} else [val] is zero \{ + + 27) vector [floor1\_step2\_flag] element [i] = unset + 28) vector [floor1\_final\_Y] element [i] = [predicted] + + \} + + \} + + 29) done + +\end{Verbatim} + + + +\item[step 2: curve synthesis] + +Curve synthesis generates a return vector \varname{[floor]} of length +\varname{[n]} (where \varname{[n]} is provided by the decode process +calling to floor decode). Floor 1 curve synthesis makes use of the +\varname{[floor1\_X\_list]}, \varname{[floor1\_final\_Y]} and +\varname{[floor1\_step2\_flag]} vectors, as well as [floor1\_multiplier] +and [floor1\_values] values. + +Decode begins by sorting the scalars from vectors +\varname{[floor1\_X\_list]}, \varname{[floor1\_final\_Y]} and +\varname{[floor1\_step2\_flag]} together into new vectors +\varname{[floor1\_X\_list]'}, \varname{[floor1\_final\_Y]'} and +\varname{[floor1\_step2\_flag]'} according to ascending sort order of the +values in \varname{[floor1\_X\_list]}. That is, sort the values of +\varname{[floor1\_X\_list]} and then apply the same permutation to +elements of the other two vectors so that the X, Y and step2\_flag +values still match. + +Then compute the final curve in one pass: + +\begin{Verbatim}[commandchars=\\\{\}] + 1) [hx] = 0 + 2) [lx] = 0 + 3) [ly] = vector [floor1\_final\_Y]' element [0] * [floor1\_multiplier] + 4) iterate [i] over the range 1 ... [floor1\_values]-1 \{ + + 5) if ( [floor1\_step2\_flag]' element [i] is set ) \{ + + 6) [hy] = [floor1\_final\_Y]' element [i] * [floor1\_multiplier] + 7) [hx] = [floor1\_X\_list]' element [i] + 8) \link{vorbis:spec:render:line}{render\_line}( [lx], [ly], [hx], [hy], [floor] ) + 9) [lx] = [hx] + 10) [ly] = [hy] + \} + \} + + 11) if ( [hx] is less than [n] ) \{ + + 12) \link{vorbis:spec:render:line}{render\_line}( [hx], [hy], [n], [hy], [floor] ) + + \} + + 13) if ( [hx] is greater than [n] ) \{ + + 14) truncate vector [floor] to [n] elements + + \} + + 15) for each scalar in vector [floor], perform a lookup substitution using + the scalar value from [floor] as an offset into the vector \link{vorbis:spec:floor1:inverse:dB:table}{[floor1\_inverse\_dB\_static\_table]} + + 16) done + +\end{Verbatim} + +\end{description} diff --git a/doc/08-residue.tex b/doc/08-residue.tex new file mode 100644 index 0000000..ea38243 --- /dev/null +++ b/doc/08-residue.tex @@ -0,0 +1,451 @@ +% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*- +%!TEX root = Vorbis_I_spec.tex +\section{Residue setup and decode} \label{vorbis:spec:residue} + +\subsection{Overview} + +A residue vector represents the fine detail of the audio spectrum of +one channel in an audio frame after the encoder subtracts the floor +curve and performs any channel coupling. A residue vector may +represent spectral lines, spectral magnitude, spectral phase or +hybrids as mixed by channel coupling. The exact semantic content of +the vector does not matter to the residue abstraction. + +Whatever the exact qualities, the Vorbis residue abstraction codes the +residue vectors into the bitstream packet, and then reconstructs the +vectors during decode. Vorbis makes use of three different encoding +variants (numbered 0, 1 and 2) of the same basic vector encoding +abstraction. + + + +\subsection{Residue format} + +Residue format partitions each vector in the vector bundle into chunks, +classifies each chunk, encodes the chunk classifications and finally +encodes the chunks themselves using the the specific VQ arrangement +defined for each selected classification. +The exact interleaving and partitioning vary by residue encoding number, +however the high-level process used to classify and encode the residue +vector is the same in all three variants. + +A set of coded residue vectors are all of the same length. High level +coding structure, ignoring for the moment exactly how a partition is +encoded and simply trusting that it is, is as follows: + +\begin{itemize} +\item Each vector is partitioned into multiple equal sized chunks +according to configuration specified. If we have a vector size of +\emph{n}, a partition size \emph{residue\_partition\_size}, and a total +of \emph{ch} residue vectors, the total number of partitioned chunks +coded is \emph{n}/\emph{residue\_partition\_size}*\emph{ch}. It is +important to note that the integer division truncates. In the below +example, we assume an example \emph{residue\_partition\_size} of 8. + +\item Each partition in each vector has a classification number that +specifies which of multiple configured VQ codebook setups are used to +decode that partition. The classification numbers of each partition +can be thought of as forming a vector in their own right, as in the +illustration below. Just as the residue vectors are coded in grouped +partitions to increase encoding efficiency, the classification vector +is also partitioned into chunks. The integer elements of each scalar +in a classification chunk are built into a single scalar that +represents the classification numbers in that chunk. In the below +example, the classification codeword encodes two classification +numbers. + +\item The values in a residue vector may be encoded monolithically in a +single pass through the residue vector, but more often efficient +codebook design dictates that each vector is encoded as the additive +sum of several passes through the residue vector using more than one +VQ codebook. Thus, each residue value potentially accumulates values +from multiple decode passes. The classification value associated with +a partition is the same in each pass, thus the classification codeword +is coded only in the first pass. + +\end{itemize} + + +\begin{center} +\includegraphics[width=\textwidth]{residue-pack} +\captionof{figure}{illustration of residue vector format} +\end{center} + + + +\subsection{residue 0} + +Residue 0 and 1 differ only in the way the values within a residue +partition are interleaved during partition encoding (visually treated +as a black box--or cyan box or brown box--in the above figure). + +Residue encoding 0 interleaves VQ encoding according to the +dimension of the codebook used to encode a partition in a specific +pass. The dimension of the codebook need not be the same in multiple +passes, however the partition size must be an even multiple of the +codebook dimension. + +As an example, assume a partition vector of size eight, to be encoded +by residue 0 using codebook sizes of 8, 4, 2 and 1: + +\begin{programlisting} + + original residue vector: [ 0 1 2 3 4 5 6 7 ] + +codebook dimensions = 8 encoded as: [ 0 1 2 3 4 5 6 7 ] + +codebook dimensions = 4 encoded as: [ 0 2 4 6 ], [ 1 3 5 7 ] + +codebook dimensions = 2 encoded as: [ 0 4 ], [ 1 5 ], [ 2 6 ], [ 3 7 ] + +codebook dimensions = 1 encoded as: [ 0 ], [ 1 ], [ 2 ], [ 3 ], [ 4 ], [ 5 ], [ 6 ], [ 7 ] + +\end{programlisting} + +It is worth mentioning at this point that no configurable value in the +residue coding setup is restricted to a power of two. + + + +\subsection{residue 1} + +Residue 1 does not interleave VQ encoding. It represents partition +vector scalars in order. As with residue 0, however, partition length +must be an integer multiple of the codebook dimension, although +dimension may vary from pass to pass. + +As an example, assume a partition vector of size eight, to be encoded +by residue 0 using codebook sizes of 8, 4, 2 and 1: + +\begin{programlisting} + + original residue vector: [ 0 1 2 3 4 5 6 7 ] + +codebook dimensions = 8 encoded as: [ 0 1 2 3 4 5 6 7 ] + +codebook dimensions = 4 encoded as: [ 0 1 2 3 ], [ 4 5 6 7 ] + +codebook dimensions = 2 encoded as: [ 0 1 ], [ 2 3 ], [ 4 5 ], [ 6 7 ] + +codebook dimensions = 1 encoded as: [ 0 ], [ 1 ], [ 2 ], [ 3 ], [ 4 ], [ 5 ], [ 6 ], [ 7 ] + +\end{programlisting} + + + +\subsection{residue 2} + +Residue type two can be thought of as a variant of residue type 1. +Rather than encoding multiple passed-in vectors as in residue type 1, +the \emph{ch} passed in vectors of length \emph{n} are first +interleaved and flattened into a single vector of length +\emph{ch}*\emph{n}. Encoding then proceeds as in type 1. Decoding is +as in type 1 with decode interleave reversed. If operating on a single +vector to begin with, residue type 1 and type 2 are equivalent. + +\begin{center} +\includegraphics[width=\textwidth]{residue2} +\captionof{figure}{illustration of residue type 2} +\end{center} + + +\subsection{Residue decode} + +\subsubsection{header decode} + +Header decode for all three residue types is identical. +\begin{programlisting} + 1) [residue\_begin] = read 24 bits as unsigned integer + 2) [residue\_end] = read 24 bits as unsigned integer + 3) [residue\_partition\_size] = read 24 bits as unsigned integer and add one + 4) [residue\_classifications] = read 6 bits as unsigned integer and add one + 5) [residue\_classbook] = read 8 bits as unsigned integer +\end{programlisting} + +\varname{[residue\_begin]} and +\varname{[residue\_end]} select the specific sub-portion of +each vector that is actually coded; it implements akin to a bandpass +where, for coding purposes, the vector effectively begins at element +\varname{[residue\_begin]} and ends at +\varname{[residue\_end]}. Preceding and following values in +the unpacked vectors are zeroed. Note that for residue type 2, these +values as well as \varname{[residue\_partition\_size]}apply to +the interleaved vector, not the individual vectors before interleave. +\varname{[residue\_partition\_size]} is as explained above, +\varname{[residue\_classifications]} is the number of possible +classification to which a partition can belong and +\varname{[residue\_classbook]} is the codebook number used to +code classification codewords. The number of dimensions in book +\varname{[residue\_classbook]} determines how many +classification values are grouped into a single classification +codeword. Note that the number of entries and dimensions in book +\varname{[residue\_classbook]}, along with +\varname{[residue\_classifications]}, overdetermines to +possible number of classification codewords. +If \varname{[residue\_classifications]}\^{}\varname{[residue\_classbook]}.dimensions +exceeds \varname{[residue\_classbook]}.entries, the +bitstream should be regarded to be undecodable. + +Next we read a bitmap pattern that specifies which partition classes +code values in which passes. + +\begin{programlisting} + 1) iterate [i] over the range 0 ... [residue\_classifications]-1 { + + 2) [high\_bits] = 0 + 3) [low\_bits] = read 3 bits as unsigned integer + 4) [bitflag] = read one bit as boolean + 5) if ( [bitflag] is set ) then [high\_bits] = read five bits as unsigned integer + 6) vector [residue\_cascade] element [i] = [high\_bits] * 8 + [low\_bits] + } + 7) done +\end{programlisting} + +Finally, we read in a list of book numbers, each corresponding to +specific bit set in the cascade bitmap. We loop over the possible +codebook classifications and the maximum possible number of encoding +stages (8 in Vorbis I, as constrained by the elements of the cascade +bitmap being eight bits): + +\begin{programlisting} + 1) iterate [i] over the range 0 ... [residue\_classifications]-1 { + + 2) iterate [j] over the range 0 ... 7 { + + 3) if ( vector [residue\_cascade] element [i] bit [j] is set ) { + + 4) array [residue\_books] element [i][j] = read 8 bits as unsigned integer + + } else { + + 5) array [residue\_books] element [i][j] = unused + + } + } + } + + 6) done +\end{programlisting} + +An end-of-packet condition at any point in header decode renders the +stream undecodable. In addition, any codebook number greater than the +maximum numbered codebook set up in this stream also renders the +stream undecodable. All codebooks in array [residue\_books] are +required to have a value mapping. The presence of codebook in array +[residue\_books] without a value mapping (maptype equals zero) renders +the stream undecodable. + + + +\subsubsection{packet decode} + +Format 0 and 1 packet decode is identical except for specific +partition interleave. Format 2 packet decode can be built out of the +format 1 decode process. Thus we describe first the decode +infrastructure identical to all three formats. + +In addition to configuration information, the residue decode process +is passed the number of vectors in the submap bundle and a vector of +flags indicating if any of the vectors are not to be decoded. If the +passed in number of vectors is 3 and vector number 1 is marked 'do not +decode', decode skips vector 1 during the decode loop. However, even +'do not decode' vectors are allocated and zeroed. + +Depending on the values of \varname{[residue\_begin]} and +\varname{[residue\_end]}, it is obvious that the encoded +portion of a residue vector may be the entire possible residue vector +or some other strict subset of the actual residue vector size with +zero padding at either uncoded end. However, it is also possible to +set \varname{[residue\_begin]} and +\varname{[residue\_end]} to specify a range partially or +wholly beyond the maximum vector size. Before beginning residue +decode, limit \varname{[residue\_begin]} and +\varname{[residue\_end]} to the maximum possible vector size +as follows. We assume that the number of vectors being encoded, +\varname{[ch]} is provided by the higher level decoding +process. + +\begin{programlisting} + 1) [actual\_size] = current blocksize/2; + 2) if residue encoding is format 2 + 3) [actual\_size] = [actual\_size] * [ch]; + 4) [limit\_residue\_begin] = minimum of ([residue\_begin],[actual\_size]); + 5) [limit\_residue\_end] = minimum of ([residue\_end],[actual\_size]); +\end{programlisting} + +The following convenience values are conceptually useful to clarifying +the decode process: + +\begin{programlisting} + 1) [classwords\_per\_codeword] = [codebook\_dimensions] value of codebook [residue\_classbook] + 2) [n\_to\_read] = [limit\_residue\_end] - [limit\_residue\_begin] + 3) [partitions\_to\_read] = [n\_to\_read] / [residue\_partition\_size] +\end{programlisting} + +Packet decode proceeds as follows, matching the description offered earlier in the document. +\begin{programlisting} + 1) allocate and zero all vectors that will be returned. + 2) if ([n\_to\_read] is zero), stop; there is no residue to decode. + 3) iterate [pass] over the range 0 ... 7 { + + 4) [partition\_count] = 0 + + 5) while [partition\_count] is less than [partitions\_to\_read] + + 6) if ([pass] is zero) { + + 7) iterate [j] over the range 0 .. [ch]-1 { + + 8) if vector [j] is not marked 'do not decode' { + + 9) [temp] = read from packet using codebook [residue\_classbook] in scalar context + 10) iterate [i] descending over the range [classwords\_per\_codeword]-1 ... 0 { + + 11) array [classifications] element [j],([i]+[partition\_count]) = + [temp] integer modulo [residue\_classifications] + 12) [temp] = [temp] / [residue\_classifications] using integer division + + } + + } + + } + + } + + 13) iterate [i] over the range 0 .. ([classwords\_per\_codeword] - 1) while [partition\_count] + is also less than [partitions\_to\_read] { + + 14) iterate [j] over the range 0 .. [ch]-1 { + + 15) if vector [j] is not marked 'do not decode' { + + 16) [vqclass] = array [classifications] element [j],[partition\_count] + 17) [vqbook] = array [residue\_books] element [vqclass],[pass] + 18) if ([vqbook] is not 'unused') { + + 19) decode partition into output vector number [j], starting at scalar + offset [limit\_residue\_begin]+[partition\_count]*[residue\_partition\_size] using + codebook number [vqbook] in VQ context + } + } + + 20) increment [partition\_count] by one + + } + } + } + + 21) done + +\end{programlisting} + +An end-of-packet condition during packet decode is to be considered a +nominal occurrence. Decode returns the result of vector decode up to +that point. + + + +\subsubsection{format 0 specifics} + +Format zero decodes partitions exactly as described earlier in the +'Residue Format: residue 0' section. The following pseudocode +presents the same algorithm. Assume: + +\begin{itemize} +\item \varname{[n]} is the value in \varname{[residue\_partition\_size]} +\item \varname{[v]} is the residue vector +\item \varname{[offset]} is the beginning read offset in [v] +\end{itemize} + + +\begin{programlisting} + 1) [step] = [n] / [codebook\_dimensions] + 2) iterate [i] over the range 0 ... [step]-1 { + + 3) vector [entry\_temp] = read vector from packet using current codebook in VQ context + 4) iterate [j] over the range 0 ... [codebook\_dimensions]-1 { + + 5) vector [v] element ([offset]+[i]+[j]*[step]) = + vector [v] element ([offset]+[i]+[j]*[step]) + + vector [entry\_temp] element [j] + + } + + } + + 6) done + +\end{programlisting} + + + +\subsubsection{format 1 specifics} + +Format 1 decodes partitions exactly as described earlier in the +'Residue Format: residue 1' section. The following pseudocode +presents the same algorithm. Assume: + +\begin{itemize} +\item \varname{[n]} is the value in +\varname{[residue\_partition\_size]} +\item \varname{[v]} is the residue vector +\item \varname{[offset]} is the beginning read offset in [v] +\end{itemize} + + +\begin{programlisting} + 1) [i] = 0 + 2) vector [entry\_temp] = read vector from packet using current codebook in VQ context + 3) iterate [j] over the range 0 ... [codebook\_dimensions]-1 { + + 4) vector [v] element ([offset]+[i]) = + vector [v] element ([offset]+[i]) + + vector [entry\_temp] element [j] + 5) increment [i] + + } + + 6) if ( [i] is less than [n] ) continue at step 2 + 7) done +\end{programlisting} + + + +\subsubsection{format 2 specifics} + +Format 2 is reducible to format 1. It may be implemented as an additional step prior to and an additional post-decode step after a normal format 1 decode. + + +Format 2 handles 'do not decode' vectors differently than residue 0 or +1; if all vectors are marked 'do not decode', no decode occurrs. +However, if at least one vector is to be decoded, all the vectors are +decoded. We then request normal format 1 to decode a single vector +representing all output channels, rather than a vector for each +channel. After decode, deinterleave the vector into independent vectors, one for each output channel. That is: + +\begin{enumerate} + \item If all vectors 0 through \emph{ch}-1 are marked 'do not decode', allocate and clear a single vector \varname{[v]}of length \emph{ch*n} and skip step 2 below; proceed directly to the post-decode step. + \item Rather than performing format 1 decode to produce \emph{ch} vectors of length \emph{n} each, call format 1 decode to produce a single vector \varname{[v]} of length \emph{ch*n}. + \item Post decode: Deinterleave the single vector \varname{[v]} returned by format 1 decode as described above into \emph{ch} independent vectors, one for each outputchannel, according to: + \begin{programlisting} + 1) iterate [i] over the range 0 ... [n]-1 { + + 2) iterate [j] over the range 0 ... [ch]-1 { + + 3) output vector number [j] element [i] = vector [v] element ([i] * [ch] + [j]) + + } + } + + 4) done + \end{programlisting} + +\end{enumerate} + + + + + + + diff --git a/doc/09-helper.tex b/doc/09-helper.tex new file mode 100644 index 0000000..0a13795 --- /dev/null +++ b/doc/09-helper.tex @@ -0,0 +1,180 @@ +% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*- +%!TEX root = Vorbis_I_spec.tex +\section{Helper equations} \label{vorbis:spec:helper} + +\subsection{Overview} + +The equations below are used in multiple places by the Vorbis codec +specification. Rather than cluttering up the main specification +documents, they are defined here and referenced where appropriate. + + +\subsection{Functions} + +\subsubsection{ilog} \label{vorbis:spec:ilog} + +The "ilog(x)" function returns the position number (1 through n) of the highest set bit in the two's complement integer value +\varname{[x]}. Values of \varname{[x]} less than zero are defined to return zero. + +\begin{programlisting} + 1) [return\_value] = 0; + 2) if ( [x] is greater than zero ) { + + 3) increment [return\_value]; + 4) logical shift [x] one bit to the right, padding the MSb with zero + 5) repeat at step 2) + + } + + 6) done +\end{programlisting} + +Examples: + +\begin{itemize} + \item ilog(0) = 0; + \item ilog(1) = 1; + \item ilog(2) = 2; + \item ilog(3) = 2; + \item ilog(4) = 3; + \item ilog(7) = 3; + \item ilog(negative number) = 0; +\end{itemize} + + + + +\subsubsection{float32\_unpack} \label{vorbis:spec:float32:unpack} + +"float32\_unpack(x)" is intended to translate the packed binary +representation of a Vorbis codebook float value into the +representation used by the decoder for floating point numbers. For +purposes of this example, we will unpack a Vorbis float32 into a +host-native floating point number. + +\begin{programlisting} + 1) [mantissa] = [x] bitwise AND 0x1fffff (unsigned result) + 2) [sign] = [x] bitwise AND 0x80000000 (unsigned result) + 3) [exponent] = ( [x] bitwise AND 0x7fe00000) shifted right 21 bits (unsigned result) + 4) if ( [sign] is nonzero ) then negate [mantissa] + 5) return [mantissa] * ( 2 ^ ( [exponent] - 788 ) ) +\end{programlisting} + + + +\subsubsection{lookup1\_values} \label{vorbis:spec:lookup1:values} + +"lookup1\_values(codebook\_entries,codebook\_dimensions)" is used to +compute the correct length of the value index for a codebook VQ lookup +table of lookup type 1. The values on this list are permuted to +construct the VQ vector lookup table of size +\varname{[codebook\_entries]}. + +The return value for this function is defined to be 'the greatest +integer value for which \varname{[return\_value]} to the power of +\varname{[codebook\_dimensions]} is less than or equal to +\varname{[codebook\_entries]}'. + + + +\subsubsection{low\_neighbor} \label{vorbis:spec:low:neighbor} + +"low\_neighbor(v,x)" finds the position \varname{n} in vector \varname{[v]} of +the greatest value scalar element for which \varname{n} is less than +\varname{[x]} and vector \varname{[v]} element \varname{n} is less +than vector \varname{[v]} element \varname{[x]}. + +\subsubsection{high\_neighbor} \label{vorbis:spec:high:neighbor} + +"high\_neighbor(v,x)" finds the position \varname{n} in vector [v] of +the lowest value scalar element for which \varname{n} is less than +\varname{[x]} and vector \varname{[v]} element \varname{n} is greater +than vector \varname{[v]} element \varname{[x]}. + + + +\subsubsection{render\_point} \label{vorbis:spec:render:point} + +"render\_point(x0,y0,x1,y1,X)" is used to find the Y value at point X +along the line specified by x0, x1, y0 and y1. This function uses an +integer algorithm to solve for the point directly without calculating +intervening values along the line. + +\begin{programlisting} + 1) [dy] = [y1] - [y0] + 2) [adx] = [x1] - [x0] + 3) [ady] = absolute value of [dy] + 4) [err] = [ady] * ([X] - [x0]) + 5) [off] = [err] / [adx] using integer division + 6) if ( [dy] is less than zero ) { + + 7) [Y] = [y0] - [off] + + } else { + + 8) [Y] = [y0] + [off] + + } + + 9) done +\end{programlisting} + + + +\subsubsection{render\_line} \label{vorbis:spec:render:line} + +Floor decode type one uses the integer line drawing algorithm of +"render\_line(x0, y0, x1, y1, v)" to construct an integer floor +curve for contiguous piecewise line segments. Note that it has not +been relevant elsewhere, but here we must define integer division as +rounding division of both positive and negative numbers toward zero. + + +\begin{programlisting} + 1) [dy] = [y1] - [y0] + 2) [adx] = [x1] - [x0] + 3) [ady] = absolute value of [dy] + 4) [base] = [dy] / [adx] using integer division + 5) [x] = [x0] + 6) [y] = [y0] + 7) [err] = 0 + + 8) if ( [dy] is less than 0 ) { + + 9) [sy] = [base] - 1 + + } else { + + 10) [sy] = [base] + 1 + + } + + 11) [ady] = [ady] - (absolute value of [base]) * [adx] + 12) vector [v] element [x] = [y] + + 13) iterate [x] over the range [x0]+1 ... [x1]-1 { + + 14) [err] = [err] + [ady]; + 15) if ( [err] >= [adx] ) { + + 16) [err] = [err] - [adx] + 17) [y] = [y] + [sy] + + } else { + + 18) [y] = [y] + [base] + + } + + 19) vector [v] element [x] = [y] + + } +\end{programlisting} + + + + + + + + diff --git a/doc/10-tables.tex b/doc/10-tables.tex new file mode 100644 index 0000000..c2881d6 --- /dev/null +++ b/doc/10-tables.tex @@ -0,0 +1,76 @@ +% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*- +%!TEX root = Vorbis_I_spec.tex +\section{Tables} \label{vorbis:spec:tables} + +\subsection{floor1\_inverse\_dB\_table} \label{vorbis:spec:floor1:inverse:dB:table} + +The vector \varname{[floor1\_inverse\_dB\_table]} is a 256 element static +lookup table consisting of the following values (read left to right +then top to bottom): + +\begin{Verbatim} + 1.0649863e-07, 1.1341951e-07, 1.2079015e-07, 1.2863978e-07, + 1.3699951e-07, 1.4590251e-07, 1.5538408e-07, 1.6548181e-07, + 1.7623575e-07, 1.8768855e-07, 1.9988561e-07, 2.1287530e-07, + 2.2670913e-07, 2.4144197e-07, 2.5713223e-07, 2.7384213e-07, + 2.9163793e-07, 3.1059021e-07, 3.3077411e-07, 3.5226968e-07, + 3.7516214e-07, 3.9954229e-07, 4.2550680e-07, 4.5315863e-07, + 4.8260743e-07, 5.1396998e-07, 5.4737065e-07, 5.8294187e-07, + 6.2082472e-07, 6.6116941e-07, 7.0413592e-07, 7.4989464e-07, + 7.9862701e-07, 8.5052630e-07, 9.0579828e-07, 9.6466216e-07, + 1.0273513e-06, 1.0941144e-06, 1.1652161e-06, 1.2409384e-06, + 1.3215816e-06, 1.4074654e-06, 1.4989305e-06, 1.5963394e-06, + 1.7000785e-06, 1.8105592e-06, 1.9282195e-06, 2.0535261e-06, + 2.1869758e-06, 2.3290978e-06, 2.4804557e-06, 2.6416497e-06, + 2.8133190e-06, 2.9961443e-06, 3.1908506e-06, 3.3982101e-06, + 3.6190449e-06, 3.8542308e-06, 4.1047004e-06, 4.3714470e-06, + 4.6555282e-06, 4.9580707e-06, 5.2802740e-06, 5.6234160e-06, + 5.9888572e-06, 6.3780469e-06, 6.7925283e-06, 7.2339451e-06, + 7.7040476e-06, 8.2047000e-06, 8.7378876e-06, 9.3057248e-06, + 9.9104632e-06, 1.0554501e-05, 1.1240392e-05, 1.1970856e-05, + 1.2748789e-05, 1.3577278e-05, 1.4459606e-05, 1.5399272e-05, + 1.6400004e-05, 1.7465768e-05, 1.8600792e-05, 1.9809576e-05, + 2.1096914e-05, 2.2467911e-05, 2.3928002e-05, 2.5482978e-05, + 2.7139006e-05, 2.8902651e-05, 3.0780908e-05, 3.2781225e-05, + 3.4911534e-05, 3.7180282e-05, 3.9596466e-05, 4.2169667e-05, + 4.4910090e-05, 4.7828601e-05, 5.0936773e-05, 5.4246931e-05, + 5.7772202e-05, 6.1526565e-05, 6.5524908e-05, 6.9783085e-05, + 7.4317983e-05, 7.9147585e-05, 8.4291040e-05, 8.9768747e-05, + 9.5602426e-05, 0.00010181521, 0.00010843174, 0.00011547824, + 0.00012298267, 0.00013097477, 0.00013948625, 0.00014855085, + 0.00015820453, 0.00016848555, 0.00017943469, 0.00019109536, + 0.00020351382, 0.00021673929, 0.00023082423, 0.00024582449, + 0.00026179955, 0.00027881276, 0.00029693158, 0.00031622787, + 0.00033677814, 0.00035866388, 0.00038197188, 0.00040679456, + 0.00043323036, 0.00046138411, 0.00049136745, 0.00052329927, + 0.00055730621, 0.00059352311, 0.00063209358, 0.00067317058, + 0.00071691700, 0.00076350630, 0.00081312324, 0.00086596457, + 0.00092223983, 0.00098217216, 0.0010459992, 0.0011139742, + 0.0011863665, 0.0012634633, 0.0013455702, 0.0014330129, + 0.0015261382, 0.0016253153, 0.0017309374, 0.0018434235, + 0.0019632195, 0.0020908006, 0.0022266726, 0.0023713743, + 0.0025254795, 0.0026895994, 0.0028643847, 0.0030505286, + 0.0032487691, 0.0034598925, 0.0036847358, 0.0039241906, + 0.0041792066, 0.0044507950, 0.0047400328, 0.0050480668, + 0.0053761186, 0.0057254891, 0.0060975636, 0.0064938176, + 0.0069158225, 0.0073652516, 0.0078438871, 0.0083536271, + 0.0088964928, 0.009474637, 0.010090352, 0.010746080, + 0.011444421, 0.012188144, 0.012980198, 0.013823725, + 0.014722068, 0.015678791, 0.016697687, 0.017782797, + 0.018938423, 0.020169149, 0.021479854, 0.022875735, + 0.024362330, 0.025945531, 0.027631618, 0.029427276, + 0.031339626, 0.033376252, 0.035545228, 0.037855157, + 0.040315199, 0.042935108, 0.045725273, 0.048696758, + 0.051861348, 0.055231591, 0.058820850, 0.062643361, + 0.066714279, 0.071049749, 0.075666962, 0.080584227, + 0.085821044, 0.091398179, 0.097337747, 0.10366330, + 0.11039993, 0.11757434, 0.12521498, 0.13335215, + 0.14201813, 0.15124727, 0.16107617, 0.17154380, + 0.18269168, 0.19456402, 0.20720788, 0.22067342, + 0.23501402, 0.25028656, 0.26655159, 0.28387361, + 0.30232132, 0.32196786, 0.34289114, 0.36517414, + 0.38890521, 0.41417847, 0.44109412, 0.46975890, + 0.50028648, 0.53279791, 0.56742212, 0.60429640, + 0.64356699, 0.68538959, 0.72993007, 0.77736504, + 0.82788260, 0.88168307, 0.9389798, 1. +\end{Verbatim} diff --git a/doc/Doxyfile.in b/doc/Doxyfile.in new file mode 100644 index 0000000..cdb894f --- /dev/null +++ b/doc/Doxyfile.in @@ -0,0 +1,1142 @@ +# Doxyfile 1.3.7 + +# This file describes the settings to be used by the documentation system +# doxygen (www.doxygen.org) for a project +# +# All text after a hash (#) is considered a comment and will be ignored +# The format is: +# TAG = value [value, ...] +# For lists items can also be appended using: +# TAG += value [value, ...] +# Values that contain spaces should be placed between quotes (" ") + +#--------------------------------------------------------------------------- +# Project related configuration options +#--------------------------------------------------------------------------- + +# The PROJECT_NAME tag is a single word (or a sequence of words surrounded +# by quotes) that should identify the project. + +PROJECT_NAME = @PACKAGE@ + +# The PROJECT_NUMBER tag can be used to enter a project or revision number. +# This could be handy for archiving the generated documentation or +# if some version control system is used. + +PROJECT_NUMBER = @VERSION@ + +# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) +# base path where the generated documentation will be put. +# If a relative path is entered, it will be relative to the location +# where doxygen was started. If left blank the current directory will be used. + +OUTPUT_DIRECTORY = vorbis + +# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create +# 2 levels of 10 sub-directories under the output directory of each output +# format and will distribute the generated files over these directories. +# Enabling this option can be useful when feeding doxygen a huge amount of source +# files, where putting all generated files in the same directory would otherwise +# cause performance problems for the file system. + +CREATE_SUBDIRS = NO + +# The OUTPUT_LANGUAGE tag is used to specify the language in which all +# documentation generated by doxygen is written. Doxygen will use this +# information to generate all constant output in the proper language. +# The default language is English, other supported languages are: +# Brazilian, Catalan, Chinese, Chinese-Traditional, Croatian, Czech, Danish, Dutch, +# Finnish, French, German, Greek, Hungarian, Italian, Japanese, Japanese-en +# (Japanese with English messages), Korean, Korean-en, Norwegian, Polish, Portuguese, +# Romanian, Russian, Serbian, Slovak, Slovene, Spanish, Swedish, and Ukrainian. + +OUTPUT_LANGUAGE = English + +# This tag can be used to specify the encoding used in the generated output. +# The encoding is not always determined by the language that is chosen, +# but also whether or not the output is meant for Windows or non-Windows users. +# In case there is a difference, setting the USE_WINDOWS_ENCODING tag to YES +# forces the Windows encoding (this is the default for the Windows binary), +# whereas setting the tag to NO uses a Unix-style encoding (the default for +# all platforms other than Windows). +#This tag is now obsolete, according to doxygen 1.5.2 +#USE_WINDOWS_ENCODING = NO + +# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will +# include brief member descriptions after the members that are listed in +# the file and class documentation (similar to JavaDoc). +# Set to NO to disable this. + +BRIEF_MEMBER_DESC = YES + +# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend +# the brief description of a member or function before the detailed description. +# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the +# brief descriptions will be completely suppressed. + +REPEAT_BRIEF = YES + +# This tag implements a quasi-intelligent brief description abbreviator +# that is used to form the text in various listings. Each string +# in this list, if found as the leading text of the brief description, will be +# stripped from the text and the result after processing the whole list, is used +# as the annotated text. Otherwise, the brief description is used as-is. If left +# blank, the following values are used ("$name" is automatically replaced with the +# name of the entity): "The $name class" "The $name widget" "The $name file" +# "is" "provides" "specifies" "contains" "represents" "a" "an" "the" + +ABBREVIATE_BRIEF = + +# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then +# Doxygen will generate a detailed section even if there is only a brief +# description. + +ALWAYS_DETAILED_SEC = NO + +# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all inherited +# members of a class in the documentation of that class as if those members were +# ordinary class members. Constructors, destructors and assignment operators of +# the base classes will not be shown. + +INLINE_INHERITED_MEMB = NO + +# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full +# path before files name in the file list and in the header files. If set +# to NO the shortest path that makes the file name unique will be used. + +FULL_PATH_NAMES = NO + +# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag +# can be used to strip a user-defined part of the path. Stripping is +# only done if one of the specified strings matches the left-hand part of +# the path. The tag can be used to show relative paths in the file list. +# If left blank the directory from which doxygen is run is used as the +# path to strip. + +STRIP_FROM_PATH = + +# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of +# the path mentioned in the documentation of a class, which tells +# the reader which header file to include in order to use a class. +# If left blank only the name of the header file containing the class +# definition is used. Otherwise one should specify the include paths that +# are normally passed to the compiler using the -I flag. + +STRIP_FROM_INC_PATH = + +# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter +# (but less readable) file names. This can be useful is your file systems +# doesn't support long names like on DOS, Mac, or CD-ROM. + +SHORT_NAMES = NO + +# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen +# will interpret the first line (until the first dot) of a JavaDoc-style +# comment as the brief description. If set to NO, the JavaDoc +# comments will behave just like the Qt-style comments (thus requiring an +# explicit @brief command for a brief description. + +JAVADOC_AUTOBRIEF = YES + +# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen +# treat a multi-line C++ special comment block (i.e. a block of //! or /// +# comments) as a brief description. This used to be the default behaviour. +# The new default is to treat a multi-line C++ comment block as a detailed +# description. Set this tag to YES if you prefer the old behaviour instead. + +MULTILINE_CPP_IS_BRIEF = NO + +# If the DETAILS_AT_TOP tag is set to YES then Doxygen +# will output the detailed description near the top, like JavaDoc. +# If set to NO, the detailed description appears after the member +# documentation. + +DETAILS_AT_TOP = NO + +# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented +# member inherits the documentation from any documented member that it +# re-implements. + +INHERIT_DOCS = YES + +# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC +# tag is set to YES, then doxygen will reuse the documentation of the first +# member in the group (if any) for the other members of the group. By default +# all members of a group must be documented explicitly. + +DISTRIBUTE_GROUP_DOC = NO + +# The TAB_SIZE tag can be used to set the number of spaces in a tab. +# Doxygen uses this value to replace tabs by spaces in code fragments. + +TAB_SIZE = 8 + +# This tag can be used to specify a number of aliases that acts +# as commands in the documentation. An alias has the form "name=value". +# For example adding "sideeffect=\par Side Effects:\n" will allow you to +# put the command \sideeffect (or @sideeffect) in the documentation, which +# will result in a user-defined paragraph with heading "Side Effects:". +# You can put \n's in the value part of an alias to insert newlines. + +ALIASES = + +# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources +# only. Doxygen will then generate output that is more tailored for C. +# For instance, some of the names that are used will be different. The list +# of all members will be omitted, etc. + +OPTIMIZE_OUTPUT_FOR_C = YES + +# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java sources +# only. Doxygen will then generate output that is more tailored for Java. +# For instance, namespaces will be presented as packages, qualified scopes +# will look different, etc. + +OPTIMIZE_OUTPUT_JAVA = NO + +# Set the SUBGROUPING tag to YES (the default) to allow class member groups of +# the same type (for instance a group of public functions) to be put as a +# subgroup of that type (e.g. under the Public Functions section). Set it to +# NO to prevent subgrouping. Alternatively, this can be done per class using +# the \nosubgrouping command. + +SUBGROUPING = YES + +#--------------------------------------------------------------------------- +# Build related configuration options +#--------------------------------------------------------------------------- + +# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in +# documentation are documented, even if no documentation was available. +# Private class members and static file members will be hidden unless +# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES + +EXTRACT_ALL = YES + +# If the EXTRACT_PRIVATE tag is set to YES all private members of a class +# will be included in the documentation. + +EXTRACT_PRIVATE = NO + +# If the EXTRACT_STATIC tag is set to YES all static members of a file +# will be included in the documentation. + +EXTRACT_STATIC = NO + +# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) +# defined locally in source files will be included in the documentation. +# If set to NO only classes defined in header files are included. + +EXTRACT_LOCAL_CLASSES = YES + +# This flag is only useful for Objective-C code. When set to YES local +# methods, which are defined in the implementation section but not in +# the interface are included in the documentation. +# If set to NO (the default) only methods in the interface are included. + +EXTRACT_LOCAL_METHODS = NO + +# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all +# undocumented members of documented classes, files or namespaces. +# If set to NO (the default) these members will be included in the +# various overviews, but no documentation section is generated. +# This option has no effect if EXTRACT_ALL is enabled. + +HIDE_UNDOC_MEMBERS = NO + +# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all +# undocumented classes that are normally visible in the class hierarchy. +# If set to NO (the default) these classes will be included in the various +# overviews. This option has no effect if EXTRACT_ALL is enabled. + +HIDE_UNDOC_CLASSES = NO + +# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all +# friend (class|struct|union) declarations. +# If set to NO (the default) these declarations will be included in the +# documentation. + +HIDE_FRIEND_COMPOUNDS = NO + +# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any +# documentation blocks found inside the body of a function. +# If set to NO (the default) these blocks will be appended to the +# function's detailed documentation block. + +HIDE_IN_BODY_DOCS = NO + +# The INTERNAL_DOCS tag determines if documentation +# that is typed after a \internal command is included. If the tag is set +# to NO (the default) then the documentation will be excluded. +# Set it to YES to include the internal documentation. + +INTERNAL_DOCS = NO + +# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate +# file names in lower-case letters. If set to YES upper-case letters are also +# allowed. This is useful if you have classes or files whose names only differ +# in case and if your file system supports case sensitive file names. Windows +# users are advised to set this option to NO. + +CASE_SENSE_NAMES = YES + +# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen +# will show members with their full class and namespace scopes in the +# documentation. If set to YES the scope will be hidden. + +HIDE_SCOPE_NAMES = NO + +# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen +# will put a list of the files that are included by a file in the documentation +# of that file. + +SHOW_INCLUDE_FILES = YES + +# If the INLINE_INFO tag is set to YES (the default) then a tag [inline] +# is inserted in the documentation for inline members. + +INLINE_INFO = YES + +# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen +# will sort the (detailed) documentation of file and class members +# alphabetically by member name. If set to NO the members will appear in +# declaration order. + +SORT_MEMBER_DOCS = YES + +# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the +# brief documentation of file, namespace and class members alphabetically +# by member name. If set to NO (the default) the members will appear in +# declaration order. + +SORT_BRIEF_DOCS = NO + +# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be +# sorted by fully-qualified names, including namespaces. If set to +# NO (the default), the class list will be sorted only by class name, +# not including the namespace part. +# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES. +# Note: This option applies only to the class list, not to the +# alphabetical list. + +SORT_BY_SCOPE_NAME = NO + +# The GENERATE_TODOLIST tag can be used to enable (YES) or +# disable (NO) the todo list. This list is created by putting \todo +# commands in the documentation. + +GENERATE_TODOLIST = YES + +# The GENERATE_TESTLIST tag can be used to enable (YES) or +# disable (NO) the test list. This list is created by putting \test +# commands in the documentation. + +GENERATE_TESTLIST = YES + +# The GENERATE_BUGLIST tag can be used to enable (YES) or +# disable (NO) the bug list. This list is created by putting \bug +# commands in the documentation. + +GENERATE_BUGLIST = YES + +# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or +# disable (NO) the deprecated list. This list is created by putting +# \deprecated commands in the documentation. + +GENERATE_DEPRECATEDLIST= YES + +# The ENABLED_SECTIONS tag can be used to enable conditional +# documentation sections, marked by \if sectionname ... \endif. + +ENABLED_SECTIONS = + +# The MAX_INITIALIZER_LINES tag determines the maximum number of lines +# the initial value of a variable or define consists of for it to appear in +# the documentation. If the initializer consists of more lines than specified +# here it will be hidden. Use a value of 0 to hide initializers completely. +# The appearance of the initializer of individual variables and defines in the +# documentation can be controlled using \showinitializer or \hideinitializer +# command in the documentation regardless of this setting. + +MAX_INITIALIZER_LINES = 30 + +# Set the SHOW_USED_FILES tag to NO to disable the list of files generated +# at the bottom of the documentation of classes and structs. If set to YES the +# list will mention the files that were used to generate the documentation. + +SHOW_USED_FILES = YES + +#--------------------------------------------------------------------------- +# configuration options related to warning and progress messages +#--------------------------------------------------------------------------- + +# The QUIET tag can be used to turn on/off the messages that are generated +# by doxygen. Possible values are YES and NO. If left blank NO is used. + +QUIET = NO + +# The WARNINGS tag can be used to turn on/off the warning messages that are +# generated by doxygen. Possible values are YES and NO. If left blank +# NO is used. + +WARNINGS = YES + +# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings +# for undocumented members. If EXTRACT_ALL is set to YES then this flag will +# automatically be disabled. + +WARN_IF_UNDOCUMENTED = YES + +# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for +# potential errors in the documentation, such as not documenting some +# parameters in a documented function, or documenting parameters that +# don't exist or using markup commands wrongly. + +WARN_IF_DOC_ERROR = YES + +# The WARN_FORMAT tag determines the format of the warning messages that +# doxygen can produce. The string should contain the $file, $line, and $text +# tags, which will be replaced by the file and line number from which the +# warning originated and the warning text. + +WARN_FORMAT = "$file:$line: $text" + +# The WARN_LOGFILE tag can be used to specify a file to which warning +# and error messages should be written. If left blank the output is written +# to stderr. + +WARN_LOGFILE = + +#--------------------------------------------------------------------------- +# configuration options related to the input files +#--------------------------------------------------------------------------- + +# The INPUT tag can be used to specify the files and/or directories that contain +# documented source files. You may enter file names like "myfile.cpp" or +# directories like "/usr/src/myproject". Separate the files or directories +# with spaces. + +INPUT = @top_srcdir@/include/vorbis + +# If the value of the INPUT tag contains directories, you can use the +# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp +# and *.h) to filter out the source-files in the directories. If left +# blank the following patterns are tested: +# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx *.hpp +# *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm + +FILE_PATTERNS = + +# The RECURSIVE tag can be used to turn specify whether or not subdirectories +# should be searched for input files as well. Possible values are YES and NO. +# If left blank NO is used. + +RECURSIVE = NO + +# The EXCLUDE tag can be used to specify files and/or directories that should +# excluded from the INPUT source files. This way you can easily exclude a +# subdirectory from a directory tree whose root is specified with the INPUT tag. + +EXCLUDE = + +# The EXCLUDE_SYMLINKS tag can be used select whether or not files or directories +# that are symbolic links (a Unix filesystem feature) are excluded from the input. + +EXCLUDE_SYMLINKS = NO + +# If the value of the INPUT tag contains directories, you can use the +# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude +# certain files from those directories. + +EXCLUDE_PATTERNS = + +# The EXAMPLE_PATH tag can be used to specify one or more files or +# directories that contain example code fragments that are included (see +# the \include command). + +EXAMPLE_PATH = + +# If the value of the EXAMPLE_PATH tag contains directories, you can use the +# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp +# and *.h) to filter out the source-files in the directories. If left +# blank all files are included. + +EXAMPLE_PATTERNS = + +# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be +# searched for input files to be used with the \include or \dontinclude +# commands irrespective of the value of the RECURSIVE tag. +# Possible values are YES and NO. If left blank NO is used. + +EXAMPLE_RECURSIVE = NO + +# The IMAGE_PATH tag can be used to specify one or more files or +# directories that contain image that are included in the documentation (see +# the \image command). + +IMAGE_PATH = + +# The INPUT_FILTER tag can be used to specify a program that doxygen should +# invoke to filter for each input file. Doxygen will invoke the filter program +# by executing (via popen()) the command , where +# is the value of the INPUT_FILTER tag, and is the name of an +# input file. Doxygen will then use the output that the filter program writes +# to standard output. + +INPUT_FILTER = + +# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using +# INPUT_FILTER) will be used to filter the input files when producing source +# files to browse (i.e. when SOURCE_BROWSER is set to YES). + +FILTER_SOURCE_FILES = NO + +#--------------------------------------------------------------------------- +# configuration options related to source browsing +#--------------------------------------------------------------------------- + +# If the SOURCE_BROWSER tag is set to YES then a list of source files will +# be generated. Documented entities will be cross-referenced with these sources. +# Note: To get rid of all source code in the generated output, make sure also +# VERBATIM_HEADERS is set to NO. + +SOURCE_BROWSER = NO + +# Setting the INLINE_SOURCES tag to YES will include the body +# of functions and classes directly in the documentation. + +INLINE_SOURCES = NO + +# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct +# doxygen to hide any special comment blocks from generated source code +# fragments. Normal C and C++ comments will always remain visible. + +STRIP_CODE_COMMENTS = YES + +# If the REFERENCED_BY_RELATION tag is set to YES (the default) +# then for each documented function all documented +# functions referencing it will be listed. + +REFERENCED_BY_RELATION = YES + +# If the REFERENCES_RELATION tag is set to YES (the default) +# then for each documented function all documented entities +# called/used by that function will be listed. + +REFERENCES_RELATION = YES + +# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen +# will generate a verbatim copy of the header file for each class for +# which an include is specified. Set to NO to disable this. + +VERBATIM_HEADERS = YES + +#--------------------------------------------------------------------------- +# configuration options related to the alphabetical class index +#--------------------------------------------------------------------------- + +# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index +# of all compounds will be generated. Enable this if the project +# contains a lot of classes, structs, unions or interfaces. + +ALPHABETICAL_INDEX = NO + +# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then +# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns +# in which this list will be split (can be a number in the range [1..20]) + +COLS_IN_ALPHA_INDEX = 5 + +# In case all classes in a project start with a common prefix, all +# classes will be put under the same header in the alphabetical index. +# The IGNORE_PREFIX tag can be used to specify one or more prefixes that +# should be ignored while generating the index headers. + +IGNORE_PREFIX = + +#--------------------------------------------------------------------------- +# configuration options related to the HTML output +#--------------------------------------------------------------------------- + +# If the GENERATE_HTML tag is set to YES (the default) Doxygen will +# generate HTML output. + +GENERATE_HTML = YES + +# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be +# put in front of it. If left blank `html' will be used as the default path. + +HTML_OUTPUT = html + +# The HTML_FILE_EXTENSION tag can be used to specify the file extension for +# each generated HTML page (for example: .htm,.php,.asp). If it is left blank +# doxygen will generate files with .html extension. + +HTML_FILE_EXTENSION = .html + +# The HTML_HEADER tag can be used to specify a personal HTML header for +# each generated HTML page. If it is left blank doxygen will generate a +# standard header. + +HTML_HEADER = + +# The HTML_FOOTER tag can be used to specify a personal HTML footer for +# each generated HTML page. If it is left blank doxygen will generate a +# standard footer. + +HTML_FOOTER = + +# The HTML_STYLESHEET tag can be used to specify a user-defined cascading +# style sheet that is used by each HTML page. It can be used to +# fine-tune the look of the HTML output. If the tag is left blank doxygen +# will generate a default style sheet. Note that doxygen will try to copy +# the style sheet file to the HTML output directory, so don't put your own +# stylesheet in the HTML output directory as well, or it will be erased! + +HTML_STYLESHEET = + +# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes, +# files or namespaces will be aligned in HTML using tables. If set to +# NO a bullet list will be used. + +HTML_ALIGN_MEMBERS = YES + +# If the GENERATE_HTMLHELP tag is set to YES, additional index files +# will be generated that can be used as input for tools like the +# Microsoft HTML help workshop to generate a compressed HTML help file (.chm) +# of the generated HTML documentation. + +GENERATE_HTMLHELP = NO + +# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can +# be used to specify the file name of the resulting .chm file. You +# can add a path in front of the file if the result should not be +# written to the html output directory. + +CHM_FILE = + +# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can +# be used to specify the location (absolute path including file name) of +# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run +# the HTML help compiler on the generated index.hhp. + +HHC_LOCATION = + +# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag +# controls if a separate .chi index file is generated (YES) or that +# it should be included in the master .chm file (NO). + +GENERATE_CHI = NO + +# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag +# controls whether a binary table of contents is generated (YES) or a +# normal table of contents (NO) in the .chm file. + +BINARY_TOC = NO + +# The TOC_EXPAND flag can be set to YES to add extra items for group members +# to the contents of the HTML help documentation and to the tree view. + +TOC_EXPAND = NO + +# The DISABLE_INDEX tag can be used to turn on/off the condensed index at +# top of each HTML page. The value NO (the default) enables the index and +# the value YES disables it. + +DISABLE_INDEX = NO + +# This tag can be used to set the number of enum values (range [1..20]) +# that doxygen will group on one line in the generated HTML documentation. + +ENUM_VALUES_PER_LINE = 4 + +# If the GENERATE_TREEVIEW tag is set to YES, a side panel will be +# generated containing a tree-like index structure (just like the one that +# is generated for HTML Help). For this to work a browser that supports +# JavaScript, DHTML, CSS and frames is required (for instance Mozilla 1.0+, +# Netscape 6.0+, Internet explorer 5.0+, or Konqueror). Windows users are +# probably better off using the HTML help feature. + +GENERATE_TREEVIEW = NO + +# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be +# used to set the initial width (in pixels) of the frame in which the tree +# is shown. + +TREEVIEW_WIDTH = 250 + +#--------------------------------------------------------------------------- +# configuration options related to the LaTeX output +#--------------------------------------------------------------------------- + +# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will +# generate Latex output. + +GENERATE_LATEX = YES + +# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be +# put in front of it. If left blank `latex' will be used as the default path. + +LATEX_OUTPUT = latex + +# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be +# invoked. If left blank `latex' will be used as the default command name. + +LATEX_CMD_NAME = latex + +# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to +# generate index for LaTeX. If left blank `makeindex' will be used as the +# default command name. + +MAKEINDEX_CMD_NAME = makeindex + +# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact +# LaTeX documents. This may be useful for small projects and may help to +# save some trees in general. + +COMPACT_LATEX = NO + +# The PAPER_TYPE tag can be used to set the paper type that is used +# by the printer. Possible values are: a4, a4wide, letter, legal and +# executive. If left blank a4wide will be used. + +PAPER_TYPE = a4wide + +# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX +# packages that should be included in the LaTeX output. + +EXTRA_PACKAGES = + +# The LATEX_HEADER tag can be used to specify a personal LaTeX header for +# the generated latex document. The header should contain everything until +# the first chapter. If it is left blank doxygen will generate a +# standard header. Notice: only use this tag if you know what you are doing! + +LATEX_HEADER = + +# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated +# is prepared for conversion to pdf (using ps2pdf). The pdf file will +# contain links (just like the HTML output) instead of page references +# This makes the output suitable for online browsing using a pdf viewer. + +PDF_HYPERLINKS = NO + +# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of +# plain latex in the generated Makefile. Set this option to YES to get a +# higher quality PDF documentation. + +USE_PDFLATEX = NO + +# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode. +# command to the generated LaTeX files. This will instruct LaTeX to keep +# running if errors occur, instead of asking the user for help. +# This option is also used when generating formulas in HTML. + +LATEX_BATCHMODE = NO + +# If LATEX_HIDE_INDICES is set to YES then doxygen will not +# include the index chapters (such as File Index, Compound Index, etc.) +# in the output. + +LATEX_HIDE_INDICES = NO + +#--------------------------------------------------------------------------- +# configuration options related to the RTF output +#--------------------------------------------------------------------------- + +# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output +# The RTF output is optimized for Word 97 and may not look very pretty with +# other RTF readers or editors. + +GENERATE_RTF = NO + +# The RTF_OUTPUT tag is used to specify where the RTF docs will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be +# put in front of it. If left blank `rtf' will be used as the default path. + +RTF_OUTPUT = rtf + +# If the COMPACT_RTF tag is set to YES Doxygen generates more compact +# RTF documents. This may be useful for small projects and may help to +# save some trees in general. + +COMPACT_RTF = NO + +# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated +# will contain hyperlink fields. The RTF file will +# contain links (just like the HTML output) instead of page references. +# This makes the output suitable for online browsing using WORD or other +# programs which support those fields. +# Note: wordpad (write) and others do not support links. + +RTF_HYPERLINKS = NO + +# Load stylesheet definitions from file. Syntax is similar to doxygen's +# config file, i.e. a series of assignments. You only have to provide +# replacements, missing definitions are set to their default value. + +RTF_STYLESHEET_FILE = + +# Set optional variables used in the generation of an rtf document. +# Syntax is similar to doxygen's config file. + +RTF_EXTENSIONS_FILE = + +#--------------------------------------------------------------------------- +# configuration options related to the man page output +#--------------------------------------------------------------------------- + +# If the GENERATE_MAN tag is set to YES (the default) Doxygen will +# generate man pages + +GENERATE_MAN = NO + +# The MAN_OUTPUT tag is used to specify where the man pages will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be +# put in front of it. If left blank `man' will be used as the default path. + +MAN_OUTPUT = man + +# The MAN_EXTENSION tag determines the extension that is added to +# the generated man pages (default is the subroutine's section .3) + +MAN_EXTENSION = .3 + +# If the MAN_LINKS tag is set to YES and Doxygen generates man output, +# then it will generate one additional man file for each entity +# documented in the real man page(s). These additional files +# only source the real man page, but without them the man command +# would be unable to find the correct page. The default is NO. + +MAN_LINKS = NO + +#--------------------------------------------------------------------------- +# configuration options related to the XML output +#--------------------------------------------------------------------------- + +# If the GENERATE_XML tag is set to YES Doxygen will +# generate an XML file that captures the structure of +# the code including all documentation. + +GENERATE_XML = NO + +# The XML_OUTPUT tag is used to specify where the XML pages will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be +# put in front of it. If left blank `xml' will be used as the default path. + +XML_OUTPUT = xml + +# The XML_SCHEMA tag can be used to specify an XML schema, +# which can be used by a validating XML parser to check the +# syntax of the XML files. + +XML_SCHEMA = + +# The XML_DTD tag can be used to specify an XML DTD, +# which can be used by a validating XML parser to check the +# syntax of the XML files. + +XML_DTD = + +# If the XML_PROGRAMLISTING tag is set to YES Doxygen will +# dump the program listings (including syntax highlighting +# and cross-referencing information) to the XML output. Note that +# enabling this will significantly increase the size of the XML output. + +XML_PROGRAMLISTING = YES + +#--------------------------------------------------------------------------- +# configuration options for the AutoGen Definitions output +#--------------------------------------------------------------------------- + +# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will +# generate an AutoGen Definitions (see autogen.sf.net) file +# that captures the structure of the code including all +# documentation. Note that this feature is still experimental +# and incomplete at the moment. + +GENERATE_AUTOGEN_DEF = NO + +#--------------------------------------------------------------------------- +# configuration options related to the Perl module output +#--------------------------------------------------------------------------- + +# If the GENERATE_PERLMOD tag is set to YES Doxygen will +# generate a Perl module file that captures the structure of +# the code including all documentation. Note that this +# feature is still experimental and incomplete at the +# moment. + +GENERATE_PERLMOD = NO + +# If the PERLMOD_LATEX tag is set to YES Doxygen will generate +# the necessary Makefile rules, Perl scripts and LaTeX code to be able +# to generate PDF and DVI output from the Perl module output. + +PERLMOD_LATEX = NO + +# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be +# nicely formatted so it can be parsed by a human reader. This is useful +# if you want to understand what is going on. On the other hand, if this +# tag is set to NO the size of the Perl module output will be much smaller +# and Perl will parse it just the same. + +PERLMOD_PRETTY = YES + +# The names of the make variables in the generated doxyrules.make file +# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX. +# This is useful so different doxyrules.make files included by the same +# Makefile don't overwrite each other's variables. + +PERLMOD_MAKEVAR_PREFIX = + +#--------------------------------------------------------------------------- +# Configuration options related to the preprocessor +#--------------------------------------------------------------------------- + +# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will +# evaluate all C-preprocessor directives found in the sources and include +# files. + +ENABLE_PREPROCESSING = YES + +# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro +# names in the source code. If set to NO (the default) only conditional +# compilation will be performed. Macro expansion can be done in a controlled +# way by setting EXPAND_ONLY_PREDEF to YES. + +MACRO_EXPANSION = NO + +# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES +# then the macro expansion is limited to the macros specified with the +# PREDEFINED and EXPAND_AS_PREDEFINED tags. + +EXPAND_ONLY_PREDEF = NO + +# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files +# in the INCLUDE_PATH (see below) will be search if a #include is found. + +SEARCH_INCLUDES = YES + +# The INCLUDE_PATH tag can be used to specify one or more directories that +# contain include files that are not input files but should be processed by +# the preprocessor. + +INCLUDE_PATH = + +# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard +# patterns (like *.h and *.hpp) to filter out the header-files in the +# directories. If left blank, the patterns specified with FILE_PATTERNS will +# be used. + +INCLUDE_FILE_PATTERNS = + +# The PREDEFINED tag can be used to specify one or more macro names that +# are defined before the preprocessor is started (similar to the -D option of +# gcc). The argument of the tag is a list of macros of the form: name +# or name=definition (no spaces). If the definition and the = are +# omitted =1 is assumed. + +PREDEFINED = + +# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then +# this tag can be used to specify a list of macro names that should be expanded. +# The macro definition that is found in the sources will be used. +# Use the PREDEFINED tag if you want to use a different macro definition. + +EXPAND_AS_DEFINED = + +# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then +# doxygen's preprocessor will remove all function-like macros that are alone +# on a line, have an all uppercase name, and do not end with a semicolon. Such +# function macros are typically used for boiler-plate code, and will confuse the +# parser if not removed. + +SKIP_FUNCTION_MACROS = YES + +#--------------------------------------------------------------------------- +# Configuration::additions related to external references +#--------------------------------------------------------------------------- + +# The TAGFILES option can be used to specify one or more tagfiles. +# Optionally an initial location of the external documentation +# can be added for each tagfile. The format of a tag file without +# this location is as follows: +# TAGFILES = file1 file2 ... +# Adding location for the tag files is done as follows: +# TAGFILES = file1=loc1 "file2 = loc2" ... +# where "loc1" and "loc2" can be relative or absolute paths or +# URLs. If a location is present for each tag, the installdox tool +# does not have to be run to correct the links. +# Note that each tag file must have a unique name +# (where the name does NOT include the path) +# If a tag file is not located in the directory in which doxygen +# is run, you must also specify the path to the tagfile here. + +TAGFILES = + +# When a file name is specified after GENERATE_TAGFILE, doxygen will create +# a tag file that is based on the input files it reads. + +GENERATE_TAGFILE = + +# If the ALLEXTERNALS tag is set to YES all external classes will be listed +# in the class index. If set to NO only the inherited external classes +# will be listed. + +ALLEXTERNALS = NO + +# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed +# in the modules index. If set to NO, only the current project's groups will +# be listed. + +EXTERNAL_GROUPS = YES + +# The PERL_PATH should be the absolute path and name of the perl script +# interpreter (i.e. the result of `which perl'). + +PERL_PATH = /usr/bin/perl + +#--------------------------------------------------------------------------- +# Configuration options related to the dot tool +#--------------------------------------------------------------------------- + +# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will +# generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base or +# super classes. Setting the tag to NO turns the diagrams off. Note that this +# option is superseded by the HAVE_DOT option below. This is only a fallback. It is +# recommended to install and use dot, since it yields more powerful graphs. + +CLASS_DIAGRAMS = YES + +# If set to YES, the inheritance and collaboration graphs will hide +# inheritance and usage relations if the target is undocumented +# or is not a class. + +HIDE_UNDOC_RELATIONS = YES + +# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is +# available from the path. This tool is part of Graphviz, a graph visualization +# toolkit from AT&T and Lucent Bell Labs. The other options in this section +# have no effect if this option is set to NO (the default) + +HAVE_DOT = NO + +# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen +# will generate a graph for each documented class showing the direct and +# indirect inheritance relations. Setting this tag to YES will force the +# the CLASS_DIAGRAMS tag to NO. + +CLASS_GRAPH = YES + +# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen +# will generate a graph for each documented class showing the direct and +# indirect implementation dependencies (inheritance, containment, and +# class references variables) of the class with other documented classes. + +COLLABORATION_GRAPH = YES + +# If the UML_LOOK tag is set to YES doxygen will generate inheritance and +# collaboration diagrams in a style similar to the OMG's Unified Modeling +# Language. + +UML_LOOK = NO + +# If set to YES, the inheritance and collaboration graphs will show the +# relations between templates and their instances. + +TEMPLATE_RELATIONS = NO + +# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT +# tags are set to YES then doxygen will generate a graph for each documented +# file showing the direct and indirect include dependencies of the file with +# other documented files. + +INCLUDE_GRAPH = YES + +# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and +# HAVE_DOT tags are set to YES then doxygen will generate a graph for each +# documented header file showing the documented files that directly or +# indirectly include this file. + +INCLUDED_BY_GRAPH = YES + +# If the CALL_GRAPH and HAVE_DOT tags are set to YES then doxygen will +# generate a call dependency graph for every global function or class method. +# Note that enabling this option will significantly increase the time of a run. +# So in most cases it will be better to enable call graphs for selected +# functions only using the \callgraph command. + +CALL_GRAPH = NO + +# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen +# will graphical hierarchy of all classes instead of a textual one. + +GRAPHICAL_HIERARCHY = YES + +# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images +# generated by dot. Possible values are png, jpg, or gif +# If left blank png will be used. + +DOT_IMAGE_FORMAT = png + +# The tag DOT_PATH can be used to specify the path where the dot tool can be +# found. If left blank, it is assumed the dot tool can be found on the path. + +DOT_PATH = + +# The DOTFILE_DIRS tag can be used to specify one or more directories that +# contain dot files that are included in the documentation (see the +# \dotfile command). + +DOTFILE_DIRS = + +# The MAX_DOT_GRAPH_WIDTH tag can be used to set the maximum allowed width +# (in pixels) of the graphs generated by dot. If a graph becomes larger than +# this value, doxygen will try to truncate the graph, so that it fits within +# the specified constraint. Beware that most browsers cannot cope with very +# large images. +#This tag is now obsolete, according to doxygen 1.5.2 +#MAX_DOT_GRAPH_WIDTH = 1024 + +# The MAX_DOT_GRAPH_HEIGHT tag can be used to set the maximum allows height +# (in pixels) of the graphs generated by dot. If a graph becomes larger than +# this value, doxygen will try to truncate the graph, so that it fits within +# the specified constraint. Beware that most browsers cannot cope with very +# large images. +#This tag is now obsolete, according to doxygen 1.5.2 +#MAX_DOT_GRAPH_HEIGHT = 1024 + +# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the +# graphs generated by dot. A depth value of 3 means that only nodes reachable +# from the root by following a path via at most 3 edges will be shown. Nodes that +# lay further from the root node will be omitted. Note that setting this option to +# 1 or 2 may greatly reduce the computation time needed for large code bases. Also +# note that a graph may be further truncated if the graph's image dimensions are +# not sufficient to fit the graph (see MAX_DOT_GRAPH_WIDTH and MAX_DOT_GRAPH_HEIGHT). +# If 0 is used for the depth value (the default), the graph is not depth-constrained. +#This tag is now obsolete, according to doxygen 1.5.2 +#MAX_DOT_GRAPH_DEPTH = 0 + +# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will +# generate a legend page explaining the meaning of the various boxes and +# arrows in the dot generated graphs. + +GENERATE_LEGEND = YES + +# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will +# remove the intermediate dot files that are used to generate +# the various graphs. + +DOT_CLEANUP = YES + +#--------------------------------------------------------------------------- +# Configuration::additions related to the search engine +#--------------------------------------------------------------------------- + +# The SEARCHENGINE tag specifies whether or not a search engine should be +# used. If set to NO the values of all tags below this one will be ignored. + +SEARCHENGINE = NO diff --git a/doc/Makefile.am b/doc/Makefile.am new file mode 100644 index 0000000..0e96ba1 --- /dev/null +++ b/doc/Makefile.am @@ -0,0 +1,148 @@ +## Process this with automake to create Makefile.in + +SUBDIRS = libvorbis vorbisfile vorbisenc + +docdir = $(datadir)/doc/$(PACKAGE)-$(VERSION) + +### all of the static docs, commited to SVN and included as is +static_docs = \ + rfc5215.xml \ + rfc5215.txt \ + eightphase.png \ + fish_xiph_org.png \ + floor1_inverse_dB_table.html \ + floorval.png \ + fourphase.png \ + framing.html \ + helper.html \ + index.html \ + oggstream.html \ + programming.html \ + squarepolar.png \ + stereo.html \ + stream.png \ + v-comment.html \ + vorbis-clip.txt \ + vorbis-errors.txt \ + vorbis-fidelity.html + +# bits needed by the spec +SPEC_PNG = \ + components.png \ + floor1-1.png \ + floor1-2.png \ + floor1-3.png \ + floor1-4.png \ + hufftree.png \ + hufftree-under.png \ + residue-pack.png \ + residue2.png \ + window1.png \ + window2.png \ + Vorbis_I_spec0x.png \ + Vorbis_I_spec1x.png \ + Vorbis_I_spec2x.png \ + Vorbis_I_spec3x.png \ + Vorbis_I_spec4x.png \ + Vorbis_I_spec5x.png \ + Vorbis_I_spec6x.png \ + Vorbis_I_spec7x.png \ + Vorbis_I_spec8x.png \ + Vorbis_I_spec9x.png \ + Vorbis_I_spec10x.png \ + Vorbis_I_spec11x.png \ + Vorbis_I_spec12x.png \ + Vorbis_I_spec13x.png \ + Vorbis_I_spec14x.png + +SPEC_TEX = \ + Vorbis_I_spec.tex \ + 01-introduction.tex \ + 02-bitpacking.tex \ + 03-codebook.tex \ + 04-codec.tex \ + 05-comment.tex \ + 06-floor0.tex \ + 07-floor1.tex \ + 08-residue.tex \ + 09-helper.tex \ + 10-tables.tex \ + a1-encapsulation-ogg.tex \ + a2-encapsulation-rtp.tex \ + footer.tex + +built_docs = Vorbis_I_spec.pdf Vorbis_I_spec.html Vorbis_I_spec.css + +# conditionally make the generated documentation +if BUILD_DOCS +doc_DATA = $(static_docs) $(SPEC_PNG) $(built_docs) doxygen-build.stamp +else +doc_DATA = $(static_docs) doxygen-build.stamp +endif + +EXTRA_DIST = $(static_docs) $(built_docs) \ + $(SPEC_TEX) $(SPEC_PNG) $(SPEC_PDF) Vorbis_I_spec.cfg Doxyfile.in + +# these are expensive; only remove if we have to +MAINTAINERCLEANFILES = $(built_docs) +CLEANFILES = $(SPEC_TEX:%.tex=%.aux) \ + Vorbis_I_spec.4ct Vorbis_I_spec.4tc \ + Vorbis_I_spec.dvi Vorbis_I_spec.idv \ + Vorbis_I_spec.lg Vorbis_I_spec.log \ + Vorbis_I_spec.out Vorbis_I_spec.tmp \ + Vorbis_I_spec.toc Vorbis_I_spec.xref \ + zzVorbis_I_spec.ps +DISTCLEANFILES = $(built_docs) + + +# explicit rules for generating docs +if BUILD_DOCS +Vorbis_I_spec.html Vorbis_I_spec.css: $(SPEC_TEX) $(SPEC_PNG) fish_xiph_org.png + htlatex $< + +Vorbis_I_spec.pdf: $(SPEC_TEX) $(SPEC_PNG) + pdflatex $< + pdflatex $< + pdflatex $< +else +Vorbis_I_spec.html: NO_DOCS_ERROR +Vorbis_I_spec.pdf: NO_DOCS_ERROR +NO_DOCS_ERROR: + @echo + @echo "*** Documentation has not been built! ***" + @echo "Try re-running after passing --enable-docs to configure." + @echo +endif + +if HAVE_DOXYGEN +doxygen-build.stamp: Doxyfile $(top_srcdir)/include/vorbis/*.h + doxygen + touch doxygen-build.stamp +else +doxygen-build.stamp: + echo "*** Warning: Documentation build is disabled." + touch doxygen-build.stamp +endif + +install-data-local: doxygen-build.stamp + $(mkinstalldirs) $(DESTDIR)$(docdir) + if test -d vorbis; then \ + for dir in vorbis/*; do \ + if test -d $$dir; then \ + b=`basename $$dir`; \ + $(mkinstalldirs) $(DESTDIR)$(docdir)/$$b; \ + for f in $$dir/*; do \ + $(INSTALL_DATA) $$f $(DESTDIR)$(docdir)/$$b; \ + done \ + fi \ + done \ + fi + +uninstall-local: + rm -rf $(DESTDIR)$(docdir) + +clean-local: + if test -d vorbis; then rm -rf vorbis; fi + if test -f doxygen-build.stamp; then rm -f doxygen-build.stamp; fi + + diff --git a/doc/Vorbis_I_spec.cfg b/doc/Vorbis_I_spec.cfg new file mode 100644 index 0000000..6fca7ce --- /dev/null +++ b/doc/Vorbis_I_spec.cfg @@ -0,0 +1,4 @@ +\Preamble{html} +\begin{document} + \DeclareGraphicsExtensions{.png} +\EndPreamble diff --git a/doc/Vorbis_I_spec.css b/doc/Vorbis_I_spec.css new file mode 100644 index 0000000..5331f18 --- /dev/null +++ b/doc/Vorbis_I_spec.css @@ -0,0 +1,144 @@ + +/* start css.sty */ +.cmex-10{font-size:83%;} +.cmssbx-10x-x-120{ font-family: sans-serif; font-weight: bold;} +.cmssbx-10x-x-120{ font-family: sans-serif; font-weight: bold;} +.cmssbx-10x-x-248{font-size:206%; font-family: sans-serif; font-weight: bold;} +.cmssbx-10x-x-248{ font-family: sans-serif; font-weight: bold;} +.cmr-17{font-size:141%;} +.cmmi-12{font-style: italic;} +.cmtt-12{font-family: monospace;} +.cmtt-12{font-family: monospace;} +.cmtt-12{font-family: monospace;} +.cmbx-12{ font-weight: bold;} +.cmti-12{ font-style: italic;} +.cmr-8{font-size:66%;} +.cmr-6{font-size:50%;} +.cmmi-8{font-size:66%;font-style: italic;} +.cmsy-8{font-size:66%;} +.cmsy-6{font-size:50%;} +.cmtt-8{font-size:66%;font-family: monospace;} +.cmtt-8{font-family: monospace;} +.cmtt-8{font-family: monospace;} +.cmtt-8x-x-75{font-size:50%;font-family: monospace;} +.cmtt-8x-x-75{font-family: monospace;} +.cmtt-8x-x-75{font-family: monospace;} +p.noindent { text-indent: 0em } +td p.noindent { text-indent: 0em; margin-top:0em; } +p.nopar { text-indent: 0em; } +p.indent{ text-indent: 1.5em } +@media print {div.crosslinks {visibility:hidden;}} +a img { border-top: 0; border-left: 0; border-right: 0; } +center { margin-top:1em; margin-bottom:1em; } +td center { margin-top:0em; margin-bottom:0em; } +.Canvas { position:relative; } +img.math{vertical-align:middle;} +li p.indent { text-indent: 0em } +li p:first-child{ margin-top:0em; } +li p:last-child, li div:last-child { margin-bottom:0.5em; } +li p~ul:last-child, li p~ol:last-child{ margin-bottom:0.5em; } +.enumerate1 {list-style-type:decimal;} +.enumerate2 {list-style-type:lower-alpha;} +.enumerate3 {list-style-type:lower-roman;} +.enumerate4 {list-style-type:upper-alpha;} +div.newtheorem { margin-bottom: 2em; margin-top: 2em;} +.obeylines-h,.obeylines-v {white-space: nowrap; } +div.obeylines-v p { margin-top:0; margin-bottom:0; } +.overline{ text-decoration:overline; } +.overline img{ border-top: 1px solid black; } +td.displaylines {text-align:center; white-space:nowrap;} +.centerline {text-align:center;} +.rightline {text-align:right;} +div.verbatim {font-family: monospace; white-space: nowrap; text-align:left; clear:both; } +.fbox {padding-left:3.0pt; padding-right:3.0pt; text-indent:0pt; border:solid black 0.4pt; } +div.fbox {display:table} +div.center div.fbox {text-align:center; clear:both; padding-left:3.0pt; padding-right:3.0pt; text-indent:0pt; border:solid black 0.4pt; } +div.minipage{width:100%;} +div.center, div.center div.center {text-align: center; margin-left:1em; margin-right:1em;} +div.center div {text-align: left;} +div.flushright, div.flushright div.flushright {text-align: right;} +div.flushright div {text-align: left;} +div.flushleft {text-align: left;} +.underline{ text-decoration:underline; } +.underline img{ border-bottom: 1px solid black; margin-bottom:1pt; } +.framebox-c, .framebox-l, .framebox-r { padding-left:3.0pt; padding-right:3.0pt; text-indent:0pt; border:solid black 0.4pt; } +.framebox-c {text-align:center;} +.framebox-l {text-align:left;} +.framebox-r {text-align:right;} +span.thank-mark{ vertical-align: super } +span.footnote-mark sup.textsuperscript, span.footnote-mark a sup.textsuperscript{ font-size:80%; } +div.tabular, div.center div.tabular {text-align: center; margin-top:0.5em; margin-bottom:0.5em; } +table.tabular td p{margin-top:0em;} +table.tabular {margin-left: auto; margin-right: auto;} +td p:first-child{ margin-top:0em; } +td p:last-child{ margin-bottom:0em; } +div.td00{ margin-left:0pt; margin-right:0pt; } +div.td01{ margin-left:0pt; margin-right:5pt; } +div.td10{ margin-left:5pt; margin-right:0pt; } +div.td11{ margin-left:5pt; margin-right:5pt; } +table[rules] {border-left:solid black 0.4pt; border-right:solid black 0.4pt; } +td.td00{ padding-left:0pt; padding-right:0pt; } +td.td01{ padding-left:0pt; padding-right:5pt; } +td.td10{ padding-left:5pt; padding-right:0pt; } +td.td11{ padding-left:5pt; padding-right:5pt; } +table[rules] {border-left:solid black 0.4pt; border-right:solid black 0.4pt; } +.hline hr, .cline hr{ height : 1px; margin:0px; } +.tabbing-right {text-align:right;} +span.TEX {letter-spacing: -0.125em; } +span.TEX span.E{ position:relative;top:0.5ex;left:-0.0417em;} +a span.TEX span.E {text-decoration: none; } +span.LATEX span.A{ position:relative; top:-0.5ex; left:-0.4em; font-size:85%;} +span.LATEX span.TEX{ position:relative; left: -0.4em; } +div.float, div.figure {margin-left: auto; margin-right: auto;} +div.float img {text-align:center;} +div.figure img {text-align:center;} +.marginpar {width:20%; float:right; text-align:left; margin-left:auto; margin-top:0.5em; font-size:85%; text-decoration:underline;} +.marginpar p{margin-top:0.4em; margin-bottom:0.4em;} +table.equation {width:100%;} +.equation td{text-align:center; } +td.equation { margin-top:1em; margin-bottom:1em; } +td.equation-label { width:5%; text-align:center; } +td.eqnarray4 { width:5%; white-space: normal; } +td.eqnarray2 { width:5%; } +table.eqnarray-star, table.eqnarray {width:100%;} +div.eqnarray{text-align:center;} +div.array {text-align:center;} +div.pmatrix {text-align:center;} +table.pmatrix {width:100%;} +span.pmatrix img{vertical-align:middle;} +div.pmatrix {text-align:center;} +table.pmatrix {width:100%;} +span.bar-css {text-decoration:overline;} +img.cdots{vertical-align:middle;} +.partToc a, .partToc, .likepartToc a, .likepartToc {line-height: 200%; font-weight:bold; font-size:110%;} +.chapterToc a, .chapterToc, .likechapterToc a, .likechapterToc, .appendixToc a, .appendixToc {line-height: 200%; font-weight:bold;} +.index-item, .index-subitem, .index-subsubitem {display:block} +div.caption {text-indent:-2em; margin-left:3em; margin-right:1em; text-align:left;} +div.caption span.id{font-weight: bold; white-space: nowrap; } +h1.partHead{text-align: center} +p.bibitem { text-indent: -2em; margin-left: 2em; margin-top:0.6em; margin-bottom:0.6em; } +p.bibitem-p { text-indent: 0em; margin-left: 2em; margin-top:0.6em; margin-bottom:0.6em; } +.paragraphHead, .likeparagraphHead { margin-top:2em; font-weight: bold;} +.subparagraphHead, .likesubparagraphHead { font-weight: bold;} +.quote {margin-bottom:0.25em; margin-top:0.25em; margin-left:1em; margin-right:1em; text-align:justify;} +.verse{white-space:nowrap; margin-left:2em} +div.maketitle {text-align:center;} +h2.titleHead{text-align:center;} +div.maketitle{ margin-bottom: 2em; } +div.author, div.date {text-align:center;} +div.thanks{text-align:left; margin-left:10%; font-size:85%; font-style:italic; } +div.author{white-space: nowrap;} +.quotation {margin-bottom:0.25em; margin-top:0.25em; margin-left:1em; } +.abstract p {margin-left:5%; margin-right:5%;} +div.abstract {width:100%;} +span.footnote-mark sup.textsuperscript, span.footnote-mark a sup.textsuperscript{ font-size:80%; } +.figure img.graphics {margin-left:10%;} +P.fancyvrb {white-space: nowrap; margin:0em;} +dt.enumerate-enumitem{float:left; clear:left; margin-left:1em; margin-right:1em;} +.uline{ text-decoration:underline; } +.uuline{ text-decoration:underline; } +span.sout {text-decoration: line-through } +span.xout {text-decoration: line-through } +span.uwave {text-decoration:underline } +/* end css.sty */ + diff --git a/doc/Vorbis_I_spec.html b/doc/Vorbis_I_spec.html new file mode 100644 index 0000000..629b2fb --- /dev/null +++ b/doc/Vorbis_I_spec.html @@ -0,0 +1,13243 @@ + + +Vorbis I specification + + + + + + + + +
+ + + + + + + +

Vorbis I specification

+
Xiph.Org Foundation

+
February 27, 2015
+
+

Contents

+
+ 1 Introduction and Description +
  1.1 Overview +
   1.1.1 Application +
   1.1.2 Classification +
   1.1.3 Assumptions +
   1.1.4 Codec Setup and Probability Model +
   1.1.5 Format Specification +
   1.1.6 Hardware Profile +
  1.2 Decoder Configuration +
   1.2.1 Global Config +
   1.2.2 Mode +
   1.2.3 Mapping + + + +
   1.2.4 Floor +
   1.2.5 Residue +
   1.2.6 Codebooks +
  1.3 High-level Decode Process +
   1.3.1 Decode Setup +
   1.3.2 Decode Procedure +
 2 Bitpacking Convention +
  2.1 Overview +
   2.1.1 octets, bytes and words +
   2.1.2 bit order +
   2.1.3 byte order +
   2.1.4 coding bits into byte sequences +
   2.1.5 signedness +
   2.1.6 coding example +
   2.1.7 decoding example +
   2.1.8 end-of-packet alignment +
   2.1.9 reading zero bits +
 3 Probability Model and Codebooks +
  3.1 Overview +
   3.1.1 Bitwise operation +
  3.2 Packed codebook format +
   3.2.1 codebook decode +
  3.3 Use of the codebook abstraction +
 4 Codec Setup and Packet Decode +
  4.1 Overview +
  4.2 Header decode and decode setup +
   4.2.1 Common header decode +
   4.2.2 Identification header +
   4.2.3 Comment header + + + +
   4.2.4 Setup header +
  4.3 Audio packet decode and synthesis +
   4.3.1 packet type, mode and window decode +
   4.3.2 floor curve decode +
   4.3.3 nonzero vector propagate +
   4.3.4 residue decode +
   4.3.5 inverse coupling +
   4.3.6 dot product +
   4.3.7 inverse MDCT +
   4.3.8 overlap_add +
   4.3.9 output channel order +
 5 comment field and header specification +
  5.1 Overview +
  5.2 Comment encoding +
   5.2.1 Structure +
   5.2.2 Content vector format +
   5.2.3 Encoding +
 6 Floor type 0 setup and decode +
  6.1 Overview +
  6.2 Floor 0 format +
   6.2.1 header decode +
   6.2.2 packet decode +
   6.2.3 curve computation +
 7 Floor type 1 setup and decode +
  7.1 Overview +
  7.2 Floor 1 format +
   7.2.1 model +
   7.2.2 header decode +
   7.2.3 packet decode + + + +
   7.2.4 curve computation +
 8 Residue setup and decode +
  8.1 Overview +
  8.2 Residue format +
  8.3 residue 0 +
  8.4 residue 1 +
  8.5 residue 2 +
  8.6 Residue decode +
   8.6.1 header decode +
   8.6.2 packet decode +
   8.6.3 format 0 specifics +
   8.6.4 format 1 specifics +
   8.6.5 format 2 specifics +
 9 Helper equations +
  9.1 Overview +
  9.2 Functions +
   9.2.1 ilog +
   9.2.2 float32_unpack +
   9.2.3 lookup1_values +
   9.2.4 low_neighbor +
   9.2.5 high_neighbor +
   9.2.6 render_point +
   9.2.7 render_line +
 10 Tables +
  10.1 floor1_inverse_dB_table +
 A Embedding Vorbis into an Ogg stream +
  A.1 Overview +
   A.1.1 Restrictions +
   A.1.2 MIME type + + + +
  A.2 Encapsulation +
 B Vorbis encapsulation in RTP +
+ + + +

1. Introduction and Description

+

+

1.1. Overview

+

This document provides a high level description of the Vorbis codec’s construction. A bit-by-bit +specification appears beginning in section 4, “Codec Setup and Packet Decode”. The later +sections assume a high-level understanding of the Vorbis decode process, which is provided +here. +

+

1.1.1. Application
+

Vorbis is a general purpose perceptual audio CODEC intended to allow maximum encoder +flexibility, thus allowing it to scale competitively over an exceptionally wide range of bitrates. At +the high quality/bitrate end of the scale (CD or DAT rate stereo, 16/24 bits) it is in the same +league as MPEG-2 and MPC. Similarly, the 1.0 encoder can encode high-quality CD and DAT +rate stereo at below 48kbps without resampling to a lower rate. Vorbis is also intended for lower +and higher sample rates (from 8kHz telephony to 192kHz digital masters) and a range of channel +representations (monaural, polyphonic, stereo, quadraphonic, 5.1, ambisonic, or up to 255 +discrete channels). +

+

1.1.2. Classification
+

Vorbis I is a forward-adaptive monolithic transform CODEC based on the Modified Discrete +Cosine Transform. The codec is structured to allow addition of a hybrid wavelet filterbank in +Vorbis II to offer better transient response and reproduction using a transform better suited to +localized time events. + + + +

+

1.1.3. Assumptions
+

The Vorbis CODEC design assumes a complex, psychoacoustically-aware encoder and simple, +low-complexity decoder. Vorbis decode is computationally simpler than mp3, although it does +require more working memory as Vorbis has no static probability model; the vector codebooks +used in the first stage of decoding from the bitstream are packed in their entirety into the Vorbis +bitstream headers. In packed form, these codebooks occupy only a few kilobytes; the extent to +which they are pre-decoded into a cache is the dominant factor in decoder memory +usage. +

Vorbis provides none of its own framing, synchronization or protection against errors; it +is solely a method of accepting input audio, dividing it into individual frames and +compressing these frames into raw, unformatted ’packets’. The decoder then accepts +these raw packets in sequence, decodes them, synthesizes audio frames from them, and +reassembles the frames into a facsimile of the original audio stream. Vorbis is a free-form +variable bit rate (VBR) codec and packets have no minimum size, maximum size, or +fixed/expected size. Packets are designed that they may be truncated (or padded) +and remain decodable; this is not to be considered an error condition and is used +extensively in bitrate management in peeling. Both the transport mechanism and +decoder must allow that a packet may be any size, or end before or after packet decode +expects. +

Vorbis packets are thus intended to be used with a transport mechanism that provides free-form +framing, sync, positioning and error correction in accordance with these design assumptions, such +as Ogg (for file transport) or RTP (for network multicast). For purposes of a few examples in this +document, we will assume that Vorbis is to be embedded in an Ogg stream specifically, +although this is by no means a requirement or fundamental assumption in the Vorbis +design. +

The specification for embedding Vorbis into an Ogg transport stream is in section A, +“Embedding Vorbis into an Ogg stream”. +

+

1.1.4. Codec Setup and Probability Model
+

Vorbis’ heritage is as a research CODEC and its current design reflects a desire to allow multiple +decades of continuous encoder improvement before running out of room within the codec +specification. For these reasons, configurable aspects of codec setup intentionally lean toward the +extreme of forward adaptive. + + + +

The single most controversial design decision in Vorbis (and the most unusual for a Vorbis +developer to keep in mind) is that the entire probability model of the codec, the Huffman and +VQ codebooks, is packed into the bitstream header along with extensive CODEC setup +parameters (often several hundred fields). This makes it impossible, as it would be with +MPEG audio layers, to embed a simple frame type flag in each audio packet, or begin +decode at any frame in the stream without having previously fetched the codec setup +header. +

Note: Vorbis can initiate decode at any arbitrary packet within a bitstream so long as the codec +has been initialized/setup with the setup headers. +

Thus, Vorbis headers are both required for decode to begin and relatively large as bitstream +headers go. The header size is unbounded, although for streaming a rule-of-thumb of 4kB or less +is recommended (and Xiph.Org’s Vorbis encoder follows this suggestion). +

Our own design work indicates the primary liability of the required header is in mindshare; it is +an unusual design and thus causes some amount of complaint among engineers as this runs +against current design trends (and also points out limitations in some existing software/interface +designs, such as Windows’ ACM codec framework). However, we find that it does not +fundamentally limit Vorbis’ suitable application space. +

+

1.1.5. Format Specification
+

The Vorbis format is well-defined by its decode specification; any encoder that produces packets +that are correctly decoded by the reference Vorbis decoder described below may be considered +a proper Vorbis encoder. A decoder must faithfully and completely implement the +specification defined below (except where noted) to be considered a proper Vorbis +decoder. +

+

1.1.6. Hardware Profile
+ + + +

Although Vorbis decode is computationally simple, it may still run into specific limitations of an +embedded design. For this reason, embedded designs are allowed to deviate in limited ways from +the ‘full’ decode specification yet still be certified compliant. These optional omissions are +labelled in the spec where relevant. +

+

1.2. Decoder Configuration

+

Decoder setup consists of configuration of multiple, self-contained component abstractions that +perform specific functions in the decode pipeline. Each different component instance of a specific +type is semantically interchangeable; decoder configuration consists both of internal component +configuration, as well as arrangement of specific instances into a decode pipeline. Componentry +arrangement is roughly as follows: +

+

+ +

PIC +

Figure 1: decoder pipeline configuration
+
+

+

1.2.1. Global Config
+

Global codec configuration consists of a few audio related fields (sample rate, channels), Vorbis +version (always ’0’ in Vorbis I), bitrate hints, and the lists of component instances. All other +configuration is in the context of specific components. +

+

1.2.2. Mode
+ + + +

Each Vorbis frame is coded according to a master ’mode’. A bitstream may use one or many +modes. +

The mode mechanism is used to encode a frame according to one of multiple possible +methods with the intention of choosing a method best suited to that frame. Different +modes are, e.g. how frame size is changed from frame to frame. The mode number of a +frame serves as a top level configuration switch for all other specific aspects of frame +decode. +

A ’mode’ configuration consists of a frame size setting, window type (always 0, the Vorbis +window, in Vorbis I), transform type (always type 0, the MDCT, in Vorbis I) and a mapping +number. The mapping number specifies which mapping configuration instance to use for low-level +packet decode and synthesis. +

+

1.2.3. Mapping
+

A mapping contains a channel coupling description and a list of ’submaps’ that bundle sets +of channel vectors together for grouped encoding and decoding. These submaps are +not references to external components; the submap list is internal and specific to a +mapping. +

A ’submap’ is a configuration/grouping that applies to a subset of floor and residue vectors +within a mapping. The submap functions as a last layer of indirection such that specific special +floor or residue settings can be applied not only to all the vectors in a given mode, but also +specific vectors in a specific mode. Each submap specifies the proper floor and residue +instance number to use for decoding that submap’s spectral floor and spectral residue +vectors. +

As an example: +

Assume a Vorbis stream that contains six channels in the standard 5.1 format. The sixth +channel, as is normal in 5.1, is bass only. Therefore it would be wasteful to encode a +full-spectrum version of it as with the other channels. The submapping mechanism can be used +to apply a full range floor and residue encoding to channels 0 through 4, and a bass-only +representation to the bass channel, thus saving space. In this example, channels 0-4 belong to +submap 0 (which indicates use of a full-range floor) and channel 5 belongs to submap 1, which +uses a bass-only representation. + + + +

+

1.2.4. Floor
+

Vorbis encodes a spectral ’floor’ vector for each PCM channel. This vector is a low-resolution +representation of the audio spectrum for the given channel in the current frame, generally used +akin to a whitening filter. It is named a ’floor’ because the Xiph.Org reference encoder has +historically used it as a unit-baseline for spectral resolution. +

A floor encoding may be of two types. Floor 0 uses a packed LSP representation on a dB +amplitude scale and Bark frequency scale. Floor 1 represents the curve as a piecewise linear +interpolated representation on a dB amplitude scale and linear frequency scale. The two floors +are semantically interchangeable in encoding/decoding. However, floor type 1 provides more +stable inter-frame behavior, and so is the preferred choice in all coupled-stereo and +high bitrate modes. Floor 1 is also considerably less expensive to decode than floor +0. +

Floor 0 is not to be considered deprecated, but it is of limited modern use. No known Vorbis +encoder past Xiph.Org’s own beta 4 makes use of floor 0. +

The values coded/decoded by a floor are both compactly formatted and make use of entropy +coding to save space. For this reason, a floor configuration generally refers to multiple +codebooks in the codebook component list. Entropy coding is thus provided as an +abstraction, and each floor instance may choose from any and all available codebooks when +coding/decoding. +

+

1.2.5. Residue
+

The spectral residue is the fine structure of the audio spectrum once the floor curve has been +subtracted out. In simplest terms, it is coded in the bitstream using cascaded (multi-pass) vector +quantization according to one of three specific packing/coding algorithms numbered +0 through 2. The packing algorithm details are configured by residue instance. As +with the floor components, the final VQ/entropy encoding is provided by external +codebook instances and each residue instance may choose from any and all available +codebooks. +

+ + + +

1.2.6. Codebooks
+

Codebooks are a self-contained abstraction that perform entropy decoding and, optionally, use +the entropy-decoded integer value as an offset into an index of output value vectors, returning +the indicated vector of values. +

The entropy coding in a Vorbis I codebook is provided by a standard Huffman binary tree +representation. This tree is tightly packed using one of several methods, depending on whether +codeword lengths are ordered or unordered, or the tree is sparse. +

The codebook vector index is similarly packed according to index characteristic. Most commonly, +the vector index is encoded as a single list of values of possible values that are then permuted +into a list of n-dimensional rows (lattice VQ). +

+

1.3. High-level Decode Process

+

+

1.3.1. Decode Setup
+

Before decoding can begin, a decoder must initialize using the bitstream headers matching the +stream to be decoded. Vorbis uses three header packets; all are required, in-order, by +this specification. Once set up, decode may begin at any audio packet belonging to +the Vorbis stream. In Vorbis I, all packets after the three initial headers are audio +packets. +

The header packets are, in order, the identification header, the comments header, and the setup +header. +

Identification Header +The identification header identifies the bitstream as Vorbis, Vorbis version, and the simple audio +characteristics of the stream such as sample rate and number of channels. + + + +

Comment Header +The comment header includes user text comments (“tags”) and a vendor string for the +application/library that produced the bitstream. The encoding and proper use of the comment +header is described in section 5, “comment field and header specification”. +

Setup Header +The setup header includes extensive CODEC setup information as well as the complete VQ and +Huffman codebooks needed for decode. +

+

1.3.2. Decode Procedure
+

The decoding and synthesis procedure for all audio packets is fundamentally the same. +

+ 1.
decode packet type flag +
+ 2.
decode mode number +
+ 3.
decode window shape (long windows only) +
+ 4.
decode floor +
+ 5.
decode residue into residue vectors +
+ 6.
inverse channel coupling of residue vectors +
+ 7.
generate floor curve from decoded floor data +
+ 8.
compute dot product of floor and residue, producing audio spectrum vector +
+ 9.
inverse monolithic transform of audio spectrum vector, always an MDCT in Vorbis + I + + + +
+ 10.
overlap/add left-hand output of transform with right-hand output of previous frame +
+ 11.
store right hand-data from transform of current frame for future lapping +
+ 12.
if not first frame, return results of overlap/add as audio result of current frame
+

Note that clever rearrangement of the synthesis arithmetic is possible; as an example, one can +take advantage of symmetries in the MDCT to store the right-hand transform data of a partial +MDCT for a 50% inter-frame buffer space savings, and then complete the transform later before +overlap/add with the next frame. This optimization produces entirely equivalent output and is +naturally perfectly legal. The decoder must be entirely mathematically equivalent to the +specification, it need not be a literal semantic implementation. +

Packet type decode +Vorbis I uses four packet types. The first three packet types mark each of the three Vorbis +headers described above. The fourth packet type marks an audio packet. All other packet types +are reserved; packets marked with a reserved type should be ignored. +

Following the three header packets, all packets in a Vorbis I stream are audio. The first step of +audio packet decode is to read and verify the packet type; 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. +

Mode decode +Vorbis allows an encoder to set up multiple, numbered packet ’modes’, as described earlier, all of +which may be used in a given Vorbis stream. The mode is encoded as an integer used as a direct +offset into the mode instance index. +

Window shape decode (long windows only) +Vorbis frames may be one of two PCM sample sizes specified during codec setup. In Vorbis I, +legal frame sizes are powers of two from 64 to 8192 samples. Aside from coupling, Vorbis +handles channels as independent vectors and these frame sizes are in samples per +channel. + + + +

Vorbis uses an overlapping transform, namely the MDCT, to blend one frame into the next, +avoiding most inter-frame block boundary artifacts. The MDCT output of one frame is windowed +according to MDCT requirements, overlapped 50% with the output of the previous frame and +added. The window shape assures seamless reconstruction. +

This is easy to visualize in the case of equal sized-windows: +

+

+ +

PIC +

Figure 2: overlap of two equal-sized windows
+
+

And slightly more complex in the case of overlapping unequal sized windows: +

+

+ +

PIC +

Figure 3: overlap of a long and a short window
+
+

In the unequal-sized window case, the window shape of the long window must be modified for +seamless lapping as above. It is possible to correctly infer window shape to be applied to the +current window from knowing the sizes of the current, previous and next window. It is legal for a +decoder to use this method. However, in the case of a long window (short windows require no +modification), Vorbis also codes two flag bits to specify pre- and post- window shape. Although +not strictly necessary for function, this minor redundancy allows a packet to be fully decoded to +the point of lapping entirely independently of any other packet, allowing easier abstraction of +decode layers as well as allowing a greater level of easy parallelism in encode and +decode. +

A description of valid window functions for use with an inverse MDCT can be found in [1]. +Vorbis windows all use the slope function +

+y = sin (.5 * π sin2((x + .5)∕n * π)). + + + +
+

+

floor decode +Each floor is encoded/decoded in channel order, however each floor belongs to a ’submap’ that +specifies which floor configuration to use. All floors are decoded before residue decode +begins. +

residue decode +Although the number of residue vectors equals the number of channels, channel coupling may +mean that the raw residue vectors extracted during decode do not map directly to specific +channels. When channel coupling is in use, some vectors will correspond to coupled magnitude or +angle. The coupling relationships are described in the codec setup and may differ from frame to +frame, due to different mode numbers. +

Vorbis codes residue vectors in groups by submap; the coding is done in submap order from +submap 0 through n-1. This differs from floors which are coded using a configuration provided by +submap number, but are coded individually in channel order. +

inverse channel coupling +A detailed discussion of stereo in the Vorbis codec can be found in the document +Stereo Channel Coupling in the Vorbis CODEC. Vorbis is not limited to only stereo +coupling, but the stereo document also gives a good overview of the generic coupling +mechanism. +

Vorbis coupling applies to pairs of residue vectors at a time; decoupling is done in-place a +pair at a time in the order and using the vectors specified in the current mapping +configuration. The decoupling operation is the same for all pairs, converting square polar +representation (where one vector is magnitude and the second angle) back to Cartesian +representation. +

After decoupling, in order, each pair of vectors on the coupling list, the resulting residue vectors +represent the fine spectral detail of each output channel. + + + +

generate floor curve +The decoder may choose to generate the floor curve at any appropriate time. It is reasonable to +generate the output curve when the floor data is decoded from the raw packet, or it +can be generated after inverse coupling and applied to the spectral residue directly, +combining generation and the dot product into one step and eliminating some working +space. +

Both floor 0 and floor 1 generate a linear-range, linear-domain output vector to be multiplied +(dot product) by the linear-range, linear-domain spectral residue. +

compute floor/residue dot product +This step is straightforward; for each output channel, the decoder multiplies the floor curve and +residue vectors element by element, producing the finished audio spectrum of each +channel. +

One point is worth mentioning about this dot product; a common mistake in a fixed point +implementation might be to assume that a 32 bit fixed-point representation for floor and +residue and direct multiplication of the vectors is sufficient for acceptable spectral depth +in all cases because it happens to mostly work with the current Xiph.Org reference +encoder. +

However, floor vector values can span ~140dB (~24 bits unsigned), and the audio spectrum +vector should represent a minimum of 120dB (~21 bits with sign), even when output is to a 16 +bit PCM device. For the residue vector to represent full scale if the floor is nailed +to -140dB, it must be able to span 0 to +140dB. For the residue vector to reach +full scale if the floor is nailed at 0dB, it must be able to represent -140dB to +0dB. +Thus, in order to handle full range dynamics, a residue vector may span -140dB to ++140dB entirely within spec. A 280dB range is approximately 48 bits with sign; thus the +residue vector must be able to represent a 48 bit range and the dot product must +be able to handle an effective 48 bit times 24 bit multiplication. This range may be +achieved using large (64 bit or larger) integers, or implementing a movable binary point +representation. +

inverse monolithic transform (MDCT) +The audio spectrum is converted back into time domain PCM audio via an inverse Modified +Discrete Cosine Transform (MDCT). A detailed description of the MDCT is available in +[1]. +

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. +

overlap/add data +Windowed MDCT output is overlapped and added with the right hand data of the previous +window such that the 3/4 point of the previous window is aligned with the 1/4 point of the +current window (as illustrated in the window overlap diagram). At this point, the audio data +between the center of the previous frame and the center of the current frame is now finished and +ready to be returned. +

cache right hand data +The decoder must cache the right hand portion of the current frame to be lapped with the left +hand portion of the next frame. +

return finished audio data +The overlapped portion produced from overlapping the previous and current frame data +is finished data to be returned by the decoder. This data spans from the center of +the previous window to the center of the current window. In the case of same-sized +windows, the amount of data to return is one-half block consisting of and only of the +overlapped portions. When overlapping a short and long window, much of the returned +range is not actually overlap. This does not damage transform orthogonality. Pay +attention however to returning the correct data range; the amount of data to be returned +is: +

+

1  window_blocksize(previous_window)/4+window_blocksize(current_window)/4
+

from the center of the previous window to the center of the current window. +

Data is not returned from the first frame; it must be used to ’prime’ the decode engine. The +encoder accounts for this priming when calculating PCM offsets; after the first frame, the proper +PCM output offset is ’0’ (as no data has been returned yet). + + + + + + +

2. Bitpacking Convention

+

+

2.1. Overview

+

The Vorbis codec uses relatively unstructured raw packets containing arbitrary-width binary +integer fields. Logically, these packets are a bitstream in which bits are coded one-by-one by the +encoder and then read one-by-one in the same monotonically increasing order by the decoder. +Most current binary storage arrangements group bits into a native word size of eight bits +(octets), sixteen bits, thirty-two bits or, less commonly other fixed word sizes. The Vorbis +bitpacking convention specifies the correct mapping of the logical packet bitstream into an actual +representation in fixed-width words. +

+

2.1.1. octets, bytes and words
+

In most contemporary architectures, a ’byte’ is synonymous with an ’octet’, that is, eight bits. +This has not always been the case; seven, ten, eleven and sixteen bit ’bytes’ have been used. +For purposes of the bitpacking convention, a byte implies the native, smallest integer +storage representation offered by a platform. On modern platforms, this is generally +assumed to be eight bits (not necessarily because of the processor but because of the +filesystem/memory architecture. Modern filesystems invariably offer bytes as the fundamental +atom of storage). A ’word’ is an integer size that is a grouped multiple of this smallest +size. +

The most ubiquitous architectures today consider a ’byte’ to be an octet (eight bits) and a word +to be a group of two, four or eight bytes (16, 32 or 64 bits). Note however that the Vorbis +bitpacking convention is still well defined for any native byte size; Vorbis uses the native +bit-width of a given storage system. This document assumes that a byte is one octet for purposes +of example. +

+ + + +

2.1.2. bit order
+

A byte has a well-defined ’least significant’ bit (LSb), which is the only bit set when the byte is +storing the two’s complement integer value +1. A byte’s ’most significant’ bit (MSb) is at the +opposite end of the byte. Bits in a byte are numbered from zero at the LSb to n (n = 7 in an +octet) for the MSb. +

+

2.1.3. byte order
+

Words are native groupings of multiple bytes. Several byte orderings are possible in a word; the +common ones are 3-2-1-0 (’big endian’ or ’most significant byte first’ in which the +highest-valued byte comes first), 0-1-2-3 (’little endian’ or ’least significant byte first’ in +which the lowest value byte comes first) and less commonly 3-1-2-0 and 0-2-1-3 (’mixed +endian’). +

The Vorbis bitpacking convention specifies storage and bitstream manipulation at the byte, not +word, level, thus host word ordering is of a concern only during optimization when writing high +performance code that operates on a word of storage at a time rather than by byte. +Logically, bytes are always coded and decoded in order from byte zero through byte +n. +

+

2.1.4. coding bits into byte sequences
+

The Vorbis codec has need to code arbitrary bit-width integers, from zero to 32 bits +wide, into packets. These integer fields are not aligned to the boundaries of the byte +representation; the next field is written at the bit position at which the previous field +ends. +

The encoder logically packs integers by writing the LSb of a binary integer to the logical +bitstream first, followed by next least significant bit, etc, until the requested number of bits +have been coded. When packing the bits into bytes, the encoder begins by placing +the LSb of the integer to be written into the least significant unused bit position of +the destination byte, followed by the next-least significant bit of the source integer +and so on up to the requested number of bits. When all bits of the destination byte +have been filled, encoding continues by zeroing all bits of the next byte and writing +the next bit into the bit position 0 of that byte. Decoding follows the same process + + + +as encoding, but by reading bits from the byte stream and reassembling them into +integers. +

+

2.1.5. signedness
+

The signedness of a specific number resulting from decode is to be interpreted by the decoder +given decode context. That is, the three bit binary pattern ’b111’ can be taken to represent +either ’seven’ as an unsigned integer, or ’-1’ as a signed, two’s complement integer. The +encoder and decoder are responsible for knowing if fields are to be treated as signed or +unsigned. +

+

2.1.6. coding example
+

Code the 4 bit integer value ’12’ [b1100] into an empty bytestream. Bytestream result: +

+

1                |
2                V
3  
4          7 6 5 4 3 2 1 0
5  byte 0 [0 0 0 0 1 1 0 0]  <-
6  byte 1 [               ] +
7  byte 2 [               ]
8  byte 3 [               ]
9               ...
10  byte n [               ]  bytestream length == 1 byte
11  
+

Continue by coding the 3 bit integer value ’-1’ [b111]: +

+

1          |
2          V
3  
4          7 6 5 4 3 2 1 0
5  byte 0 [0 1 1 1 1 1 0 0]  <-
6  byte 1 [               ] +
7  byte 2 [               ]
8  byte 3 [               ]
9               ...
10  byte n [               ]  bytestream length == 1 byte
+

Continue by coding the 7 bit integer value ’17’ [b0010001]: +

+

1            |
2            V
3  
4          7 6 5 4 3 2 1 0
5  byte 0 [1 1 1 1 1 1 0 0]
6  byte 1 [0 0 0 0 1 0 0 0]  <-
7  byte 2 [               ] +
8  byte 3 [               ]
9               ...
10  byte n [               ]  bytestream length == 2 bytes
11                            bit cursor == 6
+

Continue by coding the 13 bit integer value ’6969’ [b110 11001110 01]: +

+

1                  |
2                  V
3  
4          7 6 5 4 3 2 1 0
5  byte 0 [1 1 1 1 1 1 0 0]
6  byte 1 [0 1 0 0 1 0 0 0] +
7  byte 2 [1 1 0 0 1 1 1 0]
8  byte 3 [0 0 0 0 0 1 1 0]  <-
9               ...
10  byte n [               ]  bytestream length == 4 bytes
11  
+ + + +

+

2.1.7. decoding example
+

Reading from the beginning of the bytestream encoded in the above example: +

+

1                        |
2                        V
3  
4          7 6 5 4 3 2 1 0
5  byte 0 [1 1 1 1 1 1 0 0]  <- +
6  byte 1 [0 1 0 0 1 0 0 0]
7  byte 2 [1 1 0 0 1 1 1 0]
8  byte 3 [0 0 0 0 0 1 1 0]  bytestream length == 4 bytes
9  
+

We read two, two-bit integer fields, resulting in the returned numbers ’b00’ and ’b11’. Two things +are worth noting here: +

    +
  • Although these four bits were originally written as a single four-bit integer, reading + some other combination of bit-widths from the bitstream is well defined. There are + no artificial alignment boundaries maintained in the bitstream. +
    • +
  • The second value is the two-bit-wide integer ’b11’. This value may be interpreted + either as the unsigned value ’3’, or the signed value ’-1’. Signedness is dependent on + decode context.
+

+

2.1.8. end-of-packet alignment
+

The typical use of bitpacking is to produce many independent byte-aligned packets which are +embedded into a larger byte-aligned container structure, such as an Ogg transport bitstream. +Externally, each bytestream (encoded bitstream) must begin and end on a byte boundary. Often, +the encoded bitstream is not an integer number of bytes, and so there is unused (uncoded) space +in the last byte of a packet. +

Unused space in the last byte of a bytestream is always zeroed during the coding process. Thus, +should this unused space be read, it will return binary zeroes. +

Attempting to read past the end of an encoded packet results in an ’end-of-packet’ condition. +End-of-packet is not to be considered an error; it is merely a state indicating that there is +insufficient remaining data to fulfill the desired read size. Vorbis uses truncated packets as a + + + +normal mode of operation, and as such, decoders must handle reading past the end of a packet as +a typical mode of operation. Any further read operations after an ’end-of-packet’ condition shall +also return ’end-of-packet’. +

+

2.1.9. reading zero bits
+

Reading a zero-bit-wide integer returns the value ’0’ and does not increment the stream cursor. +Reading to the end of the packet (but not past, such that an ’end-of-packet’ condition has not +triggered) and then reading a zero bit integer shall succeed, returning 0, and not trigger an +end-of-packet condition. Reading a zero-bit-wide integer after a previous read sets ’end-of-packet’ +shall also fail with ’end-of-packet’. + + + + + + +

3. Probability Model and Codebooks

+

+

3.1. Overview

+

Unlike practically every other mainstream audio codec, Vorbis has no statically configured +probability model, instead packing all entropy decoding configuration, VQ and Huffman, into the +bitstream itself in the third header, the codec setup header. This packed configuration consists of +multiple ’codebooks’, each containing a specific Huffman-equivalent representation for decoding +compressed codewords as well as an optional lookup table of output vector values to which a +decoded Huffman value is applied as an offset, generating the final decoded output corresponding +to a given compressed codeword. +

+

3.1.1. Bitwise operation
+

The codebook mechanism is built on top of the vorbis bitpacker. Both the codebooks themselves +and the codewords they decode are unrolled from a packet as a series of arbitrary-width values +read from the stream according to section 2, “Bitpacking Convention”. +

+

3.2. Packed codebook format

+

For purposes of the examples below, we assume that the storage system’s native byte width is +eight bits. This is not universally true; see section 2, “Bitpacking Convention” for discussion +relating to non-eight-bit bytes. + + + +

+

3.2.1. codebook decode
+

A codebook begins with a 24 bit sync pattern, 0x564342: +

+

1  byte 0: [ 0 1 0 0 0 0 1 0 ] (0x42)
2  byte 1: [ 0 1 0 0 0 0 1 1 ] (0x43)
3  byte 2: [ 0 1 0 1 0 1 1 0 ] (0x56)
+

16 bit [codebook_dimensions] and 24 bit [codebook_entries] fields: +

+

1  
2  byte 3: [ X X X X X X X X ]
3  byte 4: [ X X X X X X X X ] [codebook_dimensions] (16 bit unsigned)
4   +
5  byte 5: [ X X X X X X X X ]
6  byte 6: [ X X X X X X X X ]
7  byte 7: [ X X X X X X X X ] [codebook_entries] (24 bit unsigned)
8  
+

Next is the [ordered] bit flag: +

+

1  
2  byte 8: [               X ] [ordered] (1 bit)
3  
+

Each entry, numbering a total of [codebook_entries], is assigned a codeword length. +We now read the list of codeword lengths and store these lengths in the array +[codebook_codeword_lengths]. Decode of lengths is according to whether the [ordered] flag +is set or unset. +

    +
  • If the [ordered] flag is unset, the codeword list is not length ordered and the decoder + needs to read each codeword length one-by-one. +

    The decoder first reads one additional bit flag, the [sparse] flag. This flag determines + whether or not the codebook contains unused entries that are not to be included in + the codeword decode tree: +

    +

    1  byte 8: [             X 1 ] [sparse] flag (1 bit)
    +

    The decoder now performs for each of the [codebook_entries] codebook entries: +

    +

    1  
    2    1) if([sparse] is set) {
    3  
    4           2) [flag] = read one bit;
    5           3) if([flag] is set) {
    6   +
    7                4) [length] = read a five bit unsigned integer;
    8                5) codeword length for this entry is [length]+1;
    9   +
    10              } else {
    11  
    12                6) this entry is unused.  mark it as such.
    13  
    14              }
    15  
    16       } else the sparse flag is not set { +
    17  
    18          7) [length] = read a five bit unsigned integer;
    19          8) the codeword length for this entry is [length]+1;
    20  
    21       }
    22  
    + + + +
    • +
  • If the [ordered] flag is set, the codeword list for this codebook is encoded in + ascending length order. Rather than reading a length for every codeword, the + encoder reads the number of codewords per length. That is, beginning at entry + zero: +

    +

    1    1) [current_entry] = 0;
    2    2) [current_length] = read a five bit unsigned integer and add 1; +
    3    3) [number] = read ilog([codebook_entries] - [current_entry]) bits as an unsigned integer +
    4    4) set the entries [current_entry] through [current_entry]+[number]-1, inclusive, +
    5      of the [codebook_codeword_lengths] array to [current_length] +
    6    5) set [current_entry] to [number] + [current_entry]
    7    6) increment [current_length] by 1 +
    8    7) if [current_entry] is greater than [codebook_entries] ERROR CONDITION;
    9      the decoder will not be able to read this stream. +
    10    8) if [current_entry] is less than [codebook_entries], repeat process starting at 3)
    11    9) done.
    +
+

After all codeword lengths have been decoded, the decoder reads the vector lookup table. Vorbis +I supports three lookup types: +

+ 1.
No lookup +
+ 2.
Implicitly populated value mapping (lattice VQ) +
+ 3.
Explicitly populated value mapping (tessellated or ’foam’ VQ)
+

The lookup table type is read as a four bit unsigned integer: +

1    1) [codebook_lookup_type] = read four bits as an unsigned integer
+

Codebook decode precedes according to [codebook_lookup_type]: +

    +
  • Lookup type zero indicates no lookup to be read. Proceed past lookup decode. +
    • +
  • Lookup types one and two are similar, differing only in the number of lookup values to + be read. Lookup type one reads a list of values that are permuted in a set pattern to + build a list of vectors, each vector of order [codebook_dimensions] scalars. Lookup + type two builds the same vector list, but reads each scalar for each vector explicitly, + rather than building vectors from a smaller list of possible scalar values. Lookup + decode proceeds as follows: +

    +

    1    1) [codebook_minimum_value] = float32_unpack( read 32 bits as an unsigned integer) +
    2    2) [codebook_delta_value] = float32_unpack( read 32 bits as an unsigned integer) +
    3    3) [codebook_value_bits] = read 4 bits as an unsigned integer and add 1
    4    4) [codebook_sequence_p] = read 1 bit as a boolean flag
    5   + + + +
    6    if ( [codebook_lookup_type] is 1 ) {
    7  
    8       5) [codebook_lookup_values] = lookup1_values([codebook_entries], [codebook_dimensions] ) +
    9  
    10    } else {
    11  
    12       6) [codebook_lookup_values] = [codebook_entries] * [codebook_dimensions]
    13  
    14    }
    15   +
    16    7) read a total of [codebook_lookup_values] unsigned integers of [codebook_value_bits] each; +
    17       store these in order in the array [codebook_multiplicands]
    +
    • +
  • A [codebook_lookup_type] of greater than two is reserved and indicates a stream that is + not decodable by the specification in this document. +
+

An ’end of packet’ during any read operation in the above steps is considered an error condition +rendering the stream undecodable. +

Huffman decision tree representation +The [codebook_codeword_lengths] array and [codebook_entries] value uniquely define the +Huffman decision tree used for entropy decoding. +

Briefly, each used codebook entry (recall that length-unordered codebooks support unused +codeword entries) is assigned, in order, the lowest valued unused binary Huffman codeword +possible. Assume the following codeword length list: +

+

1  entry 0: length 2
2  entry 1: length 4
3  entry 2: length 4
4  entry 3: length 4
5  entry 4: length 4
6  entry 5: length 2 +
7  entry 6: length 3
8  entry 7: length 3
+

Assigning codewords in order (lowest possible value of the appropriate length to highest) results +in the following codeword list: +

+

1  entry 0: length 2 codeword 00
2  entry 1: length 4 codeword 0100
3  entry 2: length 4 codeword 0101
4  entry 3: length 4 codeword 0110 +
5  entry 4: length 4 codeword 0111
6  entry 5: length 2 codeword 10
7  entry 6: length 3 codeword 110
8  entry 7: length 3 codeword 111
+

Note: Unlike most binary numerical values in this document, we intend the above codewords to +be read and used bit by bit from left to right, thus the codeword ’001’ is the bit string ’zero, zero, +one’. When determining ’lowest possible value’ in the assignment definition above, the leftmost +bit is the MSb. +

It is clear that the codeword length list represents a Huffman decision tree with the entry +numbers equivalent to the leaves numbered left-to-right: + + + +

+

+ +

PIC +

Figure 4: huffman tree illustration
+
+

As we assign codewords in order, we see that each choice constructs a new leaf in the leftmost +possible position. +

Note that it’s possible to underspecify or overspecify a Huffman tree via the length list. +In the above example, if codeword seven were eliminated, it’s clear that the tree is +unfinished: +

+

+ +

PIC +

Figure 5: underspecified huffman tree illustration
+
+

Similarly, in the original codebook, it’s clear that the tree is fully populated and a ninth +codeword is impossible. Both underspecified and overspecified trees are an error condition +rendering the stream undecodable. +

Codebook entries marked ’unused’ are simply skipped in the assigning process. They have no +codeword and do not appear in the decision tree, thus it’s impossible for any bit pattern read +from the stream to decode to that entry number. +

Errata 20150226: Single entry codebooks +A ’single-entry codebook’ is a codebook with one active codeword entry. A single-entry codebook +may be either a fully populated codebook with only one declared entry, or a sparse codebook +with only one entry marked used. The Vorbis I spec provides no means to specify a codeword +length of zero, and as a result, a single-entry codebook is inherently malformed because it is +underpopulated. The original specification did not address directly the matter of single-entry +codebooks; they were implicitly illegal as it was not possible to write such a codebook with a +valid tree structure. + + + +

In r14811 of the libvorbis reference implementation, Xiph added an additional check to the +codebook implementation to reject underpopulated Huffman trees. This change led to the +discovery of single-entry books used ’in the wild’ when the new, stricter checks rejected a number +of apparently working streams. +

In order to minimize breakage of deployed (if technically erroneous) streams, r16073 of the +reference implementation explicitly special-cased single-entry codebooks to tolerate the +single-entry case. Commit r16073 also added the following to the specification: +

“Take special care that a codebook with a single used entry is handled properly; it consists of a +single codework of zero bits and reading a value out of such a codebook always returns the single +used value and sinks zero bits. ” +

The intent was to clarify the spec and codify current practice. However, this addition is +erroneously at odds with the intent of preserving usability of existing streams using single-entry +codebooks, disagrees with the code changes that reinstated decoding, and does not address how +single-entry codebooks should be encoded. +

As such, the above addition made in r16037 is struck from the specification and replaced by the +following: +

+

+

It is possible to declare a Vorbis codebook containing a single codework + entry. A single-entry codebook may be either a fully populated codebook with + [codebook_entries] set to 1, or a sparse codebook marking only one entry + used. Note that it is not possible to also encode a [codeword_length] of zero + for the single used codeword, as the unsigned value written to the stream + is [codeword_length]-1. Instead, encoder implementations should indicate a + [codeword_length] of 1 and ’write’ the codeword to a stream during audio + encoding by writing a single zero bit. +

Decoder implementations shall reject a codebook if it contains only one used + entry and the encoded [codeword_length] of that entry is not 1. ’Reading’ a + value from single-entry codebook always returns the single used codeword value + and sinks one bit. Decoders should tolerate that the bit read from the stream + be ’1’ instead of ’0’; both values shall return the single used codeword.

+

VQ lookup table vector representation +Unpacking the VQ lookup table vectors relies on the following values: + + + +

1  the [codebook\_multiplicands] array
2  [codebook\_minimum\_value]
3  [codebook\_delta\_value]
4  [codebook\_sequence\_p] +
5  [codebook\_lookup\_type]
6  [codebook\_entries]
7  [codebook\_dimensions]
8  [codebook\_lookup\_values]
+

Decoding (unpacking) a specific vector in the vector lookup table proceeds according to +[codebook_lookup_type]. The unpacked vector values are what a codebook would return +during audio packet decode in a VQ context. +

Vector value decode: Lookup type 1 +Lookup type one specifies a lattice VQ lookup table built algorithmically from a list of +scalar values. Calculate (unpack) the final values of a codebook entry vector from +the entries in [codebook_multiplicands] as follows ([value_vector] is the output +vector representing the vector of values for entry number [lookup_offset] in this +codebook): +

+

1    1) [last] = 0;
2    2) [index_divisor] = 1;
3    3) iterate [i] over the range 0 ... [codebook_dimensions]-1 (once for each scalar value in the value vector) { +
4  
5         4) [multiplicand_offset] = ( [lookup_offset] divided by [index_divisor] using integer +
6            division ) integer modulo [codebook_lookup_values]
7  
8         5) vector [value_vector] element [i] = +
9              ( [codebook_multiplicands] array element number [multiplicand_offset] ) * +
10              [codebook_delta_value] + [codebook_minimum_value] + [last];
11   +
12         6) if ( [codebook_sequence_p] is set ) then set [last] = vector [value_vector] element [i]
13   +
14         7) [index_divisor] = [index_divisor] * [codebook_lookup_values]
15  
16       }
17  
18    8) vector calculation completed.
+

Vector value decode: Lookup type 2 +Lookup type two specifies a VQ lookup table in which each scalar in each vector is explicitly set +by the [codebook_multiplicands] array in a one-to-one mapping. Calculate [unpack] the final +values of a codebook entry vector from the entries in [codebook_multiplicands] as follows +([value_vector] is the output vector representing the vector of values for entry number +[lookup_offset] in this codebook): +

+

1    1) [last] = 0;
2    2) [multiplicand_offset] = [lookup_offset] * [codebook_dimensions] +
3    3) iterate [i] over the range 0 ... [codebook_dimensions]-1 (once for each scalar value in the value vector) {
4   +
5         4) vector [value_vector] element [i] =
6              ( [codebook_multiplicands] array element number [multiplicand_offset] ) * +
7              [codebook_delta_value] + [codebook_minimum_value] + [last];
8   +
9         5) if ( [codebook_sequence_p] is set ) then set [last] = vector [value_vector] element [i]
10   +
11         6) increment [multiplicand_offset]
12  
13       }
14  
15    7) vector calculation completed.
+ + + +

+

3.3. Use of the codebook abstraction

+

The decoder uses the codebook abstraction much as it does the bit-unpacking convention; a +specific codebook reads a codeword from the bitstream, decoding it into an entry number, and +then returns that entry number to the decoder (when used in a scalar entropy coding context), or +uses that entry number as an offset into the VQ lookup table, returning a vector of values (when +used in a context desiring a VQ value). Scalar or VQ context is always explicit; any +call to the codebook mechanism requests either a scalar entry number or a lookup +vector. +

Note that VQ lookup type zero indicates that there is no lookup table; requesting +decode using a codebook of lookup type 0 in any context expecting a vector return +value (even in a case where a vector of dimension one) is forbidden. If decoder setup +or decode requests such an action, that is an error condition rendering the packet +undecodable. +

Using a codebook to read from the packet bitstream consists first of reading and decoding the +next codeword in the bitstream. The decoder reads bits until the accumulated bits match a +codeword in the codebook. This process can be though of as logically walking the +Huffman decode tree by reading one bit at a time from the bitstream, and using the +bit as a decision boolean to take the 0 branch (left in the above examples) or the 1 +branch (right in the above examples). Walking the tree finishes when the decode process +hits a leaf in the decision tree; the result is the entry number corresponding to that +leaf. Reading past the end of a packet propagates the ’end-of-stream’ condition to the +decoder. +

When used in a scalar context, the resulting codeword entry is the desired return +value. +

When used in a VQ context, the codeword entry number is used as an offset into the VQ lookup +table. The value returned to the decoder is the vector of scalars corresponding to this +offset. + + + + + + +

4. Codec Setup and Packet Decode

+

+

4.1. Overview

+

This document serves as the top-level reference document for the bit-by-bit decode specification +of Vorbis I. This document assumes a high-level understanding of the Vorbis decode +process, which is provided in section 1, “Introduction and Description”. section 2, +“Bitpacking Convention” covers reading and writing bit fields from and to bitstream +packets. +

+

4.2. Header decode and decode setup

+

A Vorbis bitstream begins with three header packets. The header packets are, in order, the +identification header, the comments header, and the setup header. All are required for decode +compliance. An end-of-packet condition during decoding the first or third header packet renders +the stream undecodable. End-of-packet decoding the comment header is a non-fatal error +condition. +

+

4.2.1. Common header decode
+

Each header packet begins with the same header fields. +

+

1    1) [packet_type] : 8 bit value
2    2) 0x76, 0x6f, 0x72, 0x62, 0x69, 0x73: the characters ’v’,’o’,’r’,’b’,’i’,’s’ as six octets
+

Decode continues according to packet type; the identification header is type 1, the comment +header type 3 and the setup header type 5 (these types are all odd as a packet with a leading +single bit of ’0’ is an audio packet). The packets must occur in the order of identification, + + + +comment, setup. +

+

4.2.2. Identification header
+

The identification header is a short header of only a few fields used to declare the stream +definitively as Vorbis, and provide a few externally relevant pieces of information about the audio +stream. The identification header is coded as follows: +

+

1   1) [vorbis_version] = read 32 bits as unsigned integer
2   2) [audio_channels] = read 8 bit integer as unsigned +
3   3) [audio_sample_rate] = read 32 bits as unsigned integer
4   4) [bitrate_maximum] = read 32 bits as signed integer +
5   5) [bitrate_nominal] = read 32 bits as signed integer
6   6) [bitrate_minimum] = read 32 bits as signed integer +
7   7) [blocksize_0] = 2 exponent (read 4 bits as unsigned integer)
8   8) [blocksize_1] = 2 exponent (read 4 bits as unsigned integer) +
9   9) [framing_flag] = read one bit
+

[vorbis_version] is to read ’0’ in order to be compatible with this document. Both +[audio_channels] and [audio_sample_rate] must read greater than zero. Allowed final +blocksize values are 64, 128, 256, 512, 1024, 2048, 4096 and 8192 in Vorbis I. [blocksize_0] +must be less than or equal to [blocksize_1]. The framing bit must be nonzero. Failure to meet +any of these conditions renders a stream undecodable. +

The bitrate fields above are used only as hints. The nominal bitrate field especially may be +considerably off in purely VBR streams. The fields are meaningful only when greater than +zero. +

    +
  • All three fields set to the same value implies a fixed rate, or tightly bounded, nearly + fixed-rate bitstream +
    • +
  • Only nominal set implies a VBR or ABR stream that averages the nominal bitrate +
    • +
  • Maximum and or minimum set implies a VBR bitstream that obeys the bitrate limits +
    • +
  • None set indicates the encoder does not care to speculate.
+ + + +

+

4.2.3. Comment header
+

Comment header decode and data specification is covered in section 5, “comment field and +header specification”. +

+

4.2.4. Setup header
+

Vorbis codec setup is configurable to an extreme degree: +

+

+ +

PIC +

Figure 6: decoder pipeline configuration
+
+

The setup header contains the bulk of the codec setup information needed for decode. The setup +header contains, in order, the lists of codebook configurations, time-domain transform +configurations (placeholders in Vorbis I), floor configurations, residue configurations, channel +mapping configurations and mode configurations. It finishes with a framing bit of ’1’. Header +decode proceeds in the following order: +

Codebooks +

+ 1.
[vorbis_codebook_count] = read eight bits as unsigned integer and add one +
+ 2.
Decode [vorbis_codebook_count] codebooks in order as defined in section 3, + “Probability Model and Codebooks”. Save each configuration, in order, in an array + of codebook configurations [vorbis_codebook_configurations].
+ + + +

Time domain transforms +These hooks are placeholders in Vorbis I. Nevertheless, the configuration placeholder values must +be read to maintain bitstream sync. +

+

+ 1.
[vorbis_time_count] = read 6 bits as unsigned integer and add one +
+ 2.
read [vorbis_time_count] 16 bit values; each value should be zero. If any value is + nonzero, this is an error condition and the stream is undecodable.
+

Floors +Vorbis uses two floor types; header decode is handed to the decode abstraction of the appropriate +type. +

+

+ 1.
[vorbis_floor_count] = read 6 bits as unsigned integer and add one +
+ 2.
For each [i] of [vorbis_floor_count] floor numbers: +
+ a)
read the floor type: vector [vorbis_floor_types] element [i] = read 16 bits + as unsigned integer +
+ b)
If the floor type is zero, decode the floor configuration as defined in section 6, + “Floor type 0 setup and decode”; save this configuration in slot [i] of the floor + configuration array [vorbis_floor_configurations]. +
+ c)
If the floor type is one, decode the floor configuration as defined in section 7, + “Floor type 1 setup and decode”; save this configuration in slot [i] of the floor + configuration array [vorbis_floor_configurations]. +
+ d)
If the the floor type is greater than one, this stream is undecodable; ERROR + CONDITION
+ + + +
+

Residues +Vorbis uses three residue types; header decode of each type is identical. +

+

+ 1.
[vorbis_residue_count] = read 6 bits as unsigned integer and add one +
+ 2.
For each of [vorbis_residue_count] residue numbers: +
+ a)
read the residue type; vector [vorbis_residue_types] element [i] = read 16 + bits as unsigned integer +
+ b)
If the residue type is zero, one or two, decode the residue configuration as defined + in section 8, “Residue setup and decode”; save this configuration in slot [i] of + the residue configuration array [vorbis_residue_configurations]. +
+ c)
If the the residue type is greater than two, this stream is undecodable; ERROR + CONDITION
+
+

Mappings +Mappings are used to set up specific pipelines for encoding multichannel audio with varying +channel mapping applications. Vorbis I uses a single mapping type (0), with implicit PCM +channel mappings. +

+

+ 1.
[vorbis_mapping_count] = read 6 bits as unsigned integer and add one +
+ 2.
For each [i] of [vorbis_mapping_count] mapping numbers: + + + +
+ a)
read the mapping type: 16 bits as unsigned integer. There’s no reason to save + the mapping type in Vorbis I. +
+ b)
If the mapping type is nonzero, the stream is undecodable +
+ c)
If the mapping type is zero: +
+ i.
read 1 bit as a boolean flag +
+ A.
if set, [vorbis_mapping_submaps] = read 4 bits as unsigned integer + and add one +
+ B.
if unset, [vorbis_mapping_submaps] = 1
+
+ ii.
read 1 bit as a boolean flag +
+ A.
if set, square polar channel mapping is in use: +
    +
  • [vorbis_mapping_coupling_steps] = read 8 bits as unsigned + integer and add one +
    • +
  • for [j] each of [vorbis_mapping_coupling_steps] steps: +
      +
    • vector [vorbis_mapping_magnitude] element [j]= read + ilog([audio_channels] - 1) bits as unsigned integer +
      • +
    • vector [vorbis_mapping_angle] element [j]= read + ilog([audio_channels] - 1) bits as unsigned integer +
      • +
    • the numbers read in the above two steps are channel numbers + representing the channel to treat as magnitude and the channel + to treat as angle, respectively. If for any coupling step the + angle channel number equals the magnitude channel number, the + magnitude channel number is greater than [audio_channels]-1, or + the angle channel is greater than [audio_channels]-1, the stream + is undecodable.
    + + + +
+
+ B.
if unset, [vorbis_mapping_coupling_steps] = 0
+
+ iii.
read 2 bits (reserved field); if the value is nonzero, the stream is undecodable +
+ iv.
if [vorbis_mapping_submaps] is greater than one, we read channel multiplex + settings. For each [j] of [audio_channels] channels: +
+ A.
vector [vorbis_mapping_mux] element [j] = read 4 bits as unsigned + integer +
+ B.
if the value is greater than the highest numbered submap + ([vorbis_mapping_submaps] - 1), this in an error condition rendering + the stream undecodable
+
+ v.
for each submap [j] of [vorbis_mapping_submaps] submaps, read the floor and + residue numbers for use in decoding that submap: +
+ A.
read and discard 8 bits (the unused time configuration placeholder) +
+ B.
read 8 bits as unsigned integer for the floor number; save in vector + [vorbis_mapping_submap_floor] element [j] +
+ C.
verify the floor number is not greater than the highest number floor + configured for the bitstream. If it is, the bitstream is undecodable +
+ D.
read 8 bits as unsigned integer for the residue number; save in vector + [vorbis_mapping_submap_residue] element [j] +
+ E.
verify the residue number is not greater than the highest number residue + configured for the bitstream. If it is, the bitstream is undecodable
+
+ vi.
save this mapping configuration in slot [i] of the mapping configuration array + [vorbis_mapping_configurations].
+
+ + + +
+

Modes +

+ 1.
[vorbis_mode_count] = read 6 bits as unsigned integer and add one +
+ 2.
For each of [vorbis_mode_count] mode numbers: +
+ a)
[vorbis_mode_blockflag] = read 1 bit +
+ b)
[vorbis_mode_windowtype] = read 16 bits as unsigned integer +
+ c)
[vorbis_mode_transformtype] = read 16 bits as unsigned integer +
+ d)
[vorbis_mode_mapping] = read 8 bits as unsigned integer +
+ e)
verify ranges; zero is the only legal value in + Vorbis I for [vorbis_mode_windowtype] and [vorbis_mode_transformtype]. + [vorbis_mode_mapping] must not be greater than the highest number mapping + in use. Any illegal values render the stream undecodable. +
+ f)
save this mode configuration in slot [i] of the mode configuration array + [vorbis_mode_configurations].
+
+ 3.
read 1 bit as a framing flag. If unset, a framing error occurred and the stream is not + decodable.
+

After reading mode descriptions, setup header decode is complete. +

+

4.3. Audio packet decode and synthesis

+ + + +

Following the three header packets, all packets in a Vorbis I stream are audio. The first step of +audio packet decode is to read and verify the packet type. 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. +

+

4.3.1. packet type, mode and window decode
+

+

+ 1.
read 1 bit [packet_type]; check that packet type is 0 (audio) +
+ 2.
read ilog([vorbis_mode_count]-1) bits [mode_number] +
+ 3.
decode blocksize [n] is equal to [blocksize_0] if [vorbis_mode_blockflag] is 0, + else [n] is equal to [blocksize_1]. +
+ 4.
perform window selection and setup; this window is used later by the inverse + MDCT: +
+ a)
if this is a long window (the [vorbis_mode_blockflag] flag of this mode is + set): +
+ i.
read 1 bit for [previous_window_flag] +
+ ii.
read 1 bit for [next_window_flag] +
+ iii.
if [previous_window_flag] is not set, the left half of the window will + be a hybrid window for lapping with a short block. See paragraph 1.3.2, + “Window shape decode (long windows only)” for an illustration of + overlapping dissimilar windows. Else, the left half window will have normal + long shape. +
+ iv.
if [next_window_flag] is not set, the right half of the window will be + a hybrid window for lapping with a short block. See paragraph 1.3.2, + + + + “Window shape decode (long windows only)” for an illustration of + overlapping dissimilar windows. Else, the left right window will have normal + long shape.
+
+ b)
if this is a short window, the window is always the same short-window + shape.
+
+

Vorbis windows all use the slope function y = sin(π +2 * sin 2((x + 0.5)∕n * π)), where n is window +size and x ranges 0…n- 1, but dissimilar lapping requirements can affect overall shape. Window +generation proceeds as follows: +

+

+ 1.
[window_center] = [n] / 2 +
+ 2.
if ([vorbis_mode_blockflag] is set and [previous_window_flag] is not set) + then +
+ a)
[left_window_start] = [n]/4 - [blocksize_0]/4 +
+ b)
[left_window_end] = [n]/4 + [blocksize_0]/4 +
+ c)
[left_n] = [blocksize_0]/2
+

else +

+ a)
[left_window_start] = 0 +
+ b)
[left_window_end] = [window_center] +
+ c)
[left_n] = [n]/2
+
+ 3.
if ([vorbis_mode_blockflag] is set and [next_window_flag] is not set) then +
+ a)
[right_window_start] = [n]*3/4 - [blocksize_0]/4 +
+ b)
[right_window_end] = [n]*3/4 + [blocksize_0]/4 + + + +
+ c)
[right_n] = [blocksize_0]/2
+

else +

+ a)
[right_window_start] = [window_center] +
+ b)
[right_window_end] = [n] +
+ c)
[right_n] = [n]/2
+
+ 4.
window from range 0 ... [left_window_start]-1 inclusive is zero +
+ 5.
for [i] in range [left_window_start] ... [left_window_end]-1, window([i]) = + sin(π +2 * sin 2( ([i]-[left_window_start]+0.5) / [left_n] *π +2) ) +
+ 6.
window from range [left_window_end] ... [right_window_start]-1 inclusive is + one +
+ 7.
for [i] in range [right_window_start] ... [right_window_end]-1, window([i]) = + sin(π2 * sin 2( ([i]-[right_window_start]+0.5) / [right_n] *π2 + π2) ) +
+ 8.
window from range [right_window_start] ... [n]-1 is zero
+

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. +

+

4.3.2. floor curve decode
+

From this point on, we assume out decode context is using mode number [mode_number] +from configuration array [vorbis_mode_configurations] and the map number +[vorbis_mode_mapping] (specified by the current mode) taken from the mapping configuration +array [vorbis_mapping_configurations]. +

Floor curves are decoded one-by-one in channel order. + + + +

For each floor [i] of [audio_channels] +

+ 1.
[submap_number] = element [i] of vector [vorbis_mapping_mux] +
+ 2.
[floor_number] = element [submap_number] of vector [vorbis_submap_floor] +
+ 3.
if the floor type of this floor (vector + [vorbis_floor_types] element [floor_number]) is zero then decode the floor for + channel [i] according to the subsubsection 6.2.2, “packet decode” +
+ 4.
if the type of this floor is one then decode the floor for channel [i] according to the + subsubsection 7.2.3, “packet decode” +
+ 5.
save the needed decoded floor information for channel for later synthesis +
+ 6.
if the decoded floor returned ’unused’, set vector [no_residue] element [i] to true, + else set vector [no_residue] element [i] to false
+

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. +

+

4.3.3. nonzero vector propagate
+

A possible result of floor decode is that a specific vector is marked ’unused’ which indicates that +that final output vector is all-zero values (and the floor is zero). The residue for that vector is not +coded in the stream, save for one complication. If some vectors are used and some are not, +channel coupling could result in mixing a zeroed and nonzeroed vector to produce two nonzeroed +vectors. +

for each [i] from 0 ... [vorbis_mapping_coupling_steps]-1 +

+

+ 1.
if either [no_residue] entry for channel ([vorbis_mapping_magnitude] element + [i]) or channel ([vorbis_mapping_angle] element [i]) are set to false, then both + must be set to false. Note that an ’unused’ floor has no decoded floor information; it + + + + is important that this is remembered at floor curve synthesis time.
+

+

4.3.4. residue decode
+

Unlike floors, which are decoded in channel order, the residue vectors are decoded in submap +order. +

for each submap [i] in order from 0 ... [vorbis_mapping_submaps]-1 +

+

+ 1.
[ch] = 0 +
+ 2.
for each channel [j] in order from 0 ... [audio_channels] - 1 +
+ a)
if channel [j] in submap [i] (vector [vorbis_mapping_mux] element [j] is equal to + [i]) +
+ i.
if vector [no_residue] element [j] is true +
+ A.
vector [do_not_decode_flag] element [ch] is set
+

else +

+ A.
vector [do_not_decode_flag] element [ch] is unset
+
+ ii.
increment [ch]
+
+
+ 3.
[residue_number] = vector [vorbis_mapping_submap_residue] element [i] +
+ 4.
[residue_type] = vector [vorbis_residue_types] element [residue_number] +
+ 5.
decode [ch] vectors using residue [residue_number], according to type [residue_type], + + + + also passing vector [do_not_decode_flag] to indicate which vectors in the bundle should + not be decoded. Correct per-vector decode length is [n]/2. +
+ 6.
[ch] = 0 +
+ 7.
for each channel [j] in order from 0 ... [audio_channels] +
+ a)
if channel [j] is in submap [i] (vector [vorbis_mapping_mux] element [j] is equal + to [i]) +
+ i.
residue vector for channel [j] is set to decoded residue vector [ch] +
+ ii.
increment [ch]
+
+
+

+

4.3.5. inverse coupling
+

for each [i] from [vorbis_mapping_coupling_steps]-1 descending to 0 +

+

+ 1.
[magnitude_vector] = the residue vector for channel (vector + [vorbis_mapping_magnitude] element [i]) +
+ 2.
[angle_vector] = the residue vector for channel (vector [vorbis_mapping_angle] + element [i]) +
+ 3.
for each scalar value [M] in vector [magnitude_vector] and the corresponding scalar value + [A] in vector [angle_vector]: +
+ a)
if ([M] is greater than zero) + + + +
+ i.
if ([A] is greater than zero) +
+ A.
[new_M] = [M] +
+ B.
[new_A] = [M]-[A]
+

else +

+ A.
[new_A] = [M] +
+ B.
[new_M] = [M]+[A]
+
+

else +

+ i.
if ([A] is greater than zero) +
+ A.
[new_M] = [M] +
+ B.
[new_A] = [M]+[A]
+

else +

+ A.
[new_A] = [M] +
+ B.
[new_M] = [M]-[A]
+
+
+ b)
set scalar value [M] in vector [magnitude_vector] to [new_M] +
+ c)
set scalar value [A] in vector [angle_vector] to [new_A]
+
+ + + +

+

4.3.6. dot product
+

For each channel, synthesize the floor curve from the decoded floor information, according to +packet type. Note that the vector synthesis length for floor computation is [n]/2. +

For each channel, multiply each element of the floor curve by each element of that +channel’s residue vector. The result is the dot product of the floor and residue vectors for +each channel; the produced vectors are the length [n]/2 audio spectrum for each +channel. +

One point is worth mentioning about this dot product; a common mistake in a fixed point +implementation might be to assume that a 32 bit fixed-point representation for floor and +residue and direct multiplication of the vectors is sufficient for acceptable spectral depth +in all cases because it happens to mostly work with the current Xiph.Org reference +encoder. +

However, floor vector values can span ~140dB (~24 bits unsigned), and the audio spectrum +vector should represent a minimum of 120dB (~21 bits with sign), even when output is to a 16 +bit PCM device. For the residue vector to represent full scale if the floor is nailed +to -140dB, it must be able to span 0 to +140dB. For the residue vector to reach +full scale if the floor is nailed at 0dB, it must be able to represent -140dB to +0dB. +Thus, in order to handle full range dynamics, a residue vector may span -140dB to ++140dB entirely within spec. A 280dB range is approximately 48 bits with sign; thus the +residue vector must be able to represent a 48 bit range and the dot product must +be able to handle an effective 48 bit times 24 bit multiplication. This range may be +achieved using large (64 bit or larger) integers, or implementing a movable binary point +representation. +

+

4.3.7. inverse MDCT
+

Convert the audio spectrum vector of each channel back into time domain PCM audio via an +inverse Modified Discrete Cosine Transform (MDCT). A detailed description of the MDCT is +available in [1]. The window function used for the MDCT is the function described +earlier. + + + +

+

4.3.8. overlap_add
+

Windowed MDCT output is overlapped and added with the right hand data of the previous +window such that the 3/4 point of the previous window is aligned with the 1/4 point of the +current window (as illustrated in paragraph 1.3.2, “Window shape decode (long windows +only)”). The overlapped portion produced from overlapping the previous and current frame data +is finished data to be returned by the decoder. This data spans from the center of +the previous window to the center of the current window. In the case of same-sized +windows, the amount of data to return is one-half block consisting of and only of the +overlapped portions. When overlapping a short and long window, much of the returned +range does not actually overlap. This does not damage transform orthogonality. Pay +attention however to returning the correct data range; the amount of data to be returned +is: +

+

1  window_blocksize(previous_window)/4+window_blocksize(current_window)/4
+

from the center (element windowsize/2) of the previous window to the center (element +windowsize/2-1, inclusive) of the current window. +

Data is not returned from the first frame; it must be used to ’prime’ the decode engine. The +encoder accounts for this priming when calculating PCM offsets; after the first frame, the proper +PCM output offset is ’0’ (as no data has been returned yet). +

+

4.3.9. output channel order
+

Vorbis I specifies only a channel mapping type 0. In mapping type 0, channel mapping is +implicitly defined as follows for standard audio applications. As of revision 16781 (20100113), the +specification adds defined channel locations for 6.1 and 7.1 surround. Ordering/location for +greater-than-eight channels remains ’left to the implementation’. +

These channel orderings refer to order within the encoded stream. It is naturally possible for a +decoder to produce output with channels in any order. Any such decoder should explicitly +document channel reordering behavior. +

+

+one channel
the stream is monophonic + + + +
+two channels
the stream is stereo. channel order: left, right +
+three channels
the stream is a 1d-surround encoding. channel order: left, center, right +
+four channels
the stream is quadraphonic surround. channel order: front left, front right, + rear left, rear right +
+five channels
the stream is five-channel surround. channel order: front left, center, front + right, rear left, rear right +
+six channels
the stream is 5.1 surround. channel order: front left, center, front right, rear + left, rear right, LFE +
+seven channels
the stream is 6.1 surround. channel order: front left, center, front right, + side left, side right, rear center, LFE +
+eight channels
the stream is 7.1 surround. channel order: front left, center, front right, + side left, side right, rear left, rear right, LFE +
+greater than eight channels
channel use and order is defined by the application +
+

Applications using Vorbis for dedicated purposes may define channel mapping as seen fit. Future +channel mappings (such as three and four channel Ambisonics) will make use of channel +mappings other than mapping 0. + + + + + + +

5. comment field and header specification

+

+

5.1. Overview

+

The Vorbis text comment header is the second (of three) header packets that begin a Vorbis +bitstream. It is meant for short text comments, not arbitrary metadata; arbitrary metadata +belongs in a separate logical bitstream (usually an XML stream type) that provides greater +structure and machine parseability. +

The comment field is meant to be used much like someone jotting a quick note on the bottom of +a CDR. It should be a little information to remember the disc by and explain it to others; a +short, to-the-point text note that need not only be a couple words, but isn’t going to be more +than a short paragraph. The essentials, in other words, whatever they turn out to be, +eg: +

+

+

Honest Bob and the Factory-to-Dealer-Incentives, “I’m Still Around”, opening + for Moxy Früvous, 1997.

+

+

5.2. Comment encoding

+

+

5.2.1. Structure
+

The comment header is logically a list of eight-bit-clean vectors; the number of vectors is +bounded to 232 - 1 and the length of each vector is limited to 232 - 1 bytes. The vector length is + + + +encoded; the vector contents themselves are not null terminated. In addition to the vector list, +there is a single vector for vendor name (also 8 bit clean, length encoded in 32 bits). For +example, the 1.0 release of libvorbis set the vendor string to “Xiph.Org libVorbis I +20020717”. +

The vector lengths and number of vectors are stored lsb first, according to the bit +packing conventions of the vorbis codec. However, since data in the comment header +is octet-aligned, they can simply be read as unaligned 32 bit little endian unsigned +integers. +

The comment header is decoded as follows: +

+

1    1) [vendor\_length] = read an unsigned integer of 32 bits
2    2) [vendor\_string] = read a UTF-8 vector as [vendor\_length] octets +
3    3) [user\_comment\_list\_length] = read an unsigned integer of 32 bits
4    4) iterate [user\_comment\_list\_length] times { +
5         5) [length] = read an unsigned integer of 32 bits
6         6) this iteration’s user comment = read a UTF-8 vector as [length] octets +
7       }
8    7) [framing\_bit] = read a single bit as boolean
9    8) if ( [framing\_bit] unset or end-of-packet ) then ERROR
10    9) done.
+

+

5.2.2. Content vector format
+

The comment vectors are structured similarly to a UNIX environment variable. That is, +comment fields consist of a field name and a corresponding value and look like: +

+

+

+

1  comment[0]="ARTIST=me";
2  comment[1]="TITLE=the sound of Vorbis";
+
+

The field name is case-insensitive and may consist of ASCII 0x20 through 0x7D, 0x3D (’=’) +excluded. ASCII 0x41 through 0x5A inclusive (characters A-Z) is to be considered equivalent to +ASCII 0x61 through 0x7A inclusive (characters a-z). +

The field name is immediately followed by ASCII 0x3D (’=’); this equals sign is used to +terminate the field name. +

0x3D is followed by 8 bit clean UTF-8 encoded value of the field contents to the end of the +field. + + + +

Field names +Below is a proposed, minimal list of standard field names with a description of intended use. No +single or group of field names is mandatory; a comment header may contain one, all or none of +the names in this list. +

+

+TITLE
Track/Work name +
+VERSION
The version field may be used to differentiate multiple versions of the same + track title in a single collection. (e.g. remix info) +
+ALBUM
The collection name to which this track belongs +
+TRACKNUMBER
The track number of this piece if part of a specific larger collection or + album +
+ARTIST
The artist generally considered responsible for the work. In popular music this is + usually the performing band or singer. For classical music it would be the composer. + For an audio book it would be the author of the original text. +
+PERFORMER
The artist(s) who performed the work. In classical music this would be the + conductor, orchestra, soloists. In an audio book it would be the actor who did the + reading. In popular music this is typically the same as the ARTIST and is omitted. +
+COPYRIGHT
Copyright attribution, e.g., ’2001 Nobody’s Band’ or ’1999 Jack Moffitt’ +
+LICENSE
License information, eg, ’All Rights Reserved’, ’Any Use Permitted’, a URL to + a license such as a Creative + Commons license (”www.creativecommons.org/blahblah/license.html”) or the EFF + Open Audio License (’distributed under the terms of the Open Audio License. see + http://www.eff.org/IP/Open_licenses/eff_oal.html for details’), etc. +
+ORGANIZATION
Name of the organization producing the track (i.e. the ’record label’) +
+DESCRIPTION
A short text description of the contents +
+ + + +GENRE
A short text indication of music genre +
+DATE
Date the track was recorded +
+LOCATION
Location where track was recorded +
+CONTACT
Contact information for the creators or distributors of the track. This could + be a URL, an email address, the physical address of the producing label. +
+ISRC
International Standard Recording Code for the track; see the ISRC intro page for + more information on ISRC numbers. +
+

Implications +Field names should not be ’internationalized’; this is a concession to simplicity not +an attempt to exclude the majority of the world that doesn’t speak English. Field +contents, however, use the UTF-8 character encoding to allow easy representation of any +language. +

We have the length of the entirety of the field and restrictions on the field name so that +the field name is bounded in a known way. Thus we also have the length of the field +contents. +

Individual ’vendors’ may use non-standard field names within reason. The proper +use of comment fields should be clear through context at this point. Abuse will be +discouraged. +

There is no vendor-specific prefix to ’nonstandard’ field names. Vendors should make some effort +to avoid arbitrarily polluting the common namespace. We will generally collect the more useful +tags here to help with standardization. +

Field names are not required to be unique (occur once) within a comment header. As an +example, assume a track was recorded by three well know artists; the following is permissible, +and encouraged: +

+

+

+ + + +

1  ARTIST=Dizzy Gillespie
2  ARTIST=Sonny Rollins
3  ARTIST=Sonny Stitt
+
+

+

5.2.3. Encoding
+

The comment header comprises the entirety of the second bitstream header packet. Unlike the +first bitstream header packet, it is not generally the only packet on the second page and may not +be restricted to within the second bitstream page. The length of the comment header packet is +(practically) unbounded. The comment header packet is not optional; it must be present in the +bitstream even if it is effectively empty. +

The comment header is encoded as follows (as per Ogg’s standard bitstream mapping which +renders least-significant-bit of the word to be coded into the least significant available bit of the +current bitstream octet first): +

+

+ 1.
Vendor string length (32 bit unsigned quantity specifying number of octets) +
+ 2.
Vendor string ([vendor string length] octets coded from beginning of string to end of + string, not null terminated) +
+ 3.
Number of comment fields (32 bit unsigned quantity specifying number of fields) +
+ 4.
Comment field 0 length (if [Number of comment fields] > 0; 32 bit unsigned quantity + specifying number of octets) +
+ 5.
Comment field 0 ([Comment field 0 length] octets coded from beginning of string to + end of string, not null terminated) +
+ 6.
Comment field 1 length (if [Number of comment fields] > 1...)... +
+

This is actually somewhat easier to describe in code; implementation of the above can be found +in vorbis/lib/info.c, _vorbis_pack_comment() and _vorbis_unpack_comment(). + + + + + + + + + +

6. Floor type 0 setup and decode

+

+

6.1. Overview

+

Vorbis floor type zero uses Line Spectral Pair (LSP, also alternately known as Line Spectral +Frequency or LSF) representation to encode a smooth spectral envelope curve as the frequency +response of the LSP filter. This representation is equivalent to a traditional all-pole infinite +impulse response filter as would be used in linear predictive coding; LSP representation may be +converted to LPC representation and vice-versa. +

+

6.2. Floor 0 format

+

Floor zero configuration consists of six integer fields and a list of VQ codebooks for use in +coding/decoding the LSP filter coefficient values used by each frame. +

+

6.2.1. header decode
+

Configuration information for instances of floor zero decodes from the codec setup header (third +packet). configuration decode proceeds as follows: +

+

1    1) [floor0_order] = read an unsigned integer of 8 bits
2    2) [floor0_rate] = read an unsigned integer of 16 bits +
3    3) [floor0_bark_map_size] = read an unsigned integer of 16 bits
4    4) [floor0_amplitude_bits] = read an unsigned integer of six bits +
5    5) [floor0_amplitude_offset] = read an unsigned integer of eight bits +
6    6) [floor0_number_of_books] = read an unsigned integer of four bits and add 1 +
7    7) array [floor0_book_list] = read a list of [floor0_number_of_books] unsigned integers of eight bits each;
+ + + +

An end-of-packet condition during any of these bitstream reads renders this stream undecodable. +In addition, any element of the array [floor0_book_list] that is greater than the maximum +codebook number for this bitstream is an error condition that also renders the stream +undecodable. +

+

6.2.2. packet decode
+

Extracting a floor0 curve from an audio packet consists of first decoding the curve +amplitude and [floor0_order] LSP coefficient values from the bitstream, and then +computing the floor curve, which is defined as the frequency response of the decoded LSP +filter. +

Packet decode proceeds as follows: +

1    1) [amplitude] = read an unsigned integer of [floor0_amplitude_bits] bits
2    2) if ( [amplitude] is greater than zero ) { +
3         3) [coefficients] is an empty, zero length vector
4         4) [booknumber] = read an unsigned integer of ilog( [floor0_number_of_books] ) bits +
5         5) if ( [booknumber] is greater than the highest number decode codebook ) then packet is undecodable
6         6) [last] = zero; +
7         7) vector [temp_vector] = read vector from bitstream using codebook number [floor0_book_list] element [booknumber] in VQ context. +
8         8) add the scalar value [last] to each scalar in vector [temp_vector]
9         9) [last] = the value of the last scalar in vector [temp_vector] +
10        10) concatenate [temp_vector] onto the end of the [coefficients] vector +
11        11) if (length of vector [coefficients] is less than [floor0_order], continue at step 6
12  
13       }
14  
15   12) done.
16  
+

Take note of the following properties of decode: +

    +
  • An [amplitude] value of zero must result in a return code that indicates this channel + is unused in this frame (the output of the channel will be all-zeroes in synthesis). + Several later stages of decode don’t occur for an unused channel. +
    • +
  • An end-of-packet condition during decode should be considered a nominal occruence; + if end-of-packet is reached during any read operation above, floor decode is to return + ’unused’ status as if the [amplitude] value had read zero at the beginning of decode. +
    • +
  • The book number used for decode can, in fact, be stored in the bitstream in ilog( + [floor0_number_of_books] - 1 ) bits. Nevertheless, the above specification is correct + and values greater than the maximum possible book value are reserved. +
    • +
  • The number of scalars read into the vector [coefficients] may be greater + than [floor0_order], the number actually required for curve computation. For + example, if the VQ codebook used for the floor currently being decoded has a + [codebook_dimensions] value of three and [floor0_order] is ten, the only way to + + + + fill all the needed scalars in [coefficients] is to to read a total of twelve scalars + as four vectors of three scalars each. This is not an error condition, and care must + be taken not to allow a buffer overflow in decode. The extra values are not used and + may be ignored or discarded.
+

+

6.2.3. curve computation
+

Given an [amplitude] integer and [coefficients] vector from packet decode as well as +the [floor0_order], [floor0_rate], [floor0_bark_map_size], [floor0_amplitude_bits] and +[floor0_amplitude_offset] values from floor setup, and an output vector size [n] specified by the +decode process, we compute a floor output vector. +

If the value [amplitude] is zero, the return value is a length [n] vector with all-zero +scalars. Otherwise, begin by assuming the following definitions for the given vector to be +synthesized: +

+ { +map = min (floor0_bark_map_size - 1,f oobar) for i ∈ [0, n - 1] + i - 1 for i = n +
+

+

where +

+ ⌊ ⌋ + ( floor0_rate--⋅ i) floor0_bark_map_size---- +f oobar = bark 2n ⋅ bark(.5 ⋅ floor0_rate ) +
+

+

and +

+ 2 +bark(x) = 13.1arctan (.00074x ) + 2.24 arctan(.0000000185x ) + .0001x +
+

+

The above is used to synthesize the LSP curve on a Bark-scale frequency axis, then map the +result to a linear-scale frequency axis. Similarly, the below calculation synthesizes the output +LSP curve [output] on a log (dB) amplitude scale, mapping it to linear amplitude in the last +step: +

+

+ 1.
[i] = 0 +
+ 2.
[ω] = π * map element [i] / [floor0_bark_map_size] +
+ 3.
if ( [floor0_order] is odd ) +
+ a)
calculate [p] and [q] according to:
+
+ floor0∏_2order-3 +p = (1 - cos2ω) 4(cos([coefficients ]2j+1) - cosω )2 + j=0 + floor0_order-1 + 1 ∏2 2 +q = 4- 4(cos([coefficients ]2j) - cosω ) + j=0 +
+
+
+

else [floor0_order] is even + + + +

+ a)
calculate [p] and [q] according to:
+
+ floor0_order-2 + (1 - cosω ) ---∏2----- +p = ----------- 4(cos([coefficients ]2j+1) - cosω)2 + 2 j=0 + floor0_order--2 + (1-+-cosω-) ∏2 2 +q = 2 4(cos([coefficients ]2j) - cos ω) + j=0 +
+
+
+
+ 4.
calculate [linear_floor_value] according to: +
+ ( ( )) + amplitude---⋅ floor0_amplitute_offset--- +exp .11512925 (2floor0_amplitude_bits - 1)√p--+-q - floor0_amplitude_offset +
+

+

+ 5.
[iteration_condition] = map element [i] +
+ 6.
[output] element [i] = [linear_floor_value] +
+ 7.
increment [i] +
+ 8.
if ( map element [i] is equal to [iteration_condition] ) continue at step + + + + 5 +
+ 9.
if ( [i] is less than [n] ) continue at step 2 +
+ 10.
done
+

Errata 20150227: Bark scale computation +Due to a typo when typesetting this version of the specification from the original HTML +document, the Bark scale computation previously erroneously read: +

+ 2 +bark(x) = 13.1arctan (.00074x ) + 2.24 arctan(.0000000185x + .0001x ) +
+

+

Note that the last parenthesis is misplaced. This document now uses the correct equation as it +appeared in the original HTML spec document: +

+bark(x) = 13.1arctan (.00074x ) + 2.24 arctan(.0000000185x2 ) + .0001x +
+

+ + + + + + +

7. Floor type 1 setup and decode

+

+

7.1. Overview

+

Vorbis floor type one uses a piecewise straight-line representation to encode a spectral envelope +curve. The representation plots this curve mechanically on a linear frequency axis and a +logarithmic (dB) amplitude axis. The integer plotting algorithm used is similar to Bresenham’s +algorithm. +

+

7.2. Floor 1 format

+

+

7.2.1. model
+

Floor type one represents a spectral curve as a series of line segments. Synthesis constructs a +floor curve using iterative prediction in a process roughly equivalent to the following simplified +description: +

    +
  • the first line segment (base case) is a logical line spanning from x˙0,y˙0 to x˙1,y˙1 + where in the base case x˙0=0 and x˙1=[n], the full range of the spectral floor to be + computed. +
    • +
  • the induction step chooses a point x˙new within an existing logical line segment and + produces a y˙new value at that point computed from the existing line’s y value at + x˙new (as plotted by the line) and a difference value decoded from the bitstream + packet. + + + +
    • +
  • floor computation produces two new line segments, one running from x˙0,y˙0 to + x˙new,y˙new and from x˙new,y˙new to x˙1,y˙1. This step is performed logically even if + y˙new represents no change to the amplitude value at x˙new so that later refinement + is additionally bounded at x˙new. +
    • +
  • the induction step repeats, using a list of x values specified in the codec setup header + at floor 1 initialization time. Computation is completed at the end of the x value list. +
+

Consider the following example, with values chosen for ease of understanding rather than +representing typical configuration: +

For the below example, we assume a floor setup with an [n] of 128. The list of selected X values +in increasing order is 0,16,32,48,64,80,96,112 and 128. In list order, the values interleave as 0, +128, 64, 32, 96, 16, 48, 80 and 112. The corresponding list-order Y values as decoded from an +example packet are 110, 20, -5, -45, 0, -25, -10, 30 and -10. We compute the floor in the following +way, beginning with the first line: +

+

+ +

PIC +

Figure 7: graph of example floor
+
+

We now draw new logical lines to reflect the correction to new˙Y, and iterate for X positions 32 +and 96: +

+

+ +

PIC +

Figure 8: graph of example floor
+
+

Although the new Y value at X position 96 is unchanged, it is still used later as an endpoint for +further refinement. From here on, the pattern should be clear; we complete the floor computation +as follows: + + + +

+

+ +

PIC +

Figure 9: graph of example floor
+
+
+

+ +

PIC +

Figure 10: graph of example floor
+
+

A more efficient algorithm with carefully defined integer rounding behavior is used for actual +decode, as described later. The actual algorithm splits Y value computation and line plotting +into two steps with modifications to the above algorithm to eliminate noise accumulation +through integer roundoff/truncation. +

+

7.2.2. header decode
+

A list of floor X values is stored in the packet header in interleaved format (used in list order +during packet decode and synthesis). This list is split into partitions, and each partition is +assigned to a partition class. X positions 0 and [n] are implicit and do not belong to an explicit +partition or partition class. +

A partition class consists of a representation vector width (the number of Y values which +the partition class encodes at once), a ’subclass’ value representing the number of +alternate entropy books the partition class may use in representing Y values, the list of +[subclass] books and a master book used to encode which alternate books were chosen +for representation in a given packet. The master/subclass mechanism is meant to be +used as a flexible representation cascade while still using codebooks only in a scalar +context. + + + +

+

1  
2    1) [floor1_partitions] = read 5 bits as unsigned integer
3    2) [maximum_class] = -1
4    3) iterate [i] over the range 0 ... [floor1_partitions]-1 { +
5  
6          4) vector [floor1_partition_class_list] element [i] = read 4 bits as unsigned integer
7  
8       }
9   +
10    5) [maximum_class] = largest integer scalar value in vector [floor1_partition_class_list]
11    6) iterate [i] over the range 0 ... [maximum_class] { +
12  
13          7) vector [floor1_class_dimensions] element [i] = read 3 bits as unsigned integer and add 1 +
14   8) vector [floor1_class_subclasses] element [i] = read 2 bits as unsigned integer +
15          9) if ( vector [floor1_class_subclasses] element [i] is nonzero ) {
16   +
17               10) vector [floor1_class_masterbooks] element [i] = read 8 bits as unsigned integer
18  
19             }
20   +
21         11) iterate [j] over the range 0 ... (2 exponent [floor1_class_subclasses] element [i]) - 1 {
22   +
23               12) array [floor1_subclass_books] element [i],[j] =
24                   read 8 bits as unsigned integer and subtract one
25             } +
26        }
27  
28   13) [floor1_multiplier] = read 2 bits as unsigned integer and add one
29   14) [rangebits] = read 4 bits as unsigned integer +
30   15) vector [floor1_X_list] element [0] = 0
31   16) vector [floor1_X_list] element [1] = 2 exponent [rangebits]; +
32   17) [floor1_values] = 2
33   18) iterate [i] over the range 0 ... [floor1_partitions]-1 { +
34  
35         19) [current_class_number] = vector [floor1_partition_class_list] element [i] +
36         20) iterate [j] over the range 0 ... ([floor1_class_dimensions] element [current_class_number])-1 { +
37               21) vector [floor1_X_list] element ([floor1_values]) =
38                   read [rangebits] bits as unsigned integer +
39               22) increment [floor1_values] by one
40             }
41       }
42  
43   23) done
+

An end-of-packet condition while reading any aspect of a floor 1 configuration during +setup renders a stream undecodable. In addition, a [floor1_class_masterbooks] or +[floor1_subclass_books] scalar element greater than the highest numbered codebook +configured in this stream is an error condition that renders the stream undecodable. Vector +[floor1_x_list] is limited to a maximum length of 65 elements; a setup indicating more than 65 +total elements (including elements 0 and 1 set prior to the read loop) renders the stream +undecodable. All vector [floor1_x_list] element values must be unique within the vector; a +non-unique value renders the stream undecodable. +

+

7.2.3. packet decode
+

Packet decode begins by checking the [nonzero] flag: +

+

1    1) [nonzero] = read 1 bit as boolean
+

If [nonzero] is unset, that indicates this channel contained no audio energy in this frame. +Decode immediately returns a status indicating this floor curve (and thus this channel) is unused +this frame. (A return status of ’unused’ is different from decoding a floor that has all +points set to minimum representation amplitude, which happens to be approximately +-140dB). +

Assuming [nonzero] is set, decode proceeds as follows: +

+

1    1) [range] = vector { 256, 128, 86, 64 } element ([floor1_multiplier]-1) + + + +
2    2) vector [floor1_Y] element [0] = read ilog([range]-1) bits as unsigned integer +
3    3) vector [floor1_Y] element [1] = read ilog([range]-1) bits as unsigned integer +
4    4) [offset] = 2;
5    5) iterate [i] over the range 0 ... [floor1_partitions]-1 {
6   +
7         6) [class] = vector [floor1_partition_class]  element [i]
8         7) [cdim]  = vector [floor1_class_dimensions] element [class] +
9         8) [cbits] = vector [floor1_class_subclasses] element [class]
10         9) [csub]  = (2 exponent [cbits])-1
11        10) [cval]  = 0 +
12        11) if ( [cbits] is greater than zero ) {
13  
14               12) [cval] = read from packet using codebook number +
15                   (vector [floor1_class_masterbooks] element [class]) in scalar context +
16            }
17  
18        13) iterate [j] over the range 0 ... [cdim]-1 {
19   +
20               14) [book] = array [floor1_subclass_books] element [class],([cval] bitwise AND [csub]) +
21               15) [cval] = [cval] right shifted [cbits] bits
22        16) if ( [book] is not less than zero ) {
23   +
24              17) vector [floor1_Y] element ([j]+[offset]) = read from packet using codebook
25                         [book] in scalar context +
26  
27                   } else [book] is less than zero {
28  
29              18) vector [floor1_Y] element ([j]+[offset]) = 0 +
30  
31                   }
32            }
33  
34        19) [offset] = [offset] + [cdim]
35  
36       }
37  
38   20) done
+

An end-of-packet condition during curve decode should be considered a nominal occurrence; if +end-of-packet is reached during any read operation above, floor decode is to return ’unused’ +status as if the [nonzero] flag had been unset at the beginning of decode. +

Vector [floor1_Y] contains the values from packet decode needed for floor 1 synthesis. +

+

7.2.4. curve computation
+

Curve computation is split into two logical steps; the first step derives final Y amplitude values +from the encoded, wrapped difference values taken from the bitstream. The second step +plots the curve lines. Also, although zero-difference values are used in the iterative +prediction to find final Y values, these points are conditionally skipped during final +line computation in step two. Skipping zero-difference values allows a smoother line +fit. +

Although some aspects of the below algorithm look like inconsequential optimizations, +implementors are warned to follow the details closely. Deviation from implementing a strictly +equivalent algorithm can result in serious decoding errors. +

Additional note: Although [floor1_final_Y] values in the prediction loop and at the end of +step 1 are inherently limited by the prediction algorithm to [0, [range]), it is possible to abuse +the setup and codebook machinery to produce negative or over-range results. We suggest that +decoder implementations guard the values in vector [floor1_final_Y] by clamping each +element to [0, [range]) after step 1. Variants of this suggestion are acceptable as valid floor1 +setups cannot produce out of range values. +

+

+step 1: amplitude value synthesis
+

Unwrap the always-positive-or-zero values read from the packet into +/- difference + + + + values, then apply to line prediction. +

+

1    1) [range] = vector { 256, 128, 86, 64 } element ([floor1_multiplier]-1)
2    2) vector [floor1_step2_flag] element [0] = set +
3    3) vector [floor1_step2_flag] element [1] = set
4    4) vector [floor1_final_Y] element [0] = vector [floor1_Y] element [0] +
5    5) vector [floor1_final_Y] element [1] = vector [floor1_Y] element [1]
6    6) iterate [i] over the range 2 ... [floor1_values]-1 {
7   +
8         7) [low_neighbor_offset] = low_neighbor([floor1_X_list],[i])
9         8) [high_neighbor_offset] = high_neighbor([floor1_X_list],[i]) +
10  
11         9) [predicted] = render_point( vector [floor1_X_list] element [low_neighbor_offset], +
12         vector [floor1_final_Y] element [low_neighbor_offset], +
13                                        vector [floor1_X_list] element [high_neighbor_offset], +
14         vector [floor1_final_Y] element [high_neighbor_offset], +
15                                        vector [floor1_X_list] element [i] )
16  
17        10) [val] = vector [floor1_Y] element [i] +
18        11) [highroom] = [range] - [predicted]
19        12) [lowroom]  = [predicted] +
20        13) if ( [highroom] is less than [lowroom] ) {
21  
22              14) [room] = [highroom] * 2
23   +
24            } else [highroom] is not less than [lowroom] {
25  
26              15) [room] = [lowroom] * 2
27  
28            }
29   +
30        16) if ( [val] is nonzero ) {
31  
32              17) vector [floor1_step2_flag] element [low_neighbor_offset] = set +
33              18) vector [floor1_step2_flag] element [high_neighbor_offset] = set +
34              19) vector [floor1_step2_flag] element [i] = set
35              20) if ( [val] is greater than or equal to [room] ) { +
36  
37                    21) if ( [highroom] is greater than [lowroom] ) {
38   +
39                          22) vector [floor1_final_Y] element [i] = [val] - [lowroom] + [predicted] +
40  
41         } else [highroom] is not greater than [lowroom] {
42   +
43                          23) vector [floor1_final_Y] element [i] = [predicted] - [val] + [highroom] - 1 +
44  
45                        }
46  
47                  } else [val] is less than [room] {
48   +
49                      24) if ([val] is odd) {
50  
51                          25) vector [floor1_final_Y] element [i] = +
52                              [predicted] - (([val] + 1) divided by  2 using integer division)
53   +
54                        } else [val] is even {
55  
56                          26) vector [floor1_final_Y] element [i] = +
57                              [predicted] + ([val] / 2 using integer division)
58  
59                        }
60   +
61                  }
62  
63            } else [val] is zero {
64  
65              27) vector [floor1_step2_flag] element [i] = unset +
66              28) vector [floor1_final_Y] element [i] = [predicted]
67  
68            }
69  
70       }
71  
72   29) done
73  
+
+step 2: curve synthesis
+

Curve synthesis generates a return vector [floor] of length [n] (where [n] is provided by + the decode process calling to floor decode). Floor 1 curve synthesis makes use of the + [floor1_X_list], [floor1_final_Y] and [floor1_step2_flag] vectors, as well as + [floor1_multiplier] and [floor1_values] values. +

Decode begins by sorting the scalars from vectors [floor1_X_list], [floor1_final_Y] and + [floor1_step2_flag] together into new vectors [floor1_X_list]’, [floor1_final_Y]’ + and [floor1_step2_flag]’ according to ascending sort order of the values in + [floor1_X_list]. That is, sort the values of [floor1_X_list] and then apply the same + permutation to elements of the other two vectors so that the X, Y and step2_flag values + still match. +

Then compute the final curve in one pass: +

+

1    1) [hx] = 0
2    2) [lx] = 0
3    3) [ly] = vector [floor1_final_Y]’ element [0] * [floor1_multiplier] +
4    4) iterate [i] over the range 1 ... [floor1_values]-1 {
5  
6         5) if ( [floor1_step2_flag]’ element [i] is set ) {
7   +
8               6) [hy] = [floor1_final_Y]’ element [i] * [floor1_multiplier]
9         7) [hx] = [floor1_X_list]’ element [i] +
10               8) render_line( [lx], [ly], [hx], [hy], [floor] )
11               9) [lx] = [hx]
12       10) [ly] = [hy] +
13            }
14       }
15  
16   11) if ( [hx] is less than [n] ) {
17  
18          12) render_line( [hx], [hy], [n], [hy], [floor] ) +
19  
20       }
21  
22   13) if ( [hx] is greater than [n] ) {
23  
24              14) truncate vector [floor] to [n] elements +
25  
26       }
27  
28   15) for each scalar in vector [floor], perform a lookup substitution using + + + +
29       the scalar value from [floor] as an offset into the vector [floor1_inverse_dB_static_table]
30  
31   16) done
32  
+
+ + + +

8. Residue setup and decode

+

+

8.1. Overview

+

A residue vector represents the fine detail of the audio spectrum of one channel in an audio frame +after the encoder subtracts the floor curve and performs any channel coupling. A residue vector +may represent spectral lines, spectral magnitude, spectral phase or hybrids as mixed by channel +coupling. The exact semantic content of the vector does not matter to the residue +abstraction. +

Whatever the exact qualities, the Vorbis residue abstraction codes the residue vectors into the +bitstream packet, and then reconstructs the vectors during decode. Vorbis makes use of three +different encoding variants (numbered 0, 1 and 2) of the same basic vector encoding +abstraction. +

+

8.2. Residue format

+

Residue format partitions each vector in the vector bundle into chunks, classifies each +chunk, encodes the chunk classifications and finally encodes the chunks themselves +using the the specific VQ arrangement defined for each selected classification. The +exact interleaving and partitioning vary by residue encoding number, however the +high-level process used to classify and encode the residue vector is the same in all three +variants. +

A set of coded residue vectors are all of the same length. High level coding structure, ignoring for +the moment exactly how a partition is encoded and simply trusting that it is, is as +follows: +

    +
  • Each vector is partitioned into multiple equal sized chunks according to configuration + specified. If we have a vector size of n, a partition size residue_partition_size, + and a total of ch residue vectors, the total number of partitioned chunks coded + + + + is n/residue_partition_size*ch. It is important to note that the integer division + truncates. In the below example, we assume an example residue_partition_size of 8. +
    • +
  • Each partition in each vector has a classification number that specifies which of + multiple configured VQ codebook setups are used to decode that partition. The + classification numbers of each partition can be thought of as forming a vector in + their own right, as in the illustration below. Just as the residue vectors are coded + in grouped partitions to increase encoding efficiency, the classification vector is also + partitioned into chunks. The integer elements of each scalar in a classification chunk + are built into a single scalar that represents the classification numbers in that chunk. + In the below example, the classification codeword encodes two classification numbers. +
    • +
  • The values in a residue vector may be encoded monolithically in a single pass through + the residue vector, but more often efficient codebook design dictates that each vector + is encoded as the additive sum of several passes through the residue vector using + more than one VQ codebook. Thus, each residue value potentially accumulates values + from multiple decode passes. The classification value associated with a partition is + the same in each pass, thus the classification codeword is coded only in the first pass. +
+
+

+ +

PIC +

Figure 11: illustration of residue vector format
+
+

+

8.3. residue 0

+

Residue 0 and 1 differ only in the way the values within a residue partition are interleaved during +partition encoding (visually treated as a black box–or cyan box or brown box–in the above +figure). +

Residue encoding 0 interleaves VQ encoding according to the dimension of the codebook used to + + + +encode a partition in a specific pass. The dimension of the codebook need not be the same in +multiple passes, however the partition size must be an even multiple of the codebook +dimension. +

As an example, assume a partition vector of size eight, to be encoded by residue 0 using +codebook sizes of 8, 4, 2 and 1: +

+

1  
2              original residue vector: [ 0 1 2 3 4 5 6 7 ]
3  
4  codebook dimensions = 8  encoded as: [ 0 1 2 3 4 5 6 7 ]
5   +
6  codebook dimensions = 4  encoded as: [ 0 2 4 6 ], [ 1 3 5 7 ]
7  
8  codebook dimensions = 2  encoded as: [ 0 4 ], [ 1 5 ], [ 2 6 ], [ 3 7 ] +
9  
10  codebook dimensions = 1  encoded as: [ 0 ], [ 1 ], [ 2 ], [ 3 ], [ 4 ], [ 5 ], [ 6 ], [ 7 ]
11  
+

It is worth mentioning at this point that no configurable value in the residue coding setup is +restricted to a power of two. +

+

8.4. residue 1

+

Residue 1 does not interleave VQ encoding. It represents partition vector scalars in order. As +with residue 0, however, partition length must be an integer multiple of the codebook dimension, +although dimension may vary from pass to pass. +

As an example, assume a partition vector of size eight, to be encoded by residue 0 using +codebook sizes of 8, 4, 2 and 1: +

+

1  
2              original residue vector: [ 0 1 2 3 4 5 6 7 ]
3  
4  codebook dimensions = 8  encoded as: [ 0 1 2 3 4 5 6 7 ]
5   +
6  codebook dimensions = 4  encoded as: [ 0 1 2 3 ], [ 4 5 6 7 ]
7  
8  codebook dimensions = 2  encoded as: [ 0 1 ], [ 2 3 ], [ 4 5 ], [ 6 7 ] +
9  
10  codebook dimensions = 1  encoded as: [ 0 ], [ 1 ], [ 2 ], [ 3 ], [ 4 ], [ 5 ], [ 6 ], [ 7 ]
11  
+

+

8.5. residue 2

+

Residue type two can be thought of as a variant of residue type 1. Rather than encoding multiple +passed-in vectors as in residue type 1, the ch passed in vectors of length n are first interleaved +and flattened into a single vector of length ch*n. Encoding then proceeds as in type 1. Decoding +is as in type 1 with decode interleave reversed. If operating on a single vector to begin with, +residue type 1 and type 2 are equivalent. + + + +

+

+ +

PIC +

Figure 12: illustration of residue type 2
+
+

+

8.6. Residue decode

+

+

8.6.1. header decode
+

Header decode for all three residue types is identical. +

1    1) [residue\_begin] = read 24 bits as unsigned integer
2    2) [residue\_end] = read 24 bits as unsigned integer +
3    3) [residue\_partition\_size] = read 24 bits as unsigned integer and add one +
4    4) [residue\_classifications] = read 6 bits as unsigned integer and add one
5    5) [residue\_classbook] = read 8 bits as unsigned integer
+

[residue_begin] and [residue_end] select the specific sub-portion of each vector that is +actually coded; it implements akin to a bandpass where, for coding purposes, the vector +effectively begins at element [residue_begin] and ends at [residue_end]. Preceding and +following values in the unpacked vectors are zeroed. Note that for residue type 2, these +values as well as [residue_partition_size]apply to the interleaved vector, not the +individual vectors before interleave. [residue_partition_size] is as explained above, +[residue_classifications] is the number of possible classification to which a partition can +belong and [residue_classbook] is the codebook number used to code classification +codewords. The number of dimensions in book [residue_classbook] determines how +many classification values are grouped into a single classification codeword. Note that +the number of entries and dimensions in book [residue_classbook], along with +[residue_classifications], overdetermines to possible number of classification +codewords. If [residue_classifications]ˆ[residue_classbook].dimensions exceeds +[residue_classbook].entries, the bitstream should be regarded to be undecodable. + + + +

Next we read a bitmap pattern that specifies which partition classes code values in which +passes. +

+

1    1) iterate [i] over the range 0 ... [residue\_classifications]-1 {
2  
3         2) [high\_bits] = 0 +
4         3) [low\_bits] = read 3 bits as unsigned integer
5         4) [bitflag] = read one bit as boolean +
6         5) if ( [bitflag] is set ) then [high\_bits] = read five bits as unsigned integer +
7         6) vector [residue\_cascade] element [i] = [high\_bits] * 8 + [low\_bits]
8       }
9    7) done
+

Finally, we read in a list of book numbers, each corresponding to specific bit set in the cascade +bitmap. We loop over the possible codebook classifications and the maximum possible number of +encoding stages (8 in Vorbis I, as constrained by the elements of the cascade bitmap being eight +bits): +

+

1    1) iterate [i] over the range 0 ... [residue\_classifications]-1 {
2  
3         2) iterate [j] over the range 0 ... 7 { +
4  
5              3) if ( vector [residue\_cascade] element [i] bit [j] is set ) {
6   +
7                   4) array [residue\_books] element [i][j] = read 8 bits as unsigned integer
8  
9                 } else {
10   +
11                   5) array [residue\_books] element [i][j] = unused
12  
13                 }
14            }
15        }
16  
17    6) done
+

An end-of-packet condition at any point in header decode renders the stream undecodable. +In addition, any codebook number greater than the maximum numbered codebook +set up in this stream also renders the stream undecodable. All codebooks in array +[residue_books] are required to have a value mapping. The presence of codebook in array +[residue_books] without a value mapping (maptype equals zero) renders the stream +undecodable. +

+

8.6.2. packet decode
+

Format 0 and 1 packet decode is identical except for specific partition interleave. Format 2 packet +decode can be built out of the format 1 decode process. Thus we describe first the decode +infrastructure identical to all three formats. +

In addition to configuration information, the residue decode process is passed the number of +vectors in the submap bundle and a vector of flags indicating if any of the vectors are not to be +decoded. If the passed in number of vectors is 3 and vector number 1 is marked ’do not decode’, +decode skips vector 1 during the decode loop. However, even ’do not decode’ vectors are +allocated and zeroed. +

Depending on the values of [residue_begin] and [residue_end], it is obvious that the +encoded portion of a residue vector may be the entire possible residue vector or some other strict +subset of the actual residue vector size with zero padding at either uncoded end. However, it is + + + +also possible to set [residue_begin] and [residue_end] to specify a range partially or wholly +beyond the maximum vector size. Before beginning residue decode, limit [residue_begin] +and [residue_end] to the maximum possible vector size as follows. We assume that +the number of vectors being encoded, [ch] is provided by the higher level decoding +process. +

+

1    1) [actual\_size] = current blocksize/2;
2    2) if residue encoding is format 2 +
3         3) [actual\_size] = [actual\_size] * [ch];
4    4) [limit\_residue\_begin] = minimum of ([residue\_begin],[actual\_size]); +
5    5) [limit\_residue\_end] = minimum of ([residue\_end],[actual\_size]);
+

The following convenience values are conceptually useful to clarifying the decode process: +

+

1    1) [classwords\_per\_codeword] = [codebook\_dimensions] value of codebook [residue\_classbook] +
2    2) [n\_to\_read] = [limit\_residue\_end] - [limit\_residue\_begin]
3    3) [partitions\_to\_read] = [n\_to\_read] / [residue\_partition\_size]
+

Packet decode proceeds as follows, matching the description offered earlier in the document. +

1    1) allocate and zero all vectors that will be returned.
2    2) if ([n\_to\_read] is zero), stop; there is no residue to decode. +
3    3) iterate [pass] over the range 0 ... 7 {
4  
5         4) [partition\_count] = 0
6   +
7         5) while [partition\_count] is less than [partitions\_to\_read]
8  
9              6) if ([pass] is zero) {
10   +
11                   7) iterate [j] over the range 0 .. [ch]-1 {
12  
13                        8) if vector [j] is not marked ’do not decode’ { +
14  
15                             9) [temp] = read from packet using codebook [residue\_classbook] in scalar context +
16                            10) iterate [i] descending over the range [classwords\_per\_codeword]-1 ... 0 { +
17  
18                                 11) array [classifications] element [j],([i]+[partition\_count]) = +
19                                     [temp] integer modulo [residue\_classifications] +
20                                 12) [temp] = [temp] / [residue\_classifications] using integer division
21   +
22                                }
23  
24                           }
25  
26                      }
27  
28                 }
29   +
30             13) iterate [i] over the range 0 .. ([classwords\_per\_codeword] - 1) while [partition\_count] +
31                 is also less than [partitions\_to\_read] {
32  
33                   14) iterate [j] over the range 0 .. [ch]-1 { +
34  
35                        15) if vector [j] is not marked ’do not decode’ {
36   +
37                             16) [vqclass] = array [classifications] element [j],[partition\_count] +
38                             17) [vqbook] = array [residue\_books] element [vqclass],[pass]
39                             18) if ([vqbook] is not ’unused’) { +
40  
41                                  19) decode partition into output vector number [j], starting at scalar +
42                                      offset [limit\_residue\_begin]+[partition\_count]*[residue\_partition\_size] using +
43                                      codebook number [vqbook] in VQ context
44                            }
45                       } +
46  
47                   20) increment [partition\_count] by one
48  
49                 }
50            }
51       }
52  
53   21) done
54  
+

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. +

+

8.6.3. format 0 specifics
+

Format zero decodes partitions exactly as described earlier in the ’Residue Format: residue 0’ +section. The following pseudocode presents the same algorithm. Assume: + + + +

    +
  • [n] is the value in [residue_partition_size] +
    • +
  • [v] is the residue vector +
    • +
  • [offset] is the beginning read offset in [v]
+

+

1   1) [step] = [n] / [codebook\_dimensions]
2   2) iterate [i] over the range 0 ... [step]-1 {
3   +
4        3) vector [entry\_temp] = read vector from packet using current codebook in VQ context +
5        4) iterate [j] over the range 0 ... [codebook\_dimensions]-1 {
6  
7             5) vector [v] element ([offset]+[i]+[j]*[step]) = +
8           vector [v] element ([offset]+[i]+[j]*[step]) +
9                  vector [entry\_temp] element [j]
10  
11           }
12  
13      }
14  
15    6) done
16  
+

+

8.6.4. format 1 specifics
+

Format 1 decodes partitions exactly as described earlier in the ’Residue Format: residue 1’ +section. The following pseudocode presents the same algorithm. Assume: +

    +
  • [n] is the value in [residue_partition_size] +
    • +
  • [v] is the residue vector +
    • +
  • [offset] is the beginning read offset in [v]
+

+

1   1) [i] = 0
2   2) vector [entry\_temp] = read vector from packet using current codebook in VQ context +
3   3) iterate [j] over the range 0 ... [codebook\_dimensions]-1 {
4  
5        4) vector [v] element ([offset]+[i]) = +
6     vector [v] element ([offset]+[i]) +
7            vector [entry\_temp] element [j]
8        5) increment [i]
9   +
10      }
11  
12    6) if ( [i] is less than [n] ) continue at step 2
13    7) done
+

+

8.6.5. format 2 specifics
+ + + +

Format 2 is reducible to format 1. It may be implemented as an additional step prior to and an +additional post-decode step after a normal format 1 decode. +

Format 2 handles ’do not decode’ vectors differently than residue 0 or 1; if all vectors are marked +’do not decode’, no decode occurrs. However, if at least one vector is to be decoded, all +the vectors are decoded. We then request normal format 1 to decode a single vector +representing all output channels, rather than a vector for each channel. After decode, +deinterleave the vector into independent vectors, one for each output channel. That +is: +

+

+ 1.
If all vectors 0 through ch-1 are marked ’do not decode’, allocate and clear a single + vector [v]of length ch*n and skip step 2 below; proceed directly to the post-decode + step. +
+ 2.
Rather than performing format 1 decode to produce ch vectors of length n each, call + format 1 decode to produce a single vector [v] of length ch*n. +
+ 3.
Post decode: Deinterleave the single vector [v] returned by format 1 decode as + described above into ch independent vectors, one for each outputchannel, according + to: +
1    1) iterate [i] over the range 0 ... [n]-1 {
2  
3         2) iterate [j] over the range 0 ... [ch]-1 {
4   +
5              3) output vector number [j] element [i] = vector [v] element ([i] * [ch] + [j])
6  
7            }
8       }
9  
10    4) done
+
+ + + + + + +

9. Helper equations

+

+

9.1. Overview

+

The equations below are used in multiple places by the Vorbis codec specification. Rather than +cluttering up the main specification documents, they are defined here and referenced where +appropriate. +

+

9.2. Functions

+

+

9.2.1. ilog
+

The ”ilog(x)” function returns the position number (1 through n) of the highest set bit in the +two’s complement integer value [x]. Values of [x] less than zero are defined to return +zero. +

+

1    1) [return\_value] = 0;
2    2) if ( [x] is greater than zero ) {
3  
4         3) increment [return\_value]; +
5         4) logical shift [x] one bit to the right, padding the MSb with zero
6         5) repeat at step 2)
7  
8       }
9  
10     6) done
+

Examples: +

    +
  • ilog(0) = 0; +
    • +
  • ilog(1) = 1; + + + +
    • +
  • ilog(2) = 2; +
    • +
  • ilog(3) = 2; +
    • +
  • ilog(4) = 3; +
    • +
  • ilog(7) = 3; +
    • +
  • ilog(negative number) = 0;
+

+

9.2.2. float32_unpack
+

”float32_unpack(x)” is intended to translate the packed binary representation of a Vorbis +codebook float value into the representation used by the decoder for floating point numbers. For +purposes of this example, we will unpack a Vorbis float32 into a host-native floating point +number. +

+

1    1) [mantissa] = [x] bitwise AND 0x1fffff (unsigned result)
2    2) [sign] = [x] bitwise AND 0x80000000 (unsigned result) +
3    3) [exponent] = ( [x] bitwise AND 0x7fe00000) shifted right 21 bits (unsigned result) +
4    4) if ( [sign] is nonzero ) then negate [mantissa]
5    5) return [mantissa] * ( 2 ^ ( [exponent] - 788 ) )
+

+

9.2.3. lookup1_values
+

”lookup1_values(codebook_entries,codebook_dimensions)” is used to compute the +correct length of the value index for a codebook VQ lookup table of lookup type 1. +The values on this list are permuted to construct the VQ vector lookup table of size +[codebook_entries]. +

The return value for this function is defined to be ’the greatest integer value for which +[return_value] to the power of [codebook_dimensions] is less than or equal to +[codebook_entries]’. + + + +

+

9.2.4. low_neighbor
+

”low_neighbor(v,x)” finds the position n in vector [v] of the greatest value scalar element for +which n is less than [x] and vector [v] element n is less than vector [v] element +[x]. +

+

9.2.5. high_neighbor
+

”high_neighbor(v,x)” finds the position n in vector [v] of the lowest value scalar element for +which n is less than [x] and vector [v] element n is greater than vector [v] element +[x]. +

+

9.2.6. render_point
+

”render_point(x0,y0,x1,y1,X)” is used to find the Y value at point X along the line specified by +x0, x1, y0 and y1. This function uses an integer algorithm to solve for the point directly without +calculating intervening values along the line. +

+

1    1)  [dy] = [y1] - [y0]
2    2) [adx] = [x1] - [x0]
3    3) [ady] = absolute value of [dy]
4    4) [err] = [ady] * ([X] - [x0]) +
5    5) [off] = [err] / [adx] using integer division
6    6) if ( [dy] is less than zero ) {
7  
8         7) [Y] = [y0] - [off] +
9  
10       } else {
11  
12         8) [Y] = [y0] + [off]
13  
14       }
15  
16    9) done
+

+

9.2.7. render_line
+ + + +

Floor decode type one uses the integer line drawing algorithm of ”render_line(x0, y0, x1, y1, v)” +to construct an integer floor curve for contiguous piecewise line segments. Note that it has not +been relevant elsewhere, but here we must define integer division as rounding division of both +positive and negative numbers toward zero. +

+

1    1)   [dy] = [y1] - [y0]
2    2)  [adx] = [x1] - [x0]
3    3)  [ady] = absolute value of [dy]
4    4) [base] = [dy] / [adx] using integer division +
5    5)    [x] = [x0]
6    6)    [y] = [y0]
7    7)  [err] = 0
8  
9    8) if ( [dy] is less than 0 ) {
10  
11          9) [sy] = [base] - 1 +
12  
13       } else {
14  
15         10) [sy] = [base] + 1
16  
17       }
18  
19   11) [ady] = [ady] - (absolute value of [base]) * [adx] +
20   12) vector [v] element [x] = [y]
21  
22   13) iterate [x] over the range [x0]+1 ... [x1]-1 {
23  
24         14) [err] = [err] + [ady]; +
25         15) if ( [err] >= [adx] ) {
26  
27               16) [err] = [err] - [adx]
28               17)   [y] = [y] + [sy]
29   +
30             } else {
31  
32               18) [y] = [y] + [base]
33  
34             }
35  
36         19) vector [v] element [x] = [y]
37  
38       }
+ + + + + + +

10. Tables

+

+

10.1. floor1_inverse_dB_table

+

The vector [floor1_inverse_dB_table] is a 256 element static lookup table consisting of the +following values (read left to right then top to bottom): +

+

1    1.0649863e-07, 1.1341951e-07, 1.2079015e-07, 1.2863978e-07,
2    1.3699951e-07, 1.4590251e-07, 1.5538408e-07, 1.6548181e-07, +
3    1.7623575e-07, 1.8768855e-07, 1.9988561e-07, 2.1287530e-07,
4    2.2670913e-07, 2.4144197e-07, 2.5713223e-07, 2.7384213e-07, +
5    2.9163793e-07, 3.1059021e-07, 3.3077411e-07, 3.5226968e-07,
6    3.7516214e-07, 3.9954229e-07, 4.2550680e-07, 4.5315863e-07, +
7    4.8260743e-07, 5.1396998e-07, 5.4737065e-07, 5.8294187e-07,
8    6.2082472e-07, 6.6116941e-07, 7.0413592e-07, 7.4989464e-07, +
9    7.9862701e-07, 8.5052630e-07, 9.0579828e-07, 9.6466216e-07,
10    1.0273513e-06, 1.0941144e-06, 1.1652161e-06, 1.2409384e-06, +
11    1.3215816e-06, 1.4074654e-06, 1.4989305e-06, 1.5963394e-06,
12    1.7000785e-06, 1.8105592e-06, 1.9282195e-06, 2.0535261e-06, +
13    2.1869758e-06, 2.3290978e-06, 2.4804557e-06, 2.6416497e-06,
14    2.8133190e-06, 2.9961443e-06, 3.1908506e-06, 3.3982101e-06, +
15    3.6190449e-06, 3.8542308e-06, 4.1047004e-06, 4.3714470e-06,
16    4.6555282e-06, 4.9580707e-06, 5.2802740e-06, 5.6234160e-06, +
17    5.9888572e-06, 6.3780469e-06, 6.7925283e-06, 7.2339451e-06,
18    7.7040476e-06, 8.2047000e-06, 8.7378876e-06, 9.3057248e-06, +
19    9.9104632e-06, 1.0554501e-05, 1.1240392e-05, 1.1970856e-05,
20    1.2748789e-05, 1.3577278e-05, 1.4459606e-05, 1.5399272e-05, +
21    1.6400004e-05, 1.7465768e-05, 1.8600792e-05, 1.9809576e-05,
22    2.1096914e-05, 2.2467911e-05, 2.3928002e-05, 2.5482978e-05, +
23    2.7139006e-05, 2.8902651e-05, 3.0780908e-05, 3.2781225e-05,
24    3.4911534e-05, 3.7180282e-05, 3.9596466e-05, 4.2169667e-05, +
25    4.4910090e-05, 4.7828601e-05, 5.0936773e-05, 5.4246931e-05,
26    5.7772202e-05, 6.1526565e-05, 6.5524908e-05, 6.9783085e-05, +
27    7.4317983e-05, 7.9147585e-05, 8.4291040e-05, 8.9768747e-05,
28    9.5602426e-05, 0.00010181521, 0.00010843174, 0.00011547824, +
29    0.00012298267, 0.00013097477, 0.00013948625, 0.00014855085,
30    0.00015820453, 0.00016848555, 0.00017943469, 0.00019109536, +
31    0.00020351382, 0.00021673929, 0.00023082423, 0.00024582449,
32    0.00026179955, 0.00027881276, 0.00029693158, 0.00031622787, +
33    0.00033677814, 0.00035866388, 0.00038197188, 0.00040679456,
34    0.00043323036, 0.00046138411, 0.00049136745, 0.00052329927, +
35    0.00055730621, 0.00059352311, 0.00063209358, 0.00067317058,
36    0.00071691700, 0.00076350630, 0.00081312324, 0.00086596457, +
37    0.00092223983, 0.00098217216, 0.0010459992,  0.0011139742,
38    0.0011863665,  0.0012634633,  0.0013455702,  0.0014330129, +
39    0.0015261382,  0.0016253153,  0.0017309374,  0.0018434235,
40    0.0019632195,  0.0020908006,  0.0022266726,  0.0023713743, +
41    0.0025254795,  0.0026895994,  0.0028643847,  0.0030505286,
42    0.0032487691,  0.0034598925,  0.0036847358,  0.0039241906, +
43    0.0041792066,  0.0044507950,  0.0047400328,  0.0050480668,
44    0.0053761186,  0.0057254891,  0.0060975636,  0.0064938176, +
45    0.0069158225,  0.0073652516,  0.0078438871,  0.0083536271,
46    0.0088964928,  0.009474637,   0.010090352,   0.010746080, +
47    0.011444421,   0.012188144,   0.012980198,   0.013823725,
48    0.014722068,   0.015678791,   0.016697687,   0.017782797, +
49    0.018938423,   0.020169149,   0.021479854,   0.022875735,
50    0.024362330,   0.025945531,   0.027631618,   0.029427276, +
51    0.031339626,   0.033376252,   0.035545228,   0.037855157,
52    0.040315199,   0.042935108,   0.045725273,   0.048696758, +
53    0.051861348,   0.055231591,   0.058820850,   0.062643361,
54    0.066714279,   0.071049749,   0.075666962,   0.080584227, +
55    0.085821044,   0.091398179,   0.097337747,   0.10366330,
56    0.11039993,    0.11757434,    0.12521498,    0.13335215, +
57    0.14201813,    0.15124727,    0.16107617,    0.17154380,
58    0.18269168,    0.19456402,    0.20720788,    0.22067342, +
59    0.23501402,    0.25028656,    0.26655159,    0.28387361,
60    0.30232132,    0.32196786,    0.34289114,    0.36517414, +
61    0.38890521,    0.41417847,    0.44109412,    0.46975890,
62    0.50028648,    0.53279791,    0.56742212,    0.60429640, +
63    0.64356699,    0.68538959,    0.72993007,    0.77736504,
64    0.82788260,    0.88168307,    0.9389798,     1.
+ + + + + + +

A. Embedding Vorbis into an Ogg stream

+

+

A.1. Overview

+

This document describes using Ogg logical and physical transport streams to encapsulate Vorbis +compressed audio packet data into file form. +

The section 1, “Introduction and Description” provides an overview of the construction of Vorbis +audio packets. +

The Ogg bitstream overview and Ogg logical bitstream and framing spec provide detailed +descriptions of Ogg transport streams. This specification document assumes a working +knowledge of the concepts covered in these named backround documents. Please read them +first. +

+

A.1.1. Restrictions
+

The Ogg/Vorbis I specification currently dictates that Ogg/Vorbis streams use Ogg transport +streams in degenerate, unmultiplexed form only. That is: +

    +
  • A meta-headerless Ogg file encapsulates the Vorbis I packets +
    • +
  • The Ogg stream may be chained, i.e., contain multiple, contigous logical streams + (links). +
    • +
  • The Ogg stream must be unmultiplexed (only one stream, a Vorbis audio stream, + per link) +
+ + + +

This is not to say that it is not currently possible to multiplex Vorbis with other media +types into a multi-stream Ogg file. At the time this document was written, Ogg was +becoming a popular container for low-bitrate movies consisting of DivX video and Vorbis +audio. However, a ’Vorbis I audio file’ is taken to imply Vorbis audio existing alone +within a degenerate Ogg stream. A compliant ’Vorbis audio player’ is not required to +implement Ogg support beyond the specific support of Vorbis within a degenrate Ogg +stream (naturally, application authors are encouraged to support full multiplexed Ogg +handling). +

+

A.1.2. MIME type
+

The MIME type of Ogg files depend on the context. Specifically, complex multimedia and +applications should use application/ogg, while visual media should use video/ogg, and audio +audio/ogg. Vorbis data encapsulated in Ogg may appear in any of those types. RTP +encapsulated Vorbis should use audio/vorbis + audio/vorbis-config. +

+

A.2. Encapsulation

+

Ogg encapsulation of a Vorbis packet stream is straightforward. +

    +
  • The first Vorbis packet (the identification header), which uniquely identifies a stream + as Vorbis audio, is placed alone in the first page of the logical Ogg stream. This + results in a first Ogg page of exactly 58 bytes at the very beginning of the logical + stream. +
    • +
  • This first page is marked ’beginning of stream’ in the page flags. +
    • +
  • The second and third vorbis packets (comment and setup headers) may span one or + more pages beginning on the second page of the logical stream. However many pages + they span, the third header packet finishes the page on which it ends. The next (first + audio) packet must begin on a fresh page. + + + +
    • +
  • The granule position of these first pages containing only headers is zero. +
    • +
  • The first audio packet of the logical stream begins a fresh Ogg page. +
    • +
  • Packets are placed into ogg pages in order until the end of stream. +
    • +
  • The last page is marked ’end of stream’ in the page flags. +
    • +
  • Vorbis packets may span page boundaries. +
    • +
  • The granule position of pages containing Vorbis audio is in units of PCM audio + samples (per channel; a stereo stream’s granule position does not increment at twice + the speed of a mono stream). +
    • +
  • The granule position of a page represents the end PCM sample position of the last + packet completed on that page. The ’last PCM sample’ is the last complete sample + returned by decode, not an internal sample awaiting lapping with a subsequent block. + A page that is entirely spanned by a single packet (that completes on a subsequent + page) has no granule position, and the granule position is set to ’-1’. +

    Note that the last decoded (fully lapped) PCM sample from a packet is not + necessarily the middle sample from that block. If, eg, the current Vorbis packet + encodes a ”long block” and the next Vorbis packet encodes a ”short block”, the last + decodable sample from the current packet be at position (3*long_block_length/4) - + (short_block_length/4). +

    • +
  • The granule (PCM) position of the first page need not indicate that the stream + started at position zero. Although the granule position belongs to the last completed + packet on the page and a valid granule position must be positive, by inference it may + indicate that the PCM position of the beginning of audio is positive or negative. +
      +
    • A positive starting value simply indicates that this stream begins at some + positive time offset, potentially within a larger program. This is a common case + when connecting to the middle of broadcast stream. +
      • +
    • A negative value indicates that output samples preceeding time zero should be + + + + discarded during decoding; this technique is used to allow sample-granularity + editing of the stream start time of already-encoded Vorbis streams. The number + of samples to be discarded must not exceed the overlap-add span of the first two + audio packets. +
    +

    In both of these cases in which the initial audio PCM starting offset is nonzero, the + second finished audio packet must flush the page on which it appears and the + third packet begin a fresh page. This allows the decoder to always be able to + perform PCM position adjustments before needing to return any PCM data from + synthesis, resulting in correct positioning information without any aditional seeking + logic. +

    Note: Failure to do so should, at worst, cause a decoder implementation to return + incorrect positioning information for seeking operations at the very beginning of the + stream. +

    • +
  • A granule position on the final page in a stream that indicates less audio data than the + final packet would normally return is used to end the stream on other than even frame + boundaries. The difference between the actual available data returned and the + declared amount indicates how many trailing samples to discard from the decoding + process. +
+ + + +

B. Vorbis encapsulation in RTP

+

Please consult RFC 5215 “RTP Payload Format for Vorbis Encoded Audio” for description of +how to embed Vorbis audio in an RTP stream. + + + + + + +

Colophon

+

PIC +

Ogg is a Xiph.Org Foundation effort to protect essential tenets of Internet multimedia from +corporate hostage-taking; Open Source is the net’s greatest tool to keep everyone honest. See +About the Xiph.Org Foundation for details. +

Ogg Vorbis is the first Ogg audio CODEC. Anyone may freely use and distribute the Ogg and +Vorbis specification, whether in a private, public or corporate capacity. However, the Xiph.Org +Foundation and the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis specification +and certify specification compliance. +

Xiph.Org’s Vorbis software CODEC implementation is distributed under a BSD-like license. This +does not restrict third parties from distributing independent implementations of Vorbis software +under other licenses. +

Ogg, Vorbis, Xiph.Org Foundation and their logos are trademarks (tm) of the Xiph.Org +Foundation. These pages are copyright (C) 1994-2015 Xiph.Org Foundation. All rights +reserved. +

This document is set using LATEX. + + + +

References

+

+

+

+ [1]   T. Sporer, K. Brandenburg and + B. Edler, The use of multirate filter banks for coding of high quality digital audio, + http://www.iocon.com/resource/docs/ps/eusipco_corrected.ps. +

+
+ + + + + + diff --git a/doc/Vorbis_I_spec.pdf b/doc/Vorbis_I_spec.pdf new file mode 100644 index 0000000..04c0682 Binary files /dev/null and b/doc/Vorbis_I_spec.pdf differ diff --git a/doc/Vorbis_I_spec.tex b/doc/Vorbis_I_spec.tex new file mode 100644 index 0000000..23bc81d --- /dev/null +++ b/doc/Vorbis_I_spec.tex @@ -0,0 +1,141 @@ +\documentclass[12pt,paper=a4]{scrartcl} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Packages +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +% ... +%\usepackage[margin=3cm]{geometry} +\usepackage{a4wide} + +% ... +\usepackage[english]{babel} + +%\usepackage[latin1]{inputenc} +%\usepackage[T1]{fontenc} + +% Do not indent paragraphs, instead separate them via vertical spacing +\usepackage{parskip} + +% Support for graphics, provides \includegraphics +\usepackage{graphicx} +%\graphicspath{{images/}} % Specify subdir containing the images + +% Hyperref enriches the generated PDF with clickable links, +% and provides many other useful features. +\usepackage{nameref} +\usepackage[colorlinks]{hyperref} +\def\sectionautorefname{Section} % Write section with capital 'S' +\def\subsectionautorefname{Subsection} % Write subsection with capital 'S' + + +% The fancyvrb package provides the "Verbatim" environment, which, +% unlike the built-in "verbatim", allows embedding TeX commands, as +% well as tons of other neat stuff (line numbers, formatting adjustments, ...) +\usepackage{fancyvrb} +\fvset{tabsize=4,fontsize=\scriptsize,numbers=left} + +% Normally, one can not use the underscore character in LaTeX without +% escaping it (\_ instead of _). Since the Vorbis specs use it a lot, +% we use the underscore package to change this default behavior. +\usepackage[nohyphen]{underscore} + +\usepackage{enumitem} + +% In LaTeX, pictures are normally put into floating environments, and it is +% left to the typesetting engine to place them in the "optimal" spot. These +% docs however expect pictures to be placed in a *specific* position. So we +% don't use \begin{figure}...\end{figure}, but rather a center environment. +% To still be able to use captions, we use the capt-of package. +\usepackage{capt-of} + +% strikeout support +\usepackage[normalem]{ulem} + +% blockquote support +\usepackage{csquotes} + +% allow 'special' characters in filenames, like undescore :-P +\usepackage{grffile} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Custom commands +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +% Custom ref command, using hyperrefs autoref & nameref, to simulate the +% behavior of DocBook's ''. +\newcommand{\xref}[1]{\autoref{#1}, ``\nameref{#1}''} + +% Emulat DocBook's ''. +\newcommand{\link}[2]{\hyperref[#1]{#2}} + +% Simple 'Note' environment. Can be customized later on. +\newenvironment{note}{\subparagraph*{Note:}}{} + +% Map DocBook's to fancyvrb's Verbatim environment +\let\programlisting\Verbatim +\let\endprogramlisting\endVerbatim + +% Fake some more DocBook elements +\newcommand{\function}[1]{\texttt{#1}} +\newcommand{\filename}[1]{\texttt{#1}} +\newcommand{\varname}[1]{\texttt{#1}} +\newcommand{\literal}[1]{\texttt{#1}} + +% Redefine \~ to generate something that looks more appropriate when used in text. +\renewcommand{\~}{$\sim$} + +% Useful helper macro that inserts TODO comments very visibly into the generated +% file. Helps you to not forget to resolve those TODOs... :) +\newcommand{\TODO}[1]{\textcolor{red}{*** #1 ***}} + +% Configure graphics formats: Prefer PDF, fall back to PNG or JPG, as available. +\DeclareGraphicsExtensions{.pdf,.png,.jpg,.jpeg} + + +% NOTE: Things to watch out for: Some chars are reserved in LaTeX. You need to translate them... +% ~ -> $\sim$ (or \~ which we defined above) +% % -> \% +% & -> \& +% < -> $<$ +% > -> $>$ +% and others. Refer to any of the many LaTeX refs out there if in doubt! + +\begin{document} + + +\title{Vorbis I specification} +\author{Xiph.Org Foundation} +\maketitle + +\tableofcontents + +\include{01-introduction} +\include{02-bitpacking} +\include{03-codebook} +\include{04-codec} +\include{05-comment} +\include{06-floor0} +\include{07-floor1} +\include{08-residue} +\include{09-helper} +\include{10-tables} + +\appendix +\include{a1-encapsulation-ogg} +\include{a2-encapsulation-rtp} + +\include{footer} + + +% TODO: Use a bibliography, as in the example below? +\begin{thebibliography}{99} + +\bibitem{Sporer/Brandenburg/Edler} T.~Sporer, K.~Brandenburg and B.~Edler, +The use of multirate filter banks for coding of high quality digital audio, +\url{http://www.iocon.com/resource/docs/ps/eusipco_corrected.ps}. + + +\end{thebibliography} + +\end{document} diff --git a/doc/Vorbis_I_spec0x.png b/doc/Vorbis_I_spec0x.png new file mode 100644 index 0000000..f6d2967 Binary files /dev/null and b/doc/Vorbis_I_spec0x.png differ diff --git a/doc/Vorbis_I_spec10x.png b/doc/Vorbis_I_spec10x.png new file mode 100644 index 0000000..086e429 Binary files /dev/null and b/doc/Vorbis_I_spec10x.png differ diff --git a/doc/Vorbis_I_spec11x.png b/doc/Vorbis_I_spec11x.png new file mode 100644 index 0000000..610e28c Binary files /dev/null and b/doc/Vorbis_I_spec11x.png differ diff --git a/doc/Vorbis_I_spec12x.png b/doc/Vorbis_I_spec12x.png new file mode 100644 index 0000000..f4f477a Binary files /dev/null and b/doc/Vorbis_I_spec12x.png differ diff --git a/doc/Vorbis_I_spec13x.png b/doc/Vorbis_I_spec13x.png new file mode 100644 index 0000000..803dd55 Binary files /dev/null and b/doc/Vorbis_I_spec13x.png differ diff --git a/doc/Vorbis_I_spec14x.png b/doc/Vorbis_I_spec14x.png new file mode 100644 index 0000000..211774f Binary files /dev/null and b/doc/Vorbis_I_spec14x.png differ diff --git a/doc/Vorbis_I_spec1x.png b/doc/Vorbis_I_spec1x.png new file mode 100644 index 0000000..0d4975a Binary files /dev/null and b/doc/Vorbis_I_spec1x.png differ diff --git a/doc/Vorbis_I_spec2x.png b/doc/Vorbis_I_spec2x.png new file mode 100644 index 0000000..8108800 Binary files /dev/null and b/doc/Vorbis_I_spec2x.png differ diff --git a/doc/Vorbis_I_spec3x.png b/doc/Vorbis_I_spec3x.png new file mode 100644 index 0000000..dabd209 Binary files /dev/null and b/doc/Vorbis_I_spec3x.png differ diff --git a/doc/Vorbis_I_spec4x.png b/doc/Vorbis_I_spec4x.png new file mode 100644 index 0000000..00544e4 Binary files /dev/null and b/doc/Vorbis_I_spec4x.png differ diff --git a/doc/Vorbis_I_spec5x.png b/doc/Vorbis_I_spec5x.png new file mode 100644 index 0000000..a723708 Binary files /dev/null and b/doc/Vorbis_I_spec5x.png differ diff --git a/doc/Vorbis_I_spec6x.png b/doc/Vorbis_I_spec6x.png new file mode 100644 index 0000000..9c7e2f7 Binary files /dev/null and b/doc/Vorbis_I_spec6x.png differ diff --git a/doc/Vorbis_I_spec7x.png b/doc/Vorbis_I_spec7x.png new file mode 100644 index 0000000..373e004 Binary files /dev/null and b/doc/Vorbis_I_spec7x.png differ diff --git a/doc/Vorbis_I_spec8x.png b/doc/Vorbis_I_spec8x.png new file mode 100644 index 0000000..370963d Binary files /dev/null and b/doc/Vorbis_I_spec8x.png differ diff --git a/doc/Vorbis_I_spec9x.png b/doc/Vorbis_I_spec9x.png new file mode 100644 index 0000000..145100b Binary files /dev/null and b/doc/Vorbis_I_spec9x.png differ diff --git a/doc/a1-encapsulation-ogg.tex b/doc/a1-encapsulation-ogg.tex new file mode 100644 index 0000000..8bbd31b --- /dev/null +++ b/doc/a1-encapsulation-ogg.tex @@ -0,0 +1,184 @@ +% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*- +%!TEX root = Vorbis_I_spec.tex +\section{Embedding Vorbis into an Ogg stream} \label{vorbis:over:ogg} + +\subsection{Overview} + +This document describes using Ogg logical and physical transport +streams to encapsulate Vorbis compressed audio packet data into file +form. + +The \xref{vorbis:spec:intro} provides an overview of the construction +of Vorbis audio packets. + +The \href{oggstream.html}{Ogg +bitstream overview} and \href{framing.html}{Ogg logical +bitstream and framing spec} provide detailed descriptions of Ogg +transport streams. This specification document assumes a working +knowledge of the concepts covered in these named backround +documents. Please read them first. + +\subsubsection{Restrictions} + +The Ogg/Vorbis I specification currently dictates that Ogg/Vorbis +streams use Ogg transport streams in degenerate, unmultiplexed +form only. That is: + +\begin{itemize} + \item + A meta-headerless Ogg file encapsulates the Vorbis I packets + + \item + The Ogg stream may be chained, i.e., contain multiple, contigous logical streams (links). + + \item + The Ogg stream must be unmultiplexed (only one stream, a Vorbis audio stream, per link) + +\end{itemize} + + +This is not to say that it is not currently possible to multiplex +Vorbis with other media types into a multi-stream Ogg file. At the +time this document was written, Ogg was becoming a popular container +for low-bitrate movies consisting of DivX video and Vorbis audio. +However, a 'Vorbis I audio file' is taken to imply Vorbis audio +existing alone within a degenerate Ogg stream. A compliant 'Vorbis +audio player' is not required to implement Ogg support beyond the +specific support of Vorbis within a degenrate Ogg stream (naturally, +application authors are encouraged to support full multiplexed Ogg +handling). + + + + +\subsubsection{MIME type} + +The MIME type of Ogg files depend on the context. Specifically, complex +multimedia and applications should use \literal{application/ogg}, +while visual media should use \literal{video/ogg}, and audio +\literal{audio/ogg}. Vorbis data encapsulated in Ogg may appear +in any of those types. RTP encapsulated Vorbis should use +\literal{audio/vorbis} + \literal{audio/vorbis-config}. + + +\subsection{Encapsulation} + +Ogg encapsulation of a Vorbis packet stream is straightforward. + +\begin{itemize} + +\item + The first Vorbis packet (the identification header), which + uniquely identifies a stream as Vorbis audio, is placed alone in the + first page of the logical Ogg stream. This results in a first Ogg + page of exactly 58 bytes at the very beginning of the logical stream. + + +\item + This first page is marked 'beginning of stream' in the page flags. + + +\item + The second and third vorbis packets (comment and setup + headers) may span one or more pages beginning on the second page of + the logical stream. However many pages they span, the third header + packet finishes the page on which it ends. The next (first audio) packet + must begin on a fresh page. + + +\item + The granule position of these first pages containing only headers is zero. + + +\item + The first audio packet of the logical stream begins a fresh Ogg page. + + +\item + Packets are placed into ogg pages in order until the end of stream. + + +\item + The last page is marked 'end of stream' in the page flags. + + +\item + Vorbis packets may span page boundaries. + + +\item + The granule position of pages containing Vorbis audio is in units + of PCM audio samples (per channel; a stereo stream's granule position + does not increment at twice the speed of a mono stream). + + +\item + The granule position of a page represents the end PCM sample + position of the last packet \emph{completed} on that + page. The 'last PCM sample' is the last complete sample returned by + decode, not an internal sample awaiting lapping with a + subsequent block. A page that is entirely spanned by a single + packet (that completes on a subsequent page) has no granule + position, and the granule position is set to '-1'. + + + Note that the last decoded (fully lapped) PCM sample from a packet + is not necessarily the middle sample from that block. If, eg, the + current Vorbis packet encodes a "long block" and the next Vorbis + packet encodes a "short block", the last decodable sample from the + current packet be at position (3*long\_block\_length/4) - + (short\_block\_length/4). + + +\item + The granule (PCM) position of the first page need not indicate + that the stream started at position zero. Although the granule + position belongs to the last completed packet on the page and a + valid granule position must be positive, by + inference it may indicate that the PCM position of the beginning + of audio is positive or negative. + + + \begin{itemize} + \item + A positive starting value simply indicates that this stream begins at + some positive time offset, potentially within a larger + program. This is a common case when connecting to the middle + of broadcast stream. + + \item + A negative value indicates that + output samples preceeding time zero should be discarded during + decoding; this technique is used to allow sample-granularity + editing of the stream start time of already-encoded Vorbis + streams. The number of samples to be discarded must not exceed + the overlap-add span of the first two audio packets. + + \end{itemize} + + + In both of these cases in which the initial audio PCM starting + offset is nonzero, the second finished audio packet must flush the + page on which it appears and the third packet begin a fresh page. + This allows the decoder to always be able to perform PCM position + adjustments before needing to return any PCM data from synthesis, + resulting in correct positioning information without any aditional + seeking logic. + + + \begin{note} + Failure to do so should, at worst, cause a + decoder implementation to return incorrect positioning information + for seeking operations at the very beginning of the stream. + \end{note} + + +\item + A granule position on the final page in a stream that indicates + less audio data than the final packet would normally return is used to + end the stream on other than even frame boundaries. The difference + between the actual available data returned and the declared amount + indicates how many trailing samples to discard from the decoding + process. + +\end{itemize} diff --git a/doc/a2-encapsulation-rtp.tex b/doc/a2-encapsulation-rtp.tex new file mode 100644 index 0000000..35a93c6 --- /dev/null +++ b/doc/a2-encapsulation-rtp.tex @@ -0,0 +1,8 @@ +% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*- +%!TEX root = Vorbis_I_spec.tex +\section{Vorbis encapsulation in RTP} \label{vorbis:over:rtp} + +% TODO: Include draft-rtp.xml somehow? + +Please consult RFC 5215 \textit{``RTP Payload Format for Vorbis Encoded + Audio''} for description of how to embed Vorbis audio in an RTP stream. diff --git a/doc/components.png b/doc/components.png new file mode 100644 index 0000000..0c4e75c Binary files /dev/null and b/doc/components.png differ diff --git a/doc/eightphase.png b/doc/eightphase.png new file mode 100644 index 0000000..8272e44 Binary files /dev/null and b/doc/eightphase.png differ diff --git a/doc/fish_xiph_org.png b/doc/fish_xiph_org.png new file mode 100644 index 0000000..dc64a03 Binary files /dev/null and b/doc/fish_xiph_org.png differ diff --git a/doc/floor1-1.png b/doc/floor1-1.png new file mode 100644 index 0000000..bd7faba Binary files /dev/null and b/doc/floor1-1.png differ diff --git a/doc/floor1-2.png b/doc/floor1-2.png new file mode 100644 index 0000000..46f0ac2 Binary files /dev/null and b/doc/floor1-2.png differ diff --git a/doc/floor1-3.png b/doc/floor1-3.png new file mode 100644 index 0000000..4d03c6a Binary files /dev/null and b/doc/floor1-3.png differ diff --git a/doc/floor1-4.png b/doc/floor1-4.png new file mode 100644 index 0000000..f96e77d Binary files /dev/null and b/doc/floor1-4.png differ diff --git a/doc/floor1_inverse_dB_table.html b/doc/floor1_inverse_dB_table.html new file mode 100644 index 0000000..99ad4b8 --- /dev/null +++ b/doc/floor1_inverse_dB_table.html @@ -0,0 +1,154 @@ + + + + + +Ogg Vorbis Documentation + + + + + + + + + +

Ogg Vorbis I format specification: floor1_inverse_dB_table

+ +

The vector [floor1_inverse_dB_table] is a 256 element static +lookup table consiting of the following values (read left to right +then top to bottom):

+ +
+  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.
+
+ + + + + diff --git a/doc/floorval.png b/doc/floorval.png new file mode 100644 index 0000000..49d6ec1 Binary files /dev/null and b/doc/floorval.png differ diff --git a/doc/footer.tex b/doc/footer.tex new file mode 100644 index 0000000..ffb2c81 --- /dev/null +++ b/doc/footer.tex @@ -0,0 +1,31 @@ +% -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*- +%!TEX root = Vorbis_I_spec.tex +\section*{Colophon} + +\includegraphics[width=5cm]{fish_xiph_org} +\label{footer} + +Ogg is a \href{http://www.xiph.org/}{Xiph.Org Foundation} effort +to protect essential tenets of Internet multimedia from corporate +hostage-taking; Open Source is the net's greatest tool to keep +everyone honest. See \href{http://www.xiph.org/about.html}{About +the Xiph.Org Foundation} for details. + + +Ogg Vorbis is the first Ogg audio CODEC. Anyone may freely use and +distribute the Ogg and Vorbis specification, whether in a private, +public or corporate capacity. However, the Xiph.Org Foundation and +the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis +specification and certify specification compliance. + +Xiph.Org's Vorbis software CODEC implementation is distributed under a +BSD-like license. This does not restrict third parties from +distributing independent implementations of Vorbis software under +other licenses. + +Ogg, Vorbis, Xiph.Org Foundation and their logos are trademarks (tm) +of the \href{http://www.xiph.org/}{Xiph.Org Foundation}. These +pages are copyright (C) 1994-2015 Xiph.Org Foundation. All rights +reserved. + +This document is set using \LaTeX. diff --git a/doc/fourphase.png b/doc/fourphase.png new file mode 100644 index 0000000..a86e128 Binary files /dev/null and b/doc/fourphase.png differ diff --git a/doc/framing.html b/doc/framing.html new file mode 100644 index 0000000..857b292 --- /dev/null +++ b/doc/framing.html @@ -0,0 +1,431 @@ + + + + + +Ogg Vorbis Documentation + + + + + + + + + +

Ogg logical bitstream framing

+ +

Ogg bitstreams

+ +

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.

+ +

Application example: Vorbis

+ +

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.

+ +

Design constraints for Ogg bitstreams

+ +
    +
  1. True streaming; we must not need to seek to build a 100% + complete bitstream.
    2. +
  2. Use no more than approximately 1-2% of bitstream bandwidth for + packet boundary marking, high-level framing, sync and seeking.
    3. +
  3. Specification of absolute position within the original sample + stream.
    4. +
  4. Simple mechanism to ease limited editing, such as a simplified + concatenation mechanism.
    5. +
  5. Detection of corruption, recapture after error and direct, random + access to data at arbitrary positions in the bitstream.
    6. +
+ +

Logical and Physical Bitstreams

+ +

A logical Ogg bitstream is a contiguous stream of +sequential pages belonging only to the logical bitstream. A +physical 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 +Ogg bitstream overview. The exact +mapping of raw Vorbis packets into a valid Ogg Vorbis physical +bitstream is described in the Vorbis I Specification.

+ +

Bitstream structure

+ +

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.

+ +

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.

+ +

Packet segmentation

+ +

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.

+ +

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.

+ +

An example should make the basic concept clear:

+ +
+
+raw packet:
+  ___________________________________________
+ |______________packet data__________________| 753 bytes
+
+lacing values for page header segment table: 255,255,243
+
+
+ +

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.

+ +

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:

+ +

+raw packet:
+  _______________________________
+ |________packet data____________|          255 bytes
+
+lacing values: 255, 0
+
+ +

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.

+ +

Packets spanning pages

+ +

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).

+ +

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).

+ +

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.

+ +

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.

+ +

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).

+ +

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.

+ +

Page header

+ +

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.

+ +

capture_pattern

+ +

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).

+ +

+ byte value
+
+  0  0x4f 'O'
+  1  0x67 'g'
+  2  0x67 'g'
+  3  0x53 'S'  
+
+ +

stream_structure_version

+ +

The capture pattern is followed by the stream structure revision:

+ +

+ byte value
+
+  4  0x00
+
+ +

header_type_flag

+ +

The header type flag identifies this page's context in the bitstream:

+ +

+ 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)
+
+ +

absolute granule position

+ +

(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.

+ +

A special value of '-1' (in two's complement) indicates that no packets +finish on this page.

+ +

+ byte value
+
+  6  0xXX LSB
+  7  0xXX
+  8  0xXX
+  9  0xXX
+ 10  0xXX
+ 11  0xXX
+ 12  0xXX
+ 13  0xXX MSB
+
+ +

stream serial number

+ +

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:

+ +

+ byte value
+
+ 14  0xXX LSB
+ 15  0xXX
+ 16  0xXX
+ 17  0xXX MSB
+
+ +

page sequence no

+ +

Page counter; lets us know if a page is lost (useful where packets +span page boundaries).

+ +

+ byte value
+
+ 18  0xXX LSB
+ 19  0xXX
+ 20  0xXX
+ 21  0xXX MSB
+
+ +

page checksum

+ +

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.

+ +

(A thorough discussion of CRC algorithms can be found in "A +Painless Guide to CRC Error Detection Algorithms" by Ross +Williams ross@ross.net.)

+ +

+ byte value
+
+ 22  0xXX LSB
+ 23  0xXX
+ 24  0xXX
+ 25  0xXX MSB
+
+ +

page_segments

+ +

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).

+ +

+ byte value
+
+ 26 0x00-0xff (0-255)
+
+ +

segment_table (containing packet lacing values)

+ +

The lacing values for each packet segment physically appearing in +this page are listed in contiguous order.

+ +

+ byte value
+
+ 27 0x00-0xff (0-255)
+ [...]
+ n  0x00-0xff (0-255, n=page_segments+26)
+
+ +

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.

+ +

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.

+ + + + + diff --git a/doc/helper.html b/doc/helper.html new file mode 100644 index 0000000..a16df28 --- /dev/null +++ b/doc/helper.html @@ -0,0 +1,239 @@ + + + + + +Ogg Vorbis Documentation + + + + + + + + + +

Ogg Vorbis I format specification: helper equations

+ +

Overview

+ +

The equations below are used in multiple places by the Vorbis codec +specification. Rather than cluttering up the main specification +documents, they are defined here and linked in the main documents +where appropriate.

+ +

ilog

+ +

The "ilog(x)" function returns the position number (1 through n) of the +highest set bit in the two's complement integer value +[x]. Values of [x] less than zero are defined to return zero.

+ +
+  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
+
+ +

Examples:

+ +
    +
  • ilog(0) = 0;
    • +
  • ilog(1) = 1;
    • +
  • ilog(2) = 2;
    • +
  • ilog(3) = 2;
    • +
  • ilog(4) = 3;
    • +
  • ilog(7) = 3;
    • +
  • ilog(negative number) = 0;
    • +
+ +

float32_unpack

+ +

"float32_unpack(x)" is intended to translate the packed binary +representation of a Vorbis codebook float value into the +representation used by the decoder for floating point numbers. For +purposes of this example, we will unpack a Vorbis float32 into a +host-native floating point number.

+ +
+  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 ) )
+
+ +

lookup1_values

+ +

"lookup1_values(codebook_entries,codebook_dimensions)" is used to +compute the correct length of the value index for a codebook VQ lookup +table of lookup type 1. The values on this list are permuted to +construct the VQ vector lookup table of size +[codebook_entries].

+ +

The return value for this function is defined to be 'the greatest +integer value for which [return_value] to the power of +[codebook_dimensions] is less than or equal to +[codebook_entries]'.

+ +

low_neighbor

+ +

"low_neighbor(v,x)" finds the position n in vector [v] of +the greatest value scalar element for which n is less than +[x] and vector [v] element n is less +than vector [v] element [x].

+ +

high_neighbor

+ +

"high_neighbor(v,x)" finds the position n in vector [v] of +the lowest value scalar element for which n is less than +[x] and vector [v] element n is greater +than vector [v] element [x].

+ +

render_point

+ +

"render_point(x0,y0,x1,y1,X)" is used to find the Y value at point X +along the line specified by x0, x1, y0 and y1. This function uses an +integer algorithm to solve for the point directly without calculating +intervening values along the line.

+ +
+  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
+
+ +

render_line

+ +

Floor decode type one uses the integer line drawing algorithm of +"render_line(x0, y0, x1, y1, v)" to construct an integer floor +curve for contiguous piecewise line segments. Note that it has not +been relevant elsewhere, but here we must define integer division as +rounding division of both positive and negative numbers toward zero.

+ +
+  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]
+
+     }
+
+ + + + + diff --git a/doc/hufftree-under.png b/doc/hufftree-under.png new file mode 100644 index 0000000..be6e8d6 Binary files /dev/null and b/doc/hufftree-under.png differ diff --git a/doc/hufftree.png b/doc/hufftree.png new file mode 100644 index 0000000..f4dc537 Binary files /dev/null and b/doc/hufftree.png differ diff --git a/doc/index.html b/doc/index.html new file mode 100644 index 0000000..6d95e45 --- /dev/null +++ b/doc/index.html @@ -0,0 +1,114 @@ + + + + + +Ogg Vorbis Documentation + + + + + + + + + +

Ogg Vorbis Documentation

+ +

Vorbis technical discussion documents

+ + +

Ogg Vorbis I specification

+ + + +

Ogg Vorbis programming documents

+ + + +

Ogg bitstream documentation

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

libvorbis documentation

libvorbis version 1.3.2 - 20101101

+ +

Libvorbis Documentation

+ +

+Libvorbis contains the Vorbis reference encoder and decoder. +

+This is the lowest-level interface to the Vorbis encoder and decoder. If +you're just looking for a simple way to extract the +audio from an Ogg Vorbis file, you probably want to use vorbisfile rather than using libogg +and libvorbis directly. +

+Libvorbis API overview
+Libvorbis API reference
+ +

+

+ + + + + + + + +

copyright © 2000-2010 Xiph.Org

Ogg Vorbis

libvorbis documentation

libvorbis version 1.3.2 - 20101101

+ + + + diff --git a/doc/libvorbis/overview.html b/doc/libvorbis/overview.html new file mode 100644 index 0000000..22cd186 --- /dev/null +++ b/doc/libvorbis/overview.html @@ -0,0 +1,136 @@ + + + +libvorbis - API Overview + + + + + + + + + +

libvorbis documentation

libvorbis version 1.3.2 - 20101101

+ +

Libvorbis API Overview

+ +

Libvorbis is the reference implementation of the Vorbis codec. It is +the lowest-level interface to the Vorbis encoder and decoder, working +with packets directly.

+ +

All libvorbis routines and structures are declared in "vorbis/codec.h".

+ +

Encoding workflow

+ +
    +
  1. Initialize a vorbis_info structure +by calling vorbis_info_init and +then functions from libvorbisenc +on it.
    2. +
  2. Initialize a vorbis_dsp_state +for encoding based on the parameters in the vorbis_info by using vorbis_analysis_init.
    3. +
  3. Initialize a vorbis_comment +structure using vorbis_comment_init, +populate it with any comments you wish to store in the stream, and call +vorbis_analysis_headerout to +get the three Vorbis stream header packets. Output the packets.
    4. +
  4. Initialize a vorbis_block structure +using vorbis_block_init.
    5. +
  5. While there is more audio to encode:
      +
    1. Submit a chunk of audio data using vorbis_analysis_buffer and vorbis_analysis_wrote.
      2. +
    2. Obtain all available blocks using vorbis_analysis_blockout +in a loop. For each block obtained:
        +
      1. Encode the block into a packet (or prepare it for bitrate management) +using vorbis_analysis. (It's a good +idea to always pass the blocks through the bitrate +management mechanism; more information is on the vorbis_analysis page. It does not affect +the resulting packets unless you are actually using a bitrate-managed +mode.)
        2. +
      2. If you are using bitrate management, submit the block using vorbis_bitrate_addblock and obtain +packets using vorbis_bitrate_flushpacket.
        3. +
      3. Output any obtained packets.
        4. +
      3. +
    6. +
  6. Submit an empty buffer to indicate the end of input; this will result +in an end-of-stream packet after all encoding steps are done to it.
    7. +
  7. Destroy the structures using the appropriate vorbis_*_clear routines.
    8. +
+ +

Decoding workflow

+ +Note: if you do not need to do anything more involved than just +decoding the audio from an Ogg Vorbis file, you can use the far simpler +libvorbisfile interface, which +will take care of all of the demuxing and low-level decoding operations +(and even the I/O, if you want) for you. + +
    +
  1. When reading the header packets of an Ogg stream, you can use vorbis_synthesis_idheader to +check whether a stream might be Vorbis.
    2. +
  2. Initialize a vorbis_info and a vorbis_comment structure using the +appropriate vorbis_*_init routines, then pass the first three packets +from the stream (the Vorbis stream header packets) to vorbis_synthesis_headerin in +order. At this point, you can see the comments and basic parameters of +the Vorbis stream.
    3. +
  3. Initialize a vorbis_dsp_state +for decoding based on the parameters in the vorbis_info by using vorbis_synthesis_init.
    4. +
  4. Initialize a vorbis_block structure +using vorbis_block_init.
    5. +
  5. While there are more packets to decode:
      +
    1. Decode the next packet into a block using vorbis_synthesis.
      2. +
    2. Submit the block to the reassembly layer using vorbis_synthesis_blockin.
      3. +
    3. Obtain some decoded audio using vorbis_synthesis_pcmout and vorbis_synthesis_read. Any audio data +returned but not marked as consumed using vorbis_synthesis_read carries +over to the next call to vorbis_synthesis_pcmout.
      4. +
    6. +
  6. Destroy the structures using the appropriate vorbis_*_clear routines.
    7. +
+ +

Metadata workflow

+ +Note: if you do not need to do anything more involved than just +reading the metadata from an Ogg Vorbis file, libvorbisfile can do this for you. + +
    +
  1. Follow the decoding workflow above until you have access to the comments +and basic parameters of the Vorbis stream.
    2. +
  2. If you want to alter the comments, copy the first packet to the output +file, then create a packet for the modified comments using vorbis_commentheader_out and output +it, then copy the third packet and all subsequent packets into the output +file.
    3. +
+ +

+
+ + + + + + + + +

copyright © 2010 Xiph.Org

Ogg Vorbis

libvorbis documentation

libvorbis version 1.3.2 - 20101101

+ + + + + diff --git a/doc/libvorbis/reference.html b/doc/libvorbis/reference.html new file mode 100644 index 0000000..642b1f9 --- /dev/null +++ b/doc/libvorbis/reference.html @@ -0,0 +1,86 @@ + + + +Libvorbis API Reference + + + + + + + + + +

Libvorbis documentation

libvorbis version 1.3.2 - 20101101

+ +

Libvorbis API Reference

+ +

+Data Structures
+vorbis_block
+vorbis_comment
+vorbis_dsp_state
+vorbis_info
+
+Functions used by both decode and encode
+vorbis_block_clear()
+vorbis_block_init()
+vorbis_dsp_clear()
+vorbis_granule_time()
+vorbis_info_blocksize()
+vorbis_info_clear()
+vorbis_info_init()
+vorbis_version_string()
+
+Decoding
+vorbis_packet_blocksize()
+vorbis_synthesis()
+vorbis_synthesis_blockin()
+vorbis_synthesis_halfrate()
+vorbis_synthesis_halfrate_p()
+vorbis_synthesis_headerin()
+vorbis_synthesis_idheader()
+vorbis_synthesis_init()
+vorbis_synthesis_lapout()
+vorbis_synthesis_pcmout()
+vorbis_synthesis_read()
+vorbis_synthesis_restart()
+vorbis_synthesis_trackonly()
+
+Encoding
+vorbis_analysis()
+vorbis_analysis_blockout()
+vorbis_analysis_buffer()
+vorbis_analysis_headerout()
+vorbis_analysis_init()
+vorbis_analysis_wrote()
+vorbis_bitrate_addblock()
+vorbis_bitrate_flushpacket()
+
+Metadata
+vorbis_comment_add()
+vorbis_comment_add_tag()
+vorbis_comment_clear()
+vorbis_comment_init()
+vorbis_comment_query()
+vorbis_comment_query_count()
+vorbis_commentheader_out()
+
+Return Codes
+ + +

+

+ + + + + + + + +

copyright © 2010 Xiph.Org

Ogg Vorbis

libvorbis documentation

libvorbis version 1.3.2 - 20101101

+ + + + diff --git a/doc/libvorbis/return.html b/doc/libvorbis/return.html new file mode 100644 index 0000000..7a008d5 --- /dev/null +++ b/doc/libvorbis/return.html @@ -0,0 +1,79 @@ + + + +libvorbis - Return Codes + + + + + + + + + +

libvorbis documentation

libvorbis version 1.3.2 - 20101101

+ +

Return Codes

+ +

+ +The following return codes are #defined in "vorbis/codec.h" and +may be returned by functions from libvorbis, libvorbisfile, and libvorbisenc. Descriptions of a code +relevant to a specific function are found in the reference description +of that function. + +

+ +
OV_FALSE
+
Not true, or no data available
+ +
OV_HOLE
+
Vorbisfile encoutered missing or corrupt data in the bitstream. Recovery +is normally automatic and this return code is for informational purposes only.
+ +
OV_EREAD
+
Read error while fetching compressed data for decode
+ +
OV_EFAULT
+
Internal inconsistency in encode or decode state. Continuing is likely not possible.
+ +
OV_EIMPL
+
Feature not implemented
+ +
OV_EINVAL
+
Either an invalid argument, or incompletely initialized argument passed to a call
+ +
OV_ENOTVORBIS
+
The given file/data was not recognized as Ogg Vorbis data.
+ +
OV_EBADHEADER
+
The file/data is apparently an Ogg Vorbis stream, but contains a corrupted or undecipherable header.
+ +
OV_EVERSION
+
The bitstream format revision of the given stream is not supported.
+ +
OV_EBADLINK
+
The given link exists in the Vorbis data stream, but is not decipherable due to garbacge or corruption.
+ +
OV_ENOSEEK
+
The given stream is not seekable
+ +
+ +

+
+ + + + + + + + +

copyright © 2000-2010 Xiph.Org

Ogg Vorbis

libvorbis documentation

libvorbis version 1.3.2 - 20101101

+ + + + diff --git a/doc/libvorbis/style.css b/doc/libvorbis/style.css new file mode 100644 index 0000000..81cf417 --- /dev/null +++ b/doc/libvorbis/style.css @@ -0,0 +1,7 @@ +BODY { font-family: Helvetica, sans-serif } +TD { font-family: Helvetica, sans-serif } +P { font-family: Helvetica, sans-serif } +H1 { font-family: Helvetica, sans-serif } +H2 { font-family: Helvetica, sans-serif } +H4 { font-family: Helvetica, sans-serif } +P.tiny { font-size: 8pt } diff --git a/doc/libvorbis/vorbis_analysis.html b/doc/libvorbis/vorbis_analysis.html new file mode 100644 index 0000000..b126f20 --- /dev/null +++ b/doc/libvorbis/vorbis_analysis.html @@ -0,0 +1,86 @@ + + + +libvorbis - function - vorbis_analysis + + + + + + + + + +

libvorbis documentation

libvorbis version 1.3.2 - 20101101

+ +

vorbis_analysis

+ +

declared in "vorbis/codec.h";

+ +

Once the uncompressed audio data has been divided into blocks, this +function is called on each block. It looks up the encoding mode and +dispatches the block to the forward transform provided by that mode. +

+

When using a basic encoding mode, with no bitrate management, +an ogg_packet pointer can be given, and the coded block is returned +directly through that structure and can be placed in the output stream. +

+

Otherwise, NULL should be passed for the ogg_packet pointer. In +that case, after the transform has been applied, the block must passed +to vorbis_bitrate_addblock() for further coding. This method works with +both basic and managed encoding modes, so it's recommended for new code. +

+ + + + + +
+

+extern int      vorbis_analysis(vorbis_block *vb,ogg_packet *op);
+
+
+ +

Parameters

+
+
vb
+
Pointer to the vorbis_block to be encoded.
+
op
+
Optional pointer to an ogg_packet. This is normally NULL, +and the final output is obtained by passing vb though the +vorbis_bitrate_*() interface to perform further refinement. +However, when not using a bitrate managed encoding mode, it +is possible to skip that step by providing an ogg_packet pointer +here, obtaining the compressed data directly.
+
+ + +

Return Values

+
    +
  • 0 for success
    • +
  • negative values for failure: +
      +
    • OV_EINVAL - Invalid request; a non-NULL value was passed for op when the encoder is using a bitrate managed mode.
      • +
    • OV_EFAULT - Internal fault; indicates a bug or memory corruption.
      • +
    • OV_EIMPL - Unimplemented; not supported by this version of the library.
      • +
    +
    • +
+

+ +

+

+ + + + + + + + +

copyright © 2010 Xiph.Org

Ogg Vorbis

libvorbis documentation

libvorbis version 1.3.2 - 20101101

+ + + + + diff --git a/doc/libvorbis/vorbis_analysis_blockout.html b/doc/libvorbis/vorbis_analysis_blockout.html new file mode 100644 index 0000000..94948b6 --- /dev/null +++ b/doc/libvorbis/vorbis_analysis_blockout.html @@ -0,0 +1,79 @@ + + + +libvorbis - function - vorbis_analysis_blockout + + + + + + + + + +

libvorbis documentation

libvorbis version 1.3.2 - 20101101

+ +

vorbis_analysis_blockout

+ +

declared in "vorbis/codec.h";

+ +

This fuction examines the available uncompressed data and tries to +break it into appropriate sized blocks. It should be called in a loop +after adding new data with vorbis_analysis_buffer()/vorbis_analysis_wrote() +until it returns zero (need more data) or an negative value (error). +

+

+Each block returned should be passed to vorbis_analysis() for transform +and coding. +

+ + + + + +
+

+extern int      vorbis_analysis_blockout(vorbis_dsp_state *v,vorbis_block *vb);
+
+
+ +

Parameters

+
+
v
+
Pointer to the vorbis_dsp_state representing the encoder.
+
vb
+
Pointer to a previously initialized vorbis_block object to hold the +returned data. +
+ + +

Return Values

+
    +
  • 1 for success when more blocks are available.
    • +
  • 0 for success when this is the last block available from the current input.
    • +
  • negative values for failure: +
      +
    • OV_EINVAL - Invalid parameters.
      • +
    • OV_EFAULT - Internal fault; indicates a bug or memory corruption.
      • +
    • OV_EIMPL - Unimplemented; not supported by this version of the library.
      • +
    +
    • + +
+ +

+
+ + + + + + + + +

copyright © 2010 Xiph.Org

Ogg Vorbis

libvorbis documentation

libvorbis version 1.3.2 - 20101101

+ + + + + diff --git a/doc/libvorbis/vorbis_analysis_buffer.html b/doc/libvorbis/vorbis_analysis_buffer.html new file mode 100644 index 0000000..cf6ae80 --- /dev/null +++ b/doc/libvorbis/vorbis_analysis_buffer.html @@ -0,0 +1,74 @@ + + + +libvorbis - function - vorbis_analysis_buffer + + + + + + + + + +

libvorbis documentation

libvorbis version 1.3.2 - 20101101

+ +

vorbis_analysis_buffer

+ +

declared in "vorbis/codec.h";

+ +

This fuction requests a buffer array for delivering audio to the +encoder for compression.

+ +

The Vorbis encoder expects the caller to write audio data as +non-interleaved floating point samples into its internal buffers. +

+

+The general procedure is to call this function with the number of samples +you have available. The encoder will arrange for that much internal storage +and return an array of buffer pointers, one for each channel of audio. +The caller must then write the audio samples into those buffers, as +float values, and finally call vorbis_analysis_wrote() to tell the +encoder the data is available for analysis. +

+ + + + + +
+

+extern float  **vorbis_analysis_buffer(vorbis_dsp_state *v,int vals);
+
+
+ +

Parameters

+
+
v
+
Pointer to the vorbis_dsp_state representing the encoder.
+
vals
+
Number of samples to provide space for in the returned buffer. 1024 is a reasonable choice.
+
+ + +

Return Values

+

Returns an array of floating point buffers which can accept data. +A (**float) where the first index is the channel, and the second is +the sample index.

+ +

+

+ + + + + + + + +

copyright © 2010 Xiph.Org

Ogg Vorbis

libvorbis documentation

libvorbis version 1.3.2 - 20101101

+ + + + + diff --git a/doc/libvorbis/vorbis_analysis_headerout.html b/doc/libvorbis/vorbis_analysis_headerout.html new file mode 100644 index 0000000..58c37c3 --- /dev/null +++ b/doc/libvorbis/vorbis_analysis_headerout.html @@ -0,0 +1,83 @@ + + + +libvorbis - function - vorbis_analysis_headerout + + + + + + + + + +

libvorbis documentation

libvorbis version 1.3.2 - 20101101

+ +

vorbis_analysis_headerout

+ +

declared in "vorbis/codec.h";

+ +

This function creates and returns the three header packets needed +to configure a decoder to accept compressed data. I should be called +after all encoder initialization and configuration is complete. The +output packets should be placed in order at the start of the compressed +vorbis stream, prior to the first data packet. +

+ + + + + +
+

+extern int      vorbis_analysis_headerout(vorbis_dsp_state *v,
+                                          vorbis_comment *vc,
+                                          ogg_packet *op,
+                                          ogg_packet *op_comm,
+                                          ogg_packet *op_code);
+
+
+ +

Parameters

+
+
v
+
Pointer to an initialized vorbis_dsp_state which holds the encoder configuration.
+
vc
+
Pointer to an initialized vorbis_comment structure which holds the metadata associated with the stream being encoded.
+
op
+
Pointer to an ogg_packet structure to be filled out with the stream identification header.
+
op_comm
+
Pointer to an ogg_packet structure to be filled out with the serialied vorbis_comment data.
+
op_code
+
Pointer to an ogg_packet structure to be filled out with the codebooks, mode descriptions, etc. which will be used encoding the stream.
+
+ + +

Return Values

+
    +
  • 0 for success
    • +
  • negative values for failure: +
      +
    • OV_EFAULT - Internal fault; indicates a bug or memory corruption.
      • +
    • OV_EIMPL - Unimplemented; not supported by this version of the library.
      • +
    +
    • +
+

+ +

+

+ + + + + + + + +

copyright © 2010 Xiph.Org

Ogg Vorbis

libvorbis documentation

libvorbis version 1.3.2 - 20101101

+ + + + + diff --git a/doc/libvorbis/vorbis_analysis_init.html b/doc/libvorbis/vorbis_analysis_init.html new file mode 100644 index 0000000..8799338 --- /dev/null +++ b/doc/libvorbis/vorbis_analysis_init.html @@ -0,0 +1,66 @@ + + + +libvorbis - function - vorbis_analysis_init + + + + + + + + + +

libvorbis documentation

libvorbis version 1.3.2 - 20101101

+ +

vorbis_analysis_init

+ +

declared in "vorbis/codec.h";

+ +

This function allocates and initializes the encoder's analysis state +inside a is vorbis_dsp_state, based on the configuration in a vorbis_info +struct. +

+ + + + + +
+

+extern int      vorbis_analysis_init(vorbis_dsp_state *v,vorbis_info *vi);
+
+
+ +

Parameters

+
+
v +
Pointer to the vorbis_dsp_state structure to be initialized for encoding.
+
vi
+
Pointer to an initialized vorbis_info struct describing the encoder configuration.
+
+ + +

Return Values

+
+
  • +0 for success
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_analysis_wrote.html b/doc/libvorbis/vorbis_analysis_wrote.html new file mode 100644 index 0000000..2326f60 --- /dev/null +++ b/doc/libvorbis/vorbis_analysis_wrote.html @@ -0,0 +1,80 @@ + + + +libvorbis - function - vorbis_analysis_wrote + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_analysis_wrote

    + +

    declared in "vorbis/codec.h";

    + +

    This function tells the encoder new data is available for compression. +Call this after writing new audio into the buffer array returned by +vorbis_analysis_buffer(). +

    + +

    +Call with the vals parameter set to zero to signal the end +of the input data. +

    + + + + + +
    +
    
+extern int      vorbis_analysis_wrote(vorbis_dsp_state *v,int vals);
+
    +
    + +

    Parameters

    +
    +
    v
    +
    Pointer to the vorbis_dsp_state representing the encoder.
    +
    vals
    +
    Number of samples successfully written. This must be less than +or equal to the value passed to vorbis_analysis_buffer(). A value +of zero means all input data has been provided and the compressed +stream should be finalized.
    +
    + + +

    Return Values

    +
      +
    • 0 for success
      • +
    • negative values for failure: +
        +
      • OV_EINVAL - Invalid request; e.g. vals overflows the allocated space.
        • +
      • OV_EFAULT - Internal fault; indicates a bug or memory corruption.
        • +
      • OV_EIMPL - Unimplemented; not supported by this version of the library.
        • +
      +
      • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_bitrate_addblock.html b/doc/libvorbis/vorbis_bitrate_addblock.html new file mode 100644 index 0000000..9de5de4 --- /dev/null +++ b/doc/libvorbis/vorbis_bitrate_addblock.html @@ -0,0 +1,74 @@ + + + +libvorbis - function - vorbis_bitrate_addblock + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_bitrate_addblock

    + +

    declared in "vorbis/codec.h";

    + +

    This fuction submits a transformed block to the bitrate management +engine for final encoding. Packets are buffered and the packet boundaries +adjusted and padded to meet the target bitrate, if any.

    + +

    After calling vorbis_bitrate_addblock(), the passed vorbis_block +structure can be reused in another call to vorbis_analysis_blockout(). +Call vorbis_bitrate_flushpacket() to obtain the final compressed data. +

    + + + + + +
    +
    
+extern int      vorbis_bitrate_addblock(vorbis_block *vb);
+
    +
    + +

    Parameters

    +
    +
    vb
    +
    Pointer to the vorbis_block to be submitted.
    +
    + + +

    Return Values

    +
      +
    • 0 for success.
      • +
    • negative values for failure: +
        +
      • OV_EINVAL - Invalid parameters.
        • +
      • OV_EFAULT - Internal fault; indicates a bug or memory corruption.
        • +
      • OV_EIMPL - Unimplemented; not supported by this version of the library.
        • +
      +
      • + +
    + +

    +
    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_bitrate_flushpacket.html b/doc/libvorbis/vorbis_bitrate_flushpacket.html new file mode 100644 index 0000000..297abb0 --- /dev/null +++ b/doc/libvorbis/vorbis_bitrate_flushpacket.html @@ -0,0 +1,80 @@ + + + +libvorbis - function - vorbis_bitrate_flushpacket + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_bitrate_flushpacket

    + +

    declared in "vorbis/codec.h";

    + +

    This function returns the next available completed packet from the +bitrate management engine. It should be called in a loop after any call +to vorbis_bitrate_addblock() until it returns either 0 (more data needed) +or a negative value (error). +

    + +

    +The data returned in the ogg_packet structure can be copied to the +final compressed output stream. +

    + + + + + +
    +
    
+extern int      vorbis_bitrate_flushpacket(vorbis_dsp_state *vd,
+                                           ogg_packet *op);
+
    +
    + +

    Parameters

    +
    +
    vd
    +
    Pointer to the vorbis_dsp_state represending the encoder.
    +
    op
    +
    Pointer to an ogg_packet to be filled out with the compressed data.
    +
    + + +

    Return Values

    +
      +
    • 1 for success when more packets are available. +
    • 0 for success when this is the last packet available from the current input.
      • +
    • negative values for failure: +
        +
      • OV_EINVAL - Invalid parameters.
        • +
      • OV_EFAULT - Internal fault; indicates a bug or memory corruption.
        • +
      • OV_EIMPL - Unimplemented; not supported by this version of the library.
        • +
      +
      • + +
    + +

    +
    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_block.html b/doc/libvorbis/vorbis_block.html new file mode 100644 index 0000000..9cd24c2 --- /dev/null +++ b/doc/libvorbis/vorbis_block.html @@ -0,0 +1,60 @@ + + + +libvorbis - datatype - vorbis_block + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_block

    + +

    declared in "vorbis/codec.h"

    + +

    +The vorbis_block structure holds the data for a single block of audio. One +vorbis_block translates to one codec packet. The encoding process consists +of splitting the audio into blocks and encoding the blocks into packets; +decoding consists of decoding the packets into blocks and reassembling +the audio from the blocks. +

    +This structure is intended to be private. Although the fields are given +in the header file, they should not be directly modified or relied upon +in any way. +

    + + + + + +
    +
    typedef struct vorbis_block{
+  /* private */
+} vorbis_block;
    +
    + +

    Parameters

    +
    • None public.
    + + +

    +
    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + diff --git a/doc/libvorbis/vorbis_block_clear.html b/doc/libvorbis/vorbis_block_clear.html new file mode 100644 index 0000000..13be5b6 --- /dev/null +++ b/doc/libvorbis/vorbis_block_clear.html @@ -0,0 +1,61 @@ + + + +libvorbis - function - vorbis_block_clear + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_block_clear

    + +

    declared in "vorbis/codec.h";

    + +

    This function frees the internal storage for a vorbis_block structure.

    + + + + + +
    +
    
+extern int      vorbis_block_clear(vorbis_block *vb);
+
    +
    + +

    Parameters

    +
    +
    vb
    +
    Pointer to a vorbis_block struct to be cleared.
    +
    + + +

    Return Values

    +
    +
  • +0 for success
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_block_init.html b/doc/libvorbis/vorbis_block_init.html new file mode 100644 index 0000000..82f6ae8 --- /dev/null +++ b/doc/libvorbis/vorbis_block_init.html @@ -0,0 +1,66 @@ + + + +libvorbis - function - vorbis_block_init + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_block_init

    + +

    declared in "vorbis/codec.h";

    + +

    This function initializes a vorbis_block structure and allocates its +internal storage. A vorbis_block is used to represent a particular block +of input audio which can be analyzed and coded as a unit. +

    + + + + + +
    +
    
+extern int      vorbis_block_init(vorbis_dsp_state *v, vorbis_block *vb);
+
    +
    + +

    Parameters

    +
    +
    v +
    Pointer to an initialized vorbis_dsp_state with which to associate the new block.
    +
    vb
    +
    Pointer to a vorbis_block struct to be initialized.
    +
    + + +

    Return Values

    +
    +
  • +0 for success
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_comment.html b/doc/libvorbis/vorbis_comment.html new file mode 100644 index 0000000..7afb7f3 --- /dev/null +++ b/doc/libvorbis/vorbis_comment.html @@ -0,0 +1,80 @@ + + + +libvorbis - datatype - vorbis_comment + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_comment

    + +

    declared in "vorbis/codec.h"

    + +

    +The vorbis_comment structure defines an Ogg Vorbis comment. +

    +Only the fields the program needs must be defined. If a field isn't +defined by the application, it will either be blank (if it's a string value) +or set to some reasonable default (usually 0). +

    +Note: When encoding, while it is supported to modify a +vorbis_comment structure directly, be sure to read the notes on the +vorbis_comment_init and +vorbis_comment_clear pages for +considerations on memory allocation and freeing before you do so. Rule of +thumb: call vorbis_comment_init, then either do all allocation, +freeing, and modification yourself and do not call +vorbis_comment_clear, or do all modification using libvorbis +functions and do call vorbis_comment_clear. +

    + + + + + +
    +
    typedef struct vorbis_comment{
+  /* unlimited user comment fields. */
+  char **user_comments;
+  int  *comment_lengths;
+  int  comments;
+  char *vendor;
+
+} vorbis_comment;
    +
    + +

    Parameters

    +
    +
    user_comments
    +
    Unlimited user comment array. The individual strings in the array are 8 bit clean, by the Vorbis specification, and as such the comment_lengths array should be consulted to determine string length. For convenience, each string is also NULL-terminated by the decode library (although Vorbis comments are not NULL terminated within the bitstream itself).
    +
    comment_lengths
    +
    An int array that stores the length of each comment string
    +
    comments
    +
    Int signifying number of user comments in user_comments field.
    +
    vendor
    +
    Information about the Vorbis implementation that encoded the file. Stored in a standard C 0-terminated string. Libvorbis will fill this in itself when encoding a comment packet from this structure; when decoding, this contains the vendor string that was in the comment packet.
    +
    + + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + diff --git a/doc/libvorbis/vorbis_comment_add.html b/doc/libvorbis/vorbis_comment_add.html new file mode 100644 index 0000000..b7125b0 --- /dev/null +++ b/doc/libvorbis/vorbis_comment_add.html @@ -0,0 +1,70 @@ + + + +libvorbis - function - vorbis_comment_add + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_comment_add

    + +

    declared in "vorbis/codec.h";

    + +

    This function adds a raw comment string to a +vorbis_comment structure.

    + +

    This function should be used if the string is already in the +form "KEY=value". If you have a separate key and value, use +vorbis_comment_add_tag +instead.

    + + + + + +
    +
    
+extern void     vorbis_comment_add(vorbis_comment *vc, const char *comment);
+
    +
    + +

    Parameters

    +
    +
    vc
    +
    Pointer to a vorbis_comment structure to add the comment to.
    +
    comment
    +
    Pointer to the null-terminated raw comment string. The string will +be copied, so it can be freed or modified after this function returns +without affecting the vorbis_comment structure's contents.
    +
    + + +

    Return Values

    +
    +
  • None.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_comment_add_tag.html b/doc/libvorbis/vorbis_comment_add_tag.html new file mode 100644 index 0000000..97565d3 --- /dev/null +++ b/doc/libvorbis/vorbis_comment_add_tag.html @@ -0,0 +1,74 @@ + + + +libvorbis - function - vorbis_comment_add_tag + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_comment_add_tag

    + +

    declared in "vorbis/codec.h";

    + +

    This function adds a tag-comment pair to a +vorbis_comment structure. There can +be more than one comment value for the same tag; if a comment with the +same tag already exists, another comment with the same tag is added.

    + +

    If you already have a string in the form "KEY=value", see +vorbis_comment_add instead.

    + + + + + +
    +
    
+extern void     vorbis_comment_add_tag(vorbis_comment *vc,
+                                       const char *tag, const char *contents);
+
    +
    + +

    Parameters

    +
    +
    vc
    +
    Pointer to a vorbis_comment structure to add the comment to.
    +
    tag
    +
    Pointer to the null-terminated tag string. The string will +be copied, so it can be freed or modified after this function returns +without affecting the vorbis_comment structure's contents.
    +
    contents
    +
    Pointer to the null-terminated comment contents string. This will +also be copied.
    +
    + + +

    Return Values

    +
    +
  • None.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_comment_clear.html b/doc/libvorbis/vorbis_comment_clear.html new file mode 100644 index 0000000..0771d6e --- /dev/null +++ b/doc/libvorbis/vorbis_comment_clear.html @@ -0,0 +1,69 @@ + + + +libvorbis - function - vorbis_comment_clear + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_comment_clear

    + +

    declared in "vorbis/codec.h";

    + +

    This function frees the internal storage associated with a vorbis_comment structure.

    + +

    Note: Be careful if you have modified the vorbis_comment +structure yourself, as libvorbis will try to use its own wrappers of +memory allocation functions to free the contents of the vorbis_comment +structure. This will not work correctly unless all arrays and comment +strings contained in the vorbis_comment structure were allocated by +libvorbis itself. This function is only guaranteed to be safe if all +modification to the vorbis_comment structure was done using libvorbis +functions.

    + + + + + +
    +
    
+extern void     vorbis_comment_clear(vorbis_comment *vc);
+
    +
    + +

    Parameters

    +
    +
    vc
    +
    The vorbis_comment structure to clear.
    +
    + + +

    Return Values

    +
    +
  • None.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_comment_init.html b/doc/libvorbis/vorbis_comment_init.html new file mode 100644 index 0000000..abce0a6 --- /dev/null +++ b/doc/libvorbis/vorbis_comment_init.html @@ -0,0 +1,72 @@ + + + +libvorbis - function - vorbis_comment_init + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_comment_init

    + +

    declared in "vorbis/codec.h";

    + +

    This function initializes a vorbis_comment +structure for use. After calling this function, the vorbis_comment +structure contains no comments.

    + +

    Note: No internal storage is allocated by this function; +internal storage is allocated as needed by other libvorbis functions that +modify the vorbis_comment structure. If you modify the vorbis_comment +structure directly, without using libvorbis, you should not +call vorbis_comment_clear when +you are finished but instead clean up after it yourself. See the note +on the vorbis_comment_clear +page for more information.

    + + + + + +
    +
    
+extern void     vorbis_comment_init(vorbis_comment *vc);
+
    +
    + +

    Parameters

    +
    +
    vc
    +
    Pointer to the vorbis_comment +structure to initialize.
    +
    + + +

    Return Values

    +
    +
  • None.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_comment_query.html b/doc/libvorbis/vorbis_comment_query.html new file mode 100644 index 0000000..f958ebb --- /dev/null +++ b/doc/libvorbis/vorbis_comment_query.html @@ -0,0 +1,72 @@ + + + +libvorbis - function - vorbis_comment_query + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_comment_query

    + +

    declared in "vorbis/codec.h";

    + +

    This function retrieves a comment string for a given tag in a +vorbis_comment structure.

    + + + + + +
    +
    
+extern char    *vorbis_comment_query(vorbis_comment *vc, const char *tag, int count);
+
    +
    + +

    Parameters

    +
    +
    vc
    +
    Pointer to the vorbis_comment structure.
    +
    tag
    +
    Pointer to a null-terminated string of the comment tag to look +for. Tags are compared case-insensitively.
    +
    count
    +
    The index of the comment string to retrieve. A value of 0 indicates +the first comment whose tag matches tag. Use +vorbis_comment_query_count +to determine the number of matching comments.
    +
    + + +

    Return Values

    +
    +
  • A pointer to the comment string. The underlying buffer is owned by +the vorbis_comment structure.
    • +
  • NULL on a nonexistent tag or if count is greater than or +equal to the number of matching comments.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_comment_query_count.html b/doc/libvorbis/vorbis_comment_query_count.html new file mode 100644 index 0000000..e8a04f4 --- /dev/null +++ b/doc/libvorbis/vorbis_comment_query_count.html @@ -0,0 +1,66 @@ + + + +libvorbis - function - vorbis_comment_query_count + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_comment_query_count

    + +

    declared in "vorbis/codec.h";

    + +

    This function determines the number of comments with a given tag +that are present in a vorbis_comment +structure.

    + + + + + +
    +
    
+extern int      vorbis_comment_query_count(vorbis_comment *vc, const char *tag);
+
    +
    + +

    Parameters

    +
    +
    vc
    +
    Pointer to the vorbis_comment structure.
    +
    tag
    +
    Pointer to a null-terminated string of the comment tag to look +for. Tags are compared case-insensitively.
    +
    + + +

    Return Values

    +
    +
  • The number of comments present with the given tag.
    • +
  • 0 if no such comments are present.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_commentheader_out.html b/doc/libvorbis/vorbis_commentheader_out.html new file mode 100644 index 0000000..0dd63d6 --- /dev/null +++ b/doc/libvorbis/vorbis_commentheader_out.html @@ -0,0 +1,65 @@ + + + +libvorbis - function - vorbis_commentheader_out + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_commentheader_out

    + +

    declared in "vorbis/codec.h";

    + +

    This function encodes the contents of a +vorbis_comment structure into an +ogg_packet.

    + + + + + +
    +
    
+extern int      vorbis_commentheader_out(vorbis_comment *vc, ogg_packet *op);
+
    +
    + +

    Parameters

    +
    +
    vc
    +
    The vorbis_comment structure to encode.
    +
    op
    +
    The ogg_packet to place the encoded comment packet into.
    +
    + + +

    Return Values

    +
    +
  • 0 on success.
    • +
  • OV_EIMPL on error.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_dsp_clear.html b/doc/libvorbis/vorbis_dsp_clear.html new file mode 100644 index 0000000..0a9b959 --- /dev/null +++ b/doc/libvorbis/vorbis_dsp_clear.html @@ -0,0 +1,63 @@ + + + +libvorbis - function - vorbis_dsp_clear + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_dsp_clear

    + +

    declared in "vorbis/codec.h";

    + +

    This function frees the internal storage for a vorbis_dsp_state +structure. This can be used independent of whether the vorbis_dsp_state +is set up for analysis (encoding) or synthesis (decoding).

    + + + + + +
    +
    
+extern void     vorbis_dsp_clear(vorbis_dsp_state *v);
+
    +
    + +

    Parameters

    +
    +
    v
    +
    Pointer to the vorbis_dsp_state to be cleared.
    +
    + + +

    Return Values

    +
    +
  • +None
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_dsp_state.html b/doc/libvorbis/vorbis_dsp_state.html new file mode 100644 index 0000000..b8baf9c --- /dev/null +++ b/doc/libvorbis/vorbis_dsp_state.html @@ -0,0 +1,57 @@ + + + +libvorbis - datatype - vorbis_dsp_state + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_dsp_state

    + +

    declared in "vorbis/codec.h"

    + +

    +The vorbis_dsp_state structure is the state for one instance of the +Vorbis encoder or decoder. +

    +This structure is intended to be private. Although the fields are given +in the header file, they should not be directly modified or relied upon +in any way. +

    + + + + + +
    +
    typedef struct vorbis_dsp_state{
+  /* private */
+} vorbis_dsp_state;
    +
    + +

    Parameters

    +
    • None public.
    + + +

    +
    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + diff --git a/doc/libvorbis/vorbis_granule_time.html b/doc/libvorbis/vorbis_granule_time.html new file mode 100644 index 0000000..f5c8b7f --- /dev/null +++ b/doc/libvorbis/vorbis_granule_time.html @@ -0,0 +1,65 @@ + + + +libvorbis - function - vorbis_granule_time + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_granule_time

    + +

    declared in "vorbis/codec.h";

    + +

    This function converts a granule position to a time for a given Vorbis stream.

    + + + + + +
    +
    
+extern double   vorbis_granule_time(vorbis_dsp_state *v,
+                                    ogg_int64_t granulepos);
+
    +
    + +

    Parameters

    +
    +
    v
    +
    Pointer to the vorbis_dsp_state for the stream.
    +
    granulepos
    +
    The granule position.
    +
    + + +

    Return Values

    +
    +
  • +The time (in seconds) corresponding to the granulepos.
    • +
  • -1 if the given granulepos is negative
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_info.html b/doc/libvorbis/vorbis_info.html new file mode 100644 index 0000000..2a06c06 --- /dev/null +++ b/doc/libvorbis/vorbis_info.html @@ -0,0 +1,80 @@ + + + +libvorbis - datatype - vorbis_info + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_info

    + +

    declared in "vorbis/codec.h"

    + +

    +The vorbis_info structure contains basic information about the audio in a vorbis bitstream. +

    + + + + + +
    +
    typedef struct vorbis_info{
+  int version;
+  int channels;
+  long rate;
+  
+  long bitrate_upper;
+  long bitrate_nominal;
+  long bitrate_lower;
+  long bitrate_window;
+
+  void *codec_setup;
+
+} vorbis_info;
    +
    + +

    Relevant Struct Members

    +
    +
    version
    +
    Vorbis encoder version used to create this bitstream.
    +
    channels
    +
    Int signifying number of channels in bitstream.
    +
    rate
    +
    Sampling rate of the bitstream.
    +
    bitrate_upper
    +
    Specifies the upper limit in a VBR bitstream. If the value matches the bitrate_nominal and bitrate_lower parameters, the stream is fixed bitrate. May be unset if no limit exists.
    +
    bitrate_nominal
    +
    Specifies the average bitrate for a VBR bitstream. May be unset. If the bitrate_upper and bitrate_lower parameters match, the stream is fixed bitrate.
    +
    bitrate_lower
    +
    Specifies the lower limit in a VBR bitstream. If the value matches the bitrate_nominal and bitrate_upper parameters, the stream is fixed bitrate. May be unset if no limit exists.
    +
    bitrate_window
    +
    Currently unset.
    + +
    codec_setup
    +
    Internal structure that contains the detailed/unpacked configuration for decoding the current Vorbis bitstream.
    +
    + + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + diff --git a/doc/libvorbis/vorbis_info_blocksize.html b/doc/libvorbis/vorbis_info_blocksize.html new file mode 100644 index 0000000..f256d24 --- /dev/null +++ b/doc/libvorbis/vorbis_info_blocksize.html @@ -0,0 +1,66 @@ + + + +libvorbis - function - vorbis_info_blocksize + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_info_blocksize

    + +

    declared in "vorbis/codec.h";

    + +

    This function gets the possible sizes for encoded blocks. There +are short blocks (zo = 0) and long blocks (zo = 1). The size of a long +block is guaranteed to be greater than or equal to the size of a short +block.

    + + + + + +
    +
    
+extern int      vorbis_info_blocksize(vorbis_info *vi,int zo);
+
    +
    + +

    Parameters

    +
    +
    vi
    +
    Pointer to the vorbis_info struct.
    +
    zo
    +
    Integer for which block size to get: 0 for short and 1 for long
    +
    + + +

    Return Values

    +
    +
  • A positive integer for the block size.
    • +
  • -1 on error.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_info_clear.html b/doc/libvorbis/vorbis_info_clear.html new file mode 100644 index 0000000..907be6f --- /dev/null +++ b/doc/libvorbis/vorbis_info_clear.html @@ -0,0 +1,61 @@ + + + +libvorbis - function - vorbis_info_clear + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_info_clear

    + +

    declared in "vorbis/codec.h";

    + +

    This function frees the internal storage for a vorbis_info structure.

    + + + + + +
    +
    
+extern void     vorbis_info_clear(vorbis_info *vi);
+
    +
    + +

    Parameters

    +
    +
    vi
    +
    Pointer to a vorbis_info struct to be cleared.
    +
    + + +

    Return Values

    +
    +
  • +None.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_info_init.html b/doc/libvorbis/vorbis_info_init.html new file mode 100644 index 0000000..a0e58fb --- /dev/null +++ b/doc/libvorbis/vorbis_info_init.html @@ -0,0 +1,62 @@ + + + +libvorbis - function - vorbis_info_init + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_info_init

    + +

    declared in "vorbis/codec.h";

    + +

    This function initializes a vorbis_info +structure and allocates its internal storage.

    + + + + + +
    +
    
+extern void     vorbis_info_init(vorbis_info *vi);
+
    +
    + +

    Parameters

    +
    +
    vi
    +
    Pointer to a vorbis_info struct to be initialized.
    +
    + + +

    Return Values

    +
    +
  • +None.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_packet_blocksize.html b/doc/libvorbis/vorbis_packet_blocksize.html new file mode 100644 index 0000000..827e03f --- /dev/null +++ b/doc/libvorbis/vorbis_packet_blocksize.html @@ -0,0 +1,66 @@ + + + +libvorbis - function - vorbis_packet_blocksize + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_packet_blocksize

    + +

    declared in "vorbis/codec.h";

    + +

    This function gets the size of the block that would result from +decoding a Vorbis packet but does not actually decode the packet.

    + + + + + +
    +
    
+extern long     vorbis_packet_blocksize(vorbis_info *vi,ogg_packet *op);
+
    +
    + +

    Parameters

    +
    +
    vi
    +
    The vorbis_info structure for the +stream the packet is from.
    +
    op
    +
    The packet to get the block size of.
    +
    + + +

    Return Values

    +
    +
  • The block size on success.
    • +
  • OV_ENOTAUDIO if the packet is not an audio packet.
    • +
  • OV_EBADPACKET if there was an error in the packet.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_synthesis.html b/doc/libvorbis/vorbis_synthesis.html new file mode 100644 index 0000000..38ac4ed --- /dev/null +++ b/doc/libvorbis/vorbis_synthesis.html @@ -0,0 +1,70 @@ + + + +libvorbis - function - vorbis_synthesis + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_synthesis

    + +

    declared in "vorbis/codec.h";

    + +

    This function decodes a Vorbis packet into a block of data. The +vorbis_block should then be submitted +to the vorbis_dsp_state +for the decoder instance using +vorbis_synthesis_blockin +to be assembled into the final decoded audio.

    + + + + + +
    +
    
+extern int      vorbis_synthesis(vorbis_block *vb,ogg_packet *op);
+
    +
    + +

    Parameters

    +
    +
    vb
    +
    The vorbis_block to decode the +packet into.
    +
    op
    +
    The ogg_packet to decode.
    +
    + + +

    Return Values

    +
    +
  • 0 on success.
    • +
  • OV_ENOTAUDIO if the packet is not an audio packet.
    • +
  • OV_EBADPACKET if there was an error in the packet.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_synthesis_blockin.html b/doc/libvorbis/vorbis_synthesis_blockin.html new file mode 100644 index 0000000..d12fd2a --- /dev/null +++ b/doc/libvorbis/vorbis_synthesis_blockin.html @@ -0,0 +1,69 @@ + + + +libvorbis - function - vorbis_synthesis_blockin + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_synthesis_blockin

    + +

    declared in "vorbis/codec.h";

    + +

    This function submits a vorbis_block +for assembly into the final decoded audio. After calling +this function, decoded audio can be obtained with +vorbis_synthesis_pcmout.

    + + + + + +
    +
    
+extern int      vorbis_synthesis_blockin(vorbis_dsp_state *v,vorbis_block *vb);
+
    +
    + +

    Parameters

    +
    +
    v
    +
    The vorbis_dsp_state for the +decoder instance.
    +
    vb
    +
    The vorbis_block to submit. After +this function returns, it can be reused in another call to +vorbis_synthesis.
    +
    + + +

    Return Values

    +
    +
  • 0 on success.
    • +
  • OV_EINVAL if the decoder is in an invalid state to accept blocks.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_synthesis_halfrate.html b/doc/libvorbis/vorbis_synthesis_halfrate.html new file mode 100644 index 0000000..fefe8d3 --- /dev/null +++ b/doc/libvorbis/vorbis_synthesis_halfrate.html @@ -0,0 +1,68 @@ + + + +libvorbis - function - vorbis_synthesis_halfrate + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_synthesis_halfrate

    + +

    declared in "vorbis/codec.h";

    + +

    This function puts the Vorbis decoder into or out of half-rate +mode. In half-rate mode, the audio is decoded to only half its original +sampling rate. Half-rate mode speeds up decoding at the expense of +decoded audio quality.

    + + + + + +
    +
    
+extern int      vorbis_synthesis_halfrate(vorbis_info *v,int flag);
+
    +
    + +

    Parameters

    +
    +
    v
    +
    The vorbis_info structure for the +decoder instance.
    +
    flag
    +
    Whether half-rate mode is to be turned on or off. Zero turns it off; +nonzero turns it on.
    +
    + + +

    Return Values

    +
    +
  • 0 on success.
    • +
  • -1 if half-rate mode could not be set.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_synthesis_halfrate_p.html b/doc/libvorbis/vorbis_synthesis_halfrate_p.html new file mode 100644 index 0000000..d82880e --- /dev/null +++ b/doc/libvorbis/vorbis_synthesis_halfrate_p.html @@ -0,0 +1,64 @@ + + + +libvorbis - function - vorbis_synthesis_halfrate_p + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_synthesis_halfrate_p

    + +

    declared in "vorbis/codec.h";

    + +

    This function gets whether a decoder is in half-rate mode. See +vorbis_synthesis_halfrate +for more information on half-rate mode.

    + + + + + +
    +
    
+extern int      vorbis_synthesis_halfrate_p(vorbis_info *v);
+
    +
    + +

    Parameters

    +
    +
    v
    +
    The vorbis_info structure for the +decoder instance.
    +
    + + +

    Return Values

    +
    +
  • 1 if half-rate mode is on.
    • +
  • 0 if half-rate mode is off.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_synthesis_headerin.html b/doc/libvorbis/vorbis_synthesis_headerin.html new file mode 100644 index 0000000..835d8ce --- /dev/null +++ b/doc/libvorbis/vorbis_synthesis_headerin.html @@ -0,0 +1,80 @@ + + + +libvorbis - function - vorbis_synthesis_headerin + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_synthesis_headerin

    + +

    declared in "vorbis/codec.h";

    + +

    This function decodes a header packet from a Vorbis stream and applies +the contents to the given vorbis_info +structure (to provide codec parameters to the decoder) and +vorbis_comment structure (to provide +access to the embedded Vorbis comments).

    + +

    Once the three Vorbis header packets (info, comments, +and codebooks, in that order) have been passed to this +function, the vorbis_info +structure is ready to be used in a call to +vorbis_synthesis_init.

    + + + + + +
    +
    
+extern int      vorbis_synthesis_headerin(vorbis_info *vi,vorbis_comment *vc,
+                                          ogg_packet *op);
+
    +
    + +

    Parameters

    +
    +
    vi
    +
    The vorbis_info structure to apply +the decoded information to.
    +
    vc
    +
    The vorbis_comment structure to +apply the decoded comments to.
    +
    op
    +
    The ogg_packet to decode.
    +
    + + +

    Return Values

    +
    +
  • 0 on success.
    • +
  • OV_ENOTVORBIS if the packet is not a Vorbis header packet.
    • +
  • OV_EBADHEADER if there was an error interpreting the packet.
    • +
  • OV_EFAULT on internal error.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_synthesis_idheader.html b/doc/libvorbis/vorbis_synthesis_idheader.html new file mode 100644 index 0000000..7fe99e9 --- /dev/null +++ b/doc/libvorbis/vorbis_synthesis_idheader.html @@ -0,0 +1,63 @@ + + + +libvorbis - function - vorbis_synthesis_idheader + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_synthesis_idheader

    + +

    declared in "vorbis/codec.h";

    + +

    This function checks whether a packet is a valid Vorbis identification +header packet. This function can be used to detect whether a logical +Ogg stream could be a Vorbis stream, given its very first packet.

    + + + + + +
    +
    
+extern int      vorbis_synthesis_idheader(ogg_packet *op);
+
    +
    + +

    Parameters

    +
    +
    op
    +
    Pointer to the ogg_packet to check.
    +
    + + +

    Return Values

    +
    +
  • 1 if the packet is a valid first packet for a Vorbis bitstream.
    • +
  • 0 if not.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_synthesis_init.html b/doc/libvorbis/vorbis_synthesis_init.html new file mode 100644 index 0000000..64f06b9 --- /dev/null +++ b/doc/libvorbis/vorbis_synthesis_init.html @@ -0,0 +1,69 @@ + + + +libvorbis - function - vorbis_synthesis_init + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_synthesis_init

    + +

    declared in "vorbis/codec.h";

    + +

    This function initializes a +vorbis_dsp_state structure for +decoding and allocates internal storage for it.

    + + + + + +
    +
    
+extern int      vorbis_synthesis_init(vorbis_dsp_state *v,vorbis_info *vi);
+
    +
    + +

    Parameters

    +
    +
    v
    +
    The vorbis_dsp_state to initialize +for decoding.
    +
    vi
    +
    The vorbis_info structure +for the stream. The vorbis_info structure must have had vorbis_synthesis_headerin +called on it for each header packet in the stream.
    +
    + + +

    Return Values

    +
    +
  • 0 on success.
    • +
  • 1 on error.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_synthesis_lapout.html b/doc/libvorbis/vorbis_synthesis_lapout.html new file mode 100644 index 0000000..7fcdf06 --- /dev/null +++ b/doc/libvorbis/vorbis_synthesis_lapout.html @@ -0,0 +1,74 @@ + + + +libvorbis - function - vorbis_synthesis_lapout + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_synthesis_lapout

    + +

    declared in "vorbis/codec.h";

    + +

    This function retrieves buffers containing decoded audio samples, similarly +to vorbis_synthesis_pcmout. +However, it includes some extra samples extrapolated from the end of +the audio, suitable for crosslapping with other blocks. This exists mainly +for libvorbisfile to use for +handling chained bitstreams and bitstreams with holes.

    + + + + + +
    +
    
+extern int      vorbis_synthesis_lapout(vorbis_dsp_state *v,float ***pcm);
+
    +
    + +

    Parameters

    +
    +
    v
    +
    The vorbis_dsp_state for the +decoder instance.
    +
    pcm
    +
    A pointer to a float** which will be made to point to an array of +pointers to the decoded samples for each channel. The memory is owned +by the decoder instance and will be freed when the application continues +decoding or destroys the decoder instance. This can be NULL, in which +case the return value gives the number of samples that would be returned +if this function were called with a non-NULL pointer here.
    +
    + + +

    Return Values

    +
    +
  • The number of samples available in the output buffer.
    • +
  • 0 if no more samples are currently available.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_synthesis_pcmout.html b/doc/libvorbis/vorbis_synthesis_pcmout.html new file mode 100644 index 0000000..0283d88 --- /dev/null +++ b/doc/libvorbis/vorbis_synthesis_pcmout.html @@ -0,0 +1,75 @@ + + + +libvorbis - function - vorbis_synthesis_pcmout + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_synthesis_pcmout

    + +

    declared in "vorbis/codec.h";

    + +

    This function retrieves buffers containing decoded audio samples.

    +

    The application is not required to make use of all of the samples +made available to it by one call to this function before it continues to +decode. Use vorbis_synthesis_read +to inform the decoder of how many samples were actually used. Any +unused samples will be included in the buffers output by the next call +to this function.

    + + + + + +
    +
    
+extern int      vorbis_synthesis_pcmout(vorbis_dsp_state *v,float ***pcm);
+
    +
    + +

    Parameters

    +
    +
    v
    +
    The vorbis_dsp_state for the +decoder instance.
    +
    pcm
    +
    A pointer to a float** which will be made to point to an array of +pointers to the decoded samples for each channel. The memory is owned +by the decoder instance and will be freed when the application continues +decoding or destroys the decoder instance. This can be NULL, in which +case the return value gives the number of samples that would be returned +if this function were called with a non-NULL pointer here.
    +
    + + +

    Return Values

    +
    +
  • The number of samples available in the output buffer.
    • +
  • 0 if no more samples are currently available.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_synthesis_read.html b/doc/libvorbis/vorbis_synthesis_read.html new file mode 100644 index 0000000..4972a85 --- /dev/null +++ b/doc/libvorbis/vorbis_synthesis_read.html @@ -0,0 +1,67 @@ + + + +libvorbis - function - vorbis_synthesis_read + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_synthesis_read

    + +

    declared in "vorbis/codec.h";

    + +

    This function informs the Vorbis decoder of how many +samples the application used from the last buffer output by +vorbis_synthesis_pcmout.

    + + + + + +
    +
    
+extern int      vorbis_synthesis_read(vorbis_dsp_state *v,int samples);
+
    +
    + +

    Parameters

    +
    +
    v
    +
    The vorbis_dsp_state for the +decoder instance.
    +
    samples
    +
    The number of samples the application has used.
    +
    + + +

    Return Values

    +
    +
  • 0 on success.
    • +
  • OV_EINVAL if samples is greater than the number of remaining +samples in the buffer.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_synthesis_restart.html b/doc/libvorbis/vorbis_synthesis_restart.html new file mode 100644 index 0000000..c02385e --- /dev/null +++ b/doc/libvorbis/vorbis_synthesis_restart.html @@ -0,0 +1,64 @@ + + + +libvorbis - function - vorbis_synthesis_restart + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_synthesis_restart

    + +

    declared in "vorbis/codec.h";

    + +

    This function restores a +vorbis_dsp_state structure +representing a decoder to its freshly-initialized state. This should be +called if the application seeks within a Vorbis bitstream.

    + + + + + +
    +
    
+extern int      vorbis_synthesis_restart(vorbis_dsp_state *v);
+
    +
    + +

    Parameters

    +
    +
    v
    +
    The vorbis_dsp_state to reset.
    +
    + + +

    Return Values

    +
    +
  • 0 on success.
    • +
  • -1 on error.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_synthesis_trackonly.html b/doc/libvorbis/vorbis_synthesis_trackonly.html new file mode 100644 index 0000000..dd3e685 --- /dev/null +++ b/doc/libvorbis/vorbis_synthesis_trackonly.html @@ -0,0 +1,71 @@ + + + +libvorbis - function - vorbis_synthesis_trackonly + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_synthesis_trackonly

    + +

    declared in "vorbis/codec.h";

    + +

    This function decodes a Vorbis packet similarly to +vorbis_synthesis, except that the +vorbis_block produced does not contain +any audio data but merely updates the decoder's state as though the +block had been actually decoded when +vorbis_synthesis_blockin +is called on it.

    + + + + + +
    +
    
+extern int      vorbis_synthesis_trackonly(vorbis_block *vb,ogg_packet *op);
+
    +
    + +

    Parameters

    +
    +
    vb
    +
    The vorbis_block to decode the +packet into.
    +
    op
    +
    The ogg_packet to decode.
    +
    + + +

    Return Values

    +
    +
  • 0 on success.
    • +
  • OV_ENOTAUDIO if the packet is not an audio packet.
    • +
  • OV_EBADPACKET if there was an error in the packet.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/libvorbis/vorbis_version_string.html b/doc/libvorbis/vorbis_version_string.html new file mode 100644 index 0000000..e85f23e --- /dev/null +++ b/doc/libvorbis/vorbis_version_string.html @@ -0,0 +1,56 @@ + + + +libvorbis - function - vorbis_version_string + + + + + + + + + +

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + +

    vorbis_version_string

    + +

    declared in "vorbis/codec.h";

    + +

    This function returns a string giving version information for libvorbis. (This is not the same string that libvorbis encodes into the vendor field of comment headers.)

    + + + + + +
    +
    
+extern const char *vorbis_version_string(void);
+
    +
    + +

    Parameters

    +

    None.

    + +

    Return Values

    +
    +
  • The libvorbis version string. The string is in static storage.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2010 Xiph.Org

    Ogg Vorbis

    libvorbis documentation

    libvorbis version 1.3.2 - 20101101

    + + + + + diff --git a/doc/oggstream.html b/doc/oggstream.html new file mode 100644 index 0000000..6952ed9 --- /dev/null +++ b/doc/oggstream.html @@ -0,0 +1,234 @@ + + + + + +Ogg Vorbis Documentation + + + + + + + + + +

    Ogg logical and physical bitstream overview

    + +

    Ogg bitstreams

    + +

    Ogg codecs use octet vectors of raw, compressed data +(packets). 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.

    + +

    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.

    + +

    Logical and physical bitstreams

    + +

    Raw packets are grouped and encoded into contiguous pages of +structured bitstream data called logical bitstreams. 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.

    + +

    Multiple logical bitstreams can be combined (with restrictions) into a +single physical bitstream. 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'.

    + +

    Ogg Logical Bitstream Framing 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.

    + +

    Mapping Restrictions

    + +

    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.

    + +

    additional end-to-end structure

    + +

    The framing specification 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.

    + +

    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.

    + +

    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.

    + +

    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.

    + +

    sequential multiplexing (chaining)

    + +

    The simplest form of logical bitstream multiplexing is concatenation +(chaining). 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.

    + +

    Each chained logical bitstream must have a unique serial number within +the scope of the physical bitstream.

    + +

    concurrent multiplexing (grouping)

    + +

    Logical bitstreams may also be multiplexed 'in parallel' +(grouped). 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.

    + +

    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.

    + +

    Each grouped bitstream must have a unique serial number within the +scope of the physical bitstream.

    + +

    sequential and concurrent multiplexing

    + +

    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.

    + +

    multiplexing example

    + +

    Below, we present an example of a grouped and chained bitstream:

    + +

    stream

    + +

    In this example, we see pages from five total logical bitstreams +multiplexed into a physical bitstream. Note the following +characteristics:

    + +
      +
    1. 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.
      2. + +
    2. The pages of concurrently multiplexed bitstreams need not conform +to a regular order; the only requirement is that page n of a +logical bitstream follow page n-1 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).
      3. +
    + + + + + diff --git a/doc/programming.html b/doc/programming.html new file mode 100644 index 0000000..4b54347 --- /dev/null +++ b/doc/programming.html @@ -0,0 +1,554 @@ + + + + + +Ogg Vorbis Documentation + + + + + + + + + +

    Programming with Xiph.Org libvorbis

    + +

    Description

    + +

    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.

    + +

    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.

    + +

    Encoding Overview

    + +

    Decoding Overview

    + +

    Decoding a bitstream with libvorbis follows roughly the following +steps:

    + +
      +
    1. Frame the incoming bitstream into pages
      2. +
    2. Sort the pages by logical bitstream and buffer then into logical streams
      3. +
    3. Decompose the logical streams into raw packets
      4. +
    4. Reconstruct segments of the original data from each packet
      5. +
    5. Glue the reconstructed segments back into a decoded stream
      6. +
    + +

    Framing

    + +

    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 ogg_sync_state buffer using ogg_sync_buffer() +and ogg_sync_wrote(). 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 ogg_sync_pageout(). Extra pages are +buffered; allowing them to build up in the ogg_sync_state +buffer will eventually exhaust memory.

    + +

    The Ogg pages returned from ogg_sync_pageout 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).

    + +

    Sorting

    + +

    The pages produced by ogg_sync_pageout are then sorted by +serial number to seperate logical bitstreams. Initialize logical +bitstream buffers (og_stream_state) using +ogg_stream_init(). Pages are submitted to the matching +logical bitstream buffer using ogg_stream_pagein; 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 +(ogg_sync_pageout and ogg_stream_packetout will +return a negative value at positions where they had to recapture the +stream).

    + +

    Extracting packets

    + +

    After submitting page[s] to a logical stream, read available packets +using ogg_stream_packetout.

    + +

    Decoding packets

    + +

    Reassembling data segments

    + +

    Ogg Bitstream Manipulation Structures

    + +

    Two of the Ogg bitstream data structures are intended to be +transparent to the developer; the fields should be used directly.

    + +

    ogg_packet

    + +
    +typedef struct {
+  unsigned char *packet;
+  long  bytes;
+  long  b_o_s;
+  long  e_o_s;
+
+  size64 granulepos;
+
+} ogg_packet;
+
    + +
    +
    packet:
    +
    a pointer to the byte data of the raw packet
    +
    bytes:
    +
    the size of the packet' raw data
    +
    b_o_s:
    +
    beginning of stream; nonzero if this is the first packet of + the logical bitstream
    +
    e_o_s:
    +
    end of stream; nonzero if this is the last packet of the + logical bitstream
    +
    granulepos:
    +
    the absolute position of this packet in the original + uncompressed data stream.
    +
    + +

    encoding notes

    + +

    The encoder is responsible for setting all of +the fields of the packet to appropriate values before submission to +ogg_stream_packetin(); however, it is noted that the value in +b_o_s is ignored; the first page produced from a given +ogg_stream_state structure will be stamped as the initial +page. e_o_s, however, must be set; this is the means by +which the stream encoding primitives handle end of stream and cleanup.

    + +

    decoding notes

    + +

    ogg_stream_packetout() 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 +granulepos). Intervening frames will see granulepos set +to -1.

    + +

    ogg_page

    + +
    +typedef struct {
+  unsigned char *header;
+  long header_len;
+  unsigned char *body;
+  long body_len;
+} ogg_page;
+
    + +
    +
    header:
    +
    pointer to the page header data
    +
    header_len:
    +
    length of the page header in bytes
    +
    body:
    +
    pointer to the page body
    +
    body_len:
    +
    length of the page body
    +
    + +

    Note that although the header and body pointers do +not necessarily point into a single contiguous page vector, the page +body must immediately follow the header in the bitstream.

    + +

    Ogg Bitstream Manipulation Functions

    + +

    +int ogg_page_bos(ogg_page *og); +

    + +

    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.

    + +

    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).

    + +

    +int ogg_page_continued(ogg_page *og); +

    + +

    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.

    + +

    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.

    + +

    +int ogg_page_eos(ogg_page *og); +

    + +

    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.

    + +

    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.

    + +

    +size64 ogg_page_granulepos(ogg_page *og); +

    + +

    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.

    + +

    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.

    + +

    +int ogg_page_pageno(ogg_page *og); +

    + +

    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.

    + +

    +int ogg_page_serialno(ogg_page *og); +

    + +

    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.

    + +

    +int ogg_page_version(ogg_page *og); +

    + +

    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.

    + +

    +int ogg_stream_clear(ogg_stream_state *os); +

    + +

    Clears and deallocates the internal storage of the given Ogg stream. +After clearing, the stream structure is not initialized for use; +ogg_stream_init must be called to reinitialize for use. +Use ogg_stream_reset to reset the stream state +to a fresh, intiialized state.

    + +

    ogg_stream_clear does not call free() on the pointer +os, allowing use of this call on stream structures in static +or automatic storage. ogg_stream_destroyis a complimentary +function that frees the pointer as well.

    + +

    Returns zero on success and non-zero on failure. This function always +succeeds.

    + +

    +int ogg_stream_destroy(ogg_stream_state *os); +

    + +

    Clears and deallocates the internal storage of the given Ogg stream, +then frees the storage associated with the pointer os.

    + +

    ogg_stream_clear does not call free() on the pointer +os, allowing use of that call on stream structures in static +or automatic storage.

    + +

    Returns zero on success and non-zero on failure. This function always +succeeds.

    + +

    +int ogg_stream_init(ogg_stream_state *os,int serialno); +

    + +

    Initialize the storage associated with os 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).

    + +

    Returns zero on success, nonzero on failure.

    + +

    +int ogg_stream_packetin(ogg_stream_state *os, ogg_packet *op); +

    + +

    Used during encoding to add the given raw packet to the given Ogg +bitstream. The contents of op are copied; +ogg_stream_packetin does not retain any pointers into +op's storage. The encoding proccess buffers incoming packets +until enough packets have been assembled to form an entire page; +ogg_stream_pageout is used to read complete pages.

    + +

    Returns zero on success, nonzero on failure.

    + +

    +int ogg_stream_packetout(ogg_stream_state *os,ogg_packet *op); +

    + +

    Used during decoding to read raw packets from the given logical +bitstream. ogg_stream_packetout 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.

    + +

    Returns zero if the next packet is not ready to be read (not buffered +or incomplete), positive if it returned a complete packet in +op 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.

    + +

    If the return value is positive, ogg_stream_packetout placed +a packet in op. The data in op points to static +storage that is valid until the next call to +ogg_stream_pagein, ogg_stream_clear, +ogg_stream_reset, or ogg_stream_destroy. The +pointers are not invalidated by more calls to +ogg_stream_packetout.

    + +

    +int ogg_stream_pagein(ogg_stream_state *os, ogg_page *og); +

    + +

    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 ogg_sync_pageout, and from the logical +bitstream associated with os (the serial numbers must match). +The contents of the given page are copied; ogg_stream_pagein +retains no pointers into og storage.

    + +

    Returns zero on success and non-zero on failure.

    + +

    +int ogg_stream_pageout(ogg_stream_state *os, ogg_page *og); +

    + +

    Used during encode to read complete pages from the stream buffer. The +returned page is ready for sending out to the real world.

    + +

    Returns zero if there is no complete page ready for reading. Returns +nonzero when it has placed data for a complete page into +og. Note that the storage returned in og points into internal +storage; the pointers in og are valid until the next call to +ogg_stream_pageout, ogg_stream_packetin, +ogg_stream_reset, ogg_stream_clear or +ogg_stream_destroy.

    + +

    +int ogg_stream_reset(ogg_stream_state *os); +

    + +

    Resets the given stream's state to that of a blank, unused stream; +this may be used during encode or decode.

    + +

    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.

    + +

    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.

    + +

    Returns zero on success and non-zero on failure. This function always +succeeds.

    + +

    +char *ogg_sync_buffer(ogg_sync_state *oy, long size); +

    + +

    This call is used to buffer a raw bitstream for framing and +verification. ogg_sync_buffer handles stream capture and +recapture, checksumming, and division into Ogg pages (as required by +ogg_stream_pagein).

    + +

    ogg_sync_buffer exposes a buffer area into which the decoder +copies the next (up to) size bytes. We expose the buffer +(rather than taking a buffer) in order to avoid an extra copy many +uses; this way, for example, read() can transfer data +directly into the stream buffer without first needing to place it in +temporary storage.

    + +

    Returns a pointer into oy's internal bitstream sync buffer; +the remaining space in the sync buffer is at least size +bytes. The decoder need not write all of size bytes; +ogg_sync_wrote is used to inform the engine how many bytes +were actually written. Use of ogg_sync_wrote after writing +into the exposed buffer is mandantory.

    + +

    +int ogg_sync_clear(ogg_sync_state *oy); +

    + +

    ogg_sync_clear +clears and deallocates the internal storage of the given Ogg sync +buffer. After clearing, the sync structure is not initialized for +use; ogg_sync_init must be called to reinitialize for use. +Use ogg_sync_reset to reset the sync state and buffer to a +fresh, intiialized state.

    + +

    ogg_sync_clear does not call free() on the pointer +oy, allowing use of this call on sync structures in static +or automatic storage. ogg_sync_destroyis a complimentary +function that frees the pointer as well.

    + +

    Returns zero on success and non-zero on failure. This function always +succeeds.

    + +

    +int ogg_sync_destroy(ogg_sync_state *oy); +

    + +

    Clears and deallocates the internal storage of the given Ogg sync +buffer, then frees the storage associated with the pointer +oy.

    + +

    An alternative function,ogg_sync_clear, does not call +free() on the pointer oy, allowing use of that call on +stream structures in static or automatic storage.

    + +

    Returns zero on success and non-zero on failure. This function always +succeeds.

    + +

    +int ogg_sync_init(ogg_sync_state *oy); +

    + +

    Initializes the sync buffer oy for use.

    + +

    Returns zero on success and non-zero on failure. This function always +succeeds.

    + +

    +int ogg_sync_pageout(ogg_sync_state *oy, ogg_page *og); +

    + +

    Reads complete, framed, verified Ogg pages from the sync buffer, +placing the page data in og.

    + +

    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 +og. Note that the data in og points into the sync +buffer storage; the pointers are valid until the next call to +ogg_sync_buffer, ogg_sync_clear, +ogg_sync_destroy or ogg_sync_reset.

    + +

    +int ogg_sync_reset(ogg_sync_state *oy); +

    + +

    ogg_sync_reset resets the sync state in oy to a +clean, empty state. This is useful, for example, when seeking to a +new location in a bitstream.

    + +

    Returns zero on success, nonzero on failure.

    + +

    +int ogg_sync_wrote(ogg_sync_state *oy, long bytes); +

    + +

    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.

    + +

    Returns zero on success and non-zero on failure; failure occurs only +when the number of bytes written were larger than the buffer.

    + + + + + diff --git a/doc/release.txt b/doc/release.txt new file mode 100644 index 0000000..38d90d7 --- /dev/null +++ b/doc/release.txt @@ -0,0 +1,16 @@ +libvorbis release checklist. + +- Bump vendor string for encoder changes in lib/info.c +- Bump release version and sonames in configure.ac +- Update CHANGES. +- Update overall copyright dates on COPYING and README. +- Verify everything is committed. +- Tag release: `git tag -S v1.x.y` Paste the CHANGES entry as a tag msg. +- Verify 'make distcheck' works. +- Publish the tag: `git push --tags` +- Copy source packages to a checkout of https://svn.xiph.org/releases/vorbis/ +- Add the packages to the repo and update checksum files there. +- Update https://xiph.org/downloads/ +- Update topic in the #vorbis irc channel on freenode.net. +- Post announcement to https://xiph.org/press/ and link from front page. +- Announce new release to mailing list. diff --git a/doc/residue-pack.png b/doc/residue-pack.png new file mode 100644 index 0000000..6ed071b Binary files /dev/null and b/doc/residue-pack.png differ diff --git a/doc/residue2.png b/doc/residue2.png new file mode 100644 index 0000000..e8bde32 Binary files /dev/null and b/doc/residue2.png differ diff --git a/doc/rfc5215.txt b/doc/rfc5215.txt new file mode 100755 index 0000000..67adf92 --- /dev/null +++ b/doc/rfc5215.txt @@ -0,0 +1,1459 @@ + + + + + + +Network Working Group L. Barbato +Request for Comments: 5215 Xiph +Category: Standards Track August 2008 + + + RTP Payload Format for Vorbis Encoded Audio + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document describes an RTP payload format for transporting Vorbis + encoded audio. It details the RTP encapsulation mechanism for raw + Vorbis data and the delivery mechanisms for the decoder probability + model (referred to as a codebook), as well as 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 Standards Track [Page 1] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Conformance and Document Conventions . . . . . . . . . . . 3 + 2. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 5 + 2.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.4. Example RTP Packet . . . . . . . . . . . . . . . . . . . . 8 + 3. Configuration Headers . . . . . . . . . . . . . . . . . . . . 8 + 3.1. In-band Header Transmission . . . . . . . . . . . . . . . 9 + 3.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 10 + 3.2. Out of Band Transmission . . . . . . . . . . . . . . . . . 12 + 3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 12 + 3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 13 + 4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 13 + 5. Frame Packetization . . . . . . . . . . . . . . . . . . . . . 14 + 5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 15 + 5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 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 . . . . . . . . . . 22 + 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 22 + 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 9.1. Stream Radio . . . . . . . . . . . . . . . . . . . . . . . 22 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 + 11. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 23 + 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 13.1. Normative References . . . . . . . . . . . . . . . . . . . 24 + 13.2. Informative References . . . . . . . . . . . . . . . . . . 25 + + + + + + + + + + + + + + + + + +Barbato Standards Track [Page 2] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + +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 bit rates. At the high quality/ + bitrate end of the scale (CD or DAT rate stereo, 16/24 bits), it is + in the same league as MPEG-4 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 [RFC3533], 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. Conformance and Document Conventions + + 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 BCP 14, [RFC2119] and + indicate requirement levels for compliant implementations. + Requirements apply to all implementations unless otherwise stated. + + An implementation is a software module that supports one of the media + types defined in this document. Software modules may support + multiple media types, but conformance is considered individually for + each type. + + Implementations that fail to satisfy one or more "MUST" requirements + are considered non-compliant. Implementations that satisfy all + "MUST" requirements, but fail to satisfy one or more "SHOULD" + requirements, are said to be "conditionally compliant". All other + implementations are "unconditionally compliant". + +2. Payload Format + + For RTP-based transport of Vorbis-encoded audio, the standard RTP + header is followed by a 4-octet payload header, and then the payload + data. The payload headers are used to associate the Vorbis data with + its associated decoding codebooks as well as indicate 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 data; an RTP + payload MUST contain just one of them at a time. + + + + + +Barbato Standards Track [Page 3] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + +2.1. RTP Header + + The format of the RTP header is specified in [RFC3550] and shown in + Figure 1. This payload format uses the fields of the header in a + manner consistent with that specification. + + 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 [RFC3550] and [RFC3551] 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 [RFC3550]. + + Extension (X): 1 bit + + The Extension bit is used in accordance with [RFC3550]. + + CSRC count (CC): 4 bits + + The CSRC count is used in accordance with [RFC3550]. + + Marker (M): 1 bit + + Set to zero. Audio silence suppression is not used. This conforms + to Section 4.1 of [VORBIS-SPEC-REF]. + + + + +Barbato Standards Track [Page 4] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + 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 that designates the payload as Vorbis. + + 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 + the packet sequence. This field is detailed further in [RFC3550]. + + Timestamp: 32 bits + + A timestamp representing the sampling time of the first sample of the + first Vorbis packet in the RTP payload. The clock frequency MUST be + set to the sample rate of the encoded audio data and is conveyed out- + of-band (e.g., as an 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 [RFC3550]. + +2.2. Payload Header + + The 4 octets following the RTP Header section are the Payload Header. + This header is split into a number of bit fields 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 a network byte order integer. + + Fragment type (F): 2 bits + + + + + + + +Barbato Standards Track [Page 5] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + 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 + + 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 + packet (e.g., you must not aggregate configuration and comment + packets in the same RTP payload). + + 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 payload 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 [LIBVORBIS] 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. + + + + + + + +Barbato Standards Track [Page 6] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + 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, and is followed by the raw Vorbis data padded to the nearest + byte boundary, as explained by the Vorbis I Specification + [VORBIS-SPEC-REF]. The length value is stored as a network byte + order integer. + + For payloads that 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. + + The Vorbis packet length header is the length of the Vorbis data + block only and does not include the length field. + + The payload packing of the Vorbis data packets MUST follow the + guidelines set out in [RFC3551], where the oldest Vorbis packet + occurs immediately after the RTP packet header. Subsequent Vorbis + packets, if any, MUST follow in temporal order. + + Audio channel mapping is in accordance with the Vorbis I + Specification [VORBIS-SPEC-REF]. + + + + + + + + + + + + + + + + + + + + + + +Barbato Standards Track [Page 7] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + +2.4. Example RTP Packet + + Here is an example RTP payload containing two Vorbis 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 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 bit field 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. + +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 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 + + + +Barbato Standards Track [Page 8] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + information are often referred to collectively as the "codebooks" for + a Vorbis stream, and are included as special "header" packets at the + start of the compressed data. In addition, the Vorbis I + specification [VORBIS-SPEC-REF] requires the presence of a comment + header packet that 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 are detailed below. In order to + set up an initial state for the client application, the configuration + MUST be conveyed via the signalling channel used to set up the + session. One example of such signalling is SDP [RFC4566] with the + Offer/Answer Model [RFC3264]. Changes to the configuration MAY be + communicated via a re-invite, conveying a new SDP, or sent in-band in + the RTP channel. Implementations MUST support an in-band delivery of + updated codebooks, and SHOULD support out-of-band codebook update + using a new SDP file. The changes may be due to different codebooks + as well as different bitrates of the RTP stream. + + For non-chained streams, the recommended Configuration delivery + method is inside the Packed Configuration (Section 3.1.1) in the SDP + as explained the Mapping Media Type Parameters into SDP + (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. If the client + detects a change in the Ident value and does not have this + information, it MUST NOT decode the raw associated Vorbis data 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 [RFC4588] the configuration headers. The RTP timestamp value MUST + reflect the transmission time of the first data packet for which this + configuration applies. + + + + + +Barbato Standards Track [Page 9] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + +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 [VORBIS-SPEC-REF], 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 stores Xiph codec configurations in a + generic way: 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), and 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 byte order; every byte has the most + significant bit used as a flag, and the following 7 bits are used to + store the value. The first 7 most significant bits are stored in the + first byte. If there are remaining bits, the flag bit is set to 1 + and the subsequent 7 bits 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. To decode, + simply iterate over the bytes until the flag bit is 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 as they are present in Ogg + [VORBIS-SPEC-REF]: Identification, Comment, Setup. + + The 2 byte length tag defines the length of the packed headers as the + sum of the Configuration, Comment, and Setup lengths. + + + + + + + + + + + + + + + + + + + + +Barbato Standards Track [Page 10] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + 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 | 1 | 1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 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 because the packet bears the full Packed configuration. The + number of the packet is set to 1. + + + + + +Barbato Standards Track [Page 11] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + +3.2. Out of Band Transmission + + The following packet definition MUST be used when Configuration is + inside 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-byte ordered) count field, which details the + number of packed headers that are contained in the bundle. The + following shows the Packed header payload for each chained Vorbis + stream. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Number of packed headers | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packed header | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packed header | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: Packed Headers Overview + + + + + + + + + + + + + + + + + + + + + + + +Barbato Standards Track [Page 12] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + 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 leads to a situation where it will not be possible to + successfully decode the stream. Implementations MAY try to recover + from an error by requesting again the missing Configuration or, if + the delivery method is in-band, by buffering the payloads waiting for + the Configuration needed to decode them. The baseline reaction + SHOULD either be reset or end the RTP session. + +4. Comment Headers + + Vorbis Data Type flag set to 2 indicates that the packet contains the + comment metadata, such as artist name, track title, and so on. These + metadata messages are not intended to be fully descriptive but rather + 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 I Specification [VORBIS-SPEC-REF]. + + + +Barbato Standards Track [Page 13] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + 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-byte length field is necessary since this packet could be + fragmented. + +5. Frame Packetization + + Each RTP payload 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 payload 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 + [RFC1191] and [RFC1981]. + + 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 consecutive fragments MUST be sent without any + other payload being sent between the first and the last fragment. + The RTP payload 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 + + + +Barbato Standards Track [Page 14] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + the sequence number incremented as normal for the subsequent RTP + payloads; this will affect the RTCP jitter measurement. The length + field shows the fragment length. + +5.1. Example Fragmented Vorbis Packet + + Here is an example of a fragmented Vorbis packet split over three RTP + payloads. Each of them contains the standard RTP headers as well as + the 4-octet 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 payload, 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 Standards Track [Page 15] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + 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 types of payloads. 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 payload. + + + + + + + + + + + + + + + + + + + + + +Barbato Standards Track [Page 16] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + 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 payload. The Fragment type is set + to 3 and the packet count remains set to 0. As in the previous + payloads, the timestamp remains set to the first payload timestamp 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 Vorbis fragments and decode the + incomplete packet. If we use the fragmented Vorbis packet example + above and the first RTP payload is lost, the client MUST detect that + the next RTP payload has the packet count field set to 0 and the + Fragment type 2 and MUST drop it. The next RTP payload, which is the + final fragmented packet, MUST be dropped in the same manner. If the + missing RTP payload is the last, the two fragments received 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 Standards Track [Page 17] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + +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 + [RFC3551]. + + channels: indicates the number of audio channels as described in + RTP Profile for Audio and Video Conferences with Minimal + Control [RFC3551]. + + configuration: the base64 [RFC4648] representation of the Packed + Headers (Section 3.2.1). + + Encoding considerations: + + This media type is framed and contains binary data. + + Security considerations: + + See Section 10 of RFC 5215. + + Interoperability considerations: + + None + + Published specification: + + RFC 5215 + + Ogg Vorbis I specification: Codec setup and packet decode. + Available from the Xiph website, http://xiph.org/ + + Applications which use this media type: + + Audio streaming and conferencing tools + + Additional information: + + None + + + + + + +Barbato Standards Track [Page 18] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + Person & email address to contact for further information: + + Luca Barbato: + IETF Audio/Video Transport Working Group + + Intended usage: + + COMMON + + Restriction on usage: + + This media type depends on RTP framing, hence is only defined for + transfer via RTP [RFC3550]. + + Author: + + Luca Barbato + + Change controller: + + IETF AVT Working Group delegated from the IESG + +6.1. Packed Headers IANA Considerations + + The following IANA considerations refers to the split configuration + Packed Headers (Section 3.2.1) used within RFC 5215. + + 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 5215. + + + + + +Barbato Standards Track [Page 19] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + Interoperability considerations: + + None + + Published specification: + + RFC 5215 + + Applications which use this media type: + + Vorbis encoded audio, configuration data + + Additional information: + + None + + Person & email address to contact for further information: + + Luca Barbato: + 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 define the mapping of the parameters + described in the IANA considerations section and their usage in the + Offer/Answer Model [RFC3264]. In order to be forward compatible, the + implementation MUST ignore unknown parameters. + +7.1. Mapping Media Type Parameters into SDP + + The information carried in the Media Type specification has a + specific mapping to fields in the Session Description Protocol (SDP) + [RFC4566], which is commonly used to describe RTP sessions. When SDP + is used to specify sessions, the mapping are as follows: + + + +Barbato Standards Track [Page 20] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + 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 the clock rate. + + o The parameter "channels" also goes in "a=rtpmap" as the channel + count. + + o The mandated parameters "configuration" MUST be included in the + SDP "a=fmtp" attribute. + + 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 port value is specified by the server application bound to the + address specified in the c= line. The channel count value specified + in the rtpmap attribute SHOULD match the current Vorbis stream or + should be considered the maximum number of channels to be expected. + The timestamp clock rate MUST be a multiple of the sample rate; a + different payload number MUST be used if the clock rate changes. The + Configuration payload delivers the exact information, thus the SDP + information SHOULD be considered a hint. An example is found below. + +7.1.1. SDP Example + + The following example shows a basic SDP single stream. The first + configuration packet is inside the SDP; other configurations could be + fetched at any time from the URIs provided. The following base64 + [RFC4648] configuration string is folded in this example due to RFC + line length limitations. + + c=IN IP4 192.0.2.1 + + m=audio RTP/AVP 98 + + a=rtpmap:98 vorbis/44100/2 + + a=fmtp:98 configuration=AAAAAZ2f4g9NAh4aAXZvcmJpcwA...; + + Note that the payload format (encoding) names are commonly shown in + uppercase. Media Type subtypes are commonly shown in lowercase. + 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 a=fmtp line is + + + + +Barbato Standards Track [Page 21] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + a single line, even if it is shown as multiple lines in this document + for clarity. + +7.2. Usage with the SDP Offer/Answer Model + + There are no negotiable parameters. All of them are declarative. + +8. Congestion Control + + The general congestion control considerations for transporting RTP + data apply to Vorbis audio over RTP as well. See the RTP + specification [RFC3550] and any applicable RTP profile (e.g., + [RFC3551]). Audio data can be encoded using a range of different bit + rates, so it is possible to adapt network bandwidth by adjusting the + encoder bit rate in real time or by having multiple copies of content + encoded at different bit rates. + +9. Example + + The following example shows a common usage pattern that MAY be + applied in such a situation. 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 situations: there is one single server + streaming content in multicast, and the clients may start a session + at a random time. The content itself could be a mix of a live stream + (as the webjockey'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. + + Upon joining, the client will receive the current Configuration + necessary to decode the current stream inside 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 inside the SDP is updated. Since the in-band method is + unreliable, an out-of-band fallback is provided. + + The client may 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 [RFC3611] if the server + supports this feature. + + + +Barbato Standards Track [Page 22] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + A server-side optimization would be to keep a hash list of the + Configurations per session, which avoids packing all of them and + sending the same Configuration with different Ident tags. + + A client-side optimization would be to keep a tag list of the + Configurations per session and not process configuration packets that + are already known. + +10. Security Considerations + + RTP packets using this payload format are subject to the security + considerations discussed in the RTP specification [RFC3550], the + base64 specification [RFC4648], and the URI Generic syntax + specification [RFC3986]. Among other considerations, 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. + +11. Copying Conditions + + The authors agree to grant third parties the irrevocable right to + copy, use, and distribute the work, with or without modification, in + any medium, without royalty, provided that, unless separate + permission is granted, redistributed modified works do not contain + misleading author, version, name of work, or endorsement information. + +12. Acknowledgments + + This document is a continuation of the following documents: + + Moffitt, J., "RTP Payload Format for Vorbis Encoded Audio", February + 2001. + + Kerr, R., "RTP Payload Format for Vorbis Encoded Audio", December + 2004. + + The Media Type declaration is a continuation of the following + document: + + Short, B., "The audio/rtp-vorbis MIME Type", January 2008. + + Thanks to the AVT, Vorbis Communities / Xiph.Org Foundation 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, Gianni Ceccarelli, and + + + +Barbato Standards Track [Page 23] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + Alessandro Salvatori. Thanks to the LScube Group, in particular + Federico Ridolfo, Francesco Varano, Giampaolo Mancini, Dario + Gallucci, and Juan Carlos De Martin. + +13. References + +13.1. Normative References + + [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", + RFC 1191, November 1990. + + [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU + Discovery for IP version 6", RFC 1981, + August 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to + Indicate Requirement Levels", BCP 14, RFC 2119, + March 1997. + + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer + Model with Session Description Protocol (SDP)", + RFC 3264, June 2002. + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, July 2003. + + [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for + Audio and Video Conferences with Minimal Control", + STD 65, RFC 3551, July 2003. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, + "Uniform Resource Identifier (URI): Generic + Syntax", STD 66, RFC 3986, January 2005. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: + Session Description Protocol", RFC 4566, + July 2006. + + [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 + Data Encodings", RFC 4648, October 2006. + + [VORBIS-SPEC-REF] "Ogg Vorbis I specification: Codec setup and + packet decode. Available from the Xiph website, + http://xiph.org/vorbis/doc/Vorbis_I_spec.html". + + + + + + +Barbato Standards Track [Page 24] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + +13.2. Informative References + + [LIBVORBIS] "libvorbis: Available from the dedicated website, + http://vorbis.com/". + + [RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format + Version 0", RFC 3533, May 2003. + + [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP + Control Protocol Extended Reports (RTCP XR)", + RFC 3611, November 2003. + + [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. + Hakenberg, "RTP Retransmission Payload Format", + RFC 4588, July 2006. + +Author's Address + + Luca Barbato + Xiph.Org Foundation + + EMail: lu_zero@gentoo.org + URI: http://xiph.org/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barbato Standards Track [Page 25] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + 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@ietf.org. + + + + + + + + + + + + +Barbato Standards Track [Page 26] + diff --git a/doc/rfc5215.xml b/doc/rfc5215.xml new file mode 100755 index 0000000..719c100 --- /dev/null +++ b/doc/rfc5215.xml @@ -0,0 +1,1176 @@ + + + + + + + + + + + + +RTP Payload Format for Vorbis Encoded Audio + + +Xiph.Org Foundation +
    +lu_zero@gentoo.org +http://xiph.org/ +
    +     + + + +General +AVT Working Group +I-D + +Internet-Draft +Vorbis +RTP + +example + + + + +This document describes an RTP payload format for transporting Vorbis encoded +audio. It details the RTP encapsulation mechanism for raw Vorbis data and +the delivery mechanisms for the decoder probability model (referred to +as a codebook), as well as 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). + + + + +     + + + +
    + + +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 bit rates. At the high +quality/bitrate end of the scale (CD or DAT rate stereo, 16/24 bits), it +is in the same league as MPEG-4 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 +, 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. + + +
    + +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 BCP 14, and indicate requirement levels for compliant implementations. Requirements apply to all implementations unless otherwise stated. +An implementation is a software module that supports one of the media types defined in this document. Software modules may support multiple media types, but conformance is considered individually for each type. +Implementations that fail to satisfy one or more "MUST" requirements are considered non-compliant. Implementations that satisfy all "MUST" requirements, but fail to satisfy one or more "SHOULD" requirements, are said to be "conditionally compliant". All other implementations are "unconditionally compliant". + +
    +
    + +
    + + +For RTP-based transport of Vorbis-encoded audio, the standard RTP header is +followed by a 4-octet payload header, and then the payload data. The payload +headers are used to associate the Vorbis data with its associated decoding +codebooks as well as indicate 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 +data; an RTP payload MUST contain just one of them at a time. + + +
    + + +The format of the RTP header is specified in +and shown in . This payload format +uses the fields of the header in a manner consistent with that specification. + + + +
    + +
    +     + + +The RTP header begins with an octet of fields (V, P, X, and CC) to support +specialized RTP uses (see and + 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 +. + + + +Extension (X): 1 bit + +The Extension bit is used in accordance with . + + + +CSRC count (CC): 4 bits + +The CSRC count is used in accordance with . + + + +Marker (M): 1 bit + +Set to zero. Audio silence suppression is not used. This conforms to Section 4.1 +of . + + + +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 that +designates the payload as Vorbis. + + + +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 the packet sequence. This +field is detailed further in . + + + +Timestamp: 32 bits + +A timestamp representing the sampling time of the first sample of the first +Vorbis packet in the RTP payload. The clock frequency MUST be set to the sample +rate of the encoded audio data and is conveyed out-of-band (e.g., as an 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 +. + + +
    + +
    + + +The 4 octets following the RTP Header section are the Payload Header. This +header is split into a number of bit fields detailing the format of the +following payload data packets. + + +
    + +
    + + +Ident: 24 bits + +This 24-bit field is used to associate the Vorbis data to a decoding +Configuration. It is stored as a 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 + +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 packet (e.g., you must not aggregate configuration and comment packets in the same RTP payload). + + + + + 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 +payload contains fragmented data, the number of packets MUST be set to 0. + + +
    + +
    + + +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 + 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. + + +
    + +
    + + +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, and is followed by the +raw Vorbis data padded to the nearest byte boundary, as explained by the Vorbis I Specification. The length value is stored +as a network byte order integer. + + + +For payloads that 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. + + + +The Vorbis packet length header is the length of the Vorbis data block only and +does not include the length field. + + + +The payload packing of the Vorbis data packets MUST follow the guidelines +set out in , where the oldest Vorbis packet occurs +immediately after the RTP packet header. Subsequent Vorbis packets, if any, MUST +follow in temporal order. + + + +Audio channel mapping is in accordance with the +Vorbis I Specification. + + +
    + +
    + + +Here is an example RTP payload containing two Vorbis packets. + + +
    + +
    + + +The payload data section of the RTP packet begins with the 24-bit Ident field +followed by the one octet bit field 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. + + +
    +
    + + + +
    + + +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 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 included as special "header" packets at the start +of the compressed data. In addition, +the Vorbis I specification +requires the presence of a comment header packet that 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 are detailed below. +In order to set up an initial state for the client application, the +configuration MUST be conveyed via the signalling channel used to set up +the session. One example of such signalling is +SDP with the +Offer/Answer Model. +Changes to the configuration MAY be communicated via a re-invite, +conveying a new SDP, or sent in-band in the RTP channel. +Implementations MUST support an in-band delivery of updated codebooks, +and SHOULD support out-of-band codebook update using a new SDP file. +The changes may be due to different codebooks as well as +different bitrates of the RTP stream. + + +For non-chained streams, the recommended Configuration delivery +method is inside the Packed +Configuration in the SDP as explained the Mapping Media Type +Parameters into SDP. + + + +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. If the client detects a change in the Ident value and +does not have this information, it MUST NOT decode the raw associated Vorbis +data until it fetches the correct Configuration. + + +
    + + +The Packed Configuration 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. +The RTP timestamp value MUST reflect the transmission time of the first data packet for which this configuration applies. + + +
    + + +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, 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 stores Xiph codec +configurations in a generic way: 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), and 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 byte order; every byte has the most significant bit used +as a flag, and the following 7 bits are used to store the value. +The first 7 most significant bits are stored in the first byte. +If there are remaining bits, the flag bit is set to 1 and the subsequent +7 bits 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. To decode, simply iterate +over the bytes until the flag bit is 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 as they are present in Ogg : +Identification, Comment, Setup. + + +The 2 byte length tag defines the length of the packed headers as the sum of +the Configuration, Comment, and Setup lengths. + +
    + +
    + +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 because the +packet bears the full Packed configuration. The number of the packet is set to 1. +
    +
    + +
    + + +The following packet definition MUST be used when Configuration is inside +in the SDP. + + +
    + + +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-byte ordered) count field, which details +the number of packed headers that are contained in the bundle. The +following shows the Packed header +payload for each chained Vorbis stream. + + +
    + +
    + +
    + +
    + +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. + +
    + +
    + +
    + + +Unlike the loss of raw Vorbis payload data, loss of a configuration header +leads to a situation where it will not be possible to successfully decode the +stream. Implementations MAY try to recover from an error by requesting again the +missing Configuration or, if the delivery method is in-band, by buffering the +payloads waiting for the Configuration needed to decode them. +The baseline reaction SHOULD either be reset or end the RTP session. + + +
    + +
    + +
    + + +Vorbis Data Type flag set to 2 indicates that the packet contains +the comment metadata, such as artist name, track title, and so on. These +metadata messages are not intended to be fully descriptive but rather 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 I Specification. + +
    + +
    + + +The 2-byte length field is necessary since this packet could be fragmented. + + +
    +
    + + +Each RTP payload 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 +payload 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 and . + + + +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 consecutive +fragments MUST be sent without any other payload being sent between the first +and the last fragment. The RTP payload 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 payloads; this will affect the +RTCP jitter measurement. The length field shows the fragment length. + + +
    + + +Here is an example of a fragmented Vorbis packet split over three RTP payloads. +Each of them contains the standard RTP headers as well as the 4-octet Vorbis +headers. + + +
    + +
    + + +In this payload, 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. + + +
    + +
    + + +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 types of payloads. +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 payload. + + +
    + +
    + + +This is the last Vorbis fragment payload. The Fragment type is set to 3 and the +packet count remains set to 0. As in the previous payloads, the timestamp remains +set to the first payload timestamp in the sequence and the sequence number has +been incremented. + +
    + +
    + + +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 Vorbis fragments and decode the incomplete packet. If we use the +fragmented Vorbis packet example above and the first RTP payload is lost, the +client MUST detect that the next RTP payload has the packet count field set +to 0 and the Fragment type 2 and MUST drop it. +The next RTP payload, which is the final fragmented packet, MUST be dropped +in the same manner. +If the missing RTP payload is the last, the two fragments received 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. + + +
    +
    +
    + + + audio + + vorbis + + + + + indicates the RTP timestamp clock rate as described in RTP Profile for Audio and Video Conferences with Minimal Control. + + + indicates the number of audio channels as described in RTP Profile for Audio and Video Conferences with Minimal Control. + + + + the base64 representation of the Packed Headers. + + + + + + +This media type is framed and contains binary data. + + + + +See Section 10 of RFC 5215. + + + +None + + + +RFC 5215 + +Ogg Vorbis I specification: Codec setup and packet decode. Available from the Xiph website, http://xiph.org/ + + + + + +Audio streaming and conferencing tools + + + +None + + + +Luca Barbato: <lu_zero@gentoo.org>
    + +IETF Audio/Video Transport Working Group + +     + + + +COMMON + + + +This media type depends on RTP framing, hence is only defined for transfer via RTP. + + +Luca Barbato + + +IETF AVT Working Group delegated from the IESG +     + +
    + + +The following IANA considerations refers to the split configuration Packed Headers used within RFC 5215. + + + + audio + + vorbis-config + + + +None + + + + +None + + + + +This media type contains binary data. + + + + +See Section 10 of RFC 5215. + + + + +None + + + + +RFC 5215 + + + + +Vorbis encoded audio, configuration data + + + + +None + + + + +Luca Barbato: <lu_zero@gentoo.org> + +IETF Audio/Video Transport Working Group + + + +COMMON + + + + +This media type doesn't depend on the transport. + + + + +Luca Barbato + + + +IETF AVT Working Group delegated from the IESG + + +
    + +
    + +
    + +The following paragraphs define the mapping of the parameters described in the IANA considerations section and their usage in the Offer/Answer Model. In order to be forward compatible, the implementation MUST ignore unknown parameters. + + +
    + + +The information carried in the Media Type specification has a +specific mapping to fields in the Session Description +Protocol (SDP), which is commonly used to describe RTP sessions. +When SDP is used to specify sessions, the mapping are as follows: + + + + +The type name ("audio") goes in SDP "m=" as the media name. + +The subtype name ("vorbis") goes in SDP "a=rtpmap" as the encoding name. + +The parameter "rate" also goes in "a=rtpmap" as the clock rate. + +The parameter "channels" also goes in "a=rtpmap" as the channel count. + +The mandated parameters "configuration" MUST be included in the SDP +"a=fmtp" attribute. + + + + +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 port value is specified by the server application bound to the address +specified in the c= line. The channel count value specified in the rtpmap +attribute SHOULD match the current Vorbis stream or should be considered the maximum +number of channels to be expected. The timestamp clock rate MUST be a multiple +of the sample rate; a different payload number MUST be used if the clock rate +changes. The Configuration payload delivers the exact information, thus the +SDP information SHOULD be considered a hint. +An example is found below. + + +
    +The following example shows a basic SDP single stream. The first +configuration packet is inside the SDP; other configurations could be +fetched at any time from the URIs provided. The following +base64 configuration string is folded in this +example due to RFC line length limitations. + + + +c=IN IP4 192.0.2.1 +m=audio RTP/AVP 98 +a=rtpmap:98 vorbis/44100/2 +a=fmtp:98 configuration=AAAAAZ2f4g9NAh4aAXZvcmJpcwA...; + +
    + + +Note that the payload format (encoding) names are commonly shown in uppercase. +Media Type subtypes are commonly shown in lowercase. 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 a=fmtp line is a single line, even if it is shown as multiple lines in this document for clarity. + + +
    + +
    + + +There are no negotiable parameters. All of them are declarative. + + +
    + +
    +
    + +The general congestion control considerations for transporting RTP +data apply to Vorbis audio over RTP as well. See the RTP specification + and any applicable RTP profile (e.g., ). +Audio data can be encoded using a range of different bit rates, so +it is possible to adapt network bandwidth by adjusting the encoder +bit rate in real time or by having multiple copies of content encoded + at different bit rates. + +
    +
    + + +The following example shows a common usage pattern that MAY be applied in +such a situation. The main scope of this section is to explain better usage +of the transmission vectors. + + +
    + +This is one of the most common situations: there is one single server streaming +content in multicast, and the clients may start a session at a random time. The +content itself could be a mix of a live stream (as the webjockey'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. + +Upon joining, the client will receive the current Configuration necessary to +decode the current stream inside 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 inside +the SDP is updated. Since the in-band method is unreliable, an out-of-band +fallback is provided. + +The client may 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 if the server supports +this feature. + +A server-side optimization would be to keep a hash list of the +Configurations per session, which avoids packing all of them and sending the same +Configuration with different Ident tags. + +A client-side optimization would be to keep a tag list of the Configurations +per session and not process configuration packets that are already known. + +
    +
    + +
    + +RTP packets using this payload format are subject to the security +considerations discussed in the +RTP specification, the +base64 specification, and the +URI Generic syntax specification. +Among other considerations, 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. + + +
    +
    + The authors agree to grant third parties the irrevocable right to copy, + use, and distribute the work, with or without modification, in any medium, + without royalty, provided that, unless separate permission is granted, + redistributed modified works do not contain misleading author, version, + name of work, or endorsement information. +
    +
    + + +This document is a continuation of the following documents: + +Moffitt, J., "RTP Payload Format for Vorbis Encoded Audio", February 2001. + +Kerr, R., "RTP Payload Format for Vorbis Encoded Audio", December 2004. + +The Media Type declaration is a continuation of the following +document: +Short, B., "The audio/rtp-vorbis MIME Type", January 2008. + + + +Thanks to the AVT, Vorbis Communities / Xiph.Org Foundation 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, Gianni Ceccarelli and Alessandro Salvatori. Thanks to the LScube Group, in particular Federico +Ridolfo, Francesco Varano, Giampaolo Mancini, Dario Gallucci, and Juan Carlos De Martin. + + +
    + +     + + + + + + + + + + + + + + + + + +Ogg Vorbis I specification: Codec setup and packet decode. Available from the Xiph website, http://xiph.org/vorbis/doc/Vorbis_I_spec.html + + + + + + + + + + + +libvorbis: Available from the dedicated website, http://vorbis.com/ + + + + + + + + +     diff --git a/doc/squarepolar.png b/doc/squarepolar.png new file mode 100644 index 0000000..4f9b03d Binary files /dev/null and b/doc/squarepolar.png differ diff --git a/doc/stereo.html b/doc/stereo.html new file mode 100644 index 0000000..9cfbbea --- /dev/null +++ b/doc/stereo.html @@ -0,0 +1,419 @@ + + + + + +Ogg Vorbis Documentation + + + + + + + + + +

    Ogg Vorbis stereo-specific channel coupling discussion

    + +

    Abstract

    + +

    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 +libvorbis codec provided by xiph.org.

    + +

    Mechanisms

    + +

    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 dual +stereo mode and Vorbis uses the same name for its analogous +uncoupled multichannel modes.

    + +

    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 channel interleaving via +residue backend type 2, and the second is square polar +mapping. 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 +lossless stereo image coupling [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.

    + +

    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.

    + + +

    Square Polar Mapping

    + +

    maximal correlation

    + +

    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.

    + +

    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.

    + +

    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.

    + +

    point and diffuse imaging

    + +

    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.

    + +

    *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.

    + +

    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.

    + +

    controlling bit leakage and symbol crosstalk

    + +

    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.

    + +

    eliminating trigonometry and rounding

    + +

    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.

    + +

    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.

    + +

    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):

    + +
    +      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;
+        }
+    }
+
    + +

    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:

    + +

    square polar

    + +

    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:

    + +
    + 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
+
+
    + +

    ...for a grand total of 121 possible values, the same number as in +Cartesian representation (note that, for example, 5,-10 is +the same as -5,10, 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.

    + +

    Channel interleaving

    + +

    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.

    + +

    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.

    + +

    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.

    + +

    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:

    + +
      +
    • Polar mapping aids in controlling entropy 'leakage' between stages +of a cascaded codebook.
      • +
    • Polar mapping separates the stereo image +into point and diffuse components which may be analyzed and handled +differently.
      • +
    + +

    Stereo Models

    + +

    Dual Stereo

    + +

    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.

    + +

    Lossless Stereo

    + +

    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.

    + +

    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.

    + +

    Phase Stereo

    + +

    Phase stereo is the least aggressive means of gracefully dropping +resolution from the stereo image; it affects only diffuse imaging.

    + +

    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.

    + +

    '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)

    + +

    example: eight phase stereo

    + +

    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':

    + +

    eight phase

    + +

    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.

    + +

    example: four phase stereo

    + +

    Similarly, four phase stereo takes the quantization one step further; +it allows only in-phase and 180 degree out-out-phase signals:

    + +

    four phase

    + +

    example: point stereo

    + +

    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.

    + +

    Mixed Stereo

    + +

    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.

    + +

    It is also the case that near-DC frequencies should be encoded using +lossless coupling to avoid frame blocking artifacts.

    + +

    Vorbis Stereo Modes

    + +

    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.

    + + + + + + + + + + + diff --git a/doc/stream.png b/doc/stream.png new file mode 100644 index 0000000..d1d2f36 Binary files /dev/null and b/doc/stream.png differ diff --git a/doc/v-comment.html b/doc/v-comment.html new file mode 100644 index 0000000..aad5e88 --- /dev/null +++ b/doc/v-comment.html @@ -0,0 +1,285 @@ + + + + + +Ogg Vorbis Documentation + + + + + + + + + +

    Ogg Vorbis I format specification: comment field and header specification

    + +

    Overview

    + +

    The Vorbis text comment header is the second (of three) header +packets that begin a Vorbis bitstream. It is meant for short, text +comments, not arbitrary metadata; arbitrary metadata belongs in a +separate logical bitstream (usually an XML stream type) that provides +greater structure and machine parseability.

    + +

    The comment field is meant to be used much like someone jotting a +quick note on the bottom of a CDR. It should be a little information to +remember the disc by and explain it to others; a short, to-the-point +text note that need not only be a couple words, but isn't going to be +more than a short paragraph. The essentials, in other words, whatever +they turn out to be, eg:

    + +

    +"Honest Bob and the Factory-to-Dealer-Incentives, _I'm Still Around_, +opening for Moxy Früvous, 1997" +

    + +

    Comment encoding

    + +

    Structure

    + +

    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".

    + +

    The comment header is decoded as follows:

    + +
    +  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.
+
    + +

    Content vector format

    + +

    The comment vectors are structured similarly to a UNIX environment variable. +That is, comment fields consist of a field name and a corresponding value and +look like:

    + +
    +comment[0]="ARTIST=me"; 
+comment[1]="TITLE=the sound of Vorbis"; 
+
    + +
      +
    • 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).
      • +
    • The field name is immediately followed by ASCII 0x3D ('='); +this equals sign is used to terminate the field name.
      • +
    • 0x3D is followed by the 8 bit clean UTF-8 encoded value of the +field contents to the end of the field.
      • +
    + +

    Field names

    + +

    Below is a proposed, minimal list of standard field names with a +description of intended use. No single or group of field names is +mandatory; a comment header may contain one, all or none of the names +in this list.

    + +
    + +
    TITLE
    +
    Track/Work name
    + +
    VERSION
    +
    The version field may be used to differentiate multiple +versions of the same track title in a single collection. +(e.g. remix info)
    + +
    ALBUM
    +
    The collection name to which this track belongs
    + +
    TRACKNUMBER
    +
    The track number of this piece if part of a specific larger collection or album
    + +
    ARTIST
    +
    The artist generally considered responsible for the work. In popular music +this is usually the performing band or singer. For classical music it would be +the composer. For an audio book it would be the author of the original text.
    + +
    PERFORMER
    +
    The artist(s) who performed the work. In classical music this would be the +conductor, orchestra, soloists. In an audio book it would be the actor who did +the reading. In popular music this is typically the same as the ARTIST and +is omitted.
    + +
    COPYRIGHT
    +
    Copyright attribution, e.g., '2001 Nobody's Band' or '1999 Jack Moffitt'
    + +
    LICENSE
    +
    License information, eg, 'All Rights Reserved', 'Any +Use Permitted', a URL to a license such as a Creative Commons license +("www.creativecommons.org/blahblah/license.html") or the EFF Open +Audio License ('distributed under the terms of the Open Audio +License. see http://www.eff.org/IP/Open_licenses/eff_oal.html for +details'), etc.
    + +
    ORGANIZATION
    +
    Name of the organization producing the track (i.e. +the 'record label')
    + +
    DESCRIPTION
    +
    A short text description of the contents
    + +
    GENRE
    +
    A short text indication of music genre
    + +
    DATE
    +
    Date the track was recorded
    + +
    LOCATION
    +
    Location where track was recorded
    + +
    CONTACT
    +
    Contact information for the creators or distributors of the track. +This could be a URL, an email address, the physical address of +the producing label.
    + +
    ISRC
    +
    ISRC number for the track; see the +ISRC intro page for more information on ISRC numbers.
    + +
    + +

    Implications

    + +
      +
    • Field names should not be 'internationalized'; this is a +concession to simplicity not an attempt to exclude the majority of +the world that doesn't speak English. Field contents, +however, use the UTF-8 character encoding to allow easy representation +of any language.
      • +
    • We have the length of the entirety of the field and restrictions on +the field name so that the field name is bounded in a known way. Thus +we also have the length of the field contents.
      • +
    • Individual 'vendors' may use non-standard field names within +reason. The proper use of comment fields should be clear through +context at this point. Abuse will be discouraged.
      • +
    • There is no vendor-specific prefix to 'nonstandard' field names. +Vendors should make some effort to avoid arbitrarily polluting the +common namespace. We will generally collect the more useful tags +here to help with standardization.
      • +
    • Field names are not required to be unique (occur once) within a +comment header. As an example, assume a track was recorded by three +well know artists; the following is permissible, and encouraged: +
      +              ARTIST=Dizzy Gillespie 
+              ARTIST=Sonny Rollins 
+              ARTIST=Sonny Stitt 
+
      • +
    + +

    Encoding

    + +

    The comment header comprises the entirety of the second bitstream +header packet. Unlike the first bitstream header packet, it is not +generally the only packet on the second page and may not be restricted +to within the second bitstream page. The length of the comment header +packet is (practically) unbounded. The comment header packet is not +optional; it must be present in the bitstream even if it is +effectively empty.

    + +

    The comment header is encoded as follows (as per Ogg's standard +bitstream mapping which renders least-significant-bit of the word to be +coded into the least significant available bit of the current +bitstream octet first):

    + +
      +
    1. Vendor string length (32 bit unsigned quantity specifying number of octets)
      2. +
    2. Vendor string ([vendor string length] octets coded from beginning of string +to end of string, not null terminated)
      3. +
    3. Number of comment fields (32 bit unsigned quantity specifying number of fields)
      4. +
    4. Comment field 0 length (if [Number of comment fields]>0; 32 bit unsigned +quantity specifying number of octets)
      5. +
    5. Comment field 0 ([Comment field 0 length] octets coded from beginning of +string to end of string, not null terminated)
      6. +
    6. Comment field 1 length (if [Number of comment fields]>1...)...
      7. +
    + +

    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()

    + + + + + diff --git a/doc/vorbis-clip.txt b/doc/vorbis-clip.txt new file mode 100644 index 0000000..2e67034 --- /dev/null +++ b/doc/vorbis-clip.txt @@ -0,0 +1,139 @@ +Topic: + +Sample granularity editing of a Vorbis file; inferred arbitrary sample +length starting offsets / PCM stream lengths + +Overview: + +Vorbis, like mp3, is a frame-based* audio compression where audio is +broken up into discrete short time segments. These segments are +'atomic' that is, one must recover the entire short time segment from +the frame packet; there's no way to recover only a part of the PCM time +segment from part of the coded packet without expanding the entire +packet and then discarding a portion of the resulting PCM audio. + +* In mp3, the data segment representing a given time period is called + a 'frame'; the roughly equivalent Vorbis construct is a 'packet'. + +Thus, when we edit a Vorbis stream, the finest physical editing +granularity is on these packet boundaries (the mp3 case is +actually somewhat more complex and mp3 editing is more complicated +than just snipping on a frame boundary because time data can be spread +backward or forward over frames. In Vorbis, packets are all +stand-alone). Thus, at the physical packet level, Vorbis is still +limited to streams that contain an integral number of packets. + +However, Vorbis streams may still exactly represent and be edited to a +PCM stream of arbitrary length and starting offset without padding the +beginning or end of the decoded stream or requiring that the desired +edit points be packet aligned. Vorbis makes use of Ogg stream +framing, and this framing provides time-stamping data, called a +'granule position'; our starting offset and finished stream length may +be inferred from correct usage of the granule position data. + +Time stamping mechanism: + +Vorbis packets are bundled into into Ogg pages (note that pages do not +necessarily contain integral numbers of packets, but that isn't +inportant in this discussion. More about Ogg framing can be found in +ogg/doc/framing.html). Each page that contains a packet boundary is +stamped with the absolute sample-granularity offset of the data, that +is, 'complete samples-to-date' up to the last completed packet of that +page. (The same mechanism is used for eg, video, where the number +represents complete 2-D frames, and so on). + +(It's possible but rare for a packet to span more than two pages such +that page[s] in the middle have no packet boundary; these packets have +a granule position of '-1'.) + +This granule position mechaism in Ogg is used by Vorbis to indicate when the +PCM data intended to be represented in a Vorbis segment begins a +number of samples into the data represented by the first packet[s] +and/or ends before the physical PCM data represented in the last +packet[s]. + +File length a non-integral number of frames: + +A file to be encoded in Vorbis will probably not encode into an +integral number of packets; such a file is encoded with the last +packet containing 'extra'* samples. These samples are not padding; they +will be discarded in decode. + +*(For best results, the encoder should use extra samples that preserve +the character of the last frame. Simply setting them to zero will +introduce a 'cliff' that's hard to encode, resulting in spread-frame +noise. Libvorbis extrapolates the last frame past the end of data to +produce the extra samples. Even simply duplicating the last value is +better than clamping the signal to zero). + +The encoder indicates to the decoder that the file is actually shorter +than all of the samples ('original' + 'extra') by setting the granule +position in the last page to a short value, that is, the last +timestamp is the original length of the file discarding extra samples. +The decoder will see that the number of samples it has decoded in the +last page is too many; it is 'original' + 'extra', where the +granulepos says that through the last packet we only have 'original' +number of samples. The decoder then ignores the 'extra' samples. +This behavior is to occur only when the end-of-stream bit is set in +the page (indicating last page of the logical stream). + +Note that it not legal for the granule position of the last page to +indicate that there are more samples in the file than actually exist, +however, implementations should handle such an illegal file gracefully +in the interests of robust programming. + +Beginning point not on integral packet boundary: + +It is possible that we will the PCM data represented by a Vorbis +stream to begin at a position later than where the decoded PCM data +really begins after an integral packet boundary, a situation analagous +to the above description where the PCM data does not end at an +integral packet boundary. The easiest example is taking a clip out of +a larger Vorbis stream, and choosing a beginning point of the clip +that is not on a packet boundary; we need to ignore a few samples to +get the desired beginning point. + +The process of marking the desired beginning point is similar to +marking an arbitrary ending point. If the encoder wishes sample zero +to be some location past the actual beginning of data, it associates a +'short' granule position value with the completion of the second* +audio packet. The granule position is associated with the second +packet simply by making sure the second packet completes its page. + +*(We associate the short value with the second packet for two reasons. + a) The first packet only primes the overlap/add buffer. No data is + returned before decoding the second packet; this places the decision + information at the point of decision. b) Placing the short value on + the first packet would make the value negative (as the first packet + normally represents position zero); a negative value would break the + requirement that granule positions increase; the headers have + position values of zero) + +The decoder sees that on the first page that will return +data from the overlap/add queue, we have more samples than the granule +position accounts for, and discards the 'surplus' from the beginning +of the queue. + +Note that short granule values (indicating less than the actually +returned about of data) are not legal in the Vorbis spec outside of +indicating beginning and ending sample positions. However, decoders +should, at minimum, tolerate inadvertant short values elsewhere in the +stream (just as they should tolerate out-of-order/non-increasing +granulepos values, although this too is illegal). + +Beginning point at arbitrary positive timestamp (no 'zero' sample): + +It's also possible that the granule position of the first page of an +audio stream is a 'long value', that is, a value larger than the +amount of PCM audio decoded. This implies only that we are starting +playback at some point into the logical stream, a potentially common +occurence in streaming applications where the decoder may be +connecting into a live stream. The decoder should not treat the long +value specially. + +A long value elsewhere in the stream would normally occur only when a +page is lost or out of sequence, as indicated by the page's sequence +number. A long value under any other situation is not legal, however +a decoder should tolerate both possibilities. + + diff --git a/doc/vorbis-errors.txt b/doc/vorbis-errors.txt new file mode 100644 index 0000000..e873d8a --- /dev/null +++ b/doc/vorbis-errors.txt @@ -0,0 +1,103 @@ +Error return codes possible from libvorbis and libvorbisfile: + +All 'failure' style returns are <0; this either indicates a generic +'false' value (eg, ready? T or F) or an error condition. Code can +safely just test for < 0, or look at the specific return code for more +detail. + +*** Return codes: + +OV_FALSE The call returned a 'false' status (eg, ov_bitrate_instant + can return OV_FALSE if playback is not in progress, and thus + there is no instantaneous bitrate information to report. + +OV_HOLE libvorbis/libvorbisfile is alerting the application that + there was an interruption in the data (one of: garbage + between pages, loss of sync followed by recapture, or a + corrupt page) + +OV_EREAD A read from media returned an error. + +OV_EFAULT Internal logic fault; indicates a bug or heap/stack + corruption. + +OV_EIMPL The bitstream makes use of a feature not implemented in this + library version. + +OV_EINVAL Invalid argument value. + +OV_ENOTVORBIS Bitstream/page/packet is not Vorbis data. + +OV_EBADHEADER Invalid Vorbis bitstream header. + +OV_EVERSION Vorbis version mismatch. + +OV_ENOTAUDIO Packet data submitted to vorbis_synthesis is not audio data. + +OV_EBADPACKET Invalid packet submitted to vorbis_synthesis. + +OV_EBADLINK Invalid stream section supplied to libvorbis/libvorbisfile, + or the requested link is corrupt. + +OV_ENOSEEK Bitstream is not seekable. + + +**************************************************************** +*** Libvorbis functions that can return failure/error codes: + +int vorbis_analysis_headerout() + OV_EIMPL + +int vorbis_analysis_wrote() + OV_EINVAL + +int vorbis_synthesis_headerin() + OV_ENOTVORBIS, OV_EVERSION, OV_EBADHEADER + +int vorbis_synthesis() + OV_ENOTAUDIO, OV_EBADPACKET + +int vorbis_synthesis_read() + OV_EINVAL + +**************************************************************** +*** Libvorbisfile functions that can return failure/error codes: + +int ov_open_callbacks() + OV_EREAD, OV_ENOTVORBIS, OV_EVERSION, OV_EBADHEADER, OV_FAULT + +int ov_open() + OV_EREAD, OV_ENOTVORBIS, OV_EVERSION, OV_EBADHEADER, OV_FAULT + +long ov_bitrate() + OV_EINVAL, OV_FALSE + +long ov_bitrate_instant() + OV_FALSE + +ogg_int64_t ov_raw_total() + OV_EINVAL + +ogg_int64_t ov_pcm_total() + OV_EINVAL + +double ov_time_total() + OV_EINVAL + +int ov_raw_seek() + OV_ENOSEEK, OV_EINVAL, OV_BADLINK + +int ov_pcm_seek_page() + OV_ENOSEEK, OV_EINVAL, OV_EREAD, OV_BADLINK, OV_FAULT + +int ov_pcm_seek() + OV_ENOSEEK, OV_EINVAL, OV_EREAD, OV_BADLINK, OV_FAULT + +int ov_time_seek() + OV_ENOSEEK, OV_EINVAL, OV_EREAD, OV_BADLINK, OV_FAULT + +int ov_time_seek_page() + OV_ENOSEEK, OV_EINVAL, OV_EREAD, OV_BADLINK, OV_FAULT + +long ov_read() + OV_HOLE, OV_EBADLINK diff --git a/doc/vorbis-fidelity.html b/doc/vorbis-fidelity.html new file mode 100644 index 0000000..2321d67 --- /dev/null +++ b/doc/vorbis-fidelity.html @@ -0,0 +1,180 @@ + + + + + +Ogg Vorbis Documentation + + + + + + + + + +

    Ogg Vorbis: Fidelity measurement and terminology discussion

    + +

    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.

    + +

    Subjective and Objective

    + +

    Objective 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.

    + +

    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 subjective and +difficult to measure but nonetheless real.

    + +

    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.

    + +

    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.

    + +

    Fidelity, Artifacts and Differences

    + +

    Audio artifacts and loss of fidelity or more simply +put, audio differences are not the same thing.

    + +

    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 not 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.

    + +

    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.

    + +

    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.

    + +

    Thus, when a CODEC must sacrifice subjective quality in order +to satisfy a user's requirements, the result should be a +difference that is generally either difficult to notice +without comparison, or easy to ignore. An artifact, 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 artifact. This +working definition differs slightly from common usage, but the coined +distinction between differences and artifacts is useful for our +discussion.

    + +

    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.

    + + + + + diff --git a/doc/vorbisenc/Makefile.am b/doc/vorbisenc/Makefile.am new file mode 100644 index 0000000..bbab3c5 --- /dev/null +++ b/doc/vorbisenc/Makefile.am @@ -0,0 +1,11 @@ +## Process this file with automake to produce Makefile.in + +docdir = $(datadir)/doc/$(PACKAGE)-$(VERSION)/vorbisenc + +doc_DATA = changes.html examples.html index.html ovectl_ratemanage2_arg.html \ + ovectl_ratemanage_arg.html overview.html reference.html style.css\ + vorbis_encode_ctl.html vorbis_encode_init.html vorbis_encode_setup_init.html \ + vorbis_encode_setup_managed.html vorbis_encode_setup_vbr.html \ + vorbis_encode_init_vbr.html + +EXTRA_DIST = $(doc_DATA) diff --git a/doc/vorbisenc/changes.html b/doc/vorbisenc/changes.html new file mode 100644 index 0000000..eb8460e --- /dev/null +++ b/doc/vorbisenc/changes.html @@ -0,0 +1,104 @@ + + + +libvorbisenc - Documentation + + + + + + + + + +

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + +

    Libvorbisenc API changes 1.0 through 1.1

    + +This document describes API additions to libvorbisenc between release +1.0 and 1.1. + +

    1.0.1

    + +The programming API and binary application ABI are unchanged and fully +forward/backward compatible between release 1.0 and 1.0.1. Libvorbis, +libvorbisenc and libvorbisfile must match versions amongst themselves, +however. + +

    1.1

    + +The binary ABI from release 1.0.1 to 1.1 is backward compatible; +applications linked against libvorbis/libvorbisenc 1.0 and 1.0.1 will +continue to function correctly when upgrading the libvorbis and +libvorbisenc dynamic libraries without re-linking.

    + +Release 1.1 adds several possible requests to the libvorbisenc vorbis_encode_ctl() call in order to +reflect the shift to bit-reservoir style +bitrate management. In addition, several vorbis_encode_ctl() requests are +deprecated (but functional) as they are redered semantically obsolete +by the new bitrate management.

    + +

    Deprecated in 1.1

    + +These calls are still available to older codebases to preserve +compatability; the fields of the ovectl_ratemanage_arg argument +are mapped as closely as possible to the fields of the new ovectl_ratemanage2_arg +structure. + +
    +
    OV_ECTL_RATEMANAGE_GET:
    Use OV_ECTL_RATEMANAGE2_GET +instead. + + +
    OV_ECTL_RATEMANAGE_SET:
    Use OV_ECTL_RATEMANAGE2_SET +instead. + +
    OV_ECTL_RATEMANAGE_AVG:
    Use OV_ECTL_RATEMANAGE2_SET +instead. + +
    OV_ECTL_RATEMANAGE_HARD:
    Use OV_ECTL_RATEMANAGE2_SET +instead. +
    + +

    Newly added in 1.1

    + +The following calls are added in 1.1 to semantically reflect movement +to a bit-reservoir-based bitrate +management scheme by introducing the ovectl_ratemanage2_arg +structure in order to better represent the abilities of the bitrate +manager.

    + +

    +
    OV_ECTL_RATEMANAGE2_GET
    + +Used to query the current state of bitrate management setup. + +
    OV_ECTL_RATEMANAGE2_SET
    + +Used to set or alter bitrate management settings. +
    + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisenc/examples.html b/doc/vorbisenc/examples.html new file mode 100644 index 0000000..1fcc7e0 --- /dev/null +++ b/doc/vorbisenc/examples.html @@ -0,0 +1,133 @@ + + + +libvorbisenc - Documentation + + + + + + + + + +

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + +

    Libvorbisenc Setup Examples

    + +VBR is always the recommended mode for Vorbis encoding when +there's no need to impose bitrate constraints. True VBR encoding will +always produce the most consistent quality output as well as the +highest quality for a the bits used. + +

    The following code examples prepare a +vorbis_info structure for encoding +use with libvorbis.

    + +

    Example: encoding using a VBR quality mode

    + + +
     
+   vorbis_info_init(&vi);
+
+  /*********************************************************************
+   Encoding using a VBR quality mode.  The usable range is -.1
+   (lowest quality, smallest file) to 1.0 (highest quality, largest file).
+   Example quality mode .4: 44kHz stereo coupled, roughly 128kbps VBR 
+   *********************************************************************/
+  
+   ret = vorbis_encode_init_vbr(&vi,2,44100,.4);
+
+  /*********************************************************************
+   do not continue if setup failed; this can happen if we ask for a
+   mode that libVorbis does not support (eg, too low a quality mode, etc,
+   will return 'OV_EIMPL')
+   *********************************************************************/
+
+   if(ret) exit(1);
+
    + +

    Example: encoding using average bitrate (ABR)

    + + +
     
+   vorbis_info_init(&vi);
+
+  /*********************************************************************
+   Encoding using an average bitrate mode (ABR).
+   example: 44kHz stereo coupled, average 128kbps ABR 
+   *********************************************************************/
+  
+   ret = vorbis_encode_init(&vi,2,44100,-1,128000,-1);
+
+  /*********************************************************************
+   do not continue if setup failed; this can happen if we ask for a
+   mode that libVorbis does not support (eg, too low a bitrate, etc,
+   will return 'OV_EIMPL')
+   *********************************************************************/
+
+   if(ret) exit(1);
+
    + +

    Example: encoding using constant bitrate (CBR)

    + + +
     
+   vorbis_info_init(&vi);
+
+  /*********************************************************************
+   Encoding using a constant bitrate mode (CBR).
+   example: 44kHz stereo coupled, average 128kbps CBR 
+   *********************************************************************/
+  
+   ret = vorbis_encode_init(&vi,2,44100,128000,128000,128000);
+
+  /*********************************************************************
+   do not continue if setup failed; this can happen if we ask for a
+   mode that libVorbis does not support (eg, too low a bitrate, etc,
+   will return 'OV_EIMPL')
+   *********************************************************************/
+
+   if(ret) exit(1);
+
    + +

    Example: encoding using VBR selected by approximate bitrate

    + + +
     
+   vorbis_info_init(&vi);
+
+  /*********************************************************************
+   Encode using a quality mode, but select that quality mode by asking for
+   an approximate bitrate.  This is not ABR, it is true VBR, but selected
+   using the bitrate interface, and then turning bitrate management off:
+   *********************************************************************/
+
+   ret = ( vorbis_encode_setup_managed(&vi,2,44100,-1,128000,-1) ||
+           vorbis_encode_ctl(&vi,OV_ECTL_RATEMANAGE2_SET,NULL) ||
+           vorbis_encode_setup_init(&vi));
+
+  /*********************************************************************
+   do not continue if setup failed; this can happen if we ask for a
+   mode that libVorbis does not support (eg, too low a bitrate, etc,
+   will return 'OV_EIMPL')
+   *********************************************************************/
+
+   if(ret) exit(1);
+
    + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisenc/index.html b/doc/vorbisenc/index.html new file mode 100644 index 0000000..ec9b988 --- /dev/null +++ b/doc/vorbisenc/index.html @@ -0,0 +1,40 @@ + + + +libvorbisenc - Documentation + + + + + + + + + +

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + +

    Libvorbisenc Documentation

    + +

    +Libvorbisenc is a convenient API for setting up an encoding environment using libvorbis. Libvorbisenc encapsulates the actions needed to set up the encoder properly. +

    +libvorbisenc api overview
    +libvorbisenc api reference
    +libvorbisenc api changes from 1.0 and 1.0.1
    +libvorbisenc encode setup examples
    + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisenc/ovectl_ratemanage2_arg.html b/doc/vorbisenc/ovectl_ratemanage2_arg.html new file mode 100644 index 0000000..3d9d417 --- /dev/null +++ b/doc/vorbisenc/ovectl_ratemanage2_arg.html @@ -0,0 +1,92 @@ + + + +vorbis - datatype - ovectl_ratemanage2_arg + + + + + + + + + +

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + +

    ovectl_ratemanage2_arg

    + +

    declared in "vorbis/vorbisenc.h"

    + +

    + +The ovectl_ratemanage2_arg structure is used with vorbis_encode_ctl() and the OV_ECTL_RATEMANAGE2_GET and +OV_ECTL_RATEMANAGE2_SET calls in order to query and modify specifics +of the encoder's bitrate management configuration. + +

    + + + + + +
    +
    struct ovectl_ratemanage2_arg {
+  int    management_active;
+
+  long   bitrate_limit_min_kbps;
+  long   bitrate_limit_max_kbps;
+  long   bitrate_limit_reservoir_bits;
+  double bitrate_limit_reservoir_bias;
+
+  long   bitrate_average_kbps;
+  double bitrate_average_damping;
+};
    +
    + +

    Relevant Struct Members

    +
    +
    management_active
    +
    nonzero if bitrate management is active
    + +
    bitrate_limit_min_kbps
    +
    Lower allowed bitrate limit in kilobits per second
    +
    bitrate_limit_max_kbps
    +
    Upper allowed bitrate limit in kilobits per second
    +
    bitrate_limit_reservoir_bits
    +
    Size of the bitrate reservoir in bits
    +
    bitrate_limit_reservoir_bias
    + +
    Regulates the bitrate reservoir's preferred fill level in a range +from 0.0 to 1.0; 0.0 tries to bank bits to buffer against future +bitrate spikes, 1.0 buffers against future sudden drops in +instantaneous bitrate. Default is 0.1
    + +
    bitrate_average_kbps
    +
    Average bitrate setting in kilobits per second
    + +
    bitrate_average_damping
    Slew rate limit setting +for average bitrate adjustment; sets the minimum time in seconds the +bitrate tracker may swing from one extreme to the other when boosting +or damping average bitrate.
    + + + +
    + + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisenc/ovectl_ratemanage_arg.html b/doc/vorbisenc/ovectl_ratemanage_arg.html new file mode 100644 index 0000000..48f5a62 --- /dev/null +++ b/doc/vorbisenc/ovectl_ratemanage_arg.html @@ -0,0 +1,92 @@ + + + +vorbis - datatype - ovectl_ratemanage_arg + + + + + + + + + +

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + +

    ovectl_ratemanage_arg

    + +

    declared in "vorbis/vorbisenc.h"

    + +

    + +The ovectl_ratemanage_arg structure is used with vorbis_encode_ctl() and the OV_ECTL_RATEMANAGE_GET, +OV_ECTL_RATEMANAGE_SET, OV_ECTL_RATEMANAGE_AVG, +OV_ECTL_RATEMANAGE_HARD calls in order to query and modify specifics +of the encoder's bitrate management configuration. Note that this is +a deprecated interface; please use vorbis_encode_ctl() with the ovectl_ratemanage2_arg struct +and OV_ECTL_RATEMANAGE2_GET and OV_ECTL_RATEMANAGE2_SET calls in new +code. + +

    + + + + + +
    +
    struct ovectl_ratemanage_arg {
+  int    management_active;
+
+  long   bitrate_hard_min;
+  long   bitrate_hard_max;
+  double bitrate_hard_window;
+
+  long   bitrate_av_lo;
+  long   bitrate_av_hi;
+  double bitrate_av_window;
+  double bitrate_av_window_center;
+};
    +
    + +

    Relevant Struct Members

    +
    + +
    management_active
    +
    nonzero if bitrate management is active
    + +
    bitrate_hard_min
    +
    hard lower limit (in kilobits per second) below which the stream bitrate will never be allowed for any given bitrate_hard_window seconds of time.
    +
    bitrate_hard_max
    +
    hard upper limit (in kilobits per second) above which the stream bitrate will never be allowed for any given bitrate_hard_window seconds of time.
    +
    bitrate_hard_window
    +
    the window period (in seconds) used to regulate the hard bitrate minimum and maximum
    + +
    bitrate_av_lo
    +
    soft lower limit (in kilobits per second) below which the average bitrate tracker will start nudging the bitrate higher.
    +
    bitrate_av_hi
    +
    soft upper limit (in kilobits per second) above which the average bitrate tracker will start nudging the bitrate lower.
    +
    bitrate_av_window
    +
    the window period (in seconds) used to regulate the average bitrate minimum and maximum.
    +
    bitrate_av_window_center
    +
    Regulates the relative centering of the average and hard windows; in libvorbis 1.0 and 1.0.1, the hard window regulation overlapped but followed the average window regulation. In libvorbis 1.1 a bit-reservoir interface replaces the old windowing interface; the older windowing interface is simulated and this field has no effect.
    + +
    + + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisenc/overview.html b/doc/vorbisenc/overview.html new file mode 100644 index 0000000..51af7b5 --- /dev/null +++ b/doc/vorbisenc/overview.html @@ -0,0 +1,382 @@ + + + +libvorbisenc - API Overview + + + + + + + + + +

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + +

    Libvorbisenc API Overview

    + +

    Libvorbisenc is an encoding convenience library intended to +encapsulate the elaborate setup that libvorbis requires for encoding. +Libvorbisenc gives easy access to all high-level adjustments an +application may require when encoding and also exposes some low-level +tuning parameters to allow applications to make detailed adjustments +to the encoding process.

    + +All the libvorbisenc routines are declared in "vorbis/vorbisenc.h". + +Note: libvorbis and libvorbisenc always +encode in a single pass. Thus, all possible encoding setups will work +properly with live input and produce streams that decode properly when +streamed. See the subsection titled "managed bitrate +modes" for details on setting limits on bitrate usage when Vorbis +streams are used in a limited-bandwidth environment. + +

    workflow

    + +

    Libvorbisenc is used only during encoder setup; its function +is to automate initialization of a multitude of settings in a +vorbis_info structure which libvorbis then uses as a reference +during the encoding process. Libvorbisenc plays no part in the +encoding process after setup. + +

    Encode setup using libvorbisenc consists of three steps: + +

      +
    1. high-level initialization of a vorbis_info structure by +calling one of vorbis_encode_setup_vbr() or vorbis_encode_setup_managed() +with the basic input audio parameters (rate and channels) and the +basic desired encoded audio output parameters (VBR quality or ABR/CBR +bitrate)

      + +

    2. optional adjustment of the basic setup defaults using vorbis_encode_ctl()

      + +

    3. calling vorbis_encode_setup_init() to +finalize the high-level setup into the detailed low-level reference +values needed by libvorbis to encode audio. The vorbis_info +structure is then ready to use for encoding by libvorbis.

      + +

    + +These three steps can be collapsed into a single call by using vorbis_encode_init_vbr to set up a +quality-based VBR stream or vorbis_encode_init to set up a managed +bitrate (ABR or CBR) stream.

    + +

    adjustable encoding parameters

    + +

    input audio parameters

    + +

    + + + + + + + + + + + + + +
    parameterdescription
    sampling rate +The sampling rate (in samples per second) of the input audio. Common examples are 8000 for telephony, 44100 for CD audio and 48000 for DAT. Note that a mono sample (one center value) and a stereo sample (one left value and one right value) both are a single sample. + +
    channels + +The number of channels encoded in each input sample. By default, +stereo input modes (two channels) are 'coupled' by Vorbis 1.1 such +that the stereo relationship between the samples is taken into account +when encoding. Stereo coupling my be disabled by using vorbis_encode_ctl() with OV_ECTL_COUPLE_SET. + +
    + +

    quality and VBR modes

    + +Vorbis is natively a VBR codec; a user requests a given constant +quality and the encoder keeps the encoding quality constant +while allowing the bitrate to vary. 'Quality' modes (Variable BitRate) +will always produce the most consistent encoding results as well as +the highest quality for the amount of bits used. + +

    + + + + + + + + + +
    parameterdescription
    quality +A decimal float value requesting a desired quality. Libvorbisenc 1.1 allows quality requests in the range of -0.1 (lowest quality, smallest files) through +1.0 (highest-quality, largest files). Quality -0.1 is intended as an ultra-low setting in which low bitrate is much more important than quality consistency. Quality settings 0.0 and above are intended to produce consistent results at all times. + +
    + + +

    managed bitrate modes

    + +Although the Vorbis codec is natively VBR, libvorbis includes +infrastructure for 'managing' the bitrate of streams by setting +minimum and maximum usage constraints, as well as functionality for +nudging a stream toward a desired average value. These features +should only be used when there is a requirement to limit +bitrate in some way. Although the difference is usually slight, +managed bitrate modes will always produce output inferior to VBR +(given equal bitrate usage). Setting overly or impossibly tight +bitrate management requirements can affect output quality dramatically +for the worse.

    + +Beginning in libvorbis 1.1, bitrate management is implemented using a +bit-reservoir algorithm. The encoder has a fixed-size +reservoir used as a 'savings account' in encoding. When a frame is +smaller than the target rate, the unused bits go into the reservoir so +that they may be used by future frames. When a frame is larger than +target bitrate, it draws 'banked' bits out of the reservoir. Encoding +is managed so that the reservoir never goes negative (when a maximum +bitrate is specified) or fills beyond a fixed limit (when a minimum +bitrate is specified). An 'average bitrate' request is used as the +set-point in a long-range bitrate tracker which adjusts the encoder's +aggressiveness up or down depending on whether or not frames are coming +in larger or smaller than the requested average point. + +

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    parameterdescription
    maximum bitrate The maximum allowed bitrate, set in bits +per second. If the bitrate would otherwise rise such that oversized +frames would underflow the bit-reservoir by consuming banked bits, +bitrate management will force the encoder to use fewer bits per frame +by encoding with a more aggressive psychoacoustic model.

    This +setting is a hard limit; the bitstream will never be allowed, under +any circumstances, to increase above the specified bitrate over the +average period set by the reservoir; it may momentarily rise over if +inspected on a granularity much finer than the average period across +the reservoir. Normally, the encoder will conserve bits gracefully by +using more aggressive psychoacoustics to shrink a frame when forced +to. However, if the encoder runs out of means of gracefully shrinking +a frame, it will simply take the smallest frame it can otherwise +generate and truncate it to the maximum allowed length. Note that +this is not an error and although it will obviously adversely affect +audio quality, a Vorbis decoder will be able to decode a truncated +frame into audio. + +

    average bitrate + +The average desired bitrate of a stream, set +in bits per second. Average bitrate is tracked via a reservoir like +minimum and maximum bitrate, however the averaging reservior does not +impose a hard limit; it is used to nudge the bitrate toward the +desired average by slowly adjusting the psychoacoustic aggressiveness. +As such, the reservoir size does not affect the average bitrate +behavior. Because this setting alone is not used to impose hard +bitrate limits, the bitrate of a stream produced using only the +average bitrate constraint will track the average over time +but not necessarily adhere strictly to that average for any given +period. Should a strict localized average be required, average +bitrate should be used along with minimum bitrate and +maximum bitrate. +
    minimum bitrate + The minimum allowed bitrate, set in bits per second. If +the bitrate would otherwise fall such that undersized frames would +overflow the bit-reservoir with unused bits, bitrate management will +force the encoder to use more bits per frame by encoding with a less +aggressive psychoacoustic model.

    This setting is a hard limit; the +bitstream will never be allowed, under any circumstances, to drop +below the specified bitrate over the average period set by the +reservoir; it may momentarily fall under if inspected on a granularity +much finer than the average period across the reservoir. Normally, +the encoder will fill out undersided frames with additional useful +coding information by increasing the perceived quality of the stream. +If the encoder runs out of useful ways to consume more bits, it will +pad frames out with zeroes. +

    reservoir size The size of the minimum/maximum bitrate +tracking reservoir, set in bits. The reservoir is used as a 'bit +bank' to average out localized surges and dips in bitrate while +providing predictable, guaranteed buffering behavior for streams to be +used in situations with constrained transport bandwidth. The default +setting is two seconds of average bitrate.

    + +When a single frame is larger than the maximum allowed overall +bitrate, the bits are 'borrowed' from the bitrate reservoir; if the +reservoir contains insufficient bits to cover the defecit, the encoder +must find some way to reduce the frame size.

    + +When a frame is under the minimum limit, the surplus bits are placed +into the reservoir, banking them for future use. If the reservoir is +already full of banked bits, the encoder is forced to find some way to +make the frame larger.

    + +If the frame size is between the minimum and maximum rates (thus +implying the minimum and maximum allowed rates are different), the +reservoir gravitates toward a fill point configured by the +reservoir bias setting described next. If the reservoir is +fuller than the fill point (a 'surplus of surplus'), the encoder will +consume a number bits from the reservoir equal to the number of the +bits by which the frame exceeds minimum size. If the reservoir is +emptier than the fillpoint (a 'surplus of defecit'), bits are returned +to the reservoir equaling the current frame's number of bits under the +maximum frame size. The idea of the fill point is to buffer against +both underruns and overruns, by trying to hold the reservoir to a +middle course. +

    reservoir bias + +Reservoir bias is a setting between 0.0 and 1.0 that biases bitrate +management toward smoothing bitrate spikes (0.0) or bitrate peaks +(1.0); the default setting is 0.1.

    + +Using settings toward 0.0 causes the bitrate manager to hoard bits in +the bit reservoir such that there is a large pool of banked surplus to +draw upon during short spikes in bitrate. As a result, the encoder +will react less aggressively and less drastically to curtail framesize +during brief surges in bitrate.

    + +Using settings toward 1.0 causes the bitrate manager to empty the bit +reservoir such that there is a large buffer available to store surplus +bits during sudden drops in bitrate. As a result, the encoder will +react less aggressively and less drastically to support minimum frame +sizes during drops in bitrate and will tend not to store any extra +bits in the reservoir for future bitrate spikes.

    + +

    average track damping + +A decimal value, in seconds, that controls how quickly the average +bitrate tracker is allowed to slew from enforcing minimum frame sizes +to maximum framesizes and vice versa. Default value is 1.5 +seconds.

    + +When the 'average bitrate' setting is in use, the average bitrate +tracker uses an unbounded reservoir to track overall bitrate-to-date +in the stream. When bitrates are too low, the tracker will try to +nudge bitrates up and when the bitrate is too high, nudge it down. +The damping value regulates the maximum strength of the nudge; it +describes, in seconds, how quickly the tracker may transition from an +extreme nudge in one direction to an extreme nudge in the other.

    + +

    + +

    encoding model adjustments

    + +The     vorbis_encode_ctl() call provides +a generalized interface for making encoding setup adjustments to the +basic high-level setup provided by vorbis_encode_setup_vbr() or vorbis_encode_setup_managed(). +In reality, these two calls use vorbis_encode_ctl() internally, and vorbis_encode_ctl() can be used to adjust +most of the parameters set by other calls.

    + +In Vorbis 1.1, vorbis_encode_ctl() can +adjust the following additional parameters not described elsewhere: + +

    + + + + + + + + + + + + + + + + + + + + +
    parameterdescription
    management mode Configures whether or not bitrate +management is in use or not. Normally, this value is set implicitly +during encoding setup; however, the supported means of selecting a +quality mode by bitrate (that is, requesting a true VBR stream, but +doing so by asking for an approximate bitrate) is to use vorbis_encode_setup_managed() +and then to explicitly turn off bitrate management by calling vorbis_encode_ctl() with OV_ECTL_RATEMANAGE2_SET +
    coupling Stereo encoding (and in the future, surround +encodings) are normally encoded assuming the channels form a stereo +image and that lossy-stereo modelling is appropriate; this is called +'coupling'. Stereo coupling may be explicitly enabled or disabled. +
    lowpass Sets the hard lowpass of a given encoding mode; +this may be used to conserve a few bits in high-rate audio that has +limited bandwidth, or in testing of the encoder's acoustic model. The +encoder is generally already configured with ideal lowpasses (if any +at all) for given modes; use of this parameter is strongly discouraged +if the point is to try to 'improve' a given encoding mode for general +encoding. +
    impulse coding aggressiveness By default, libvorbis +attempts to compromise between preventing wide bitrate swings and +high-resolution impulse coding (which is required for the crispest +possible attacks, but also requires a relatively large momentary +bitrate increase). This parameter allows an application to tune the +compromise or eliminate it; A value of 0.0 indicates normal behavior +while a value of -15.0 requests maximum possible impulse +resolution.
    + + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + + + + + diff --git a/doc/vorbisenc/reference.html b/doc/vorbisenc/reference.html new file mode 100644 index 0000000..59d6432 --- /dev/null +++ b/doc/vorbisenc/reference.html @@ -0,0 +1,54 @@ + + + +Vorbisfile API Reference + + + + + + + + + +

    vorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + +

    Vorbisenc API Reference

    + +

    Data Structures

    + +

    +vorbis_info (from libvorbis)
    +ovectl_ratemanage_arg
    +ovectl_ratemanage2_arg
    +

    + +

    Encoder Setup

    + +

    +vorbis_encode_ctl()
    +vorbis_encode_init()
    +vorbis_encode_init_vbr()
    +vorbis_encode_setup_init()
    +vorbis_encode_setup_managed()
    +vorbis_encode_setup_vbr()
    +

    + +

    The actual encoding is done using the libvorbis API.

    + +
    +
    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisenc/style.css b/doc/vorbisenc/style.css new file mode 100644 index 0000000..81cf417 --- /dev/null +++ b/doc/vorbisenc/style.css @@ -0,0 +1,7 @@ +BODY { font-family: Helvetica, sans-serif } +TD { font-family: Helvetica, sans-serif } +P { font-family: Helvetica, sans-serif } +H1 { font-family: Helvetica, sans-serif } +H2 { font-family: Helvetica, sans-serif } +H4 { font-family: Helvetica, sans-serif } +P.tiny { font-size: 8pt } diff --git a/doc/vorbisenc/vorbis_encode_ctl.html b/doc/vorbisenc/vorbis_encode_ctl.html new file mode 100644 index 0000000..13de574 --- /dev/null +++ b/doc/vorbisenc/vorbis_encode_ctl.html @@ -0,0 +1,183 @@ + + + +libvorbisenc - function - vorbis_encode_ctl + + + + + + + + + +

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + +

    vorbis_encode_ctl

    + +

    declared in "vorbis/vorbisenc.h";

    + +

    This function implements a generic interface to miscellaneous +encoder settings similar to the clasasic UNIX 'ioctl()' system call. +Applications may use vorbis_encode_ctl() to query or set bitrate +management or quality mode details by using one of several +request arguments detailed below. Vorbis_encode_ctl() must be +called after one of vorbis_encode_setup_managed() +or vorbis_encode_setup_vbr(). +When used to modify settings, vorbis_encode_ctl() must be called +before vorbis_encode_setup_init(). + +

    +

    + + + + +
    +
    
+extern int vorbis_encode_ctl(vorbis_info *vi,int request,void *arg);
+
+
    +
    + +

    Parameters

    +
    +
    vi
    +
    Pointer to an initialized vorbis_info struct.

    +

    request
    +
    Specifies the desired action; possible request fields are detailed below.

    +

    arg
    +
    void * pointing to a data structure matching the request argument.

    +

    + +

    Requests

    +
    + +
    OV_ECTL_RATEMANAGE2_GET
    + +
    Argument: struct +ovectl_ratemanage2_arg *
    Used to query the current +encoder bitrate management setting. Also used to initialize fields of +an ovectl_ratemanage2_arg structure for use with +OV_ECTL_RATEMANAGE2_SET.

    + +

    OV_ECTL_RATEMANAGE2_SET
    +
    Argument: struct +ovectl_ratemanage2_arg *
    Used to set the current +encoder bitrate management settings to the values listed in the +ovectl_ratemanage2_arg. Passing a NULL pointer will disable bitrate +management. +

    + +

    OV_ECTL_LOWPASS_GET
    +
    Argument: double *
    Returns the current encoder hard-lowpass +setting (kHz) in the double pointed to by arg. +

    + +

    OV_ECTL_LOWPASS_SET
    +
    Argument: double *
    Sets the encoder hard-lowpass to the value +(kHz) pointed to by arg. Valid lowpass settings range from 2 to 99. +

    + +

    OV_ECTL_IBLOCK_GET
    +
    Argument: double *
    Returns the current encoder impulse +block setting in the double pointed to by arg.

    + +

    OV_ECTL_IBLOCK_SET
    Argument: double *
    Sets +the impulse block bias to the the value pointed to by arg; valid range +is -15.0 to 0.0 [default]. A negative impulse block bias will direct +to encoder to use more bits when incoding short blocks that contain +strong impulses, thus improving the accuracy of impulse encoding.

    + +

    OV_ECTL_COUPLING_GET
    +
    Argument: int *
    +Returns the current encoder coupling enabled/disabled +setting in the int pointed to by arg. +

    + +

    OV_ECTL_COUPLING_SET
    +
    Argument: int *
    +Enables/disables channel coupling in multichannel encoding according to arg. +*arg of zero disables all channel coupling, nonzero allows the encoder to use +coupling if a coupled mode is available for the input. At present, coupling +is available for stereo and 5.1 input modes. +

    + +

    OV_ECTL_RATEMANAGE_GET [deprecated]
    +
    + +Argument: struct +ovectl_ratemanage_arg *
    Old interface to querying bitrate +management settings; deprecated after move to bit-reservoir style +management in 1.1 rendered this interface partially obsolete. Please +use OV_ECTL_RATEMANGE2_GET instead. + +

    + +

    OV_ECTL_RATEMANAGE_SET [deprecated]
    +
    +Argument: struct +ovectl_ratemanage_arg *
    Old interface to modifying bitrate +management settings; deprecated after move to bit-reservoir style +management in 1.1 rendered this interface partially obsolete. Please +use OV_ECTL_RATEMANGE2_SET instead. +

    + +

    OV_ECTL_RATEMANAGE_AVG [deprecated]
    +
    +Argument: struct +ovectl_ratemanage_arg *
    Old interface to setting +average-bitrate encoding mode; deprecated after move to bit-reservoir +style management in 1.1 rendered this interface partially obsolete. +Please use OV_ECTL_RATEMANGE2_SET instead. +

    + +

    OV_ECTL_RATEMANAGE_HARD [deprecated]
    +
    +Argument: struct +ovectl_ratemanage_arg *
    Old interface to setting +bounded-bitrate encoding modes; deprecated after move to bit-reservoir +style management in 1.1 rendered this interface partially obsolete. +Please use OV_ECTL_RATEMANGE2_SET instead. +

    + + +

    + + +

    Return Values

    vorbis_encode_ctl() returns zero on success, +placing any further return information (such as the result of a query) +into the storage pointed to by *arg. On error, +vorbis_encode_ctl() may return one of the following error codes: + +
    + +
    OV_EINVAL
    Invalid argument, or an attempt to modify a +setting after calling vorbis_encode_setup_init().

    + +

    OV_EIMPL
    Unimplemented or unknown request

    + +

    + +

    + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + + + + + diff --git a/doc/vorbisenc/vorbis_encode_init.html b/doc/vorbisenc/vorbis_encode_init.html new file mode 100644 index 0000000..d371899 --- /dev/null +++ b/doc/vorbisenc/vorbis_encode_init.html @@ -0,0 +1,88 @@ + + + +libvorbisenc - function - vorbis_encode_init + + + + + + + + + +

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + +

    vorbis_encode_init

    + +

    declared in "vorbis/vorbisenc.h";

    + +

    This is the primary function within libvorbisenc for setting up managed bitrate modes. +

    Before this function is called, the vorbis_info struct should be initialized by using vorbis_info_init() from the libvorbis API. After encoding, vorbis_info_clear should be called. +

    The max_bitrate, nominal_bitrate, and min_bitrate settings are used to set constraints for the encoded file. This function uses these settings to select the appropriate encoding mode and set it up. +

    +

    + + + + +
    +
    
+extern int vorbis_encode_init(vorbis_info *vi,
+			      long channels,
+			      long rate,
+			      
+			      long max_bitrate,
+			      long nominal_bitrate,
+			      long min_bitrate);
+
+
    +
    + +

    Parameters

    +
    +
    vi
    +
    Pointer to an initialized vorbis_info struct.
    +
    channels
    +
    The number of channels to be encoded.
    +
    rate
    +
    The sampling rate of the source audio.
    +
    max_bitrate
    +
    Desired maximum bitrate (limit). -1 indicates unset.
    +
    nominal_bitrate
    +
    Desired average, or central, bitrate. -1 indicates unset.
    +
    min_bitrate
    +
    Desired minimum bitrate. -1 indicates unset.
    +
    + + +

    Return Values

    +
    +
  • +0 for success
    • + +
  • less than zero for failure:
    • +
      +
    • OV_EFAULT - Internal logic fault; indicates a bug or heap/stack corruption.
      • +
    • OV_EINVAL - Invalid setup request, eg, out of range argument.
      • +
    • OV_EIMPL - Unimplemented mode; unable to comply with bitrate request.
      • +
    +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + + + + + diff --git a/doc/vorbisenc/vorbis_encode_init_vbr.html b/doc/vorbisenc/vorbis_encode_init_vbr.html new file mode 100644 index 0000000..800d257 --- /dev/null +++ b/doc/vorbisenc/vorbis_encode_init_vbr.html @@ -0,0 +1,81 @@ + + + +libvorbisenc - function - vorbis_encode_init_vbr + + + + + + + + + +

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + +

    vorbis_encode_init_vbr

    + +

    declared in "vorbis/vorbisenc.h";

    + +

    This is the primary function within libvorbisenc for setting up variable bitrate ("quality" based) modes. +

    Before this function is called, the vorbis_info struct should be initialized by using vorbis_info_init() from the libvorbis API. After encoding, vorbis_info_clear should be called. +

    +

    + + + + +
    +
    
+extern int vorbis_encode_init_vbr(vorbis_info *vi,
+			      long channels,
+			      long rate,
+			      
+			      float base_quality);
+
+
    +
    + +

    Parameters

    +
    +
    vi
    +
    Pointer to an initialized vorbis_info struct.
    +
    channels
    +
    The number of channels to be encoded.
    +
    rate
    +
    The sampling rate of the source audio.
    +
    base_quality
    +
    Desired quality level, currently from -0.1 to 1.0 (lo to hi).
    +
    + + +

    Return Values

    +
    +
  • +0 for success
    • + +
  • less than zero for failure:
    • +
      +
    • OV_EFAULT - Internal logic fault; indicates a bug or heap/stack corruption.
      • +
    • OV_EINVAL - Invalid setup request, eg, out of range argument.
      • +
    • OV_EIMPL - Unimplemented mode; unable to comply with quality level request.
      • +
    +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + + + + + diff --git a/doc/vorbisenc/vorbis_encode_setup_init.html b/doc/vorbisenc/vorbis_encode_setup_init.html new file mode 100644 index 0000000..aa2c904 --- /dev/null +++ b/doc/vorbisenc/vorbis_encode_setup_init.html @@ -0,0 +1,88 @@ + + + +libvorbisenc - function - vorbis_encode_setup_init + + + + + + + + + +

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + +

    vorbis_encode_setup_init

    + +

    declared in "vorbis/vorbisenc.h";

    + +

    This function performs the last stage of three-step encoding setup, as described in the API overview under managed bitrate modes. + +

    Before this function is called, the vorbis_info struct should be initialized +by using vorbis_info_init() from the libvorbis API, one of vorbis_encode_setup_managed() +or vorbis_encode_setup_vbr() +called to initialize the high-level encoding setup, and vorbis_encode_ctl() called if +necessary to make encoding setup changes. vorbis_encode_setup_init() +finalizes the highlevel encoding structure into a complete encoding +setup after which the application may make no further setup changes.

    + +After encoding, vorbis_info_clear should be called. +

    +

    + + + + +
    +
    
+extern int vorbis_encode_setup_init(vorbis_info *vi);
+
+
    +
    + +

    Parameters

    +
    +
    vi
    +
    Pointer to an initialized vorbis_info struct.
    +
    + + +

    Return Values

    +
    +
  • +0 for success
    • + +
  • less than zero for failure:
    • +
      +
    • OV_EFAULT - Internal logic fault; indicates a bug or heap/stack corruption.
      • +
    • OV_EINVAL - Attempt to use vorbis_encode_setup_init() without first calling one of vorbis_encode_setup_managed() +or vorbis_encode_setup_vbr() +to initialize the high-level encoding setup +
      • +
    +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + + + + + diff --git a/doc/vorbisenc/vorbis_encode_setup_managed.html b/doc/vorbisenc/vorbis_encode_setup_managed.html new file mode 100644 index 0000000..0389dde --- /dev/null +++ b/doc/vorbisenc/vorbis_encode_setup_managed.html @@ -0,0 +1,102 @@ + + + +libvorbisenc - function - vorbis_encode_setup_managed + + + + + + + + + +

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + +

    vorbis_encode_setup_managed

    + +

    declared in "vorbis/vorbisenc.h";

    + +

    This function performs step-one of a three-step bitrate-managed +encode setup. It functions similarly to the one-step setup performed +by vorbis_encode_init() but +allows an application to make further encode setup tweaks using vorbis_encode_ctl() before finally +calling vorbis_encode_setup_init() to +complete the setup process. + +

    Before this function is called, the vorbis_info struct should be initialized +by using vorbis_info_init() from the libvorbis API. After encoding, +vorbis_info_clear should be called. + +

    The max_bitrate, nominal_bitrate, and min_bitrate settings are used +to set constraints for the encoded file. This function uses these +settings to select the appropriate encoding mode and set it up. +

    +

    + + + + +
    +
    
+extern int vorbis_encode_init(vorbis_info *vi,
+			      long channels,
+			      long rate,
+			      
+			      long max_bitrate,
+			      long nominal_bitrate,
+			      long min_bitrate);
+
+
    +
    + +

    Parameters

    +
    +
    vi
    +
    Pointer to an initialized vorbis_info struct.
    +
    channels
    +
    The number of channels to be encoded.
    +
    rate
    +
    The sampling rate of the source audio.
    +
    max_bitrate
    +
    Desired maximum bitrate (limit). -1 indicates unset.
    +
    nominal_bitrate
    +
    Desired average, or central, bitrate. -1 indicates unset.
    +
    min_bitrate
    +
    Desired minimum bitrate. -1 indicates unset.
    +
    + + +

    Return Values

    +
    +
  • +0 for success
    • + +
  • less than zero for failure:
    • +
      +
    • OV_EFAULT - Internal logic fault; indicates a bug or heap/stack corruption.
      • +
    • OV_EINVAL - Invalid setup request, eg, out of range argument.
      • +
    • OV_EIMPL - Unimplemented mode; unable to comply with bitrate request.
      • +
    +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + + + + + diff --git a/doc/vorbisenc/vorbis_encode_setup_vbr.html b/doc/vorbisenc/vorbis_encode_setup_vbr.html new file mode 100644 index 0000000..e390edf --- /dev/null +++ b/doc/vorbisenc/vorbis_encode_setup_vbr.html @@ -0,0 +1,90 @@ + + + +libvorbisenc - function - vorbis_encode_setup_vbr + + + + + + + + + +

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + +

    vorbis_encode_setup_vbr

    + +

    declared in "vorbis/vorbisenc.h";

    + +

    This function performs step-one of a three-step variable bitrate +(quality-based) encode setup. It functions similarly to the one-step +setup performed by vorbis_encode_init_vbr() but +allows an application to make further encode setup tweaks using vorbis_encode_ctl() before finally +calling vorbis_encode_setup_init() to +complete the setup process. + +

    Before this function is called, the vorbis_info struct should be initialized by using vorbis_info_init() from the libvorbis API. After encoding, vorbis_info_clear should be called. +

    +

    + + + + +
    +
    
+extern int vorbis_encode_init_vbr(vorbis_info *vi,
+			      long channels,
+			      long rate,
+			      
+			      float base_quality);
+
+
    +
    + +

    Parameters

    +
    +
    vi
    +
    Pointer to an initialized vorbis_info struct.
    +
    channels
    +
    The number of channels to be encoded.
    +
    rate
    +
    The sampling rate of the source audio.
    +
    base_quality
    +
    Desired quality level, currently from -0.1 to 1.0 (lo to hi).
    +
    + + +

    Return Values

    +
    +
  • +0 for success
    • + +
  • less than zero for failure:
    • +
      +
    • OV_EFAULT - Internal logic fault; indicates a bug or heap/stack corruption.
      • +
    • OV_EINVAL - Invalid setup request, eg, out of range argument.
      • +
    • OV_EIMPL - Unimplemented mode; unable to comply with quality level request.
      • +
    +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    libvorbisenc documentation

    libvorbisenc version 1.3.2 - 20101101

    + + + + + diff --git a/doc/vorbisfile/Makefile.am b/doc/vorbisfile/Makefile.am new file mode 100644 index 0000000..fb27d44 --- /dev/null +++ b/doc/vorbisfile/Makefile.am @@ -0,0 +1,25 @@ +## Process this file with automake to produce Makefile.in + +docdir = $(datadir)/doc/$(PACKAGE)-$(VERSION)/vorbisfile + +doc_DATA = OggVorbis_File.html callbacks.html chaining_example_c.html\ + chainingexample.html crosslap.html datastructures.html decoding.html\ + example.html exampleindex.html fileinfo.html index.html\ + initialization.html ov_bitrate.html ov_bitrate_instant.html\ + ov_callbacks.html ov_clear.html ov_comment.html ov_crosslap.html\ + ov_fopen.html\ + ov_info.html ov_open.html ov_open_callbacks.html ov_pcm_seek.html\ + ov_pcm_seek_lap.html ov_pcm_seek_page.html ov_pcm_seek_page_lap.html\ + ov_pcm_tell.html ov_pcm_total.html ov_raw_seek.html\ + ov_raw_seek_lap.html ov_raw_tell.html ov_raw_total.html ov_read.html\ + ov_read_float.html ov_read_filter.html\ + ov_seekable.html ov_serialnumber.html\ + ov_streams.html ov_test.html ov_test_callbacks.html ov_test_open.html\ + ov_time_seek.html ov_time_seek_lap.html ov_time_seek_page.html\ + ov_time_seek_page_lap.html ov_time_tell.html ov_time_total.html\ + overview.html reference.html seekexample.html seeking.html\ + seeking_example_c.html seeking_test_c.html seekingexample.html\ + style.css threads.html\ + vorbisfile_example_c.html + +EXTRA_DIST = $(doc_DATA) diff --git a/doc/vorbisfile/OggVorbis_File.html b/doc/vorbisfile/OggVorbis_File.html new file mode 100644 index 0000000..67f47d7 --- /dev/null +++ b/doc/vorbisfile/OggVorbis_File.html @@ -0,0 +1,137 @@ + + + +Vorbisfile - datatype - OggVorbis_File + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    OggVorbis_File

    + +

    declared in "vorbis/vorbisfile.h"

    + +

    +The OggVorbis_File structure defines an Ogg Vorbis file. +

    + +This structure is used in all libvorbisfile routines. Before it can +be used, it must be initialized by ov_open(), ov_fopen(), or ov_open_callbacks(). Important +Note: The use of ov_open() is +discouraged under Windows due to a peculiarity of Windows linking +convention; use ov_fopen() or ov_open_callbacks() instead. This +caution only applies to Windows; use of ov_open() is appropriate for all other +platforms. See the ov_open() page for more +information. + +

    +After use, the OggVorbis_File structure must be deallocated with a +call to ov_clear(). + +

    +Note that once a file handle is passed to a successful ov_open() call, the handle is owned by +libvorbisfile and will be closed by libvorbisfile later during the +call to ov_clear(). The handle should not +be used or closed outside of the libvorbisfile API. Similarly, files +opened by ov_fopen() will also be closed +internally by vorbisfile in ov_clear().

    + +ov_open_callbacks() allows the +application to choose whether libvorbisfile will or will not close the +handle in ov_clear(); see the ov_open_callbacks() page for more information.

    + +If a call to ov_open() or ov_open_callbacks() fails, +libvorbisfile does not assume ownership of the handle and the +application is expected to close it if necessary. A failed ov_fopen() call will internally close the +file handle if the open process fails.

    + +

    + + + + +
    +
    typedef struct {
+  void             *datasource; /* Pointer to a FILE *, etc. */
+  int              seekable;
+  ogg_int64_t      offset;
+  ogg_int64_t      end;
+  ogg_sync_state   oy; 
+
+  /* If the FILE handle isn't seekable (eg, a pipe), only the current
+     stream appears */
+  int              links;
+  ogg_int64_t      *offsets;
+  ogg_int64_t      *dataoffsets;
+  long             *serialnos;
+  ogg_int64_t      *pcmlengths;
+  vorbis_info      *vi;
+  vorbis_comment   *vc;
+
+  /* Decoding working state local storage */
+  ogg_int64_t      pcm_offset;
+  int              ready_state;
+  long             current_serialno;
+  int              current_link;
+
+  ogg_int64_t      bittrack;
+  ogg_int64_t      samptrack;
+
+  ogg_stream_state os; /* take physical pages, weld into a logical
+                          stream of packets */
+  vorbis_dsp_state vd; /* central working state for the packet->PCM decoder */
+  vorbis_block     vb; /* local working space for packet->PCM decode */
+
+  ov_callbacks callbacks;
+
+} OggVorbis_File;
    +
    + +

    Relevant Struct Members

    +
    +
    datasource
    + +
    Pointer to file or other ogg source. When using stdio based +file/stream access, this field contains a FILE pointer. When using +custom IO via callbacks, libvorbisfile treats this void pointer as a +black box only to be passed to the callback routines provided by the +application.
    + +
    seekable
    +
    Read-only int indicating whether file is seekable. E.g., a physical file is seekable, a pipe isn't.
    +
    links
    +
    Read-only int indicating the number of logical bitstreams within the physical bitstream.
    +
    ov_callbacks
    +
    Collection of file manipulation routines to be used on this data source. When using stdio/FILE access via ov_open(), the callbacks will be filled in with stdio calls or wrappers to stdio calls.
    +
    + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/callbacks.html b/doc/vorbisfile/callbacks.html new file mode 100644 index 0000000..20ae55a --- /dev/null +++ b/doc/vorbisfile/callbacks.html @@ -0,0 +1,121 @@ + + + +Vorbisfile - Callbacks and non-stdio I/O + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    Callbacks and non-stdio I/O

    + +Although stdio is convenient and nearly universally implemented as per +ANSI C, it is not suited to all or even most potential uses of Vorbis. +For additional flexibility, embedded applications may provide their +own I/O functions for use with Vorbisfile when stdio is unavailable or not +suitable. One common example is decoding a Vorbis stream from a +memory buffer.

    + +Use custom I/O functions by populating an ov_callbacks structure and calling ov_open_callbacks() or ov_test_callbacks() rather than the +typical ov_open() or ov_test(). Past the open call, use of +libvorbisfile is identical to using it with stdio. + +

    Read function

    + +The read-like function provided in the read_func field is +used to fetch the requested amount of data. It expects the fetch +operation to function similar to file-access, that is, a multiple read +operations will retrieve contiguous sequential pieces of data, +advancing a position cursor after each read.

    + +The following behaviors are also expected:

    +

      +
    • a return of '0' indicates end-of-data (if the by-thread errno is unset) +
    • short reads mean nothing special (short reads are not treated as error conditions) +
    • a return of zero with the by-thread errno set to nonzero indicates a read error +
    +

    + +

    Seek function

    + +The seek-like function provided in the seek_func field is +used to request non-sequential data access by libvorbisfile, moving +the access cursor to the requested position. The seek function is +optional; if callbacks are only to handle non-seeking (streaming) data +or the application wishes to force streaming behavior, +seek_func and tell_func should be set to NULL. If +the seek function is non-NULL, libvorbisfile mandates the following +behavior: + +
      +
    • The seek function must always return -1 (failure) if the given +data abstraction is not seekable. It may choose to always return -1 +if the application desires libvorbisfile to treat the Vorbis data +strictly as a stream (which makes for a less expensive open +operation).

      + +

    • If the seek function initially indicates seekability, it must +always succeed upon being given a valid seek request.

      + +

    • The seek function must implement all of SEEK_SET, SEEK_CUR and +SEEK_END. The implementation of SEEK_END should set the access cursor +one past the last byte of accessible data, as would stdio +fseek()

      +

    + +

    Close function

    + +The close function should deallocate any access state used by the +passed in instance of the data access abstraction and invalidate the +instance handle. The close function is assumed to succeed; its return +code is not checked.

    + +The close_func may be set to NULL to indicate that libvorbis +should not attempt to close the file/data handle in ov_clear but allow the application to handle +file/data access cleanup itself. For example, by passing the normal +stdio calls as callback functions, but passing a close_func +that is NULL or does nothing (as in the case of OV_CALLBACKS_NOCLOSE), an +application may call ov_clear() and then +later fclose() the file originally passed to libvorbisfile. + +

    Tell function

    + +The tell function is intended to mimic the +behavior of ftell() and must return the byte position of the +next data byte that would be read. If the data access cursor is at +the end of the 'file' (pointing to one past the last byte of data, as +it would be after calling fseek(file,SEEK_END,0)), the tell +function must return the data position (and thus the total file size), +not an error.

    + +The tell function need not be provided if the data IO abstraction is +not seekable, or the application wishes to force streaming +behavior. In this case, the tell_func and seek_func +fields should be set to NULL.

    + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/chaining_example_c.html b/doc/vorbisfile/chaining_example_c.html new file mode 100644 index 0000000..e40689c --- /dev/null +++ b/doc/vorbisfile/chaining_example_c.html @@ -0,0 +1,90 @@ + + + +vorbisfile - chaining_example.c + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    chaining_example.c

    + +

    +The example program source: + +

    + + + + +
    +
    
+
+#include <vorbis/codec.h>
+#include <vorbis/vorbisfile.h>
+
+int main(){
+  OggVorbis_File ov;
+  int i;
+
+#ifdef _WIN32 /* We need to set stdin to binary mode on windows. */
+  _setmode( _fileno( stdin ), _O_BINARY );
+#endif
+
+  /* open the file/pipe on stdin */
+  if(ov_open_callbacks(stdin,&ov,NULL,-1,OV_CALLBACKS_NOCLOSE)<0){
+    printf("Could not open input as an OggVorbis file.\n\n");
+    exit(1);
+  }
+  
+  /* print details about each logical bitstream in the input */
+  if(ov_seekable(&ov)){
+    printf("Input bitstream contained %ld logical bitstream section(s).\n",
+           ov_streams(&ov));
+    printf("Total bitstream playing time: %ld seconds\n\n",
+           (long)ov_time_total(&ov,-1));
+
+  }else{
+    printf("Standard input was not seekable.\n"
+           "First logical bitstream information:\n\n");
+  }
+
+  for(i=0;i<ov_streams(&ov);i++){
+    vorbis_info *vi=ov_info(&ov,i);
+    printf("\tlogical bitstream section %d information:\n",i+1);
+    printf("\t\t%ldHz %d channels bitrate %ldkbps serial number=%ld\n",
+           vi->rate,vi->channels,ov_bitrate(&ov,i)/1000,
+           ov_serialnumber(&ov,i));
+    printf("\t\tcompressed length: %ld bytes ",(long)(ov_raw_total(&ov,i)));
+    printf(" play time: %lds\n",(long)ov_time_total(&ov,i));
+  }
+
+  ov_clear(&ov);
+  return 0;
+}
+
+
    +
    + + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/chainingexample.html b/doc/vorbisfile/chainingexample.html new file mode 100644 index 0000000..9e0440d --- /dev/null +++ b/doc/vorbisfile/chainingexample.html @@ -0,0 +1,175 @@ + + + +vorbisfile - Example Code + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    Chaining Example Code

    + +

    +The following is a run-through of the chaining example program supplied +with vorbisfile - chaining_example.c. +This program demonstrates how to work with a chained bitstream. + +

    +First, relevant headers, including vorbis-specific "codec.h" and "vorbisfile.h" have to be included. + +

    + + + + +
    +
    
+#include "vorbis/codec.h"
+#include "vorbis/vorbisfile.h"
+#include "../lib/misc.h"
+
    +
    + +

    Inside main(), we declare our primary OggVorbis_File structure. We also declare a other helpful variables to track our progress within the file. +

    + + + + +
    +
    
+int main(){
+  OggVorbis_File ov;
+  int i;
+
    +
    + +

    This example takes its input on stdin which is in 'text' mode by default under Windows; this will corrupt the input data unless set to binary mode. This applies only to Windows. +

    + + + + +
    +
    
+#ifdef _WIN32 /* We need to set stdin to binary mode under Windows */
+  _setmode( _fileno( stdin ), _O_BINARY );
+#endif
+
    +
    + +

    We call ov_open_callbacks() to +initialize the OggVorbis_File +structure. ov_open_callbacks() +also checks to ensure that we're reading Vorbis format and not +something else. The OV_CALLBACKS_NOCLOSE callbacks instruct +libvorbisfile not to close stdin later during cleanup.

    + +

    + + + + +
    +
    
+  if(ov_open_callbacks(stdin,&ov,NULL,-1,OV_CALLBACKS_NOCLOSE)<0){
+    printf("Could not open input as an OggVorbis file.\n\n");
+    exit(1);
+  }
+
+
    +
    + +

    +First we check to make sure the stream is seekable using ov_seekable. + +

    Then we're going to find the number of logical bitstreams in the physical bitstream using ov_streams. + +

    We use ov_time_total to determine the total length of the physical bitstream. We specify that we want the entire bitstream by using the argument -1. + +

    + + + + +
    +
    
+  if(ov_seekable(&ov)){
+    printf("Input bitstream contained %ld logical bitstream section(s).\n",
+	   ov_streams(&ov));
+    printf("Total bitstream playing time: %ld seconds\n\n",
+	   (long)ov_time_total(&ov,-1));
+
+  }else{
+    printf("Standard input was not seekable.\n"
+	   "First logical bitstream information:\n\n");
+  }
+  
+
    +
    + +

    Now we're going to iterate through each logical bitstream and print information about that bitstream. + +

    We use ov_info to pull out the vorbis_info struct for each logical bitstream. This struct contains bitstream-specific info. + +

    ov_serialnumber retrieves the unique serial number for the logical bistream. ov_raw_total gives the total compressed bytes for the logical bitstream, and ov_time_total gives the total time in the logical bitstream. + +

    + + + + +
    +
    
+  for(i=0;i<ov_streams(&ov);i++){
+    vorbis_info *vi=ov_info(&ov,i);
+    printf("\tlogical bitstream section %d information:\n",i+1);
+    printf("\t\t%ldHz %d channels bitrate %ldkbps serial number=%ld\n",
+	   vi->rate,vi->channels,ov_bitrate(&ov,i)/1000,
+	   ov_serialnumber(&ov,i));
+    printf("\t\tcompressed length: %ld bytes ",(long)(ov_raw_total(&ov,i)));
+    printf(" play time: %lds\n",(long)ov_time_total(&ov,i));
+  } 
+
    +
    +

    +When we're done with the entire physical bitstream, we need to call ov_clear() to release the bitstream. + +

    + + + + +
    +
    
+  ov_clear(&ov);
+  return 0;
+}
+
    +
    + +

    +The full source for chaining_example.c can be found with the vorbis +distribution in chaining_example.c. + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/crosslap.html b/doc/vorbisfile/crosslap.html new file mode 100644 index 0000000..9d28b0b --- /dev/null +++ b/doc/vorbisfile/crosslap.html @@ -0,0 +1,121 @@ + + + +Vorbisfile - Sample Crosslapping + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    What is Crosslapping?

    + +

    Crosslapping blends two samples together using a window function, +such that any sudden discontinuities between the samples that may +cause clicks or thumps are eliminated or blended away. The technique +is nearly identical to how Vorbis internally splices together frames +of audio data during normal decode. API functions are provided to crosslap transitions between seperate +streams, or to crosslap when seeking within +a single stream. + +

    Why Crosslap?

    +

    The source of boundary clicks

    + +

    Vorbis is a lossy compression format such that any compressed +signal is at best a close approximation of the original. The +approximation may be very good (ie, indistingushable to the human +ear), but it is an approximation nonetheless. Even if a sample or set +of samples is contructed carefully such that transitions from one to +another match perfectly in the original, the compression process +introduces minute amplitude and phase errors. It's an unavoidable +result of such high compression rates. + +

    If an application transitions instantly from one sample to another, +any tiny discrepancy introduced in the lossy compression process +becomes audible as a stairstep discontinuity. Even if the discrepancy +in a normal lapped frame is only .1dB (usually far below the +threshhold of perception), that's a sudden cliff of 380 steps in a 16 +bit sample (when there's a boundary with no lapping). + +

    I thought Vorbis was gapless

    + +

    It is. Vorbis introduces no extra samples at the beginning or end +of a stream, nor does it remove any samples. Gapless encoding +eliminates 99% of the click, pop or outright blown speaker that would +occur if boundaries had gaps or made no effort to align +transitions. However, gapless encoding is not enough to entirely +eliminate stairstep discontinuities all the time for exactly the +reasons described above. + +

    Frame lapping, like Vorbis performs internally during continuous +playback, is necessary to eliminate that last epsilon of trouble. + +

    Easiest Crosslap

    + +The easiest way to perform crosslapping in Vorbis is to use the +lapping functions with no other extra effort. These functions behave +identically to when lapping isn't used except to provide +at-least-very-good lapping results. Crosslapping will not introduce +any samples into or remove any samples from the decoded audio; the +only difference is that the transition is lapped. Lapping occurs from +the current PCM position (either in the old stream, or at the position +prior to calling a lapping seek) forward into the next +half-short-block of audio data to be read from the new stream or +position. + +

    Ideally, vorbisfile internally reads an extra frame of audio from +the old stream/position to perform lapping into the new +stream/position. However, automagic crosslapping works properly even +if the old stream/position is at EOF. In this case, the synthetic +post-extrapolation generated by the encoder to pad out the last block +with appropriate data (and avoid encoding a stairstep, which is +inefficient) is used for crosslapping purposes. Although this is +synthetic data, the result is still usually completely unnoticable +even in careful listening (and always preferable to a click or pop). + +

    Vorbisfile will lap between streams of differing numbers of +channels. Any extra channels from the old stream are ignored; playback +of these channels simply ends. Extra channels in the new stream are +lapped from silence. Vorbisfile will also lap between streams links +of differing sample rates. In this case, the sample rates are ignored +(no implicit resampling is done to match playback). It is up to the +application developer to decide if this behavior makes any sense in a +given context; in practical use, these default behaviors perform +sensibly. + +

    Best Crosslap

    + +

    To acheive the best possible crosslapping results, avoid the case +where synthetic extrapolation data is used for crosslapping. That is, +design loops and samples such that a little bit of data is left over +in sample A when seeking to sample B. Normally, the end of sample A +and the beginning of B would overlap exactly; this allows +crosslapping to perform exactly as it would within vorbis when +stitching audio frames together into continuous decoded audio. + +

    The optimal amount of overlap is half a short-block, and this +varies by compression mode. Each encoder will vary in exact block +size selection; for vorbis 1.0, for -q0 through -q10 and 44kHz or +greater, a half-short block is 64 samples. + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/datastructures.html b/doc/vorbisfile/datastructures.html new file mode 100644 index 0000000..00f8f8d --- /dev/null +++ b/doc/vorbisfile/datastructures.html @@ -0,0 +1,61 @@ + + + +Vorbisfile - Base Data Structures + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    Base Data Structures

    +

    There are several data structures used to hold file and bitstream information during libvorbisfile decoding. These structures are declared in "vorbis/vorbisfile.h" and "vorbis/codec.h". +

    +

    When using libvorbisfile, it's not necessary to know about most of the contents of these data structures, but it may be helpful to understand what they contain. +

    + + + + + + + + + + + + + + + + + + + + + + +
    datatypepurpose
    OggVorbis_FileThis structure represents the basic file information. It contains + a pointer to the physical file or bitstream and various information about that bitstream.
    vorbis_commentThis structure contains the file comments. It contains + a pointer to unlimited user comments, information about the number of comments, and a vendor description.
    vorbis_infoThis structure contains encoder-related information about the bitstream. It includes encoder info, channel info, and bitrate limits.
    ov_callbacksThis structure contains pointers to the application-specified file manipulation routines set for use by ov_open_callbacks(). See also the provided document on using application-provided callbacks instead of stdio.
    + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/decoding.html b/doc/vorbisfile/decoding.html new file mode 100644 index 0000000..f394376 --- /dev/null +++ b/doc/vorbisfile/decoding.html @@ -0,0 +1,92 @@ + + + +Vorbisfile - Decoding + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    Decoding

    + +

    +All libvorbisfile decoding routines are declared in "vorbis/vorbisfile.h". +

    + +After initialization, decoding audio +is as simple as calling ov_read() (or the +similar functions ov_read_float() and +ov_read_filter). This function works +similarly to reading from a normal file using read().

    + +However, a few differences are worth noting: + +

    multiple stream links

    + +A Vorbis stream may consist of multiple sections (called links) that +encode differing numbers of channels or sample rates. It is vitally +important to pay attention to the link numbers returned by ov_read and handle audio changes that may +occur at link boundaries. Such multi-section files do exist in the +wild and are not merely a specification curiosity. + +

    returned data amount

    + +ov_read does not attempt to completely fill +a large, passed in data buffer; it merely guarantees that the passed +back data does not overflow the passed in buffer size. Large buffers +may be filled by iteratively looping over calls to ov_read (incrementing the buffer pointer) +until the original buffer is filled. + +

    file cursor position

    + +Vorbis files do not necessarily start at a sample number or time offset +of zero. Do not be surprised if a file begins at a positive offset of +several minutes or hours, such as would happen if a large stream (such +as a concert recording) is chopped into multiple seperate files. + +

    + + + + + + + + + + + + + + + + + +
    functionpurpose
    ov_readThis function makes up the main chunk of a decode loop. It takes an +OggVorbis_File structure, which must have been initialized by a previous +call to ov_open(), ov_fopen(), +or ov_open_callbacks().
    ov_read_floatThis function decodes to floats instead of integer samples.
    ov_read_filterThis function works like ov_read, but passes the PCM data through the provided filter before converting to integer sample data.
    + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/example.html b/doc/vorbisfile/example.html new file mode 100644 index 0000000..e0c4fa3 --- /dev/null +++ b/doc/vorbisfile/example.html @@ -0,0 +1,208 @@ + + + +Vorbisfile - Example Code + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    Decoding Example Code

    + +

    +The following is a run-through of the decoding example program supplied +with libvorbisfile, vorbisfile_example.c. +This program takes a vorbis bitstream from stdin and writes raw pcm to stdout. + +

    +First, relevant headers, including vorbis-specific "vorbis/codec.h" and "vorbisfile.h" have to be included. + +

    + + + + +
    +
    
+#include <stdio.h>
+#include <stdlib.h>
+#include <math.h>
+#include "vorbis/codec.h"
+#include "vorbisfile.h"
+
    +
    +

    +We also have to make a concession to Windows users here. If we are using windows for decoding, we must declare these libraries so that we can set stdin/stdout to binary. +

    + + + + +
    +
    
+#ifdef _WIN32
+#include <io.h>
+#include <fcntl.h>
+#endif
+
    +
    +

    +Next, a buffer for the pcm audio output is declared. + +

    + + + + +
    +
    
+char pcmout[4096];
+
    +
    + +

    Inside main(), we declare our primary OggVorbis_File structure. We also declare a few other helpful variables to track out progress within the file. +Also, we make our final concession to Windows users by setting the stdin and stdout to binary mode. +

    + + + + +
    +
    
+int main(int argc, char **argv){
+  OggVorbis_File vf;
+  int eof=0;
+  int current_section;
+
+#ifdef _WIN32
+  _setmode( _fileno( stdin ), _O_BINARY );
+  _setmode( _fileno( stdout ), _O_BINARY );
+#endif
+
    +
    + +

    We call ov_open_callbacks() to +initialize the OggVorbis_File structure with default values. +ov_open_callbacks() also checks +to ensure that we're reading Vorbis format and not something else. The +OV_CALLBACKS_NOCLOSE callbacks instruct libvorbisfile not to close +stdin later during cleanup. + +

    + + + + +
    +
    
+  if(ov_open_callbacks(stdin, &vf, NULL, 0, OV_CALLBACKS_NOCLOSE) < 0) {
+      fprintf(stderr,"Input does not appear to be an Ogg bitstream.\n");
+      exit(1);
+  }
+
+
    +
    + +

    +We're going to pull the channel and bitrate info from the file using ov_info() and show them to the user. +We also want to pull out and show the user a comment attached to the file using ov_comment(). + +

    + + + + +
    +
    
+  {
+    char **ptr=ov_comment(&vf,-1)->user_comments;
+    vorbis_info *vi=ov_info(&vf,-1);
+    while(*ptr){
+      fprintf(stderr,"%s\n",*ptr);
+      ++ptr;
+    }
+    fprintf(stderr,"\nBitstream is %d channel, %ldHz\n",vi->channels,vi->rate);
+    fprintf(stderr,"\nDecoded length: %ld samples\n",
+            (long)ov_pcm_total(&vf,-1));
+    fprintf(stderr,"Encoded by: %s\n\n",ov_comment(&vf,-1)->vendor);
+  }
+  
+
    +
    + +

    +Here's the read loop: + +

    + + + + +
    +
    
+
+  while(!eof){
+    long ret=ov_read(&vf,pcmout,sizeof(pcmout),0,2,1,&current_section);
+    if (ret == 0) {
+      /* EOF */
+      eof=1;
+    } else if (ret < 0) {
+      /* error in the stream.  Not a problem, just reporting it in
+	 case we (the app) cares.  In this case, we don't. */
+    } else {
+      /* we don't bother dealing with sample rate changes, etc, but
+	 you'll have to*/
+      fwrite(pcmout,1,ret,stdout);
+    }
+  }
+
+  
+
    +
    + +

    +The code is reading blocks of data using ov_read(). +Based on the value returned, we know if we're at the end of the file or have invalid data. If we have valid data, we write it to the pcm output. + +

    +Now that we've finished playing, we can pack up and go home. It's important to call ov_clear() when we're finished. + +

    + + + + +
    +
    
+
+  ov_clear(&vf);
+    
+  fprintf(stderr,"Done.\n");
+  return(0);
+}
+
    +
    + +

    + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/exampleindex.html b/doc/vorbisfile/exampleindex.html new file mode 100644 index 0000000..9227b97 --- /dev/null +++ b/doc/vorbisfile/exampleindex.html @@ -0,0 +1,39 @@ + + + +vorbisfile - Documentation + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    VorbisFile Example Code

    + +

    +Three sample programs are included with the vorbisfile distribution. +

    +vorbisfile decoding
    +vorbisfile seeking
    +vorbisfile bitstream chaining
    + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/fileinfo.html b/doc/vorbisfile/fileinfo.html new file mode 100644 index 0000000..c025dd6 --- /dev/null +++ b/doc/vorbisfile/fileinfo.html @@ -0,0 +1,95 @@ + + + +Vorbisfile - File Information + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    File Information

    +

    Libvorbisfile contains many functions to get information about bitstream attributes and decoding status. +

    +All libvorbisfile file information routines are declared in "vorbis/vorbisfile.h". +

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    functionpurpose
    ov_bitrateReturns the average bitrate of the current logical bitstream.
    ov_bitrate_instantReturns the exact bitrate since the last call of this function, or -1 if at the beginning of the bitream or no new information is available.
    ov_streamsGives the number of logical bitstreams within the current physical bitstream.
    ov_seekableIndicates whether the bitstream is seekable.
    ov_serialnumberReturns the unique serial number of the specified logical bitstream.
    ov_raw_totalReturns the total (compressed) bytes in a physical or logical seekable bitstream.
    ov_pcm_totalReturns the total number of samples in a physical or logical seekable bitstream.
    ov_time_totalReturns the total time length in seconds of a physical or logical seekable bitstream.
    ov_raw_tellReturns the byte location of the next sample to be read, giving the approximate location in the stream that the decoding engine has reached.
    ov_pcm_tellReturns the sample location of the next sample to be read, giving the approximate location in the stream that the decoding engine has reached.
    ov_time_tellReturns the time location of the next sample to be read, giving the approximate location in the stream that the decoding engine has reached.
    ov_infoReturns the vorbis_info struct for a specific bitstream section.
    ov_commentReturns attached comments for the current bitstream.
    + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/index.html b/doc/vorbisfile/index.html new file mode 100644 index 0000000..167e1c0 --- /dev/null +++ b/doc/vorbisfile/index.html @@ -0,0 +1,49 @@ + + + +Vorbisfile - Documentation + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    Vorbisfile Documentation

    + +

    + +The Vorbisfile library provides a convenient high-level API for +decoding and basic manipulation of all Vorbis I audio streams. +Libvorbisfile is implemented as a layer on top of Xiph.Org's reference +libogg and libvorbis libraries.

    + +Vorbisfile can be used along with any ANSI compliant stdio implementation +for file/stream access, or use custom stream i/o routines provided by +the embedded environment. Both uses are described in detail in this +documentation. + +

    +API overview
    +API reference
    +Code Examples
    + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/initialization.html b/doc/vorbisfile/initialization.html new file mode 100644 index 0000000..da83957 --- /dev/null +++ b/doc/vorbisfile/initialization.html @@ -0,0 +1,118 @@ + + + +Vorbisfile - Setup/Teardown + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    Setup/Teardown

    In order to decode audio using +libvorbisfile, a bitstream containing Vorbis audio must be properly +initialized before decoding and cleared when decoding is finished. +The simplest possible case is to use ov_fopen() to open the file for access, check +it for Vorbis content, and prepare it for playback. A successful return code from ov_fopen() indicates the file is ready for use. +Once the file is no longer needed, ov_clear() is used to close the file and +deallocate decoding resources.

    + +On systems other than Windows[a], an +application may also open a file itself using fopen(), then pass the +FILE * to libvorbisfile using ov_open(). Do not call +fclose() on a file handle successfully submitted to ov_open(); libvorbisfile does this in the ov_clear() call.

    + +An application that requires more setup flexibility may open a data +stream using ov_open_callbacks() +to change default libvorbis behavior or specify non-stdio data access +mechanisms.

    + +

    +All libvorbisfile initialization and deallocation routines are declared in "vorbis/vorbisfile.h". +

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    functionpurpose
    ov_fopenOpens a file and initializes the Ogg Vorbis bitstream with default values. This must be called before other functions in the library may be + used.
    ov_openInitializes the Ogg Vorbis bitstream with default values from a passed in file handle. This must be called before other functions in the library may be + used. Do not use this call under Windows [a]; Use ov_fopen() or ov_open_callbacks() instead.
    ov_open_callbacksInitializes the Ogg Vorbis bitstream from a file handle and custom file/bitstream manipulation routines. Used instead of ov_open() or ov_fopen() when altering or replacing libvorbis's default stdio I/O behavior, or when a bitstream must be initialized from a FILE * under Windows.
    ov_testPartially opens a file just far enough to determine if the file +is an Ogg Vorbis file or not. A successful return indicates that the +file appears to be an Ogg Vorbis file, but the OggVorbis_File struct is not yet fully +initialized for actual decoding. After a successful return, the file +may be closed using ov_clear() or fully +opened for decoding using ov_test_open().

    This call is intended to +be used as a less expensive file open test than a full ov_open().

    +Note that libvorbisfile owns the passed in file resource is it returns success; do not fclose() files owned by libvorbisfile.

    ov_test_callbacksAs above but allowing application-define I/O callbacks.

    +Note that libvorbisfile owns the passed in file resource is it returns success; do not fclose() files owned by libvorbisfile.

    ov_test_open +Finish opening a file after a successful call to ov_test() or ov_test_callbacks().
    ov_clear Closes the + bitstream and cleans up loose ends. Must be called when + finished with the bitstream. After return, the OggVorbis_File struct is + invalid and may not be used before being initialized again + before begin reinitialized. + +
    + +

    +

    + + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_bitrate.html b/doc/vorbisfile/ov_bitrate.html new file mode 100644 index 0000000..eb3c4d7 --- /dev/null +++ b/doc/vorbisfile/ov_bitrate.html @@ -0,0 +1,72 @@ + + + +Vorbisfile - function - ov_bitrate + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_bitrate

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    This function returns the average bitrate for the specified logical bitstream. This may be different from the ov_info->nominal_bitrate value, as it is based on the actual average for this bitstream if the file is seekable. +

    Nonseekable files will return the nominal bitrate setting or the average of the upper and lower bounds, if any of these values are set. +

    + +

    + + + + +
    +
    
+long ov_bitrate(OggVorbis_File *vf,int i);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions.
    +
    i
    +
    Link to the desired logical bitstream. For nonseekable files, this argument is ignored. To retrieve the bitrate for the entire bitstream, this parameter should be set to -1.
    +
    + + +

    Return Values

    +
    +
  • OV_EINVAL indicates that an invalid argument value was submitted or that the stream represented by vf is not open.
    • +
  • OV_FALSE means the call returned a 'false' status, which in this case most likely indicates that the file is nonseekable and the upper, lower, and nominal bitrates were unset. +
  • n indicates the bitrate for the given logical bitstream or the entire + physical bitstream. If the file is open for random (seekable) access, it will + find the *actual* average bitrate. If the file is streaming (nonseekable), it + returns the nominal bitrate (if set) or else the average of the + upper/lower bounds (if set).
    • +
    +

    + + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_bitrate_instant.html b/doc/vorbisfile/ov_bitrate_instant.html new file mode 100644 index 0000000..da44dcf --- /dev/null +++ b/doc/vorbisfile/ov_bitrate_instant.html @@ -0,0 +1,65 @@ + + + +Vorbisfile - function - ov_bitrate + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_bitrate_instant

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    Used to find the most recent bitrate played back within the file. Will return 0 if the bitrate has not changed or it is the beginning of the file. + +

    + + + + +
    +
    
+long ov_bitrate_instant(OggVorbis_File *vf);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions. +
    + + +

    Return Values

    +
    +
  • 0 indicates the beginning of the file or unchanged bitrate info.
    • +
  • n indicates the actual bitrate since the last call.
    • +
  • OV_FALSE indicates that playback is not in progress, and thus there is no instantaneous bitrate information to report.
    • +
  • OV_EINVAL indicates that the stream represented by vf is not open.
    • +
    +

    + + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_callbacks.html b/doc/vorbisfile/ov_callbacks.html new file mode 100644 index 0000000..d1b64be --- /dev/null +++ b/doc/vorbisfile/ov_callbacks.html @@ -0,0 +1,117 @@ + + + +Vorbisfile - datatype - ov_callbacks + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_callbacks

    + +

    declared in "vorbis/codec.h"

    + +

    +The ov_callbacks structure contains file manipulation function prototypes necessary for opening, closing, seeking, and location. + +

    +The ov_callbacks structure does not need to be user-defined if you are +working with stdio-based file manipulation; the ov_fopen() and ov_open() calls internally provide default callbacks for +stdio. ov_callbacks are defined and passed to ov_open_callbacks() when +implementing non-stdio based stream manipulation (such as playback +from a memory buffer) or when ov_open()-style initialization from a FILE * is required under Windows [a]. +

    + + + + + +
    +
    typedef struct {
+  size_t (*read_func)  (void *ptr, size_t size, size_t nmemb, void *datasource);
+  int    (*seek_func)  (void *datasource, ogg_int64_t offset, int whence);
+  int    (*close_func) (void *datasource);
+  long   (*tell_func)  (void *datasource);
+} ov_callbacks;
    +
    + +

    Relevant Struct Members

    +
    +
    read_func
    +
    Pointer to custom data reading function.
    +
    seek_func
    +
    Pointer to custom data seeking function. If the data source is not seekable (or the application wants the data source to be treated as unseekable at all times), the provided seek callback should always return -1 (failure) or the seek_func and tell_func fields should be set to NULL.
    +
    close_func
    +
    Pointer to custom data source closure function. Set to NULL if libvorbisfile should not attempt to automatically close the file/data handle.
    +
    tell_func
    +
    Pointer to custom data location function. If the data source is not seekable (or the application wants the data source to be treated as unseekable at all times), the provided tell callback should always return -1 (failure) or the seek_func and tell_func fields should be set to NULL.
    +
    + +

    + +

    Predefined callbacks

    +The header vorbis/vorbisfile.h provides several predefined static ov_callbacks structures that may be passed to ov_open_callbacks(): +
    +
    OV_CALLBACKS_DEFAULT
    + +These callbacks provide the same behavior as used internally by ov_fopen() and ov_open(). + +
    OV_CALLBACKS_NOCLOSE
    + +The same as OV_CALLBACKS_DEFAULT, but with the +close_func field set to NULL. The most typical use would be +to use ov_open_callbacks() to +provide the same behavior as ov_open(), but +not close the file/data handle in ov_clear(). + +
    OV_CALLBACKS_STREAMONLY
    + +A set of callbacks that set seek_func and tell_func +to NULL, thus forcing strict streaming-only behavior regardless of +whether or not the input is actually seekable. + +
    OV_CALLBACKS_STREAMONLY_NOCLOSE
    + +The same as OV_CALLBACKS_STREAMONLY, but with +close_func also set to null, preventing libvorbisfile from +attempting to close the file/data handle in ov_clear(). + +
    +

    + +

    Examples and usage

    + +See the callbacks and non-stdio I/O document for more +detailed information on required behavior of the various callback +functions.

    + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_clear.html b/doc/vorbisfile/ov_clear.html new file mode 100644 index 0000000..e67107c --- /dev/null +++ b/doc/vorbisfile/ov_clear.html @@ -0,0 +1,64 @@ + + + +Vorbisfile - function - ov_clear + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_clear

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    After a bitstream has been opened using ov_fopen()/ov_open()/ov_open_callbacks() and decoding is complete, the application must call ov_clear() to clear +the decoder's buffers. ov_clear() will also close the file unless it was opened using ov_open_callbacks() with the close_func callback set to NULL.

    + +ov_clear() must also be called after a successful call to ov_test() or ov_test_callbacks().

    + +

    + + + + +
    +
    
+int ov_clear(OggVorbis_File *vf);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions. After ov_clear has been called, the contents of this structure are deallocated, and it can no longer be used without being reinitialized by a call to ov_fopen(), ov_open() or ov_open_callbacks().
    +
    + + +

    Return Values

    +
    +
  • 0 for success
    • +
    + + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_comment.html b/doc/vorbisfile/ov_comment.html new file mode 100644 index 0000000..9f1b499 --- /dev/null +++ b/doc/vorbisfile/ov_comment.html @@ -0,0 +1,66 @@ + + + +Vorbisfile - function - ov_bitrate + + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_comment

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    Returns a pointer to the vorbis_comment struct for the specified bitstream. For nonseekable streams, returns the struct for the current bitstream. +

    + +

    + + + + +
    +
    
+vorbis_comment *ov_comment(OggVorbis_File *vf,int link);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions.
    +
    i
    +
    Link to the desired logical bitstream. For nonseekable files, this argument is ignored. To retrieve the vorbis_comment struct for the current bitstream, this parameter should be set to -1.
    +
    + + +

    Return Values

    +
    +
  • Returns the vorbis_comment struct for the specified bitstream.
    • +
  • NULL if the specified bitstream does not exist or the file has been initialized improperly.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_crosslap.html b/doc/vorbisfile/ov_crosslap.html new file mode 100644 index 0000000..0b2b102 --- /dev/null +++ b/doc/vorbisfile/ov_crosslap.html @@ -0,0 +1,100 @@ + + + +Vorbisfile - function - ov_crosslap + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_crosslap()

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    ov_crosslap overlaps and blends the boundary at a transition +between two separate streams represented by separate OggVorbis_File structures. For lapping +transitions due to seeking within a single stream represented by a +single OggVorbis_File structure, +consider using the lapping versions of the vorbisfile seeking functions instead. + +

    ov_crosslap is used between the last (usually ov_read) call on +the old stream and the first ov_read from the new stream. Any +desired positioning of the new stream must occur before the call to +ov_crosslap() as a seek dumps all prior lapping information from a +stream's decode state. Crosslapping does not introduce or remove any +extraneous samples; positioning works exactly as if ov_crosslap was not +called. + +

    ov_crosslap will lap between streams of differing numbers of +channels. Any extra channels from the old stream are ignored; playback +of these channels simply ends. Extra channels in the new stream are +lapped from silence. ov_crosslap will also lap between streams links +of differing sample rates. In this case, the sample rates are ignored +(no implicit resampling is done to match playback). It is up to the +application developer to decide if this behavior makes any sense in a +given context; in practical use, these default behaviors perform +sensibly. + +

    + + + + +
    +
    
+long ov_crosslap(OggVorbis_File *old, OggVorbis_File *new);
+
+
    +
    + +

    Parameters

    +
    +
    old
    +
    A pointer to the OggVorbis_File structure representing the origin stream from which to transition playback.
    + +
    new
    +
    A pointer to the OggVorbis_File structure representing the stream with which playback continues.
    +
    + + +

    Return Values

    +
    +
    +
    OV_EINVAL
    +
    crosslap called with an OggVorbis_File structure that isn't open.
    +
    OV_EFAULT
    +
    internal error; implies a library bug or external heap corruption.
    +
    OV_EREAD
    +
    A read from media returned an error.
    +
    OV_EOF
    +
    indicates stream vf2 is at end of file, or that vf1 is at end of file immediately after a seek (making crosslap impossible as there's no preceding decode state to crosslap).
    +
    0
    +
    success.
    +
    +
    + + + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_fopen.html b/doc/vorbisfile/ov_fopen.html new file mode 100644 index 0000000..9a7b14b --- /dev/null +++ b/doc/vorbisfile/ov_fopen.html @@ -0,0 +1,124 @@ + + + +Vorbisfile - function - ov_fopen + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_fopen

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    This is the simplest function used to open and initialize an OggVorbis_File +structure. It sets up all the related decoding structure. +

    The first argument is a file path suitable +for passing to fopen(). vf should be a pointer to an empty +OggVorbis_File structure -- this is used for ALL the externally visible +libvorbisfile functions. Once this has been called, the same OggVorbis_File struct should be passed +to all the libvorbisfile functions. +

    The vf structure initialized using ov_fopen() must +eventually be cleaned using ov_clear(). + +

    +It is often useful to call ov_fopen() simply to determine +whether a given file is a Vorbis bitstream. If the ov_fopen() +call fails, then the file is either inaccessable (errno is set) or not +recognizable as Vorbis (errno unchanged). If the call succeeds but +the initialized vf structure will not be used, the +application is responsible for calling ov_clear() to clear the decoder's buffers and +close the file.

    + +

    + + + + +
    +
    
+int ov_fopen(const char *path,OggVorbis_File *vf);
+
    +
    + +

    Parameters

    +
    +
    path
    +
    Null terminated string containing a file path suitable for passing to fopen(). +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions. Once this has been called, the same OggVorbis_File +struct should be passed to all the libvorbisfile functions.
    +
    + + +

    Return Values

    +
    +
  • 0 indicates success
    • + +
  • less than zero for failure:
    • +
      +
    • OV_EREAD - A read from media returned an error.
      • +
    • OV_ENOTVORBIS - Bitstream does not contain any Vorbis data.
      • +
    • OV_EVERSION - Vorbis version mismatch.
      • +
    • OV_EBADHEADER - Invalid Vorbis bitstream header.
      • +
    • OV_EFAULT - Internal logic fault; indicates a bug or heap/stack corruption.
      • +
    +
    +

    + +

    Notes

    +
    + +
    [a] Threaded decode

    +

    If your decoder is threaded, it is recommended that you NOT call +ov_open_callbacks() +in the main control thread--instead, call ov_open_callbacks() in your decode/playback +thread. This is important because ov_open_callbacks() may be a fairly time-consuming +call, given that the full structure of the file is determined at this point, +which may require reading large parts of the file under certain circumstances +(determining all the logical bitstreams in one physical bitstream, for +example). See Thread Safety for other information on using libvorbisfile with threads. +

    + +

    [b] Mixed media streams

    +

    +As of Vorbisfile release 1.2.0, Vorbisfile is able to access the +Vorbis content in mixed-media Ogg streams, not just Vorbis-only +streams. For example, Vorbisfile may be used to open and access the +audio from an Ogg stream consisting of Theora video and Vorbis audio. +Vorbisfile 1.2.0 decodes the first logical audio stream of each +physical stream section.

    + +

    [c] Faster testing for Vorbis files

    +

    ov_test() and ov_test_callbacks() provide less +computationally expensive ways to test a file for Vorbisness, but +require more setup code.

    + +

    + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_info.html b/doc/vorbisfile/ov_info.html new file mode 100644 index 0000000..b94fa68 --- /dev/null +++ b/doc/vorbisfile/ov_info.html @@ -0,0 +1,64 @@ + + + +Vorbisfile - function - ov_info + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_info

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    Returns the vorbis_info struct for the specified bitstream. For nonseekable files, always returns the current vorbis_info struct. + +

    + + + + +
    +
    
+vorbis_info *ov_info(OggVorbis_File *vf,int link);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions.
    +
    i
    +
    Link to the desired logical bitstream. For nonseekable files, this argument is ignored. To retrieve the vorbis_info struct for the current bitstream, this parameter should be set to -1.
    +
    + + +

    Return Values

    +
    +
  • Returns the vorbis_info struct for the specified bitstream. Returns vorbis_info for current bitstream if the file is nonseekable or i=-1.
    • +
  • NULL if the specified bitstream does not exist or the file has been initialized improperly.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_open.html b/doc/vorbisfile/ov_open.html new file mode 100644 index 0000000..d0311ce --- /dev/null +++ b/doc/vorbisfile/ov_open.html @@ -0,0 +1,183 @@ + + + +Vorbisfile - function - ov_open + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_open

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    ov_open is one of three initialization functions used to initialize +an OggVorbis_File structure and prepare a bitstream for playback. + +

    WARNING for Windows developers: Do not use ov_open() in +Windows applications; Windows linking places restrictions on +passing FILE * handles successfully, and ov_open() runs +afoul of these restrictions [a]. See the ov_open_callbacks() page for +details on using ov_open_callbacks() instead. + +

    The first argument must be a file pointer to an already opened file +or pipe (it need not be seekable--though this obviously restricts what +can be done with the bitstream). vf should be a pointer to the +OggVorbis_File structure -- this is used for ALL the externally visible libvorbisfile +functions. Once this has been called, the same OggVorbis_File +struct should be passed to all the libvorbisfile functions.

    + +The vf structure initialized using ov_fopen() must eventually +be cleaned using ov_clear(). Once a +FILE * handle is passed to ov_open() successfully, the +application MUST NOT fclose() or in any other way manipulate +that file handle. Vorbisfile will close the file in ov_clear(). If the application must be able +to close the FILE * handle itself, see ov_open_callbacks() with the use of +OV_CALLBACKS_NOCLOSE. + +

    It is often useful to call ov_open() simply to determine +whether a given file is a Vorbis bitstream. If the ov_open() +call fails, then the file is not recognizable as Vorbis. If the call +succeeds but the initialized vf structure will not be used, +the application is responsible for calling ov_clear() to clear the decoder's buffers and +close the file.

    + +If [and only if] an ov_open() call fails, the application +must explicitly fclose() the FILE * pointer itself. + + +

    + + + + +
    +
    
+int ov_open(FILE *f,OggVorbis_File *vf,char *initial,long ibytes);
+
    +
    + +

    Parameters

    +
    +
    f
    +
    File pointer to an already opened file +or pipe (it need not be seekable--though this obviously restricts what +can be done with the bitstream).
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions. Once this has been called, the same OggVorbis_File +struct should be passed to all the libvorbisfile functions.
    +
    initial
    +
    Typically set to NULL. This parameter is useful if some data has already been +read from the file and the stream is not seekable. It is used in conjunction with ibytes. In this case, initial +should be a pointer to a buffer containing the data read.
    +
    ibytes
    +
    Typically set to 0. This parameter is useful if some data has already been +read from the file and the stream is not seekable. In this case, ibytes +should contain the length (in bytes) of the buffer. Used together with initial
    +
    + + +

    Return Values

    +
    +
  • 0 indicates success
    • + +
  • less than zero for failure:
    • +
      +
    • OV_EREAD - A read from media returned an error.
      • +
    • OV_ENOTVORBIS - Bitstream is not Vorbis data.
      • +
    • OV_EVERSION - Vorbis version mismatch.
      • +
    • OV_EBADHEADER - Invalid Vorbis bitstream header.
      • +
    • OV_EFAULT - Internal logic fault; indicates a bug or heap/stack corruption.
      • +
    +
    +

    + + +

    Notes

    +
    + + +
    [a] Windows and ov_open()

    + +

    Under Windows, stdio file access is implemented in each of many +variants of crt.o, several of which are typically installed on any one +Windows machine. If libvorbisfile and the application using +libvorbisfile are not linked against the exact same +version/variant/build of crt.o (and they usually won't be, especially +using a prebuilt libvorbis DLL), FILE * handles cannot be +opened in the application and then passed to vorbisfile to be used +by stdio calls from vorbisfile's different version of CRT. For this +reason, using ov_open() under Windows +without careful, expert linking will typically cause a protection +fault. Windows programmers should use ov_fopen() (which will only use libvorbis's +crt.o) or ov_open_callbacks() +(which will only use the application's crt.o) instead.

    + +This warning only applies to Windows and only applies to ov_open(). It is perfectly safe to use ov_open() on all other platforms.

    + +For more information, see the following microsoft pages on C +runtime library linking and a specific description of restrictions +on passing CRT objects across DLL boundaries. + +

    + +

    [b] Threaded decode

    +

    If your decoder is threaded, it is recommended that you NOT call +ov_open() +in the main control thread--instead, call ov_open() in your decode/playback +thread. This is important because ov_open() may be a fairly time-consuming +call, given that the full structure of the file is determined at this point, +which may require reading large parts of the file under certain circumstances +(determining all the logical bitstreams in one physical bitstream, for +example). See Thread Safety for other information on using libvorbisfile with threads. +

    + +

    [c] Mixed media streams

    +

    +As of Vorbisfile release 1.2.0, Vorbisfile is able to access the +Vorbis content in mixed-media Ogg streams, not just Vorbis-only +streams. For example, Vorbisfile may be used to open and access the +audio from an Ogg stream consisting of Theora video and Vorbis audio. +Vorbisfile 1.2.0 decodes the first logical audio stream of each +physical stream section.

    + +

    [d] Faster testing for Vorbis files

    +

    ov_test() and ov_test_callbacks() provide less +computationally expensive ways to test a file for Vorbisness, but +require more setup code.

    + +

    + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_open_callbacks.html b/doc/vorbisfile/ov_open_callbacks.html new file mode 100644 index 0000000..6d59e0b --- /dev/null +++ b/doc/vorbisfile/ov_open_callbacks.html @@ -0,0 +1,147 @@ + + + +Vorbisfile - function - ov_open_callbacks + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_open_callbacks

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    This is an alternative function used to open and initialize an +OggVorbis_File structure when using a data source other than a file, +when its necessary to modify default file access behavior, or to +initialize a Vorbis decode from a FILE * pointer under +Windows where ov_open() cannot be used. It +allows the application to specify custom file manipulation routines +and sets up all the related decoding structures. + +

    Once ov_open_callbacks() has been called, the same +OggVorbis_File struct should be passed to all the +libvorbisfile functions. Unlike ov_fopen() and ov_open(), ov_open_callbacks() may be used to +instruct vorbisfile to either automatically close or not to close the +file/data access handle in ov_clear(). +Automatic closure is disabled by passing NULL as the close callback, +or using one of the predefined callback sets that specify a NULL close +callback. The application is responsible for closing a file when a +call to ov_open_callbacks() is unsuccessful.

    + +See also Callbacks and Non-stdio I/O for +information on designing and specifying custom callback functions.

    + +

    + + + + +
    +
    
+int ov_open_callbacks(void *datasource, OggVorbis_File *vf, char *initial, long ibytes, ov_callbacks callbacks);
+
    +
    + +

    Parameters

    +
    +
    datasource
    +
    Pointer to a data structure allocated by the calling application, containing any state needed by the callbacks provided.
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions. Once this has been called, the same OggVorbis_File +struct should be passed to all the libvorbisfile functions.
    +
    initial
    +
    Typically set to NULL. This parameter is useful if some data has already been +read from the stream and the stream is not seekable. It is used in conjunction with ibytes. In this case, initial +should be a pointer to a buffer containing the data read.
    +
    ibytes
    +
    Typically set to 0. This parameter is useful if some data has already been +read from the stream and the stream is not seekable. In this case, ibytes +should contain the length (in bytes) of the buffer. Used together with initial.
    +
    callbacks
    +
    A completed ov_callbacks struct which indicates desired custom file manipulation routines. vorbisfile.h defines several preprovided callback sets; see ov_callbacks for details.
    +
    + + +

    Return Values

    +
    +
  • 0 for success
    • +
  • less than zero for failure:
    • +
      +
    • OV_EREAD - A read from media returned an error.
      • +
    • OV_ENOTVORBIS - Bitstream does not contain any Vorbis data.
      • +
    • OV_EVERSION - Vorbis version mismatch.
      • +
    • OV_EBADHEADER - Invalid Vorbis bitstream header.
      • +
    • OV_EFAULT - Internal logic fault; indicates a bug or heap/stack corruption.
      • +
    +
    +

    + +

    Notes

    +
    + +
    [a] Windows and use as an ov_open() substitute

    Windows +applications should not use ov_open() due +to the likelihood of CRT linking +mismatches and runtime protection faults +[ov_open:a]. ov_open_callbacks() is a safe substitute; specifically: + +

    ov_open_callbacks(f, vf, initial, ibytes, OV_CALLBACKS_DEFAULT);
+
    + +... provides exactly the same functionality as ov_open() but will always work correctly under +Windows, regardless of linking setup details.

    + +

    [b] Threaded decode

    +

    If your decoder is threaded, it is recommended that you NOT call +ov_open_callbacks() +in the main control thread--instead, call ov_open_callbacks() in your decode/playback +thread. This is important because ov_open_callbacks() may be a fairly time-consuming +call, given that the full structure of the file is determined at this point, +which may require reading large parts of the file under certain circumstances +(determining all the logical bitstreams in one physical bitstream, for +example). See Thread Safety for other information on using libvorbisfile with threads. +

    + +

    [c] Mixed media streams

    +

    +As of Vorbisfile release 1.2.0, Vorbisfile is able to access the +Vorbis content in mixed-media Ogg streams, not just Vorbis-only +streams. For example, Vorbisfile may be used to open and access the +audio from an Ogg stream consisting of Theora video and Vorbis audio. +Vorbisfile 1.2.0 decodes the first logical audio stream of each +physical stream section.

    + +

    [d] Faster testing for Vorbis files

    +

    ov_test() and ov_test_callbacks() provide less +computationally expensive ways to test a file for Vorbisness, but +require more setup code.

    + +

    + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_pcm_seek.html b/doc/vorbisfile/ov_pcm_seek.html new file mode 100644 index 0000000..81b0c1c --- /dev/null +++ b/doc/vorbisfile/ov_pcm_seek.html @@ -0,0 +1,83 @@ + + + +Vorbisfile - function - ov_pcm_seek + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_pcm_seek

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    Seeks to the offset specified (in pcm samples) within the physical bitstream. This function only works for seekable streams. +

    This also updates everything needed within the +decoder, so you can immediately call ov_read() and get data from +the newly seeked to position. +

    + +

    + + + + +
    +
    
+int ov_pcm_seek(OggVorbis_File *vf,ogg_int64_t pos);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions.
    +
    pos
    +
    Position in pcm samples to seek to in the bitstream.
    +
    + + +

    Return Values

    +
    +
      +
    • 0 for success
      • + +
    • +nonzero indicates failure, described by several error codes: +
        +
      • OV_ENOSEEK - Bitstream is not seekable. +
        • +
      • OV_EINVAL - Invalid argument value; possibly called with an OggVorbis_File structure that isn't open. +
        • +
      • OV_EREAD - A read from media returned an error. +
        • +
      • OV_EFAULT - Internal logic fault; indicates a bug or heap/stack + corruption. +
        • +
      • OV_EBADLINK - Invalid stream section supplied to libvorbisfile, or the requested link is corrupt. +
        • +
      • +
    + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_pcm_seek_lap.html b/doc/vorbisfile/ov_pcm_seek_lap.html new file mode 100644 index 0000000..6310e42 --- /dev/null +++ b/doc/vorbisfile/ov_pcm_seek_lap.html @@ -0,0 +1,103 @@ + + + +Vorbisfile - function - ov_pcm_seek_lap + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_pcm_seek_lap

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    Seeks to the offset specified (in pcm samples) within the physical bitstream. This variant of ov_pcm_seek also automatically +crosslaps the transition from the previous playback position into the +new playback position in order to eliminate clicking and boundary +discontinuities. Otherwise, usage and behavior is identical to ov_pcm_seek. + +

    ov_pcm_seek_lap also updates everything needed within the decoder, +so you can immediately call ov_read() and +get data from the newly seeked to position. + +

    ov_pcm_seek_lap will lap between logical stream links of differing +numbers of channels. Any extra channels from the origin of the seek +are ignored; playback of these channels simply ends. Extra channels at +the destination are lapped from silence. ov_pcm_seek_lap will also +lap between logical stream links of differing sample rates. In this +case, the sample rates are ignored (no implicit resampling is done to +match playback). It is up to the application developer to decide if +this behavior makes any sense in a given context; in practical use, +these default behaviors perform sensibly. + +

    This function only works for seekable streams. + +

    + + + + +
    +
    
+int ov_pcm_seek_lap(OggVorbis_File *vf,ogg_int64_t pos);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions.
    +
    pos
    +
    Position in pcm samples to seek to in the bitstream.
    +
    + + +

    Return Values

    +
    +
      +
    • 0 for success
      • + +
    • +nonzero indicates failure, described by several error codes: +
        +
      • OV_ENOSEEK - Bitstream is not seekable. +
        • +
      • OV_EINVAL - Invalid argument value; possibly called with an OggVorbis_File structure that isn't open. +
        • +
      • OV_EREAD - A read from media returned an error. +
        • +
      • OV_EFAULT - Internal logic fault; indicates a bug or heap/stack + corruption. +
        • +
      • OV_EOF - Indicates stream is at end of file immediately after a seek + (making crosslap impossible as there's no preceeding decode state to crosslap). +
        • +
      • OV_EBADLINK - Invalid stream section supplied to libvorbisfile, or the requested link is corrupt. +
        • +
      • +
    + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_pcm_seek_page.html b/doc/vorbisfile/ov_pcm_seek_page.html new file mode 100644 index 0000000..8f1959a --- /dev/null +++ b/doc/vorbisfile/ov_pcm_seek_page.html @@ -0,0 +1,84 @@ + + + +Vorbisfile - function - ov_pcm_seek_page + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_pcm_seek_page

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    Seeks to the closest page preceding the specified location (in pcm samples) within the physical bitstream. This function only works for seekable streams. +

    This function is faster than ov_pcm_seek because the function can begin decoding at a page boundary rather than seeking through any remaining samples before the specified location. However, it is less accurate. +

    This also updates everything needed within the +decoder, so you can immediately call ov_read() and get data from +the newly seeked to position. +

    + +

    + + + + +
    +
    
+int ov_pcm_seek_page(OggVorbis_File *vf,ogg_int64_t pos);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions.
    +
    pos
    +
    Position in pcm samples to seek to in the bitstream.
    +
    + + +

    Return Values

    +
    +
      +
    • 0 for success
      • + +
    • +nonzero indicates failure, described by several error codes: +
        +
      • OV_ENOSEEK - Bitstream is not seekable. +
        • +
      • OV_EINVAL - Invalid argument value; possibly called with an OggVorbis_File structure that isn't open. +
        • +
      • OV_EREAD - A read from media returned an error. +
        • +
      • OV_EFAULT - Internal logic fault; indicates a bug or heap/stack + corruption. +
        • +
      • OV_EBADLINK - Invalid stream section supplied to libvorbisfile, or the requested link is corrupt. +
        • +
      • +
    + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_pcm_seek_page_lap.html b/doc/vorbisfile/ov_pcm_seek_page_lap.html new file mode 100644 index 0000000..d9694e8 --- /dev/null +++ b/doc/vorbisfile/ov_pcm_seek_page_lap.html @@ -0,0 +1,112 @@ + + + +Vorbisfile - function - ov_pcm_seek_page_lap + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_pcm_seek_page_lap

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    Seeks to the closest page preceding the specified location (in pcm +samples) within the physical bitstream. This variant of ov_pcm_seek_page also automatically +crosslaps the transition from the previous playback position into the +new playback position in order to eliminate clicking and boundary +discontinuities. Otherwise, usage and behavior is identical to ov_pcm_seek_page. + +

    This function is faster than ov_pcm_seek_lap because the function +can begin decoding at a page boundary rather than seeking through any +remaining samples before the specified location. However, it is less +accurate. + +

    ov_pcm_seek_page_lap also updates everything needed within the +decoder, so you can immediately call ov_read() and get data from the newly seeked +to position. + +

    ov_pcm_seek_page_lap will lap between logical stream links of +differing numbers of channels. Any extra channels from the origin of +the seek are ignored; playback of these channels simply ends. Extra +channels at the destination are lapped from silence. +ov_pcm_seek_page_lap will also lap between logical stream links of +differing sample rates. In this case, the sample rates are ignored +(no implicit resampling is done to match playback). It is up to the +application developer to decide if this behavior makes any sense in a +given context; in practical use, these default behaviors perform +sensibly. + +

    This function only works for seekable streams. + +

    + + + + +
    +
    
+int ov_pcm_seek_page_lap(OggVorbis_File *vf,ogg_int64_t pos);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions.
    +
    pos
    +
    Position in pcm samples to seek to in the bitstream.
    +
    + + +

    Return Values

    +
    +
      +
    • 0 for success
      • + +
    • +nonzero indicates failure, described by several error codes: +
        +
      • OV_ENOSEEK - Bitstream is not seekable. +
        • +
      • OV_EINVAL - Invalid argument value; possibly called with an OggVorbis_File structure that isn't open. +
        • +
      • OV_EREAD - A read from media returned an error. +
        • +
      • OV_EFAULT - Internal logic fault; indicates a bug or heap/stack + corruption. +
        • +
      • OV_EOF - Indicates stream is at end of file immediately after a seek + (making crosslap impossible as there's no preceeding decode state to crosslap). +
        • +
      • OV_EBADLINK - Invalid stream section supplied to libvorbisfile, or the requested link is corrupt. +
        • +
      • +
    + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_pcm_tell.html b/doc/vorbisfile/ov_pcm_tell.html new file mode 100644 index 0000000..2d8ea83 --- /dev/null +++ b/doc/vorbisfile/ov_pcm_tell.html @@ -0,0 +1,63 @@ + + + +Vorbisfile - function - ov_pcm_tell + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_pcm_tell

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    Returns the current offset in samples. + +

    + + + + +
    +
    
+ogg_int64_t ov_pcm_tell(OggVorbis_File *vf);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions.
    +
    + + +

    Return Values

    +
    +
  • n indicates the current offset in samples.
    • +
  • OV_EINVAL means that the argument was invalid. In this case, the requested bitstream did not exist.
    • +
    +

    + + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_pcm_total.html b/doc/vorbisfile/ov_pcm_total.html new file mode 100644 index 0000000..297a8e1 --- /dev/null +++ b/doc/vorbisfile/ov_pcm_total.html @@ -0,0 +1,67 @@ + + + +Vorbisfile - function - ov_pcm_total + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_pcm_total

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    Returns the total pcm samples of the physical bitstream or a specified logical bitstream. + +

    + + + + +
    +
    
+ogg_int64_t ov_pcm_total(OggVorbis_File *vf,int i);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions.
    +
    i
    +
    Link to the desired logical bitstream. To retrieve the total pcm samples for the entire physical bitstream, this parameter should be set to -1.
    +
    + + +

    Return Values

    +
    +
  • OV_EINVAL means that the argument was invalid. In this case, the requested bitstream did not exist or the bitstream is unseekable.
    • +
  • +total length in pcm samples of content if i=-1.
    • +
  • length in pcm samples of logical bitstream if i=0 to n.
    • +
    +

    + + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_raw_seek.html b/doc/vorbisfile/ov_raw_seek.html new file mode 100644 index 0000000..04ed549 --- /dev/null +++ b/doc/vorbisfile/ov_raw_seek.html @@ -0,0 +1,83 @@ + + + +Vorbisfile - function - ov_raw_seek + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_raw_seek

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    Seeks to the offset specified (in compressed raw bytes) within the physical bitstream. This function only works for seekable streams. +

    This also updates everything needed within the +decoder, so you can immediately call ov_read() and get data from +the newly seeked to position. +

    When seek speed is a priority, this is the best seek funtion to use. +

    + + + + +
    +
    
+int ov_raw_seek(OggVorbis_File *vf,long pos);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions.
    +
    pos
    +
    Position in compressed bytes to seek to in the bitstream.
    +
    + + +

    Return Values

    +
    +
      +
    • 0 for success
      • + +
    • +nonzero indicates failure, described by several error codes: +
        +
      • OV_ENOSEEK - Bitstream is not seekable. +
        • +
      • OV_EINVAL - Invalid argument value; possibly called with an OggVorbis_File structure that isn't open. +
        • +
      • OV_EREAD - A read from media returned an error. +
        • +
      • OV_EFAULT - Internal logic fault; indicates a bug or heap/stack + corruption. +
        • +
      • OV_EBADLINK - Invalid stream section supplied to libvorbisfile, or the requested link is corrupt. +
        • +
      • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_raw_seek_lap.html b/doc/vorbisfile/ov_raw_seek_lap.html new file mode 100644 index 0000000..8e8c24d --- /dev/null +++ b/doc/vorbisfile/ov_raw_seek_lap.html @@ -0,0 +1,110 @@ + + + +Vorbisfile - function - ov_raw_seek_lap + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_raw_seek_lap

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    Seeks to the offset specified (in compressed raw bytes) within the +physical bitstream. This variant of ov_raw_seek also automatically crosslaps +the transition from the previous playback position into the new +playback position in order to eliminate clicking and boundary +discontinuities. Otherwise, usage and behavior is identical to ov_raw_seek. + +

    When seek speed is a priority, but crosslapping is still desired, +this is the best seek funtion to use. + +

    ov_raw_seek_lap also updates everything needed within the decoder, +so you can immediately call ov_read() and +get data from the newly seeked to position. + +

    ov_raw_seek_lap will lap between logical stream links of differing +numbers of channels. Any extra channels from the origin of the seek +are ignored; playback of these channels simply ends. Extra channels at +the destination are lapped from silence. ov_raw_seek_lap will also +lap between logical stream links of differing sample rates. In this +case, the sample rates are ignored (no implicit resampling is done to +match playback). It is up to the application developer to decide if +this behavior makes any sense in a given context; in practical use, +these default behaviors perform sensibly. + +

    This function only works for seekable streams. + + +

    + + + + +
    +
    
+int ov_raw_seek_lap(OggVorbis_File *vf,long pos);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions.
    +
    pos
    +
    Position in compressed bytes to seek to in the bitstream.
    +
    + + +

    Return Values

    +
    +
      +
    • 0 for success
      • + +
    • +nonzero indicates failure, described by several error codes: +
        +
      • OV_ENOSEEK - Bitstream is not seekable. +
        • +
      • OV_EINVAL - Invalid argument value; possibly called with an OggVorbis_File structure that isn't open. +
        • +
      • OV_EREAD - A read from media returned an error. +
        • +
      • OV_EFAULT - Internal logic fault; indicates a bug or heap/stack + corruption. +
        • +
      • OV_EOF - Indicates stream is at end of file immediately after a seek + (making crosslap impossible as there's no preceeding decode state to crosslap). +
        • +
      • OV_EBADLINK - Invalid stream section supplied to libvorbisfile, or the requested link is corrupt. +
        • +
      • +
    + +

    + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_raw_tell.html b/doc/vorbisfile/ov_raw_tell.html new file mode 100644 index 0000000..5f30eff --- /dev/null +++ b/doc/vorbisfile/ov_raw_tell.html @@ -0,0 +1,65 @@ + + + +Vorbisfile - function - ov_raw_tell + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_raw_tell

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    Returns the current offset in raw compressed bytes.

    + +

    Note that if you later use ov_raw_seek() to return to this point, you won't generally get back to exactly the same place, due to internal buffering. Also note that a read operation may not cause a change to the current raw offset - only a read that requires reading more data from the underlying data source will do that.

    + +

    + + + + +
    +
    
+ogg_int64_t ov_raw_tell(OggVorbis_File *vf);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions.
    +
    + + +

    Return Values

    +
    +
  • n indicates the current offset in bytes.
    • +
  • OV_EINVAL means that the argument was invalid. In this case, the requested bitstream did not exist.
    • +
    +

    + + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_raw_total.html b/doc/vorbisfile/ov_raw_total.html new file mode 100644 index 0000000..d9d8303 --- /dev/null +++ b/doc/vorbisfile/ov_raw_total.html @@ -0,0 +1,68 @@ + + + +Vorbisfile - function - ov_raw_total + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_raw_total

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    Returns the total (compressed) bytes of the physical bitstream or a specified logical bitstream. + +

    + + + + +
    +
    
+ogg_int64_t ov_raw_total(OggVorbis_File *vf,int i);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions.
    +
    i
    +
    Link to the desired logical bitstream. To retrieve the total bytes for the entire physical bitstream, this parameter should be set to -1.
    +
    + + +

    Return Values

    +
    +
  • OV_EINVAL means that the argument was invalid. In this case, the requested bitstream did not exist or the bitstream is nonseekable
    • +
  • n +total length in compressed bytes of content if i=-1.
    • +
  • n length in compressed bytes of logical bitstream if i=0 to n.
    • +
    +

    + + + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_read.html b/doc/vorbisfile/ov_read.html new file mode 100644 index 0000000..5461a84 --- /dev/null +++ b/doc/vorbisfile/ov_read.html @@ -0,0 +1,148 @@ + + + +Vorbisfile - function - ov_read + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_read()

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    + This is the main function used to decode a Vorbis file within a + loop. It returns up to the specified number of bytes of decoded PCM audio + in the requested endianness, signedness, and word size. If the audio is + multichannel, the channels are interleaved in the output buffer. + If the passed in buffer is large, ov_read() will not fill + it; the passed in buffer size is treated as a limit and + not a request. + +

    The output channels are in stream order and not remapped. Vorbis I +defines channel order as follows: + +

      +
    • one channel - the stream is monophonic +
    • two channels - the stream is stereo. channel order: left, right +
    • three channels - the stream is a 1d-surround encoding. channel order: left, +center, right +
    • four channels - the stream is quadraphonic surround. channel order: front left, +front right, rear left, rear right +
    • five channels - the stream is five-channel surround. channel order: front left, +center, front right, rear left, rear right +
    • six channels - the stream is 5.1 surround. channel order: front left, center, +front right, rear left, rear right, LFE +
    • seven channels - the stream is 6.1 surround. channel order: front left, center, +front right, side left, side right, rear center, LFE +
    • eight channels - the stream is 7.1 surround. channel order: front left, center, +front right, side left, side right, rear left, rear right, +LFE +
    • greater than eight channels - channel use and order is undefined +
    + +

    Note that up to this point, the Vorbisfile API could more or less hide the + multiple logical bitstream nature of chaining from the toplevel + application if the toplevel application didn't particularly care. + However, when reading audio back, the application must be aware + that multiple bitstream sections do not necessarily use the same + number of channels or sampling rate.

    ov_read() passes + back the index of the sequential logical bitstream currently being + decoded (in *bitstream) along with the PCM data in order + that the toplevel application can handle channel and/or sample + rate changes. This number will be incremented at chaining + boundaries even for non-seekable streams. For seekable streams, it + represents the actual chaining index within the physical bitstream. +

    + +

    + + + + +
    +
    
+long ov_read(OggVorbis_File *vf, char *buffer, int length, int bigendianp, int word, int sgned, int *bitstream);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions.
    +
    buffer
    +
    A pointer to an output buffer. The decoded output is inserted into this buffer.
    +
    length
    +
    Number of bytes to be read into the buffer. Should be the same size as the buffer. A typical value is 4096.
    +
    bigendianp
    +
    Specifies big or little endian byte packing. 0 for little endian, 1 for b +ig endian. Typical value is 0.
    +
    word
    +
    Specifies word size. Possible arguments are 1 for 8-bit samples, or 2 or +16-bit samples. Typical value is 2.
    +
    sgned
    +
    Signed or unsigned data. 0 for unsigned, 1 for signed. Typically 1.
    +
    bitstream
    +
    A pointer to the number of the current logical bitstream.
    +
    + + +

    Return Values

    +
    +
    +
    OV_HOLE
    +
    indicates there was an interruption in the data. +
    (one of: garbage between pages, loss of sync followed by + recapture, or a corrupt page)
    +
    OV_EBADLINK
    +
    indicates that an invalid stream section was supplied to + libvorbisfile, or the requested link is corrupt.
    +
    OV_EINVAL
    +
    indicates the initial file headers couldn't be read or + are corrupt, or that the initial open call for vf + failed.
    +
    0
    +
    indicates EOF
    +
    n
    +
    indicates actual number of bytes read. ov_read() will + decode at most one vorbis packet per invocation, so the value + returned will generally be less than length. +
    +
    + +

    Notes

    +

    Typical usage: +

    +bytes_read = ov_read(&vf, +buffer, 4096,0,2,1,&current_section) +
    + +This reads up to 4096 bytes into a buffer, with signed 16-bit +little-endian samples. +

    + + + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_read_filter.html b/doc/vorbisfile/ov_read_filter.html new file mode 100644 index 0000000..e3f2e84 --- /dev/null +++ b/doc/vorbisfile/ov_read_filter.html @@ -0,0 +1,114 @@ + + + +Vorbisfile - function - ov_read_filter + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_read_filter()

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    + ov_read_filter() is a variant of ov_read(), the main function used to decode + a Vorbis file within a loop. It passes the decoded floating point + PCM data to the filter specified in the function arguments before + converting the data to integer output samples. All other aspects of + its behavior are as with ov_read(). +

    + +

    + + + + +
    +
    
+long ov_read_filter(OggVorbis_File *vf, char *buffer, int length, int bigendianp, int word, int sgned, int *bitstream, 
+                    void (*filter)(float **pcm,long channels,long samples,void *filter_param),void *filter_param);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions.
    +
    buffer
    +
    A pointer to an output buffer. The decoded output is inserted into this buffer.
    +
    length
    +
    Number of bytes to be read into the buffer. Should be the same size as the buffer. A typical value is 4096.
    +
    bigendianp
    +
    Specifies big or little endian byte packing. 0 for little endian, 1 for b +ig endian. Typical value is 0.
    +
    word
    +
    Specifies word size. Possible arguments are 1 for 8-bit samples, or 2 or +16-bit samples. Typical value is 2.
    +
    sgned
    +
    Signed or unsigned data. 0 for unsigned, 1 for signed. Typically 1.
    +
    bitstream
    +
    A pointer to the number of the current logical bitstream.
    +
    filter
    +
    Filter function to process float PCM data prior to conversion to interleaved integer output.
    +
    filter_param
    +
    Data to pass through to the filter function.
    + +
    + + +

    Return Values

    +
    +
    +
    OV_HOLE
    +
    indicates there was an interruption in the data. +
    (one of: garbage between pages, loss of sync followed by + recapture, or a corrupt page)
    +
    OV_EBADLINK
    +
    indicates that an invalid stream section was supplied to + libvorbisfile, or the requested link is corrupt.
    +
    0
    +
    indicates EOF
    +
    n
    +
    indicates actual number of bytes read. ov_read() will + decode at most one vorbis packet per invocation, so the value + returned will generally be less than length. +
    +
    + +

    Notes

    +

    Typical usage: +

    +bytes_read = ov_read_filter(&vf, +buffer, 4096,0,2,1,&current_section, filter, (void *)filter_data_ptr) +
    + +This reads up to 4096 bytes into a buffer, with signed 16-bit +little-endian samples. The decoded data is passed to the function filter before integer conversiona nd interleave. +

    + + + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_read_float.html b/doc/vorbisfile/ov_read_float.html new file mode 100644 index 0000000..0c36eb0 --- /dev/null +++ b/doc/vorbisfile/ov_read_float.html @@ -0,0 +1,105 @@ + + + +Vorbisfile - function - ov_read_float + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_read_float()

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    + This is the function used to decode a Vorbis file within a loop, but + returns samples in native float format instead of in integer formats. +

    + For information on channel ordering and how ov_read_float() deals with the complex issues + of chaining, etc, refer to the documentation for ov_read(). +

    + +

    + + + + +
    +
    
+long ov_read_float(OggVorbis_File *vf, float ***pcm_channels, int samples, int *bitstream);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible vorbisfile +functions.
    +
    pcm_channels
    +
    A pointer to an output buffer. The pointer will be set to the decoded output buffer.
    +
    samples
    +
    Maximum number of decoded samples to produce.
    +
    bitstream
    +
    A pointer to the number of the current logical bitstream.
    +
    + + +

    Return Values

    +
    +
    +
    OV_HOLE
    +
    indicates there was an interruption in the data. +
    (one of: garbage between pages, loss of sync followed by + recapture, or a corrupt page)
    +
    OV_EBADLINK
    +
    indicates that an invalid stream section was supplied to + libvorbisfile, or the requested link is corrupt.
    +
    OV_EINVAL
    +
    indicates the initial file headers couldn't be read or + are corrupt, or that the initial open call for vf + failed.
    +
    0
    +
    indicates EOF
    +
    n
    +
    indicates actual number of samples read. ov_read_float() will + decode at most one vorbis packet per invocation, so the value + returned will generally be less than length. +
    +
    + +

    Notes

    +

    Typical usage: +

    +float **pcm; +samples_read = ov_read_float(&vf,pcm, 1024, &current_section) +
    + +This decodes up to 1024 float samples. +

    + +
    +

    +
    + + + + + + + + +

    copyright © 2002 vorbis team

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + + + + + diff --git a/doc/vorbisfile/ov_seekable.html b/doc/vorbisfile/ov_seekable.html new file mode 100644 index 0000000..59b6e97 --- /dev/null +++ b/doc/vorbisfile/ov_seekable.html @@ -0,0 +1,63 @@ + + + +Vorbisfile - function - ov_seekable + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_seekable

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    This indicates whether or not the bitstream is seekable. + + +

    + + + + +
    +
    
+long ov_seekable(OggVorbis_File *vf);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions.
    +
    + + +

    Return Values

    +
    +
  • 0 indicates that the file is not seekable.
    • +
  • nonzero indicates that the file is seekable.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_serialnumber.html b/doc/vorbisfile/ov_serialnumber.html new file mode 100644 index 0000000..1b64415 --- /dev/null +++ b/doc/vorbisfile/ov_serialnumber.html @@ -0,0 +1,67 @@ + + + +Vorbisfile - function - ov_serialnumber + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_serialnumber

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    Returns the serialnumber of the specified logical bitstream link number within the overall physical bitstream. + +

    + + + + +
    +
    
+long ov_serialnumber(OggVorbis_File *vf,int i);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions.
    +
    i
    +
    Link to the desired logical bitstream. For nonseekable files, this argument is ignored. To retrieve the serial number of the current bitstream, this parameter should be set to -1.
    +
    + + +

    Return Values

    +
    +
  • +-1 if the specified logical bitstream i does not exist.
    • + +
  • Returns the serial number of the logical bitstream i or the serial number of the current bitstream if the file is nonseekable.
    • +
    +

    + + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_streams.html b/doc/vorbisfile/ov_streams.html new file mode 100644 index 0000000..e455b07 --- /dev/null +++ b/doc/vorbisfile/ov_streams.html @@ -0,0 +1,64 @@ + + + +Vorbisfile - function - ov_streams + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_streams

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    Returns the number of logical bitstreams within our physical bitstream. + +

    + + + + +
    +
    
+long ov_streams(OggVorbis_File *vf);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions.
    +
    + + +

    Return Values

    +
    +
  • +1 indicates a single logical bitstream or an unseekable file.
    • +
  • n indicates the number of logical bitstreams.
    • +
    +

    + + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_test.html b/doc/vorbisfile/ov_test.html new file mode 100644 index 0000000..cb11d01 --- /dev/null +++ b/doc/vorbisfile/ov_test.html @@ -0,0 +1,104 @@ + + + +Vorbisfile - function - ov_test + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_test

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    +This partially opens a vorbis file to test for Vorbis-ness. It loads +the headers for the first chain and tests for seekability (but does +not seek). Use ov_test_open() to +finish opening the file or ov_clear to +close/free it. Note that vorbisfile does not take ownership of +the file if the call fails; the calling applicaiton is responsible for +closing the file if this call returns an error. +

    + +

    WARNING for Windows developers: Do not use ov_test() +in Windows applications; Windows linking places restrictions on +passing FILE * handles successfully, and ov_test() runs afoul +of these restrictions [a] in exactly the same +way as ov_open(). See the ov_test_callbacks() page for +details on using ov_test_callbacks() instead. +

    + + + + + +
    +
    
+int ov_test(FILE *f,OggVorbis_File *vf,char *initial,long ibytes);
+
    +
    + +

    Parameters

    +
    +
    f
    +
    File pointer to an already opened file +or pipe (it need not be seekable--though this obviously restricts what +can be done with the bitstream).
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions. Once this has been called, the same OggVorbis_File +struct should be passed to all the libvorbisfile functions.
    +
    initial
    +
    Typically set to NULL. This parameter is useful if some data has already been +read from the file and the stream is not seekable. It is used in conjunction with ibytes. In this case, initial +should be a pointer to a buffer containing the data read.
    +
    ibytes
    +
    Typically set to 0. This parameter is useful if some data has already been +read from the file and the stream is not seekable. In this case, ibytes +should contain the length (in bytes) of the buffer. Used together with initial
    +
    + + +

    Return Values

    +
    +
  • 0 for success
    • + +
  • less than zero for failure:
    • +
      +
    • OV_EREAD - A read from media returned an error.
      • +
    • OV_ENOTVORBIS - Bitstream contains no Vorbis data.
      • +
    • OV_EVERSION - Vorbis version mismatch.
      • +
    • OV_EBADHEADER - Invalid Vorbis bitstream header.
      • +
    • OV_EFAULT - Internal logic fault; indicates a bug or heap/stack corruption.
      • +
    +
    +

    + +

    Notes

    + +All the notes from ov_open() apply to ov_test(). + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_test_callbacks.html b/doc/vorbisfile/ov_test_callbacks.html new file mode 100644 index 0000000..9abc84c --- /dev/null +++ b/doc/vorbisfile/ov_test_callbacks.html @@ -0,0 +1,111 @@ + + + +Vorbisfile - function - ov_test_callbacks + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_test_callbacks

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    This is an alternative function used to open and test an OggVorbis_File +structure when using a data source other than a file, +when its necessary to modify default file access behavior, or to +test for Vorbis content from a FILE * pointer under +Windows where ov_test() cannot be used. It +allows the application to specify custom file manipulation routines +and sets up all the related decoding structures. + +

    Once this has been called, the same OggVorbis_File +struct should be passed to all the libvorbisfile functions. +

    +

    + + + + +
    +
    
+int ov_test_callbacks(void *datasource, OggVorbis_File *vf, char *initial, long ibytes, ov_callbacks callbacks);
+
    +
    + +

    Parameters

    +
    +
    f
    +
    File pointer to an already opened file +or pipe (it need not be seekable--though this obviously restricts what +can be done with the bitstream).
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions. Once this has been called, the same OggVorbis_File +struct should be passed to all the libvorbisfile functions.
    +
    initial
    +
    Typically set to NULL. This parameter is useful if some data has already been +read from the file and the stream is not seekable. It is used in conjunction with ibytes. In this case, initial +should be a pointer to a buffer containing the data read.
    +
    ibytes
    +
    Typically set to 0. This parameter is useful if some data has already been +read from the file and the stream is not seekable. In this case, ibytes +should contain the length (in bytes) of the buffer. Used together with initial.
    +
    callbacks
    +
    A completed ov_callbacks struct which indicates desired custom file manipulation routines. vorbisfile.h defines several preprovided callback sets; see ov_callbacks for details.
    +
    + + +

    Return Values

    +
    +
  • 0 for success
    • +
  • less than zero for failure:
    • +
      +
    • OV_EREAD - A read from media returned an error.
      • +
    • OV_ENOTVORBIS - Bitstream contains no Vorbis data.
      • +
    • OV_EVERSION - Vorbis version mismatch.
      • +
    • OV_EBADHEADER - Invalid Vorbis bitstream header.
      • +
    • OV_EFAULT - Internal logic fault; indicates a bug or heap/stack corruption.
      • +
    +
    +

    + +

    Notes

    +
    + +
    [a] Windows and use as an ov_test() substitute

    Windows +applications should not use ov_test() due +to the likelihood of CRT linking +mismatches and runtime protection faults +[ov_open:a]. ov_test_callbacks() is a safe substitute; specifically: + +

    ov_test_callbacks(f, vf, initial, ibytes, OV_CALLBACKS_DEFAULT);
+
    + +... provides exactly the same functionality as ov_test() but will always work correctly under +Windows, regardless of linking setup details.

    + +

    + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_test_open.html b/doc/vorbisfile/ov_test_open.html new file mode 100644 index 0000000..6fb8ae9 --- /dev/null +++ b/doc/vorbisfile/ov_test_open.html @@ -0,0 +1,82 @@ + + + +Vorbisfile - function - ov_test_open + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_test_open

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    +Finish opening a file partially opened with ov_test() +or ov_test_callbacks(). +

    + + + + + +
    +
    
+int ov_test_open(OggVorbis_File *vf);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions. Once this has been called, the same OggVorbis_File +struct should be passed to all the libvorbisfile functions.
    +
    + + +

    Return Values

    +
    +
  • +0 for success
    • + +
  • less than zero for failure:
    • +
      +
    • OV_EREAD - A read from media returned an error.
      • +
    • OV_ENOTVORBIS - Bitstream is not Vorbis data.
      • +
    • OV_EVERSION - Vorbis version mismatch.
      • +
    • OV_EBADHEADER - Invalid Vorbis bitstream header.
      • +
    • OV_EFAULT - Internal logic fault; indicates a bug or heap/stack corruption.
      • +
    +
    +

    + + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + + + + + + + + diff --git a/doc/vorbisfile/ov_time_seek.html b/doc/vorbisfile/ov_time_seek.html new file mode 100644 index 0000000..ec19ce3 --- /dev/null +++ b/doc/vorbisfile/ov_time_seek.html @@ -0,0 +1,82 @@ + + + +Vorbisfile - function - ov_time_seek + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_time_seek

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    For seekable +streams, this seeks to the given time. For implementing seeking in a player, +this is the only function generally needed. This also updates everything needed within the +decoder, so you can immediately call ov_read() and get data from +the newly seeked to position. This function does not work for unseekable streams. + +

    + + + + +
    +
    
+int ov_time_seek(OggVorbis_File *vf, double s);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    Pointer to our already opened and initialized OggVorbis_File structure.
    +
    pos
    +
    Location to seek to within the file, specified in seconds.
    +
    + + +

    Return Values

    +
    +
      +
    • 0 for success
      • + +
    • +nonzero indicates failure, described by several error codes: +
        +
      • OV_ENOSEEK - Bitstream is not seekable. +
        • +
      • OV_EINVAL - Invalid argument value; possibly called with an OggVorbis_File structure that isn't open. +
        • +
      • OV_EREAD - A read from media returned an error. +
        • +
      • OV_EFAULT - Internal logic fault; indicates a bug or heap/stack + corruption. +
        • +
      • OV_EBADLINK - Invalid stream section supplied to libvorbisfile, or the requested link is corrupt. +
        • +
      • +
    + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_time_seek_lap.html b/doc/vorbisfile/ov_time_seek_lap.html new file mode 100644 index 0000000..f300f3b --- /dev/null +++ b/doc/vorbisfile/ov_time_seek_lap.html @@ -0,0 +1,105 @@ + + + +Vorbisfile - function - ov_time_seek_lap + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_time_seek_lap

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    For seekable +streams, ov_time_seek_lap seeks to the given time. This variant of ov_time_seek also automatically +crosslaps the transition from the previous playback position into the +new playback position in order to eliminate clicking and boundary +discontinuities. Otherwise, usage and behavior is identical to ov_time_seek. + +

    ov_time_seek_lap also updates everything needed within the decoder, +so you can immediately call ov_read() and +get data from the newly seeked to position. + +

    ov_time_seek_lap will lap between logical stream links of differing +numbers of channels. Any extra channels from the origin of the seek +are ignored; playback of these channels simply ends. Extra channels at +the destination are lapped from silence. ov_time_seek_lap will also +lap between logical stream links of differing sample rates. In this +case, the sample rates are ignored (no implicit resampling is done to +match playback). It is up to the application developer to decide if +this behavior makes any sense in a given context; in practical use, +these default behaviors perform sensibly. + +

    This function does not work for unseekable streams. + + +

    + + + + +
    +
    
+int ov_time_seek_lap(OggVorbis_File *vf, double s);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    Pointer to our already opened and initialized OggVorbis_File structure.
    +
    pos
    +
    Location to seek to within the file, specified in seconds.
    +
    + + +

    Return Values

    +
    +
      +
    • 0 for success
      • + +
    • +nonzero indicates failure, described by several error codes: +
        +
      • OV_ENOSEEK - Bitstream is not seekable. +
        • +
      • OV_EINVAL - Invalid argument value; possibly called with an OggVorbis_File structure that isn't open. +
        • +
      • OV_EREAD - A read from media returned an error. +
        • +
      • OV_EFAULT - Internal logic fault; indicates a bug or heap/stack + corruption. +
        • +
      • OV_EOF - Indicates stream is at end of file immediately after a seek + (making crosslap impossible as there's no preceeding decode state to crosslap). +
        • +
      • OV_EBADLINK - Invalid stream section supplied to libvorbisfile, or the requested link is corrupt. +
        • +
      • +
    + + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_time_seek_page.html b/doc/vorbisfile/ov_time_seek_page.html new file mode 100644 index 0000000..271d575 --- /dev/null +++ b/doc/vorbisfile/ov_time_seek_page.html @@ -0,0 +1,83 @@ + + + +Vorbisfile - function - ov_time_seek_page + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_time_seek_page

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    For seekable +streams, this seeks to closest full page preceding the given time. This function is faster than ov_time_seek because it doesn't seek through the last few samples to reach an exact time, but it is also less accurate. This should be used when speed is important. +

    This function also updates everything needed within the +decoder, so you can immediately call ov_read() and get data from +the newly seeked to position. +

    This function does not work for unseekable streams. + +

    + + + + +
    +
    
+int ov_time_seek_page(OggVorbis_File *vf, double s);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    Pointer to our already opened and initialized OggVorbis_File structure.
    +
    pos
    +
    Location to seek to within the file, specified in seconds.
    +
    + + +

    Return Values

    +
    +
      +
    • 0 for success
      • + +
    • +nonzero indicates failure, described by several error codes: +
        +
      • OV_ENOSEEK - Bitstream is not seekable. +
        • +
      • OV_EINVAL - Invalid argument value; possibly called with an OggVorbis_File structure that isn't open. +
        • +
      • OV_EREAD - A read from media returned an error. +
        • +
      • OV_EFAULT - Internal logic fault; indicates a bug or heap/stack + corruption. +
        • +
      • OV_EBADLINK - Invalid stream section supplied to libvorbisfile, or the requested link is corrupt. +
        • +
      • +
    + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_time_seek_page_lap.html b/doc/vorbisfile/ov_time_seek_page_lap.html new file mode 100644 index 0000000..3b1effa --- /dev/null +++ b/doc/vorbisfile/ov_time_seek_page_lap.html @@ -0,0 +1,112 @@ + + + +Vorbisfile - function - ov_time_seek_page_lap + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_time_seek_page_lap

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    For seekable streams, ov_time_seek_page_lap seeks to the closest +full page preceeding the given time. This variant of ov_time_seek_page also automatically +crosslaps the transition from the previous playback position into the +new playback position in order to eliminate clicking and boundary +discontinuities. Otherwise, usage and behavior is identical to ov_time_seek_page. + +

    ov_time_seek_page_lap is faster than ov_time_seek_lap because it doesn't +seek through the last few samples to reach an exact time, but it is +also less accurate. This should be used when speed is important, but +crosslapping is still desired. + +

    ov_time_seek_page_lap also updates everything needed within the +decoder, so you can immediately call ov_read() and get data from the newly seeked +to position. + +

    ov_time_seek_page_lap will lap between logical stream links of +differing numbers of channels. Any extra channels from the origin of +the seek are ignored; playback of these channels simply ends. Extra +channels at the destination are lapped from silence. +ov_time_seek_page_lap will also lap between logical stream links of +differing sample rates. In this case, the sample rates are ignored +(no implicit resampling is done to match playback). It is up to the +application developer to decide if this behavior makes any sense in a +given context; in practical use, these default behaviors perform +sensibly. + +

    This function does not work for unseekable streams. + +

    + + + + +
    +
    
+int ov_time_seek_page_lap(OggVorbis_File *vf, double s);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    Pointer to our already opened and initialized OggVorbis_File structure.
    +
    pos
    +
    Location to seek to within the file, specified in seconds.
    +
    + + +

    Return Values

    +
    +
      +
    • 0 for success
      • + +
    • +nonzero indicates failure, described by several error codes: +
        +
      • OV_ENOSEEK - Bitstream is not seekable. +
        • +
      • OV_EINVAL - Invalid argument value; possibly called with an OggVorbis_File structure that isn't open. +
        • +
      • OV_EREAD - A read from media returned an error. +
        • +
      • OV_EFAULT - Internal logic fault; indicates a bug or heap/stack + corruption. +
        • +
      • OV_EOF - Indicates stream is at end of file immediately after a seek + (making crosslap impossible as there's no preceeding decode state to crosslap). +
        • +
      • OV_EBADLINK - Invalid stream section supplied to libvorbisfile, or the requested link is corrupt. +
        • +
      • +
    + + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_time_tell.html b/doc/vorbisfile/ov_time_tell.html new file mode 100644 index 0000000..92d171c --- /dev/null +++ b/doc/vorbisfile/ov_time_tell.html @@ -0,0 +1,63 @@ + + + +Vorbisfile - function - ov_time_tell + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_time_tell

    + +

    declared in "vorbis/vorbisfile.h";

    + +

    Returns the current decoding offset in seconds. + +

    + + + + +
    +
    
+double ov_time_tell(OggVorbis_File *vf);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions.
    +
    + + +

    Return Values

    +
    +
  • n indicates the current decoding time offset in seconds.
    • +
  • OV_EINVAL means that the argument was invalid. In this case, the requested bitstream did not exist.
    • +
    +

    + + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/ov_time_total.html b/doc/vorbisfile/ov_time_total.html new file mode 100644 index 0000000..3b34f93 --- /dev/null +++ b/doc/vorbisfile/ov_time_total.html @@ -0,0 +1,67 @@ + + + +Vorbisfile - function - ov_time_total + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    ov_time_total

    + +

    declared in "vorbis/vorbisfile.h";

    + + +

    Returns the total time in seconds of the physical bitstream or a specified logical bitstream. + + +

    + + + + +
    +
    
+double ov_time_total(OggVorbis_File *vf,int i);
+
    +
    + +

    Parameters

    +
    +
    vf
    +
    A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile +functions.
    +
    i
    +
    Link to the desired logical bitstream. To retrieve the time total for the entire physical bitstream, this parameter should be set to -1.
    +
    + + +

    Return Values

    +
    +
  • OV_EINVAL means that the argument was invalid. In this case, the requested bitstream did not exist or the bitstream is nonseekable.
    • +
  • n total length in seconds of content if i=-1.
    • +
  • n length in seconds of logical bitstream if i=0 to n.
    • +
    +

    + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/overview.html b/doc/vorbisfile/overview.html new file mode 100644 index 0000000..1306495 --- /dev/null +++ b/doc/vorbisfile/overview.html @@ -0,0 +1,61 @@ + + + +Vorbisfile - API Overview + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    Vorbisfile API Overview

    + +

    The makeup of the Vorbisfile libvorbisfile library API is relatively +simple. It revolves around a single file resource. This file resource is +passed to libvorbisfile, where it is opened, manipulated, and closed, +in the form of an OggVorbis_File +struct. +

    +The Vorbisfile API consists of the following functional categories: +

    +

    +

    +In addition, the following subjects deserve attention additional to +the above general overview: +

    +

    +

    + + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + + diff --git a/doc/vorbisfile/reference.html b/doc/vorbisfile/reference.html new file mode 100644 index 0000000..7c3c789 --- /dev/null +++ b/doc/vorbisfile/reference.html @@ -0,0 +1,86 @@ + + + +Vorbisfile API Reference + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    Vorbisfile API Reference

    + +

    +Data Structures
    +OggVorbis_File
    +ov_callbacks
    +
    +Data Structures from libvorbis
    +vorbis_comment
    +vorbis_info
    +
    +Setup/Teardown
    +ov_fopen()
    +ov_open()
    +ov_open_callbacks()
    +ov_clear()
    +ov_test()
    +ov_test_callbacks()
    +ov_test_open()
    +
    +Decoding
    +ov_read()
    +ov_read_float()
    +ov_read_filter()
    +ov_crosslap()
    +
    +Seeking
    +ov_raw_seek()
    +ov_pcm_seek()
    +ov_time_seek()
    +ov_pcm_seek_page()
    +ov_time_seek_page()

    +ov_raw_seek_lap()
    +ov_pcm_seek_lap()
    +ov_time_seek_lap()
    +ov_pcm_seek_page_lap()
    +ov_time_seek_page_lap()
    +
    +File Information
    +ov_bitrate()
    +ov_bitrate_instant()
    +ov_streams()
    +ov_seekable()
    +ov_serialnumber()
    +ov_raw_total()
    +ov_pcm_total()
    +ov_time_total()
    +ov_raw_tell()
    +ov_pcm_tell()
    +ov_time_tell()
    +ov_info()
    +ov_comment()
    +
    +Return Codes (from libvorbis)
    + + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/seekexample.html b/doc/vorbisfile/seekexample.html new file mode 100644 index 0000000..897403d --- /dev/null +++ b/doc/vorbisfile/seekexample.html @@ -0,0 +1,152 @@ + + + +vorbisfile - Example Code + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    Example Code: seeking

    + +

    +The following is a run-through of the seeking example program supplied +with vorbisfile - seeking_test.c. +This program tests the vorbisfile ov_time_seek function by seeking to random points within the file. + +

    +First, relevant headers, including vorbis-specific "codec.h" and "vorbisfile.h" have to be included. + +

    + + + + +
    +
    
+#include <stdlib.h>
+#include <stdio.h>
+#include "vorbis/codec.h"
+#include "vorbis/vorbisfile.h"
+
    +
    + +

    Inside main(), we declare our primary OggVorbis_File structure. We also declare other helpful variables to track our progress within the file. +

    + + + + +
    +
    
+int main(){
+  OggVorbis_File ov;
+  int i;
+
    +
    + +

    This example takes its input on stdin which is in 'text' mode by default under Windows; this will corrupt the input data unless set to binary mode. This applies only to Windows. +

    + + + + +
    +
    
+#ifdef _WIN32 /* We need to set stdin to binary mode under Windows */
+  _setmode( _fileno( stdin ), _O_BINARY );
+#endif
+
    +
    + +

    ov_open() must be +called to initialize the OggVorbis_File structure with default values. +ov_open_callbacks() also checks to ensure that we're reading Vorbis format and not something else. + +

    + + + + +
    +
    
+  if(ov_open_callbacks(stdin,&ov,NULL,-1, OV_CALLBACKS_NOCLOSE)<0){
+    printf("Could not open input as an OggVorbis file.\n\n");
+    exit(1);
+  }
+
+
    +
    + +

    +First we check to make sure the stream is seekable using ov_seekable. + +

    Then we seek to 100 random spots in the bitstream using ov_time_seek with randomly generated values. + +

    + + + + +
    +
    
+  
+  /* print details about each logical bitstream in the input */
+  if(ov_seekable(&ov)){
+    double length=ov_time_total(&ov,-1);
+    printf("testing seeking to random places in %g seconds....\n",length);
+    for(i=0;i<100;i++){
+      double val=(double)rand()/RAND_MAX*length;
+      ov_time_seek(&ov,val);
+      printf("\r\t%d [%gs]...     ",i,val);
+      fflush(stdout);
+    }
+    
+    printf("\r                                   \nOK.\n\n");
+  }else{
+    printf("Standard input was not seekable.\n");
+  }
+  
+
    +
    +

    +When we're done seeking, we need to call ov_clear() to release the bitstream. + +

    + + + + +
    +
    
+  ov_clear(&ov);
+  return 0;
+}
+
    +
    + +

    +The full source for seeking_test.c can be found with the vorbis +distribution in seeking_test.c. + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/seeking.html b/doc/vorbisfile/seeking.html new file mode 100644 index 0000000..17e4e82 --- /dev/null +++ b/doc/vorbisfile/seeking.html @@ -0,0 +1,107 @@ + + + +Vorbisfile - Seeking + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    Seeking

    +

    Seeking functions allow you to specify a specific point in the stream to begin or continue decoding. +

    +All libvorbisfile seeking routines are declared in "vorbis/vorbisfile.h". + +

    Certain seeking functions are best suited to different situations. +When speed is important and exact positioning isn't required, +page-level seeking should be used. Note also that Vorbis files do not +necessarily start at a sample number or time offset of zero. Do not +be surprised if a file begins at a positive offset of several minutes +or hours, such as would happen if a large stream (such as a concert +recording) is chopped into multiple separate files. Requesting to +seek to a position before the beginning of such a file will seek to +the position where audio begins. + +

    As of vorbisfile version 1.68, seeking also optionally provides +automatic crosslapping to eliminate clicks and other discontinuity +artifacts at seeking boundaries. This fetaure is of particular +interest to player and game developers implementing dynamic music and +audio engines, or others looking for smooth transitions within a +single sample or across multiple samples.

    + +

    Naturally, seeking is available only within a seekable file or +stream. Seeking functions will return OV_ENOSEEK on +nonseekable files and streams. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    functionpurpose
    ov_raw_seekThis function seeks to a position specified in the compressed bitstream, specified in bytes.
    ov_pcm_seekThis function seeks to a specific audio sample number, specified in pcm samples.
    ov_pcm_seek_pageThis function seeks to the closest page preceding the specified audio sample number, specified in pcm samples.
    ov_time_seekThis function seeks to the specific time location in the bitstream, specified in seconds
    ov_time_seek_pageThis function seeks to the closest page preceding the specified time position in the bitstream
    ov_raw_seek_lapThis function seeks to a position specified in the compressed bitstream, specified in bytes. The boundary between the old and new playback positions is crosslapped to eliminate discontinuities.
    ov_pcm_seek_lapThis function seeks to a specific audio sample number, specified in pcm samples. The boundary between the old and new playback positions is crosslapped to eliminate discontinuities.
    ov_pcm_seek_page_lapThis function seeks to the closest page preceding the specified audio sample number, specified in pcm samples. The boundary between the old and new playback positions is crosslapped to eliminate discontinuities.
    ov_time_seek_lapThis function seeks to the specific time location in the bitstream, specified in seconds. The boundary between the old and new playback positions is crosslapped to eliminate discontinuities.
    ov_time_seek_page_lapThis function seeks to the closest page preceding the specified time position in the bitstream. The boundary between the old and new playback positions is crosslapped to eliminate discontinuities.
    + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/seeking_example_c.html b/doc/vorbisfile/seeking_example_c.html new file mode 100644 index 0000000..eb10a98 --- /dev/null +++ b/doc/vorbisfile/seeking_example_c.html @@ -0,0 +1,86 @@ + + + +vorbisfile - seeking_test.c + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    seeking_test.c

    + +

    +The example program source: + +

    + + + + +
    +
    
+
+#include <stdlib.h>
+#include <stdio.h>
+#include "vorbis/codec.h"
+#include "vorbis/vorbisfile.h"
+
+int main(){
+  OggVorbis_File ov;
+  int i;
+
+#ifdef _WIN32 /* We need to set stdin to binary mode under Windows */
+  _setmode( _fileno( stdin ), _O_BINARY );
+#endif
+
+  /* open the file/pipe on stdin */
+  if(ov_open_callbacks(stdin,&ov,NULL,-1,OV_CALLBACKS_NOCLOSE)==-1){
+    printf("Could not open input as an OggVorbis file.\n\n");
+    exit(1);
+  }
+  
+  /* print details about each logical bitstream in the input */
+  if(ov_seekable(&ov)){
+    double length=ov_time_total(&ov,-1);
+    printf("testing seeking to random places in %g seconds....\n",length);
+    for(i=0;i<100;i++){
+      double val=(double)rand()/RAND_MAX*length;
+      ov_time_seek(&ov,val);
+      printf("\r\t%d [%gs]...     ",i,val);
+      fflush(stdout);
+    }
+    
+    printf("\r                                   \nOK.\n\n");
+  }else{
+    printf("Standard input was not seekable.\n");
+  }
+
+  ov_clear(&ov);
+  return 0;
+}
+
+
    +
    + + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/seeking_test_c.html b/doc/vorbisfile/seeking_test_c.html new file mode 100644 index 0000000..eb10a98 --- /dev/null +++ b/doc/vorbisfile/seeking_test_c.html @@ -0,0 +1,86 @@ + + + +vorbisfile - seeking_test.c + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    seeking_test.c

    + +

    +The example program source: + +

    + + + + +
    +
    
+
+#include <stdlib.h>
+#include <stdio.h>
+#include "vorbis/codec.h"
+#include "vorbis/vorbisfile.h"
+
+int main(){
+  OggVorbis_File ov;
+  int i;
+
+#ifdef _WIN32 /* We need to set stdin to binary mode under Windows */
+  _setmode( _fileno( stdin ), _O_BINARY );
+#endif
+
+  /* open the file/pipe on stdin */
+  if(ov_open_callbacks(stdin,&ov,NULL,-1,OV_CALLBACKS_NOCLOSE)==-1){
+    printf("Could not open input as an OggVorbis file.\n\n");
+    exit(1);
+  }
+  
+  /* print details about each logical bitstream in the input */
+  if(ov_seekable(&ov)){
+    double length=ov_time_total(&ov,-1);
+    printf("testing seeking to random places in %g seconds....\n",length);
+    for(i=0;i<100;i++){
+      double val=(double)rand()/RAND_MAX*length;
+      ov_time_seek(&ov,val);
+      printf("\r\t%d [%gs]...     ",i,val);
+      fflush(stdout);
+    }
+    
+    printf("\r                                   \nOK.\n\n");
+  }else{
+    printf("Standard input was not seekable.\n");
+  }
+
+  ov_clear(&ov);
+  return 0;
+}
+
+
    +
    + + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/seekingexample.html b/doc/vorbisfile/seekingexample.html new file mode 100644 index 0000000..8263f02 --- /dev/null +++ b/doc/vorbisfile/seekingexample.html @@ -0,0 +1,203 @@ + + + +vorbisfile - Example Code + + + + + + + + + +

    vorbisfile documentation

    vorbisfile version 1.25 - 20000615

    + +

    Example Code

    + +

    +The following is a run-through of the decoding example program supplied +with vorbisfile - vorbisfile_example.c. +This program takes a vorbis bitstream from stdin and writes raw pcm to stdout. + +

    +First, relevant headers, including vorbis-specific "codec.h" and "vorbisfile.h" have to be included. + +

    + + + + +
    +
    
+#include <stdio.h>
+#include <stdlib.h>
+#include <math.h>
+#include "vorbis/codec.h"
+#include "vorbis/vorbisfile.h"
+
    +
    +

    +We also have to make a concession to Windows users here. If we are using windows for decoding, we must declare these libraries so that we can set stdin/stdout to binary. +

    + + + + +
    +
    
+#ifdef _WIN32
+#include <io.h>
+#include <fcntl.h>
+#endif
+
    +
    +

    +Next, a buffer for the pcm audio output is declared. + +

    + + + + +
    +
    
+char pcmout[4096];
+
    +
    + +

    Inside main(), we declare our primary OggVorbis_File structure. We also declare a few other helpful variables to track out progress within the file. +Also, we make our final concession to Windows users by setting the stdin and stdout to binary mode. +

    + + + + +
    +
    
+int main(int argc, char **argv){
+  OggVorbis_File vf;
+  int eof=0;
+  int current_section;
+
+#ifdef _WIN32
+  _setmode( _fileno( stdin ), _O_BINARY );
+#endif
+
    +
    + +

    ov_open_callbacks() must be +called to initialize the OggVorbis_File structure with default values. +ov_open_callbacks() also checks to ensure that we're reading Vorbis format and not something else. + +

    + + + + +
    +
    
+  if(ov_open_callbacks(stdin, &vf, NULL, 0, OV_CALLBACKS_NOCLOSE) < 0) {
+      fprintf(stderr,"Input does not appear to be an Ogg bitstream.\n");
+      exit(1);
+  }
+
+
    +
    + +

    +We're going to pull the channel and bitrate info from the file using ov_info() and show them to the user. +We also want to pull out and show the user a comment attached to the file using ov_comment(). + +

    + + + + +
    +
    
+  {
+    char **ptr=ov_comment(&vf,-1)->user_comments;
+    vorbis_info *vi=ov_info(&vf,-1);
+    while(*ptr){
+      fprintf(stderr,"%s\n",*ptr);
+      ++ptr;
+    }
+    fprintf(stderr,"\nBitstream is %d channel, %ldHz\n",vi->channels,vi->rate);
+    fprintf(stderr,"Encoded by: %s\n\n",ov_comment(&vf,-1)->vendor);
+  }
+  
+
    +
    + +

    +Here's the read loop: + +

    + + + + +
    +
    
+
+  while(!eof){
+    long ret=ov_read(&vf,pcmout,sizeof(pcmout),0,2,1,&current_section);
+    switch(ret){
+    case 0:
+      /* EOF */
+      eof=1;
+      break;
+    case -1:
+      break;
+    default:
+      fwrite(pcmout,1,ret,stdout);
+      break;
+    }
+  }
+  
+
    +
    + +

    +The code is reading blocks of data using ov_read(). +Based on the value returned, we know if we're at the end of the file or have invalid data. If we have valid data, we write it to the pcm output. + +

    +Now that we've finished playing, we can pack up and go home. It's important to call ov_clear() when we're finished. + +

    + + + + +
    +
    
+
+  ov_clear(&vf);
+    
+  fprintf(stderr,"Done.\n");
+  return(0);
+}
+
    +
    + +

    +The full source for vorbisfile_example.c can be found with the vorbis +distribution in vorbisfile_example.c. + +

    +

    + + + + + + + + +

    copyright © 2000 vorbis team

    Ogg Vorbis

    vorbisfile documentation

    vorbisfile version 1.25 - 20000615

    + + + + diff --git a/doc/vorbisfile/style.css b/doc/vorbisfile/style.css new file mode 100644 index 0000000..81cf417 --- /dev/null +++ b/doc/vorbisfile/style.css @@ -0,0 +1,7 @@ +BODY { font-family: Helvetica, sans-serif } +TD { font-family: Helvetica, sans-serif } +P { font-family: Helvetica, sans-serif } +H1 { font-family: Helvetica, sans-serif } +H2 { font-family: Helvetica, sans-serif } +H4 { font-family: Helvetica, sans-serif } +P.tiny { font-size: 8pt } diff --git a/doc/vorbisfile/threads.html b/doc/vorbisfile/threads.html new file mode 100644 index 0000000..274e115 --- /dev/null +++ b/doc/vorbisfile/threads.html @@ -0,0 +1,50 @@ + + + +Vorbisfile - Thread Safety + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    Thread Safety

    + +Vorbisfile's libvorbisfile may be used safely in a threading environment +so long as thread access to individual OggVorbis_File instances is serialized. +
      + +
    • Only one thread at a time may enter a function that takes a given OggVorbis_File instance, even if the +functions involved appear to be read-only.

      + +

    • Multiple threads may enter +libvorbisfile at a given time, so long as each thread's function calls +are using different OggVorbis_File +instances.

      + +

    • Any one OggVorbis_File instance may be used safely from multiple threads so long as only one thread at a time is making calls using that instance.

      +

    + +

    +
    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/vorbisfile/vorbisfile_example_c.html b/doc/vorbisfile/vorbisfile_example_c.html new file mode 100644 index 0000000..f3ba1d6 --- /dev/null +++ b/doc/vorbisfile/vorbisfile_example_c.html @@ -0,0 +1,106 @@ + + + +vorbisfile - vorbisfile_example.c + + + + + + + + + +

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + +

    vorbisfile_example.c

    + +

    +The example program source: + +

    + + + + +
    +
    
+#include <stdio.h>
+#include <stdlib.h>
+#include <math.h>
+#include "vorbis/codec.h"
+#include "vorbis/vorbisfile.h"
+
+#ifdef _WIN32
+#include <io.h>
+#include <fcntl.h>
+#endif
+
+char pcmout[4096];
+
+int main(int argc, char **argv){
+  OggVorbis_File vf;
+  int eof=0;
+  int current_section;
+
+#ifdef _WIN32
+  _setmode( _fileno( stdin ), _O_BINARY );
+  _setmode( _fileno( stdout ), _O_BINARY );
+#endif
+
+  if(ov_open_callbacks(stdin, &vf, NULL, 0, OV_CALLBACKS_NOCLOSE) < 0) {
+      fprintf(stderr,"Input does not appear to be an Ogg bitstream.\n");
+      exit(1);
+  }
+
+  {
+    char **ptr=ov_comment(&vf,-1)->user_comments;
+    vorbis_info *vi=ov_info(&vf,-1);
+    while(*ptr){
+      fprintf(stderr,"%s\n",*ptr);
+      ++ptr;
+    }
+    fprintf(stderr,"\nBitstream is %d channel, %ldHz\n",vi->channels,vi->rate);
+    fprintf(stderr,"Encoded by: %s\n\n",ov_comment(&vf,-1)->vendor);
+  }
+  
+  while(!eof){
+    long ret=ov_read(&vf,pcmout,sizeof(pcmout),0,2,1,&current_section);
+    if (ret == 0) {
+      /* EOF */
+      eof=1;
+    } else if (ret < 0) {
+      /* error in the stream.  Not a problem, just reporting it in
+	 case we (the app) cares.  In this case, we don't. */
+    } else {
+      /* we don't bother dealing with sample rate changes, etc, but
+	 you'll have to */
+      fwrite(pcmout,1,ret,stdout);
+    }
+  }
+
+  ov_clear(&vf);
+    
+  fprintf(stderr,"Done.\n");
+  return(0);
+}
+
+
    +
    + + +

    +

    + + + + + + + + +

    copyright © 2000-2010 Xiph.Org

    Ogg Vorbis

    Vorbisfile documentation

    vorbisfile version 1.3.2 - 20101101

    + + + + diff --git a/doc/window1.png b/doc/window1.png new file mode 100644 index 0000000..968bd3f Binary files /dev/null and b/doc/window1.png differ diff --git a/doc/window2.png b/doc/window2.png new file mode 100644 index 0000000..bd8e3bb Binary files /dev/null and b/doc/window2.png differ -- cgit v1.1