possible bug in the AccurateRip DB

[calestyo]

Hey Spoon.


While this happens with EAC 1.0 beta 4, it may also be a bug in the AR DB itself, so maybe you can have a loot the the issue below:

Attached you'll find 3 EAC logs with both AccurateRip and CTDB, all
from the same medium, from rips made directly after each other.

01: Test&Copy Image (without C2)
02: Test&Copy Tracks
03: Copy Image (with C2)


The resulting images (respectively the concatenated WAVS from 02) were
all fully binary identical.


When you look at the logs, you'll see that CTDB always verifies each
track, but AccurateRip fails, interestingly with different results:

01: track 33 okay, but with much lower confidence
track 34 marked as failed with a high confidence

02: same as 03:

03: track 33 not in accurate rip DB
track 34 okay with a high confindece



That's kinda weird isn't it? How can it be, that (while the actual
ripped data is bitwise identical) these different results come up for
the same tracks.

(No submission of the new data has happened in the meantime to the AR
DB from my side,... but even if, that wouldn't explain why the records
for 33 vanish).



I've had similar (but not equal) symptoms with several other CDs (about
10):
There all 3 rips produced exactly the same results for CTDB and AR, and
also the files were fully bitwise identical.
The interesting thing here was, that for AR one tracks (in all cases
but one: the last) was marked as "not in the AR DB", while all other
tracks had a quite high confidence (>20 or so).
So I'd guess it's highly unlikely that all of these people ripped all
tracks except the last one.


So my point is, either something is wrong in EAC when it does the AR
verification (respectively when it queries the AR DB)... or something
in the AR DB itself is wrong.



Any ideas?

Thanks,
Chris.

[Spoon]

Re: possible bug in the AccurateRip DB

The AR DB works like this:

You lookup a disc, and that disc is cached on your HDD, for upto 2 weeks.

So if track 33 verified once then says not in db, it is either a bug in eac, a problem with your HDD, or some security software is blocking the reading of the file.

[calestyo]

Re: possible bug in the AccurateRip DB

Well I guess it's quite clear that it cannot be a HDD issue, since the WAVs are bitwise identical,... the likeliness of and HDD error actually correcting the data to be the same again is basically zero.
It cannot be a memory/bus/etc. error either, since when I repeat these rips, exactly the same happens (with exactly the same CRC values reported),... again how likely would that be? lim goes to 0.

Plus the fact that CTDB always verifies okay... so any bus/memory error would need to happen by chance always when the AR values are calculated,... HDD errors are at that level anyway already excluded, since the data is long cached in the memory.

Anyway I found the same issue with another CD (the logs are attached), 01, 02, 03 with the same extractions modes as described before.

It seems that such issues always only happen with very high track numbers (76 and 66)... anything that pops into your mind how this could play a role?

Apart from that, not security software is in place (or anything similar),... I've already send a mail to EAC's upstream,... but I still wouldn't fully exclude that this is a bug on the AR DB side.
I mean how likely is it, that software calculates/checks the CRCs valid for thousands of cases, but not for a few single ones, plus that it calculates it differently even though the ripped data is the same. Cheers, Chris.

[calestyo]

Re: possible bug in the AccurateRip DB

Forgot the new logs.

[Spoon]

Re: possible bug in the AccurateRip DB

You would have to try dBpoweramp to try those discs, to rule out EAC.

[calestyo]

Re: possible bug in the AccurateRip DB

The cross check with dbp was already on my todo list ;-)

And it seems in fact that the problem lays at EAC's side, though one can see an anomaly at tracks 39 and 45 (taking the 2nd CD which log's I've posted here) as well, in that the confidence is only 9 (and much lower than all the other tracks where it is 24.

But that could also just mean, that the 24-9 submissions where made with EAC which may not have submitted the two tracks correctly. But that's of course just speculation.


Cheers,
Chris.