@trixie Can't find your mail adress. So taking it here instead.
The problem is when i insert a cd. It finds the wrong info. The inserted cd is a single, Panjabi MC - mundian to back ke. This problem occurs on other cds aswell.
Quote:
What exactly do you mean? When you insert a CD, ADRipper doesn't find any info for it in CDDB? Or the CDDB data is incorrect? Can you please make a screenshot showing the problem and send it to me via e-mail? Thanks!
It's probably because the data used to identify the CD for the FreeDB database lookup are the same on the two CDs. With singles, there is a bigger risk of duplicates because the total time and the number of tracks (which both are part of the calculation, IIRC) will statistically match more often.
Have you tried letting FreeDB (the older MUI program by Alfonso Ranieri) find the disc info? I think ADRipper does not yet implement full support for so-called multi-matches, where FreeDB might be better at showing the choices. It could be interesting to hear what it shows you for the same CD.
ADRipper uses libcddb to calculate a unique ID for each inserted CD and then tries to download from CDDB the metadata relating to this particular ID. The ID is calculated based on total data length, track length and number of tracks. As Niels says, with singles there may be a higher probability of a mis-match because there are fewer parameters for the calculation.
For the peace of my mind I've just checked 30 of my CD collection (including two CD singles), and all of them were recognized properly. So I guess you're just having bad luck
Quote:
Can't find your mail adress.
Try ADripper.guide, the "Contact" section
@nbache
Quote:
I think ADRipper does not yet implement full support for so-called multi-matches
Contrary to what I wrote you in an e-mail (sorry about that, I was wrong), ADRipper does support multi-matches in full. It's just less conspicuous compared to Alfonso's FreeDB If there are multiple matches, you can select them from the toolbar - it's the second "arrow" pop-up button from the left.
@Antique
So try this - there could be a better match for your CD
That was a feature i did not know of before. I got 2 results for the single. None matched though. But will try this on other cds if they don't match. :)
I remember once inserting a data CD by mistake. Of course the CDDB "match" ADRipper found was completely bogus. As I said, the program uses whatever parameters are available to determine the unique ID. By design CDs carry no IDs.
I got 2 results for the single. None matched though.
Did you check on freedb.org (http://www.freedb.org/freedb_search.php) whether your CD is registered in the database at all? If not, you could submit it (either when ADRipper's submit function works correctly, or with FreeDB), then the next one who tries will get three choices .
CDDB submission (in fact the overall CDDB support) has been greatly improved for the upcoming version. Still, there's a rather big issue I need to look into: it appears that sometimes the CD ID gets miscalculated. This pretty much spoils the fun because submission for a wrong ID never works, of course.
Is it the one second miscalculation? FreeDB used to have that problem too. When it happened, I would usually fix the CDDB file up manually, from the copy returned in the error mail from FreeDB.org, and resubmit per mail. At one point, an update to FreeDB fixed it.
IIRC, it was a common error in many clients, which they have described on their developer info page.
Well, I may have condemned the poor program too fast
I did some more testing yesterday with a CD that showed a different ID compared to this CD's only entry in the CDDB database. I then checked the program code for obvious mistakes but I didn't spot anything that would indicate an error. The track offsets and the CD length (which are crucial for the determination of the ID) seem to be calculated all right.
The CD eventually got exported and was accepted in the CDDB database under the ID provided by ADRipper.
As Alfonso's FreeDB calculates the same ID for this CD, I'd guess that ADRipper determines the ID just fine. It could be that the original CDDB entry (which showed slightly different track offsets, hence a slightly different ID) had been generated by a program that calculates frame offsets incorrectly - or it could have been a different pressing of the CD, don't know.
@all
Anyway here you can see a database entry exported by ADRipper 1.13 showing that CDDB sumbission indeed works, including revision bumping. (Previous versions would just try to export revision 0, often ending up in server rejection.)
IIRC, the issue I saw back then has to to with the way the disc length is determined. You cannot necessarily rely on the reported disc length, you have to add the length of the last track to the start offset of the last track instead, or you may - with some discs - end up with the wrong length for the calculated discID, which gives you e.g. this error back from FreeDB:
"Invalid DB submission: disc ID generated from track offsets (9509cb0b) not found in DISCID"
This one is from an error mail I got (back in 2005) when I had submitted the following CDDB from FreeDB:
a CD that showed a different ID compared to this CD's only entry in the CDDB database
[...]
It could be that the original CDDB entry (which showed slightly different track offsets, hence a slightly different ID) had been generated by a program that calculates frame offsets incorrectly - or it could have been a different pressing of the CD, don't know.
The latter is very likely to be the case. You will find many examples of this, where the same title exists with different IDs because e.g. it has been remastered with slightly varying track lengths as a result.
Looking forward to that! I'll make sure to find some of those CDs which gave the problem back then. (I knew it would some day turn out to be useful to keep all those old rejection mails ).
A small graphic teaser for the upcoming version 1.13. Apart from other improvements it now features an AutoRip mode, which starts ripping automatically upon inserting a CD. The mode activation is indicated in the bottom-right corner of the GUI, which now also displays the currently selected encoder: