[cdin] has an archive located at
http://mailman.cdin.org/pipermail/cdin/. It contains a lot of discussion
items, including much of what you mention below.
Regarding database design, that discussion is moving along quite well on
the cdin-server mailing list. Subscription info and a link to its
archives is available at
http://mailman.cdin.org/mailman/listinfo/cdin-server
> I agree that we should aim to create something way _better_ than current
> cddb, not merely replicate it. We need a well thougth out and easily
> extensible format for the data.
>
> Below is my proposal, based on what I've seen on these lists, and some
> of my own ideas.
>
> Tables:
>
> Album
> Performance
> Song
> Composer
> Artist
>
> The logic being like this:
>
> * One album contains one or more performances.
>
> * One performance is a certain song, played by a certain artist in a
> certain way. (the same song is often played by various artists, lyrics
> and composer is still the same and sometimes the same band has
> multiple different performances of the same song, like a live version
> or various mixes)
>
> I think it's important that we make the distinction between a song and a
> performance. otherwise we'll end up with a need to replicate info like
> lyrics in several places, or alternatively we'll be considering the same
> song performed by different artists the same, wich it clearly isn't.
>
> I also feel it's a mistake to have a "artist" field in the album table.
> Afterall there's no rule that an album has to be made by one artist.
I'm not sure on the part of your other proposal, whether the discussion
is towards supporting classical music properly, or going with a simpler
form. I'm a bit behind on my reading, but I know that it has been
discussed extensively.
However, I think everybody is in consistent agreement to support an
artist per track (and breaking out the artist into a separate table).
> Adding artist with the album would make it logical to add composer and
> other info there as well, and all this info is _really_ linked to the
> various tracks at the album, not to the album at large.
>
> On an unrelated note we do _not_ want an organization of the database
> servers that need a central "root" server, or that gives any one
> administrator control over the base at large. We should go for a flat,
> distributed database, possibly under the model of usenet news.
This has been discussed at length, and the consensus has been to NOT use
a usenet-news like model (the complexities are solvable, but the simple
solution is easier all around and meets our needs). Instead, we'll be
going for a central, root server and replicate/distribute the data out
to multiple machines.
The problems that we are seeing with CDDB today is not related to a
central root server. It is caused by NOT publishing the data freely. We
fully intend to keep multiple copies of the data distributed to the
public at all times. This will prevent anybody from "hoarding" the data.
Please refer to the [cdin] archives for past discussion on this topic.
Cheers,
-g
-- Greg Stein, http://www.lyra.org/