Rather than re-hash the whole thing, I'll just do comments tonite (I'll try
and do a fancy collection of everything this weekend). I'm too tired to do
full attribution properly, so let me just say that I saw good responses from
Brian Murray, Larry Kain, Eivind, Greg Stein, Mike Oliphant, and Alexander
Dietrich.
--------
Allowing all fields the "chance" for abbreviations makes sense, as well as
for language. My thinking is getting bogged down in implementation issues,
but I think it'd be good to try for.
Do we all agree that abbreviation support is required? I think I've seen
consensus for language support, am I off base? (just checking).
---------
I don't think that there'll be any real way to include multi-cd set
information in one record, as each will have unique identifying
characteristics, and there'll be no way for the DB engine to associate one
entry with another.
I do think that having end-times for "virtual track" or "selections" or
"blocks" (what do we want to call these? I like "selections" myself) makes
sense. I'd intended for it to be inferred from the start of the next track,
but giving the user more power is usually a better answer (can edit out
inter-track chatter for shuffle mode that way).
I also want to store information for these, as well as the ToC information,
as M:S:F, rather than just frames. Firstly, that's a bit more
human-readable (I just like that), and some systems (some jukeboxes,
apparently, for example) might not provide the end user access to Frame
information (so the DB can at least do a pretty good match with just MM:SS
info) (mostly a ToC issue).
---------
At first glance, I like the idea for having the DB or client 'automatically'
select the first non-blank composer/performer/conductor/orchestra field for
"artist" name, but I think I'd like to see CD-Artist and CD-Title be
strictly related to how you buy the CD--whatever's on the spine, usually.
Still can be ambiguous, though...we should probably write some simple
guidelines for end users...(we should do this in any case).
It does make sense, however we implement the storage of "freeform" or
"optional" data fields, that we suggest a list of standard field names like
Engineer, Producer, etc. Anyone care to whip up a canonical list of
"standard optional" fields?
--------
Building an Internet Music Data Base (acronym collision alert!) -- I would
love to see that, eventually, and maybe this'll turn into that, but for now,
I think we should continue to concentrate on solving the initial problems
(and making the DB flexible enough that we can expand or export).
---------
Genres -- somewhat connected with an UberDB, Genres would be great, if we
could find the right way to do it. Maybe we need to drop the idea of
"pre-packaged genre names" like 'rock,' 'jazz' or 'pop," and pick terms that
acutally describe the music (fast, loud, quiet, angry, relaxing, electronic,
acoustic, etc.).
If the protocol and client people do their jobs right, we can always add
this in a later revision.
I move we table Genres for now--leave them out of CDIN-1.0. Any objections?
----------
I think we're on the cusp of having our DB content finalized. One nagging
question I have (closer to implementation, though).
Will somebody please convince me that we can do this as a true RDBMS? My
skepticism isn't that we can define a schema, it's that we can (and want)
have clients that actually interact to the degree that they receive pop-up
lists of artists, or spelling corrections, or what-not. The existing CDDB
is very much "submit only," and I'm just afraid that if we go to an
interactive model it'll become much more complicated.
For example, with "submit and forget," the user, well, submits an entry and
forgets about it.
If you've got a correction request returned, what if the user ignores it?
Do we accept with a typo, unilaterally correct the entry, or refuse to store
it?
I'm not dismissing it out of hand, I'm just wondering how we want to handle
this.
-------
That's it for now....if the Boss lets me back online later tonight (I think
I'm due for some housecleaning) I'll try and write 1.2 of the content
proposal.
david.
Brian also suggested that super-track information could be used to handle
multiple CD sets...I don't think that'll work, since each CD in a set gets
individually recognized--there'd need to be some way for the database to
recognize that two different entries were related.
Brian asked also if we should also have an End Time (in addition to start
time) for "virtual tracks." Probably wouldn't hurt--I'd intended for that
to be inferred from the start of the next track (as Brian correctly
guessed), but there could be times when you *want* to separate out
inter-track chatter, esp. for shuffle mode (though it'd get played when
listening straight through). The more power we give the listener, the
better...