Movatterモバイル変換

Ogg Vorbis I format specification: comment field and header specification

Overview

The Vorbis text comment header is the second (of three) headerpackets that begin a Vorbis bitstream. It is meant for short, textcomments, not arbitrary metadata; arbitrary metadata belongs in aseparate logical bitstream (usually an XML stream type) that providesgreater structure and machine parseability.

The comment field is meant to be used much like someone jotting aquick note on the bottom of a CDR. It should be a little information toremember the disc by and explain it to others; a short, to-the-pointtext note that need not only be a couple words, but isn't going to bemore than a short paragraph. The essentials, in other words, whateverthey 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; thenumber of vectors is bounded to 2^32-1 and the length of each vectoris limited to 2^32-1 bytes. The vector length is encoded; the vectorcontents themselves are not null terminated. In addition to the vectorlist, 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 andlook like:

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

A case-insensitive field name that may consist of ASCII 0x20 through0x7D, 0x3D ('=') excluded. ASCII 0x41 through 0x5A inclusive (A-Z) isto 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 adescription of intended use. No single or group of field names ismandatory; a comment header may contain one, all or none of the namesin this list.

TITLE: Track/Work name
VERSION: The version field may be used to differentiate multipleversions 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 musicthis is usually the performing band or singer. For classical music it would bethe 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 theconductor, orchestra, soloists. In an audio book it would be the actor who didthe reading. In popular music this is typically the same as the ARTIST andis omitted.
COPYRIGHT: Copyright attribution, e.g., '2001 Nobody's Band' or '1999 Jack Moffitt'
LICENSE: License information, for example, 'All Rights Reserved', 'AnyUse Permitted', a URL to a license such as a Creative Commons license(e.g. "creativecommons.org/licenses/by/4.0/"), or similar.
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 ofthe producing label.
ISRC: ISRC number for the track; seetheISRC intro page for more information on ISRC numbers.

Implications

Field names should not be 'internationalized'; this is aconcession to simplicity not an attempt to exclude the majority ofthe world that doesn't speak English. Fieldcontents, 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 onthe field name so that the field name is bounded in a known way. Thuswe also have the length of the field contents.
Individual 'vendors' may use non-standard field names withinreason. The proper use of comment fields should be clear throughcontext 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 thecommon namespace. We will generally collect the more useful tagshere to help with standardization.
Field names are not required to be unique (occur once) within acomment header. As an example, assume a track was recorded by threewell 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 bitstreamheader packet. Unlike the first bitstream header packet, it is notgenerally the only packet on the second page and may not be restrictedto within the second bitstream page. The length of the comment headerpacket is (practically) unbounded. The comment header packet is notoptional; it must be present in the bitstream even if it iseffectively empty.

The comment header is encoded as follows (as per Ogg's standardbitstream mapping which renders least-significant-bit of the word to becoded into the least significant available bit of the currentbitstream octet first):

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

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

[8]ページ先頭