Cool idea NWestBury... On Sun, 2006-01-08 at 23:52 -0800, Listener wrote: > You started with the data collection part of the problem. I see some > interesting ideas in your proposal: > > - capture the information about a composer once, including spelling. > > - capture the information about a composition once. > > - don't wire in the way this information is stored in tags. > > - capture the info about CDs in a format that is different from the > CDDB/FreeDB format. > > So how will this information get into music files or player databases?
The key is to design a database well normalized for classical music. About all that is useful from CDDB/Freedb is the disk id hash, and maybe a little of the data. I've found that very few if my classical CDs are even listed, and what little data is three on ones that match pretty bad. So the first think I'd do is have both the CDDB/FreeDB hash and a better hash in the primary "CD table". I am not convinced that this data belongs in tags in the files. I know my position is not popular, and tags have a few nice characteristics, mainly that they move with the files when you move the tunes on your disks, change computers, etc. But the data really needs to be relational, and tags don't do that well. At best you flatten the relationships. > Do we have to write new ripper s/w? If not, how do we interface to > existing ripper s/w? (We might write some s/w that acts like a FreeDB > server but how do we pass extra tag info like composer, conductor, work > and performers through the FreeDB interface?) If we don't provide an > interface to the riper s/w, how will we know where the ripper stores > music files and what's in them? I see no point in writing a new ripper. Just let it do its thing it puts the files where you tell it to anyway. I see running a stand alone utility that reads the tags and populates the database, and maybe tweaks some of the tags. > Do we have to write a tag editor? If not, how do we interface to > existing tag editors? (This is somewhat like the ripper situation but > the music files have already been stored.) You do not want to write a tag editor, I've done it, it is very painful. The formats (esp ID3) are a disaster. So you want to get some software reuse with an existing tag library, like the one in the SlimServer > Do we have to write a new player? if not, how do we get our info into > the player? Or is it all in tags in the music files? As Slim users, we just use our SqueezeBox or softsqueeze. If you want to support something like an iPod, that says you need to rewrite the tags into the file. I've written a player, depending on the platform, you can use the components of one of the existing ones, with your own file input module and your own skin. I see that as a lot of work for very little gain. The vision I have, and have had since the early design work of SlimServer 6.0 was that you just add columns and tables to the existing SS database. Or you could write a utility that converted data from the ClassicialTuneDatabase to the SS style database. The first thing to do is to patch the SS so it doesn't glibly trash the database, since we want lots more data than is in the tags. -- Pat http://www.pfarrell.com/music/slimserver/slimsoftware.html _______________________________________________ ripping mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/ripping
