[vorbis] Comment field spec needs to be expanded and tightened

[Moritz Grimm]

David Wheeler wrote:
> First, the misleading names.
> Change "ORGANIZATION" to "PUBLISHER"; many other organizations
> may be involved, and not all publishers are organizations.

IMO, "ORGANIZATION" is a good tag. First, there's usually exactly ONE
organization in charge of the coordination of a production or the
coordination between multiple organisations (= companies/unions).
(Coproductions can also use the tag: ORGANIZATION=Label1/Label2 ; the
word "publisher" behaves the same way as "organization" when it comes to
plural and singular.) Second, every group of e.g. musicians can be
called an "organization" (releases by the authors themselves won't use
that tag anyways). That's why I don't see the point in changing the tag
and producing that much hassle ...

> Note that MP3's related spec already calls this value "publisher".  I suggest

Mh, that's a point. But this doesn't make "publisher" better than
"organization". Its also a matter of taste, and most OGG users might
have gotten used to "organization" by now.

> changing "DATE" to "RECORDING_DATE" and "LOCATION" to "RECORDING_LOCATION";
> there are many other potential dates and locations someone might store.

Without thinking about it, yes ... but after the few thoughts i had
about it now i can't make up any other dates and locations...?

Anyways, (i wish that) the goal is to get to a point where users are not
confronted with these tags any more. I imagine some comfortable comment
editors that offer a user interface in natural language with
hints-on-demand and all that
keeping-dumb-users-from-asking-stupid-questions stuff. Most important is
an exact definition in v-comment.html to help the utility coders to do
it right.

> COMPOSER
>  Track composer of the music.
> 
> AUTHOR
>  Track author of the words/text (the lyricist, if this is music).
> 
> ARRANGER
>  Arranger of the music (if different than composer).

Legally, composer and author are the same, and if an arranger creates
something new with the given material, he also is an adequate author
(although he might have to pay licensing fees for the material he used).
My suggestion would be to keep that one AUTHOR tag and maybe introduce a
CREDITS tag for the remaining contributors in the creation process of a
track. This could also include the conductor. Introducing a tag that
makes only sense in the classical and bigband genre would be overkill.
IMO.

> PRODUCER
>  Track producer; this is often different from the PUBLISHER.

Hm, is this interesting? I mean, who really wants to know that some
strange guy named William Orbit produced the Ray Of Light by Madonna?
This is insider knowledge and not of interest for the common user, and
since everyone can define his own tags if necessary, why not this one,
too.

> ACCOMPANIMENT
>  The band, orchestra, or other accompaniment (may be a group), e.g.,
>  "E Street Band".
> ACCOMPANIMENT_ARTIST
>  The name of an accompanist, may include parenthetically the
>  instruments/vocal roles played.
>  E.G., "Iman Example (Bass Guitar, Fiddle, Alto)".

Hmmm, this is too much tags for relatively uninteresting information.
This can either be put into CREDITS or into a tag INTERPRETER that
describes the artist that were involved in playing a track that was not
composed by themselves.

Under accompaniment I understand those fake keyboarders that shake their
boobs in the background of a one-man-band's live act. Well, I don't need
a tag for that. ;)

> STATION
>  Station from which this was streamed (radio, Internet radio, etc.).
> 
> INTERVIEWEE
>  If the material is an interview, who is being interviewed?
> 
> INTERVIEWER
>  If the material is an interview, who is doing the interviewing?

Those are all tags that can be defined by the user if necessary. Usually
it's music that is encoded in OGG anyways. For speech only you can use
smaller formats and codecs in 8kHz, 8bit.

> LENGTH
>  Total playing time in seconds, m:ss, or h:mm:ss.
>  The seconds may be a floating point value (i.e., have a decimal point),
>  and if there's no colon the value in seconds may be any nonnegative number.
>  Examples are "7:23", "3600", and "75:40:45.3". The value "0" is legal.

Werd, all the players I used for playing any musical format on the
computer or my CD-Player knew the total length by themselves. Why
introduce a tag? Only for the Napster guys who need to know whether they
got an incomplete download or not? Naaahh...

