On Mon, 2006-01-09 at 10:02 -0800, nwestbury wrote: > about 95% of my classical music CDs are in the freedb database, so I > find Pat's comments about only 'three on ones' to be very strange.
I meant to write "I've found that very few if my classical CDs are even listed, and what little data that is available on ones that match is pretty bad." But I typo'd it past comprehension. I find less than half of mine matched CDDB at all, and the data quality was terrible. YMMV, etc. > I was planning on initially populating the database by having a smart > program that extracts data from the freedb database, but Pat's comments > suggest this will not give us good coverage?! If you implemented your own FreeDB, that might work fairly well. The big problem is that classical CDs sell in the thousands, 10,000 is a very successful release, so the odds that a lot of people will have already done the database is pretty low. The second problem is that the CDDB/Feedb hash algorithm is simplistic to the point of being nearly useless when you have only three movements per CD. So a better approach is to hash the contents of the songs, rather than just looking at the table of contents. We don't have to feed all of the data to the hashing function, just a few thousand bytes would be a huge improvement over the CDDB/Freedb hash. > Does the data belong in tags? We don't have to decide that. With the > proposed database, a user can have the data put into tags so existing > music players can find the data, or the user can write software to take > the data directly from the database. Agreed, it is fairly easy to read a Sql table. and do a few joins. > Do we want to add columns to the SS database? Again, I would see no > reason why that could not be done. However, I don't think the SS > database should be the official repository of the data. 1) Although I > am a SS owner, I do not think we should prevent other users from using > the database, 2) the database is online, 3) we would need to add > columns and tables to the SS database and that would require either a > fork of the SS software or polute the software for those users that are > not interested in classical music. The only reason to have the data in the SS database is to have a single source. A lot of users don't want to think about databases, and since SS 6.5 has a nice MySql database, there for the using, it biases me. I didn't catch that you see this as being online. Accessible with some suitable CGI or WebApp? > Do we have to write a tag editor? I would think this would be a very > useful tool. While writing a tag editor from scratch may be a lot of > work, there are open source libraries available so we need only replace > the code that reads the freedb data with code that submits a query thru > JDBC and then looks at the user's options to see what data the user > wants in the standard tags. That is a lot less work than starting from scratch. > In my view, getting a good initial set of data in the CD, compositions, > and performances tables will be a little tricky. Any automated tool is > likely to fail to match data that is really the same (we will find the > compositions table contains Beethoven's 'Symphony No. 9', and another > piece called 'symphony 9 in D minor', and another piece called 'The > Choral Symphony', if the conversion tool does not have a lot of clever > pattern matching. We will then need a tool to merge the rows). The database schema and tools is the easy part. As you point out, the naming is where the brains have to be, and I don't know of any way to do it without a smart human. Ludwig van Beethoven: Symphony No.9, Op.125 "Choral" in d Minor is just one of the ways to list it. -- Pat http://www.pfarrell.com/music/slimserver/slimsoftware.html _______________________________________________ ripping mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/ripping
