[vorbis] Re: proposal1

[David Mitchell]

In an effort to redeem my earlier flame, here is my attempt at rewording the
standard to correct the flaws I see in it. The latest draft as writting by 
Jonathan
is prefixed with >>. My comments have > before them. My rewritten version
includes no line prefix.

>>Jonathon Walther wrote:
>David Mitchell commented:
A Modest Proposal

>>Proposal for a Vorbis TAG Standard 
>>================================== 
>>

> I'm going to say right up front that I don't agree with dropping the Artist
> tag. I will admit that it is quite vague, to the point of being useless for
> some purposes. However, I feel it is still a well-defined field. It is 
simply
> the most important of the performer, soloist, composer, etc. data. In
> some cases it provides a consolidation of them. While in a perfect world
> we wouldn't have to deal with such vagaries, the reality is that people are
> going to tag Ogg files using the existing freedb and cddb databases. We
> should acknowledge this, standardize that practice, and provide the 
framework
> for more comprehensive tags. I think it is counter-productive to waste
> time trying to elimiate the artist tag when it's a certainty that most 
people
> will use it anyway. Having said that:

>>Goals for the proposed standard: 
>>

1) Provide tags so that a compliant player application can display
user readable identification information about the song or track. At a 
minimum
the track should include TITLE tags and one or more tags indicating the 
"artist" where
artist is the most relevant of ENSEMBLE, PERFORMER, LYRICIST, COMPOSER, etc. 
Preferably the track will include tags which provide more specific and 
detailed information
about the work rather than the generic ARTIST tag.

>>1) Identify a track so I can know exactly what I am listening to. 
>>   For a pop song, name of performer and title of song are often 
>>   enough.  For a piece of classical music, much more is typically 
>>   needed. 

2) Provide contact information so that the listener will have a place start 
trying
to obtain similar tracks, obtain original versions of the same track, or 
provide
support to the copyright holders. Such information should include enough
information to identify the original physical source medium when appropriate,
a URI to locate the artist or copyright holder on the Internet when 
appropriate, or both.

>>2) Identify a track so I can run out and buy the exact CD it is was 
>>   ripped from.  In many cases, even pop songs need as much information 
>>   for this purpose as a typical piece of classical music. 

> I don't think it's good to be overly CD-specific. For one, we shoud be 
planning
> for the future when physical media might be phased out. The standard
> should also not carry the tone of "so I was pirating music on Napster and
> found a CD I wanted to buy". 

3) The tags in the track should be self-contained, and not require access to
external information or databases to be useful.

>>3) Let goals 1 and 2 be fulfilled without access to external databases 
>>   or the Internet.  This helps for embedded use. 
>>4) Be usable and not painful for all genres of recording. 

> 4) is extranious. It just says "The standart shouldn't suck" which should 
be implied ;-)>

>>
>>NOT goals for the proposed standard are: 
>>
>>1) Stuff every available bit of information about a track and the CD it 
>>   is on into the TAGS section. (liner notes, lyrics, the bandleaders 
>>   dogs name...) 

1) Tags which are extranious to the specified goals should not be included. 
Specifically,
tags which might be overly large and/or do not provide identification 
information should not
be included. Ogg will provide other stream formats which are more appropriate 
to things
such as lyrics and album-cover scans. Those formats should be used when they 
become
available.

>>2) Backward compatibility with ID3 and MP3 tagging schemes, structures, 
>>   and infrastructures. 

>this phrase should be dropped. The existing CDDB-style databases do provide
> useful information. They should not be discarded simply because the
> Artist tag is imprecise. We should be polishing the wheel, not reinventing 
it.

>>
>>This document is written in the context of 
>>     http://www.xiph.org/ogg/vorbis/doc/v-comment.html 
>>which hasn't been updated since Feb 19, 2001. 
>>
A tagged track should provide at a minimum a "TITLE" tag and one or more
of the artist-specifying tags. It is preferred that a track include the more
specific artist tags such as COMPOSER and PERFORMER rather than the
generic ARTIST tag. The ARTIST tag is provided only for backwards 
compatability.

A compliant track will only use specified tags for their intended purpose. A 
track with
no tags at all is considered to be outside the scope of this standard.

>>All tags are OPTIONAL; you can have an ogg file with NO tags present and 
>>it will still be standard compliant. 
>>
>>Before we continue, here is a nifty bourne shell function you can stick 
>>in your ~/.bash_profile 

> I would put it in my .bashrc file so that I could use it in cron jobs, but 
that's just
> me :-)>