> SUBTITLE
>  Subtitle.

Hm, VERSION does that job already. Things like "dJ lEeT RMX" fit in
there and by players this should be displayed as a subtitle, so it can
fullfill both purposes.

> LANGUAGE
>  The language(s) used in the recording (comma-separated if more than one).

Yeah, this makes some sense. But on the other hand, this could also be
covered by the VERSION tag.

> CD_ID
>  The table of contents (TOC) frame from the CD, uniquely identifying the CD.
>  When combined with TRACKNUMBER this forms a unique id for the track.
>  This allows use of databases such as "CDDB" and "Freedb" (freedb.freedb.org).
>  This is a 4-byte header, 8 bytes/track, plus 8 bytes "lead out",
>  from the table of contents (TOC) header of the CD.
>  Its maximum size is 804 bytes (99 songs), but normally it's much smaller
>  (a 10 song CD uses 92 bytes).
>  The Vorbis specification can handle binary data, but since it would be
>  unusual to do this, this should be represented using 2 hexadecimal
>  digits/byte (this doubles a 10-song CD ID to 184 bytes of data).
>  {It could be straight binary, or uuencoded, or whatever; any druthers?}

Now this sounds interesting. I'd like to see that some day, especially
in the CD-Rip... eh, CD-A Backup software.

> DEMO
>  If set, this indicates this is only a "demo" of a "real" track
>  (e.g., it only has part of the track). The text describes in what way
>  it's a demo (e.g., "First XYZ minutes").
>   See TRACK-URL, ALBUM-URL, or PURCHASE-URL to get the real thing.

VERSION!

> REDISTRIBUTION
>  Text describing redistribution conditions. May be "never", "unlimited",
>  "[non-commercial | private | restricted ] redistribution
>   [in {list of countries using ISO 639 names}]", or some other text.
>  For commercial music, "never" would be common. The value
>  "non-commercial redistribution" is encouraged.
> 
> USAGE
>  Text indicating usage (replaying) conditions. May be "never", "unlimited",
>  "[non-commercial | commercial ] [private | public | public performance ] use
>   [in {list of countries using ISO 639 names}] |
>   [at {location}]   [only]", or some other text.
>  For commercial music "private use only" would a common value;
>  "non-commercial use" would certainly be encouraged.
>  Note that ``fair use'' laws grant additional usage privileges beyond this.
>  If the use terms are unusual, it's best to define a USAGE-URL.
>  For rights of modification or extraction, see LICENSE.

I, from a musicians point of view, VERY discourage the intoduction of
those two tags. Copyright law is way too complex and also too different
from country to country that it could be summed up in so few words.
Every musician with his head attached would only say: "(C) by me, all
rights reserved. Modification, redistribution, hiring, lending,
broadcasting, public performance and every other use of the material,
except for your private entertainment, is strictly prohibited." (Those
guys from the music industry wouldn't say anything different.)

Musical theft is a huge problem. I am not talking about the theft and
piracy the music industry is complaining about, it's what some within
the music industry steal from musicians that offer their music for free.
I know of three proven cases in my nearer circle of acquaintances, and
that's a disturbingly high percentage when it comes to the total amount
of people i both know and who also make music for free.

Copyrights are all worth a lot of money, and if you let someone enjoy
(or not ;) ) your music for free, you won't give him any rights to make
money out of it, direct or indirect.

We have this discussion about similar points concerning that GPL
inspired eMPL and refrained from letting anyone copy and redistribute
the free music, because web sites could make money with ads while
offering content from people who don't see a single cent. This also
affects Napster, once they demand fees for the service.

This all is more delicate with music than with software, because
software always stays in the "electronic domain". Its somewhat more
controllable, but music is not. If some guy in Japan steals my music and
makes big $$$ out of it, I can't really do anything about it, but at
least I can make clear that he didn't steal it because he seriously
believed that he was allowed to do so. Musicians that offer their music
for free have a hard live when it comes to enforcing their rights,
because they usually have nothing they could fight with (money, so to
speak).

