title
Products            Buy            Support Forum            Professional            About            Codec Central
 
Results 1 to 6 of 6

Thread: possible bug in the AccurateRip DB

  1. #1

    Join Date
    Nov 2006
    Location
    München, Germany
    Posts
    46

    Exclamation possible bug in the AccurateRip DB

    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.
    Attached Files Attached Files
    Last edited by calestyo; 08-18-2015 at 07:02 PM. Reason: because this forum is apparently buggy... o.O

  2. #2
    Administrator
    Join Date
    Apr 2002
    Posts
    38,590

    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.

  3. #3

    Join Date
    Nov 2006
    Location
    München, Germany
    Posts
    46

    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.
    Last edited by calestyo; 08-20-2015 at 11:27 AM. Reason: since this forum is broken when JS is disabled

  4. #4

    Join Date
    Nov 2006
    Location
    München, Germany
    Posts
    46

    Re: possible bug in the AccurateRip DB

    Forgot the new logs.
    Attached Files Attached Files

  5. #5
    Administrator
    Join Date
    Apr 2002
    Posts
    38,590

    Re: possible bug in the AccurateRip DB

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

  6. #6

    Join Date
    Nov 2006
    Location
    München, Germany
    Posts
    46

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •