CUETools versions 1.9.5 through 2.1.5 (current)
dalza:[ CTDBID ] Status [720aa726] (309/309) Differs in 292 samples @22:35:49,22:52:04-22:52:05,23:04:11-23:04:12,23:06:46-23:06:47 seems scratched around playing time 22-23min for CTDB05 [ced55a29] (200/330) No match but offset seems scratched at track 5 for AR ... seems like you can fix it with CTDB, (otherwise CTDB would return either "not found", "no match" or "could not verify"), try encode/repair, then if it matches you corrected it. Edit: You can listen at min 22-23min & see if you ear a glitch ... then, if you ear a glitch, you can compare with your EAC log ... that is a rewarding bittersweet experience ... if you ear a glitch that EAC didn't reported despite "perfect settings" for the drive, I can tell ya that you will trust . accurip more than .log after that !!! If earable, you can even re-listen to the glitch before & after fixing it ... to fully convince yourself. The only problem with repair that you should be aware, is that it looks like sometimes you can fix a perfect but not yet in database rip X with the data of perfect rip Y already in database. It's not a big issue, it's just up to the end user to decide if it's worth fixing with all the positive/negative hints privided by AR/CTDB/LOG & listening test. Personnaly, so far I always fixed unless there was 2 entry in CTDB, one matching/one differing but in this case the clash is obvious. Also fixing first & last tracks is also dubtious sometimes because of excluded samples: sometimes if it differs at the very beginnings/ends, you know you might only have partially fixed it, but it's all you can do. Anyway very short glitches shouldn't be earable at these locations (likely in the middle of silence) (... well I hope).