How wonderful! My favorite gaming platform, my favorite OS, and my favorite hardware vendor, are all coming together! Now, if we could throw some Montgomery Inn ribs and Budweiser in there...
Just because the code is available doesn't mean it's free (like beer, or like OSS,) The fact that it was once GPL'd, though, means two things. One, it's free (like beer, and like OSS,) and two, Escient is violating the GPL whenever it derives a licensing fee from commercial players (as are the authors of the commercial players.)
There are a few problems : One, not all CDs that are identical have the same stamped ID. Example : Pearl Jam Verses. Not all Stamped IDs are unique. Example : White Zombie Astrocreep 200 and other delusions of the electric head and a crappy bach remix I bought a while back. The discid algo that xmcd and others use is guaranteed to be unique, or at least, pretty damn close. The search engine that CDDB uses checks not only the discid, but the frame length of every track. It can generate "fuzzy" matches, which the user then chooses from.
OK, so as far as I know, the algo. is free. If that's the case, and I/we can get our hands on the most recent copy of the database that was publicly released, I don't see any reason why a new database couldn't be started. Am I missing something? As far as I can tell, the database shouldn't be more than a few hundred megs...
I'm not sure. I _KNOW_ from the license, that we can't write software that checks a new database, then checks CDDB if the entry isn't found, then puts that entry into the new db. What MIGHT be legitimate, is an application that does nothing but connect to the cddb database, then stores that info locally, then a seaparate app to upload that data to the new DB. The more I think about this, the easier it sounds, and the more practical it seems. Their protocol is simple. A clone, and a much BETTER clone, would be simple. The only trick is coming up with a ID algo that generates unique IDs, and is nothing like the CDDB algo.
Heh. The cddb software I'm working on HAS no gui. Heh. I agree that it's time to start a new db protocol. CDDB has been getting a bit too weird lately. The problem with starting a new DB is that the cddb license prohibits us from building a new DB using data from theirs. Starting a new one would be very, very slow. Plus, there are issues with patents owned by Escelent. Are there any? Even a new ID calculation method was developed, would it still be in violation of Escelent's intellectual property? I'm interested in starting such a project... it wouldn't be that difficult. Anyone interested?
What you fail to understand, is that there are certain pieces of information that a government (or any large organization which has competition,) must keep secret from all parties, including its constituants. T'would be quite horrible if Saddam Hussein were to know US troop movements in advance, or if a group of terrorists learned the location of, then access codes to, a stockpile of US biological weapons? Please, let's not debate whether or not the US does, or even should have, such weapons. The point is, there are certain things that need to be kept secret.
They'd need 1> more memory, and 2> a faster processor. That, of course, is on top of changing the audio support (16-bit, stereo, etc.) It would be expensive, and make the thing bigger.
I'm currently working on this. I'm combining a ripper/encoder with CDDB (I know, it's been done...) then storing all the info, plus the location of the resulting MP3 file, in a database. No web page for the project yet; it's still in its early stages. All of the cddb stuff works, and the ripper is, er, well... started. All that's left after that is the encoder, and cleaning up the database stuff. Should be tres cool.
I got an explanation on this from a dell representative last night. It seems that Dell bought a bunch of ISA V.90 modems, and won't put them in PIII systems 'cause they're trying to make their systems 100% PCI. You can't even ask them to put 'em in... the MBs don't have ISA slots. Well, they have a shared ISA/PCI slot...
Cox's writing was painful to read. Stick with code, my friend; your writing style is quite poor. Good point, though. I, too, find myself trying to explain the merits of open source to the corporate "suits." It must be done gently, and with GREAT care. If open source software falls short of the suits' expectations, it will be more difficult to convince those in power to adopt it again.
Slashdot Mirror
How wonderful! My favorite gaming platform, my favorite OS, and my favorite hardware vendor, are all coming together! Now, if we could throw some Montgomery Inn ribs and Budweiser in there...
Just because the code is available doesn't mean it's free (like beer, or like OSS,) The fact that it was once GPL'd, though, means two things. One, it's free (like beer, and like OSS,) and two, Escient is violating the GPL whenever it derives a licensing fee from commercial players (as are the authors of the commercial players.)
There are a few problems : One, not all CDs that are identical have the same stamped ID. Example : Pearl Jam Verses. Not all Stamped IDs are unique. Example : White Zombie Astrocreep 200 and other delusions of the electric head and a crappy bach remix I bought a while back. The discid algo that xmcd and others use is guaranteed to be unique, or at least, pretty damn close. The search engine that CDDB uses checks not only the discid, but the frame length of every track. It can generate "fuzzy" matches, which the user then chooses from.
OK, so as far as I know, the algo. is free. If that's the case, and I/we can get our hands on the most recent copy of the database that was publicly released, I don't see any reason why a new database couldn't be started. Am I missing something? As far as I can tell, the database shouldn't be more than a few hundred megs...
Nah. Taken it the context in which he made the remark, he's right.
I'm not sure. I _KNOW_ from the license, that we can't write software that checks a new database, then checks CDDB if the entry isn't found, then puts that entry into the new db. What MIGHT be legitimate, is an application that does nothing but connect to the cddb database, then stores that info locally, then a seaparate app to upload that data to the new DB.
The more I think about this, the easier it sounds, and the more practical it seems. Their protocol is simple. A clone, and a much BETTER clone, would be simple. The only trick is coming up with a ID algo that generates unique IDs, and is nothing like the CDDB algo.
Heh. The cddb software I'm working on HAS no gui. Heh.
I agree that it's time to start a new db protocol. CDDB has been getting a bit too weird lately. The problem with starting a new DB is that the cddb license prohibits us from building a new DB using data from theirs. Starting a new one would be very, very slow. Plus, there are issues with patents owned by Escelent. Are there any? Even a new ID calculation method was developed, would it still be in violation of Escelent's intellectual property? I'm interested in starting such a project... it wouldn't be that difficult. Anyone interested?
What you fail to understand, is that there are certain pieces of information that a government (or any large organization which has competition,) must keep secret from all parties, including its constituants. T'would be quite horrible if Saddam Hussein were to know US troop movements in advance, or if a group of terrorists learned the location of, then access codes to, a stockpile of US biological weapons? Please, let's not debate whether or not the US does, or even should have, such weapons. The point is, there are certain things that need to be kept secret.
They'd need 1> more memory, and 2> a faster processor. That, of course, is on top of changing the audio support (16-bit, stereo, etc.) It would be expensive, and make the thing bigger.
No... what does that have to do with his point?
True, it does. And I've used it. It doesn't do EXACTLY what I want it to do, though. Besides all that, yeah... I do like to recreate the wheel.
That's sorta like my idea. I'm using mySQL, though.
I'm currently working on this. I'm combining a ripper/encoder with CDDB (I know, it's been done...) then storing all the info, plus the location of the resulting MP3 file, in a database. No web page for the project yet; it's still in its early stages. All of the cddb stuff works, and the ripper is, er, well... started. All that's left after that is the encoder, and cleaning up the database stuff. Should be tres cool.
I got an explanation on this from a dell representative last night. It seems that Dell bought a bunch of ISA V.90 modems, and won't put them in PIII systems 'cause they're trying to make their systems 100% PCI. You can't even ask them to put 'em in... the MBs don't have ISA slots. Well, they have a shared ISA/PCI slot...
Cox's writing was painful to read. Stick with code, my friend; your writing style is quite poor. Good point, though. I, too, find myself trying to explain the merits of open source to the corporate "suits." It must be done gently, and with GREAT care. If open source software falls short of the suits' expectations, it will be more difficult to convince those in power to adopt it again.
Took me a second...
You guys rock nads. Really, I mean that. Without slashdot, I'd go out of my head on slow days at work...