Consistency of AR results across programs

[timw0932]

I've ripped a bunch of CDs lately, and I've double-checked a few with CueTools and the foobar2000 verifier. I have a couple of CDs that dbpa reports (for example) as Accurate(8) for every track, while the other programs say the disks aren't in AR at all. Why is this happening?

Also, does dbpa maintain a history of ripped CDs anywhere? I've found the AR cache in AppData and by getting an AR id via CueTools, I can search for a matching filename in the cache. Is that the only way? It would be really nice if I could simply insert a CD and the ripper would give some indication that the disk has been previously ripped. In particular, I'd like to view the previous AR data for the disk without ripping it again. I guess multiple pressings could make that somewhat unreliable, but I don't have any, and I would find it valuable.

[Spoon]

Re: Consistency of AR results across programs

If the disc does not start exactly at 2 seconds, the other programs cannot guess where it starts and cannot check the disc, only a CD Ripper has access to this information (and a cuesheet).

There is no cache of ripping results.

[EliC]

Re: Consistency of AR results across programs

Also, does dbpa maintain a history of ripped CDs anywhere? ... I would find it valuable.

I have requested this multiple time. It would be nice if there was a database of ripped discs and the user had the power to sort discs into directories based on if the ENTIRE disc was accurate/secure vs inaccurate/insecure. If a disc that was previously inaccurate/insecure is re-inserted you could more easily see what tracks where previously bad and re-rip just those. If the ENTRIE disc is now correct the program should move the disc to the correct directory.

[timw0932]

Re: Consistency of AR results across programs

I have requested this multiple time. It would be nice if there was a database of ripped discs and the user had the power to sort discs into directories based on if the ENTIRE disc was accurate/secure vs inaccurate/insecure. If a disc that was previously inaccurate/insecure is re-inserted you could more easily see what tracks where previously bad and re-rip just those. If the ENTRIE disc is now correct the program should move the disc to the correct directory.

I'd like that!

To add to my first post, I got distracted and mixed up a handful of CDs, so I wasn't sure which I had reripped with dbpa and which I had ripped years ago with a non-AR ripper. I wanted to find out which I ripped with dbpa, or at least verify the ones in question were accurate. That's how I got into CueTools. But like spoon said, CueTools and programs like it don't always work, and sometimes they can't even find discs in the AR database that really are there, so I can't even match the AR ID from CueTools to the %AppData%\AccurateRipCache filenames. However, I left the folder open while inserting discs with dbpa Ripper also open, and I observed that dbpa either creates or updates the AR file for that disc and only that disc immediately upon inserting the disc; you don't have to rip the disc. When I opened the file properties for the AR file that just bubbled to the top of the Explorer window sorted in descending order by modification date, I found the creation date had NOT been modified if it was a pre-existing file, meaning at the very least it had been seen by dbpa once before. In my case, it means it was successfully ripped, because I haven't had any bad discs. So it appears this is a good way for me to achieve my goal of telling which discs I ripped with dbpa, when CueTools is unable to verify the files as accurate after the fact. Not what you're after, but good enough for my purposes!