From 41eb9f147ca68e1000399b9afc8540dd6a7b8dda Mon Sep 17 00:00:00 2001 From: Ralph Giles Date: Wed, 3 Oct 2001 04:34:34 +0000 Subject: [PATCH] add PERFORMER, DISCID and CONTACT field names. clarify the (overloaded) role of ARTIST. clarify that COPYRIGHT included license info. in response to the recent thread by Jonathan Walther. svn path=/trunk/vorbis/; revision=2111 --- doc/v-comment.html | 32 ++++++++++++++++++++------------ 1 file changed, 20 insertions(+), 12 deletions(-) diff --git a/doc/v-comment.html b/doc/v-comment.html index 99876df..2f57e18 100644 --- a/doc/v-comment.html +++ b/doc/v-comment.html @@ -7,12 +7,13 @@ Ogg Vorbis comment field specification -Last update to this document: February 9, 2001

+Last update to this document: October 2, 2001

-The text comment header is the second (of three) header packets that +

The 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 -metadata stream (usually an XML stream type).

+not arbitrary metadata; arbitrary metadata belongs in a separate +logical bitream (usually an XML stream type) that provides greater +structure and machine parseability.

Comment use rationale

@@ -36,9 +37,9 @@ is limited to 2^32-1 bytes. The vector length is encoded; the vector is 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). Libvorbis currently sets the vendor string to "Xiphophorus -libVorbis I 20010119".

+libVorbis I 20010910".

-The comment vectors are structured similarly to a UNIX environment. +The comment vectors are structured similarly to a UNIX environment variable. That is, comment fields consist of a field name and a field value and look like: @@ -58,8 +59,8 @@ to be considered equivalent to ASCII 0x61 through 0x7A inclusive

  • 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 field contents to the end of -the field. +
  • 0x3D is followed by 8 bit clean UTF-8 encoded field contents +to the end of the field.

    Field names

    @@ -72,13 +73,15 @@ in this list.
    TITLE
    Track name
    VERSION
    The version field may be used to differentiate multiple -version of the same track title in a single collection. (e.g. remix info) +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
    Track performer +
    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 ommitted.
    ORGANIZATION
    Name of the organization producing the track (i.e. the 'record label') @@ -91,10 +94,14 @@ the 'record label')
    LOCATION
    Location where track was recorded -
    COPYRIGHT
    Copyright information +
    COPYRIGHT
    Copyright and license information (e.g. '(c) 2001 Nobody's Band. All rights reserved' or '(c) 1999 Jack Moffit, distributed under the terms of the Open Audio License. see http://www.eff.org/IP/Open_licenses/eff_oal.html for details') + +
    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. +
    DISCID
    Table of contents hash from an associated disc, generally used to index the track in published music databases. See http://freedb.org/ for and example of such a hash. +

    Implications

    @@ -115,7 +122,8 @@ 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. +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 -- 2.7.4