I really don't care about people giving away copies to friends or
burning their stuff to CD or whatever. Nobody could prevent this anyways
and I do it myself. But I'd never explicitly allow that to anyone ... 
"showing to some friends" becomes "playing on a 50+ people (err,
'friends') house party that costs US$10 admittance" pretty fast and they
might even find a lawyer that twists it legal out of what I allowed.

> LICENSE
>  The license used.  May be a license such as "Free Music License",
>  "Public Domain", or a generic "All rights reserved"; see LICENSE-URL
>  (if defined) for its text.

Concerning the efforts about the eMPL, this could be useful.

> LICENSEE
>  Licensee of the file contents.  Sometimes this person is called the ``owner'',
>  but the real owner of the track is specified in the COPYRIGHT information.

Makes no sense. If you have an .OGG with some music, YOU are also a
licensee (maybe with less rights than the licensee you got the .ogg
from). However, if you are not another licensee, you may not have the
.ogg. Easy thing. It's more interesting what license you are entirely
consent with, so LICENSE and LICENSE_URL make sense.

The Copyright holder ( (C) ) is the "root" of the guys who own rights of
a track. He has the exclusive Copyright and may give away restricted,
simple rights (also independent of the author, if the author sold his
exclusive rights to the new owner).

> LYRICS_COPYRIGHT
>  The copyright on the text/lyrics, same format as COPYRIGHT;
>  this may be "Public Domain".
> 
> MUSIC_COPYRIGHT
>  The copyright on the music, same format as COPYRIGHT;
>  this may be "Public Domain".

Those are things that are internally managed, e.g. within a label.
Things that aren't your own have to licensed (e.g. for the distribution
and publication of the final material). This is not interesting for the
public, because they always get the material as a whole thing.

> PURCHASE-URL
>  Open this URL to begin purchasing this track (in many cases this will
>  involve purchasing the entire album).  Going to this URL must not
>  "instantly" purchase it; users must be allowed to confirm their
>  purchase information.

I believe that this is covered by the URL tag. Providers usually want to
show the user all the other great stuff they have and sell him not only
the track/album he is already interested in.

> (Modify COPYRIGHT to say): This field should have a date, a space,
> and then the name of the copyright owner.
> This is the copyright of the particular performance, not the copyright
> of the music or text/lyrics.

As mentioned above, the copyright of the instrumental part and the
vocals/lyrics is not interesting for any user. What they should know is
who owns the music they're listening to right now.

Right now, I'm remastering and encoding all our mp3 releases to ogg, and
our copyright tag is "COPYRIGHT=(C) xxxx by KOLABORE. All Rights
Reserved." I think that this is the usual copyright phrase. I didn't use
what is written in HTML as © because I don't want current players
to display ISO-encoded characters in plain text.

> Note that some copyrighted works may be freely distributed or freely used,
> and that ``fair use'' laws allow certain uses even when the copyright
> owner has not permitted such uses.  If it's in the public domain, instead use
> specify "Public Domain" for the "LICENSE" value.

In German copyright law for example, there is no "fair use". (You either
have a right or not, and those rights are entirely given away by the
owner of the exclusive copyright. They can be restricted in kind, time
and location.) I'd be happy if the legal things related to OGG comments
could be as internationalized as possible.

Concering the public domain and music ... I already thought of releasing
a track into the public domain, maybe just to see what happens. But
there are many what-ifs, so I decided not to do it. Maybe it's because I
really have no spare money and it'd suck badly if someone makes money
out of even the crappiest shit I ever produced without giving me a
share. I really doubt that I am alone with this opinion.

> the MIME type; the problem with these is, do you really want to
> store image data inside a comment field?

Hmmm, but this'd be funky. Maybe if the image size (resolution and
filesize) is reasonably restricted?

Moritz

P.S.: 7:20 am and no sleep yet ... i won't proofread that mail now. If I
said something odd, just let me know and I will try to straighten it out
after i had sleep. :)

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