annotate src/libvorbis-1.3.3/doc/05-comment.tex @ 168:ceec0dd9ec9c

Replace these with versions built using an older toolset (so as to avoid ABI compatibilities when linking on Ubuntu 14.04 for packaging purposes)
author Chris Cannam <cannam@all-day-breakfast.com>
date Fri, 07 Feb 2020 11:51:13 +0000
parents 98c1576536ae
children
rev   line source
cannam@86 1 % -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*-
cannam@86 2 %!TEX root = Vorbis_I_spec.tex
cannam@86 3 % $Id$
cannam@86 4 \section{comment field and header specification} \label{vorbis:spec:comment}
cannam@86 5
cannam@86 6 \subsection{Overview}
cannam@86 7
cannam@86 8 The Vorbis text comment header is the second (of three) header
cannam@86 9 packets that begin a Vorbis bitstream. It is meant for short text
cannam@86 10 comments, not arbitrary metadata; arbitrary metadata belongs in a
cannam@86 11 separate logical bitstream (usually an XML stream type) that provides
cannam@86 12 greater structure and machine parseability.
cannam@86 13
cannam@86 14 The comment field is meant to be used much like someone jotting a
cannam@86 15 quick note on the bottom of a CDR. It should be a little information to
cannam@86 16 remember the disc by and explain it to others; a short, to-the-point
cannam@86 17 text note that need not only be a couple words, but isn't going to be
cannam@86 18 more than a short paragraph. The essentials, in other words, whatever
cannam@86 19 they turn out to be, eg:
cannam@86 20
cannam@86 21 \begin{quote}
cannam@86 22 Honest Bob and the Factory-to-Dealer-Incentives, \textit{``I'm Still
cannam@86 23 Around''}, opening for Moxy Fr\"{u}vous, 1997.
cannam@86 24 \end{quote}
cannam@86 25
cannam@86 26
cannam@86 27
cannam@86 28
cannam@86 29 \subsection{Comment encoding}
cannam@86 30
cannam@86 31 \subsubsection{Structure}
cannam@86 32
cannam@86 33 The comment header is logically a list of eight-bit-clean vectors; the
cannam@86 34 number of vectors is bounded to $2^{32}-1$ and the length of each vector
cannam@86 35 is limited to $2^{32}-1$ bytes. The vector length is encoded; the vector
cannam@86 36 contents themselves are not null terminated. In addition to the vector
cannam@86 37 list, there is a single vector for vendor name (also 8 bit clean,
cannam@86 38 length encoded in 32 bits). For example, the 1.0 release of libvorbis
cannam@86 39 set the vendor string to ``Xiph.Org libVorbis I 20020717''.
cannam@86 40
cannam@86 41 The vector lengths and number of vectors are stored lsb first, according
cannam@86 42 to the bit packing conventions of the vorbis codec. However, since data
cannam@86 43 in the comment header is octet-aligned, they can simply be read as
cannam@86 44 unaligned 32 bit little endian unsigned integers.
cannam@86 45
cannam@86 46 The comment header is decoded as follows:
cannam@86 47
cannam@86 48 \begin{programlisting}
cannam@86 49 1) [vendor\_length] = read an unsigned integer of 32 bits
cannam@86 50 2) [vendor\_string] = read a UTF-8 vector as [vendor\_length] octets
cannam@86 51 3) [user\_comment\_list\_length] = read an unsigned integer of 32 bits
cannam@86 52 4) iterate [user\_comment\_list\_length] times {
cannam@86 53 5) [length] = read an unsigned integer of 32 bits
cannam@86 54 6) this iteration's user comment = read a UTF-8 vector as [length] octets
cannam@86 55 }
cannam@86 56 7) [framing\_bit] = read a single bit as boolean
cannam@86 57 8) if ( [framing\_bit] unset or end-of-packet ) then ERROR
cannam@86 58 9) done.
cannam@86 59 \end{programlisting}
cannam@86 60
cannam@86 61
cannam@86 62
cannam@86 63
cannam@86 64 \subsubsection{Content vector format}
cannam@86 65
cannam@86 66 The comment vectors are structured similarly to a UNIX environment variable.
cannam@86 67 That is, comment fields consist of a field name and a corresponding value and
cannam@86 68 look like:
cannam@86 69
cannam@86 70 \begin{quote}
cannam@86 71 \begin{programlisting}
cannam@86 72 comment[0]="ARTIST=me";
cannam@86 73 comment[1]="TITLE=the sound of Vorbis";
cannam@86 74 \end{programlisting}
cannam@86 75 \end{quote}
cannam@86 76
cannam@86 77 The field name is case-insensitive and may consist of ASCII 0x20
cannam@86 78 through 0x7D, 0x3D ('=') excluded. ASCII 0x41 through 0x5A inclusive
cannam@86 79 (characters A-Z) is to be considered equivalent to ASCII 0x61 through
cannam@86 80 0x7A inclusive (characters a-z).
cannam@86 81
cannam@86 82
cannam@86 83 The field name is immediately followed by ASCII 0x3D ('=');
cannam@86 84 this equals sign is used to terminate the field name.
cannam@86 85
cannam@86 86
cannam@86 87 0x3D is followed by 8 bit clean UTF-8 encoded value of the
cannam@86 88 field contents to the end of the field.
cannam@86 89
cannam@86 90
cannam@86 91 \paragraph{Field names}
cannam@86 92
cannam@86 93 Below is a proposed, minimal list of standard field names with a
cannam@86 94 description of intended use. No single or group of field names is
cannam@86 95 mandatory; a comment header may contain one, all or none of the names
cannam@86 96 in this list.
cannam@86 97
cannam@86 98 \begin{description} %[style=nextline]
cannam@86 99 \item[TITLE]
cannam@86 100 Track/Work name
cannam@86 101
cannam@86 102 \item[VERSION]
cannam@86 103 The version field may be used to differentiate multiple
cannam@86 104 versions of the same track title in a single collection. (e.g. remix
cannam@86 105 info)
cannam@86 106
cannam@86 107 \item[ALBUM]
cannam@86 108 The collection name to which this track belongs
cannam@86 109
cannam@86 110 \item[TRACKNUMBER]
cannam@86 111 The track number of this piece if part of a specific larger collection or album
cannam@86 112
cannam@86 113 \item[ARTIST]
cannam@86 114 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.
cannam@86 115
cannam@86 116 \item[PERFORMER]
cannam@86 117 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.
cannam@86 118
cannam@86 119 \item[COPYRIGHT]
cannam@86 120 Copyright attribution, e.g., '2001 Nobody's Band' or '1999 Jack Moffitt'
cannam@86 121
cannam@86 122 \item[LICENSE]
cannam@86 123 License information, eg, 'All Rights Reserved', 'Any
cannam@86 124 Use Permitted', a URL to a license such as a Creative Commons license
cannam@86 125 ("www.creativecommons.org/blahblah/license.html") or the EFF Open
cannam@86 126 Audio License ('distributed under the terms of the Open Audio
cannam@86 127 License. see http://www.eff.org/IP/Open\_licenses/eff\_oal.html for
cannam@86 128 details'), etc.
cannam@86 129
cannam@86 130 \item[ORGANIZATION]
cannam@86 131 Name of the organization producing the track (i.e.
cannam@86 132 the 'record label')
cannam@86 133
cannam@86 134 \item[DESCRIPTION]
cannam@86 135 A short text description of the contents
cannam@86 136
cannam@86 137 \item[GENRE]
cannam@86 138 A short text indication of music genre
cannam@86 139
cannam@86 140 \item[DATE]
cannam@86 141 Date the track was recorded
cannam@86 142
cannam@86 143 \item[LOCATION]
cannam@86 144 Location where track was recorded
cannam@86 145
cannam@86 146 \item[CONTACT]
cannam@86 147 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.
cannam@86 148
cannam@86 149 \item[ISRC]
cannam@86 150 International Standard Recording Code for the
cannam@86 151 track; see \href{http://www.ifpi.org/isrc/}{the ISRC
cannam@86 152 intro page} for more information on ISRC numbers.
cannam@86 153
cannam@86 154 \end{description}
cannam@86 155
cannam@86 156
cannam@86 157
cannam@86 158 \paragraph{Implications}
cannam@86 159
cannam@86 160 Field names should not be 'internationalized'; this is a
cannam@86 161 concession to simplicity not an attempt to exclude the majority of
cannam@86 162 the world that doesn't speak English. Field \emph{contents},
cannam@86 163 however, use the UTF-8 character encoding to allow easy representation
cannam@86 164 of any language.
cannam@86 165
cannam@86 166 We have the length of the entirety of the field and restrictions on
cannam@86 167 the field name so that the field name is bounded in a known way. Thus
cannam@86 168 we also have the length of the field contents.
cannam@86 169
cannam@86 170 Individual 'vendors' may use non-standard field names within
cannam@86 171 reason. The proper use of comment fields should be clear through
cannam@86 172 context at this point. Abuse will be discouraged.
cannam@86 173
cannam@86 174 There is no vendor-specific prefix to 'nonstandard' field names.
cannam@86 175 Vendors should make some effort to avoid arbitrarily polluting the
cannam@86 176 common namespace. We will generally collect the more useful tags
cannam@86 177 here to help with standardization.
cannam@86 178
cannam@86 179 Field names are not required to be unique (occur once) within a
cannam@86 180 comment header. As an example, assume a track was recorded by three
cannam@86 181 well know artists; the following is permissible, and encouraged:
cannam@86 182
cannam@86 183 \begin{quote}
cannam@86 184 \begin{programlisting}
cannam@86 185 ARTIST=Dizzy Gillespie
cannam@86 186 ARTIST=Sonny Rollins
cannam@86 187 ARTIST=Sonny Stitt
cannam@86 188 \end{programlisting}
cannam@86 189 \end{quote}
cannam@86 190
cannam@86 191
cannam@86 192
cannam@86 193
cannam@86 194
cannam@86 195
cannam@86 196
cannam@86 197 \subsubsection{Encoding}
cannam@86 198
cannam@86 199 The comment header comprises the entirety of the second bitstream
cannam@86 200 header packet. Unlike the first bitstream header packet, it is not
cannam@86 201 generally the only packet on the second page and may not be restricted
cannam@86 202 to within the second bitstream page. The length of the comment header
cannam@86 203 packet is (practically) unbounded. The comment header packet is not
cannam@86 204 optional; it must be present in the bitstream even if it is
cannam@86 205 effectively empty.
cannam@86 206
cannam@86 207 The comment header is encoded as follows (as per Ogg's standard
cannam@86 208 bitstream mapping which renders least-significant-bit of the word to be
cannam@86 209 coded into the least significant available bit of the current
cannam@86 210 bitstream octet first):
cannam@86 211
cannam@86 212 \begin{enumerate}
cannam@86 213 \item
cannam@86 214 Vendor string length (32 bit unsigned quantity specifying number of octets)
cannam@86 215
cannam@86 216 \item
cannam@86 217 Vendor string ([vendor string length] octets coded from beginning of string to end of string, not null terminated)
cannam@86 218
cannam@86 219 \item
cannam@86 220 Number of comment fields (32 bit unsigned quantity specifying number of fields)
cannam@86 221
cannam@86 222 \item
cannam@86 223 Comment field 0 length (if [Number of comment fields] $>0$; 32 bit unsigned quantity specifying number of octets)
cannam@86 224
cannam@86 225 \item
cannam@86 226 Comment field 0 ([Comment field 0 length] octets coded from beginning of string to end of string, not null terminated)
cannam@86 227
cannam@86 228 \item
cannam@86 229 Comment field 1 length (if [Number of comment fields] $>1$...)...
cannam@86 230
cannam@86 231 \end{enumerate}
cannam@86 232
cannam@86 233
cannam@86 234 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()}.
cannam@86 235
cannam@86 236
cannam@86 237
cannam@86 238
cannam@86 239
cannam@86 240