Improved CDDB?

I came across this thread over on the EAC forums, and it does make for an interesting concept.

Every time a CD is ripped/inserted/used with EAC, EAC stores the FreeDB info for it in a file called CDDB.dat. If the user edits the information this corrected/updated info is stored instead. So slowly over time EAC builds up a database of the users CDs with the correct info so that if they should insert the same CD again it will have the correct info.

Now I have no idea why some one would be ripping their again unless it is because they want to rip them to different encoder - that is the only advantage I can see to this. Except for what is mentioned in that thread link above. You see it is possible to import someone else’s cddb.dat file into your and gain more info about CDs you don't have, and should you purchase them in the future your bigger cddb.dat file might have the details.

So why do this?
Well something I'm trying todo is to completely automate the ripping process, which is not that difficult todo. The clincher is the correct naming & tag info, 80% correct is only as good as 20% correct when you have to go back and double check everything.
We all know how good CDDB & FreeDB are, good enough most of the time to point you in the right direction but there is still the need for user input to correct things.
But if you knew that the info was 100% correct every time, you could just sit there feeding in CDs to your hearts content. Automation!

So what I'm asking for is do people think that this is a worth while endeavor?
It would take a bit of work on an individual bases, if someone could write some flexibly tools to be able to access the cddb.dat file for editing it would make it even easier. Especially if it could auto correct "Beetles, The" entries and included Roger's (right person?) proper case function that he wrote in Perl (going on a bad memory here).

Thoughts?

The whole point of CDDB and FreeDB is that they can be updated and corrected over time. You are supposed to be able to send corrections to them. So I'm not sure what you're asking to do that's different?

And by the way, the best automation of this task that I've ever seen is the Rio Central. Stick the disc in the drive and that's all.

Since I started out as a Central owner first, the Central's way of ripping against the internal CDDB was what I was first exposed to. I liked their idea of including the CDDB database on the hard drive and only doing Internet lookups on very obscure discs or new ones that were newer than the CDDB.

Well, after having the Central now for a couple of years plus, I've had a lot of time to use it and rip CDs with it.

I've made quite a few corrections to the tags provided by the on-board copy of CDDB and the web lookups. No problem there, I expect to have to make a few changes in capitalization, spelling, etc.

But it would sure be nice to get an updated CDDB file set. I'm finding now that most of my CD rips are going out to be looked up on the Internet, because most of them are newer titles and they are too new to have been included in the 2001 copy of the Central CDDB....

Oh well, a wish list item I guess....Any chance of an updated CDDB for the Central? I've tried using Gracenote's website and making that inquiry twice, and haven't received any response from them...

Randy

You could remove the CDDB database from the Central altogether, thus forcing it to do internet lookups each and every time it rips a CD. I don't know which file it is, though. Anyone?

Of course, this only guarantees you get the latest data from gracenote, it doesn't guarantee the accuracy of that data.

I'm actually interested in updating the CDDB file to help prevent Internet lookups and that extra few seconds. The accuracy of the supplied CDDB data is fine, no problem with that.

Since many of my rips are newer CDs, they just aren't included in the supplied CDDB.

I'm not in front of my home PC right now, but at one time I had it figured out which 2 files were related to the CDDB.

I was hoping to get updated copies of the files when installing the 1.10 Central software, but I was unable to get anywhere with Gracenote. I didn't try Rio Support, just figured that there was no support available...

I was thinking that maybe I could try to hook up with someone that has one of the Gracenote-featured music servers (the "other" brands) and see what their CDDB files / dates looked like...

Randy

Correct Tony, one can send the corrected data to them, but that seems to result in several entries for the one CD rather then one corrected entry.
I just think that it can be done better, mainly because I have a use for a better version.

So you're talking about writing something completely new that will compete with freeDB and CDDB? Please give more details of what you envision. And most importantly, how are you going to correct for the human factor?

The problem I have had with the central ripping / CDDB is that many times the year isn't filled in and the genre is not what I would have picked.

Quote:
The problem I have had with the central ripping / CDDB is that many times the year isn't filled in and the genre is not what I would have picked.

And thus the nail is hit squarely on the head!

The why can be found here and the how here

EAC can be automated from the command line, and a script handles the extra work.
So at the point I have the ability to convert a stack of CDs with the press of a button, but with out definitely correct tags.

I've considered a few different ways about this, manually editing them after the fact (time consuming, error prone), Music Brainz music ID thumb printing (23% failure rate), a custom application using a different DB (time to develop & costs).

So currently I'm back to pursuing getting the tags right from the get go.
So here is what I envision:
EAC create a local database of CDs that it has seen.
The info in this local database is only as accurate as that local user (the human factor).
This database can be imported by other users into their copy of EAC and merged with their local database.
And slowly the database grows.

Like CDDB & FreeDB it depends on a community of users and their collective accuracy, and this is where I'm trying to reduce the human factor. I hoping if the empeg community would help me achieve this, if collectively the community could agree on a standard, if collectively the community could go through their CDs, query them against FreeDB and then correct the entries.

And slowly a perfected local cddb.dat file would be created, and obviously I stand to gain a lot more out of this then any other individual would, I would be getting an important asset for my business. So if the community helped me out with this then I would owe the community, and how I would return the favour to the community? I don't know, I'll let the community decide that.

If anyone can come up with another solution to this problem I'm all ears, I am currently in the process of putting my money where my mouth is and going ahead with this. How well it will fly I don't know, but I'm willing to try it out and see.

Oh, and I know that even then it would not be perfect, as Matt and Glenn have rightly pointed out [orange]the genre is not what I would have picked, all I can hope is that an agreed standard can settle some of this and at least produce better then the current option.

The thing is that it comes down to trusting the people updating the database. What you're trying to accomplish is getting a good set of users by making the buy-in cost fairly high (having to import and export a file manually) so as to not let every no-spelling idiot out there click on the submit button.

This, IMO, is not a good solution. The great thing about FreeDB is that it is going to have almost everything you can think of in it, even if some or much of it is slightly wrong. You want to trade that universality off for correctness, which is probably less useful. What you really need is a large userbase, but a technical way to prevent errors.

As it turns out, I have such an idea. The problem with most of the errors in FreeDB is that people simply submit unchecked info. This usually results in typos. Typos are infrequently duplicated. That is, there is only one correct way to spell "Pink Floyd", but there are many ways to misspell it. If, instead of assuming that the first person who enters the data for a title is correct, you gather a few data submissions first, it should be easy for a program to accept the first duplicated set of data. Since it's more likely that two different people will submit the same correct data than submitting identical incorrect data, this ought to work pretty well.

That being said, if you plan to make money off of this idea, I demand a piece of the action. That is, this idea is mine and I reserve the right to make money from it. (He says as if that has some sort of legal binding.)

Quote:
That being said, if you plan to make money off of this idea, I demand a piece of the action. That is, this idea is mine and I reserve the right to make money from it.

Too late, I think the big A already has a software patent for that.