>>
>>ogg-grep () { 
>>        REGEX="$1"; 
>>        shift; 
>>        for i in "$@"; do 
>>                vorbiscomment -l "$i"|grep "$REGEX" >/dev/null && echo 
"$i"; 
>>        done; 
>>} 
>>
>>You could use it like this: 
>>
>>ogg-grep "CONDUCTOR=.*Karajan" ~/music/oggfiles/*.ogg 
>>
>>It would display, one per line, all the ogg files where Karajan 
>>was the conductor of the piece.  This should answer the people 
>>screaming that all the extra tags require external databases. 
>>
>>
>>Who Will Use This?  Who Will Be Affected By The Standard? 
>>========================================================= 
>>
>>Who is this standard for?  Let's examine the various players in this 
>>drama. 

> This discussion doesn't really belong in the final standard, but it does
> bring up some points I want to address so I'm including it here.

>>
>>USERS: Users will be playing their oggs; their player software is expected 
>>       to display the tags that exist in an oggfile, intelligently. 
>>       
>>       Therefore the users are not affected by this standard and need know 
nothing
>>       about it.  Player programs ARE affected, and their job should be 
made as
>>       easy as possible. 

>Users are somewhat affected, if nothing else to the degree that this 
standard
>helps provide them with useful information about the music they are 
enjoying.

>>
>>ENCODERS: There will be a subset of users who use ripping tools to create 
ogg
>>       tracks off their legally bought CD's.  Inasmuch as it is their 
>>       responsibility to tag their files correctly, it would be nice if 
they
>>       knew about the standard.  However, their ripping software should 
make
>>        it trivial for them to fill in the correct tags in the common 
cases,

> I feel compelled to note that this goal is only acheived by allowing use of
> the existing Artist information in various databases, at least for the time
> being.

>>        and let them access the full tagset if they feel they need it. 
>>       Therefore, encoders will almost not notice the adoption of this 
standard, 

> Well, encoders are only going to not notice if they can make use of
> existing Artist information. If the standard requires encoders to not
> use existing databases and hand-enter tags, I guarantee that they
> will take quite a notice.

>>        unless they wanted to benefit from its increased flexibility, in 
which 
>>        case they will rejoice.  Ripper and tagging SOFTWARE on the other 
hand
>>        will need to support the standard, and again, its job should be 
made as
>>        easy as possible. 
>>
>>CODERS: Coders are those who write the software used by users and rippers.  
>>They are the ones who will need to make their software standard compliant, 
>> and the ones who need to make sure their software is easy for people to 
use. 

>Once again, coders include database lookups so that their software is easy 
to use.
>Forbiding the use of existing Artist information does not help them acheive 
this goal.

>>
>>Therefore, it is the coders who will be affected most by the standard.  
Their 
>>  job should be made as easy as possible so they can support it trivially 
and 
>> well. 
>>
>>Standard Compliance: 
>>==================== 
>>
>>A compliant Ogg player program will intelligently display, or let the user 
>>specify how to display, all the ALLOWED tags in this document. 

> Many people, including Jonathon, have stated their desire for tags
> to be optional and also stated that non-defined tags should not
> be disallowed. Hence, the use of the word "ALLOWED" is not really
> appropriate. The above section would thus read better as:

A compliant Ogg player program will be capable of intelligently displaying
all tags which are defined in this standard.

>>
>>
>>A compliant Ogg file may contain tags not in the standard. 

>The above should be cut, because it's really only needed to try
>and balance the use of the overly-strict "ALLOWED" above.

>>
>>Compliant tag editors and rippers may support tags not in the 
>>standard, as long as they encourage use of standard tags over 
>>any non-standard tags. 

> I think we should require "compliant" programs to use the defined
> tags when appropriate. If a program wants to include additional
> information in some other tag, that should be fine. However, if
> a tag is defined to hold some specific fact, that tag should be used.
> For example, if we define a "LENGTH" tag to hold the length of the
> track, it should not be "compliant" behavior to place that information
> in a "DURATION" tag instead of the "LENGTH" tag. Including both
> should be allowed, I think. But discarding a standard tag in lieu of
> a non-standard one should disqualify a program from being complient.
> But I'm not sure how to word this so it sounds nice and "standard-like."

>>
>>-------------------------------------------------------- 
>>
>>If a tag can denote more than one item, repeat the tag for each 
>>item, one item for each usage of the tag. 
>>
>>Following the list of standard tags below will be some examples 
>>of ogg123 output for the corresponding tags. 
>>
>>-------------------------------------------------------- 
>>First, a few tags are now DEPRECATED: 
>>
>>ARTIST 
>>        role fulfilled by COMPOSER, LYRICIST, PERFORMER, ENSEMBLE, 
>>        CONDUCTOR, AUTHOR, PRODUCER, and ARRANGER tags. 
>>

<SNIP> I don't consider ARTIST to be deprecated.

>>ORGANIZATION 
>>        role fulfilled by PRODUCER, LABEL, 
>>        and COPYRIGHT tags. 

>Agreed. ORGANIZATION is overly-vague like ARTIST, but does
>not have the plus-side of wide spread use to encourage it's
>use.

>>
>>PUBLISHER 
>>        noone ever explained what this tag would be used for 

> I think this might be useful someday. I've included it below.

>>
>>-------------------------------------------------------- 
>>We are then left with the following ALLOWED tags: 

> Once again, bad wording. ALLOWED clearly and unambiguously
> implies that all other tags are DISALLOWED. No one has yet
> stood up for the practice of banning tags, hence this
> strong language is inappropriate.

> Rather than break tags down by singleton and multiple tags, I'm going so
> sort them by tags which are aimed towards satisfying goal #1 and goal #2.

Goal #1 Tags. The purpose of these tags is to provide the user with
human readable information about the track.

TITLE: The name of the work contained in the track. While it should describe 
the
work, it should not duplicate information which would be more appropriate in
another tag (such as LOCATION, OPUS, etc.)

ARTIST: Provide a simple description of the artist who is primarily 
responsible
for the work. In other words: it's common usage. This tag should be replaced 
with
the more specific artist tags below when the information is available. It 
should be
considered the least common denominator which should be used only when artist
information is available, but more specific information is not available.

>>COMPOSER 
>>        composer of the work. eg, Gustav Mahler 
>>
>>ARRANGER 
>>        the person who arranged the piece, eg, Ravel 
>>
>>PRODUCER 
>>        the person who produced the recording, eg Brian Eno 
>>
>>LYRICIST 
>>        the person who wrote the lyrics, eg Donizetti 
>>        
>>AUTHOR 
>>        for text that is spoken, or was originally meant to 
>>        be spoken, the author, eg JRR Tolkien 
>>
>>CONDUCTOR 
>>        conductor of the work; eg Herbert von Karajan 
>>
>>PERFORMER 
>>        the artists responsible for performing the work, also
>>         individual performers singled out for mention; 
>>        eg, Yoyo Ma (violinist) 
>>

> I've snipped ENSEMBLE to reflect the feelings on the list
> that it was often an arbitrary distinction compared to PERFORMER.

>>OPUS 
>>        the number of the work; eg, Opus 10, BVW 81, K6 
>>
>>PART 
>>        a division within a work; movement of a symphony, eg 

>>ALBUM 
>>        if appropriate, an album name 

> The ALBUM tag also helps satisfy Goal #2, but I know I like to see it
> when I'm listening to a song, so I've included it under #1.

>>TYPE 
>>        type of work, eg, symphony, concerto, song, speech, ballet 
>>
>>GENRE 
>>        id3 type classification (classical, pop, jazz, blues, etc) 
>>
>>DATE 
>>        date of recording, or other date of interest 
>>
>>LOCATION 
>>        location of recording, if known 
>>
>>COMMENT 
>>        additional comments pertaining to the piece. 

Goal #2 tags. These tags help the user in specifying the exact
source medium which the track came from when appropriate,
or in locating a web site or similar for the copyright holder/artist/etc.

>>COPYRIGHT 
>>        who holds copyright to the track 
>>
>>DISCNUMBER 
>>        if part of a multi-disc album, put the disc number here 
>>
>>ISRC 
>>        this number lets you order a CD over the phone from 
>>        a record shop.  it may require special tools to extract 
>>        this number from the CD. 

>I think ISRC should be dropped in lieu of a generic ID tag which includes
>the type of ID. Ala:

SOURCEID: An ID which can be used to identify the source medium or to
identify the original network source of the track. Since the SOURCEID tag
is meant to provide exact machine-understandable information, it's format
should comply with specified formats. Here are samples:
SOURCEID=CDDB:0x1234aab
SOURCEID=ISRC:7464-37689-2

>>
>>LABEL 
>>        the record label or imprint on the disc 
>>

> I think the old PUBLISHER tag might be more appropriate. After all, a 
record label
> is really just a publisher. They can be included under publisher while 
allowing for
> future types of publishers in the future.

PUBLISHER: The company or individual responsible for the distribution of the 
work.
When possible the tag should include a URI for the publisher. Alternatively, 
it can include
a postal address for the publisher. At a minimum it should include the name 
of the
organization.

>>
>>SOURCEMEDIA 
>>        the recording media the track came from.  eg, CD, Cassette, 
>>        Radio Broadcast, LP, CD Single 
>>
>>
>>TRACKNUMBER 
>>        the track number on the CD 
>>
>>VERSION 
>>        Make sure you don't put DATE or LOCATION information in this tag 
>>        "live", "acoustic", "Radio Edit" "12 inch remix" might be typical 
>>        values of this tag 
>>
>>
>>
>>

>>

I've snipped the examples.

Overall, I think I'm just making pretty minor tweaks. My only real beef with 
the proposal
as put forward by Jonathon is the insistance on dropping the ARTIST tag 
despite the
obvious advantages to keeping it. Anyway, that's been by $0.02. Hopefully it 
will provide
fuel to the fire which has been quiet all week long.

-David Mitchell

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.