* Added 'Silent track' diagnostics in AR log
I still don't understand, how CUERipper handles C2 pointers.
Second, i've total chaos from many explanations related to defeating cache with or without FUA support, they are offen contradictory. I suppose, CUERipper doesn't have FUA implemented, maybe in the future, or it isn't necessary at all (of course it must be firstly supported by the drive itself).
On start, a message "CUETools 2.0.9 is out!" appears.Is the bug with the de-DE.dll fixed BTW?
I wanted to underline that the fact that you left out "not present in database" results from the local database as the side effect that finding dupes within rips that are not in AR database doesn't work, while I think technically CT could be used to find dupes within those rips, even just by comparing CTDB TOCID, if sums are not calculated (when using "verify only if found").
So my first question is how do I nuke the database ?
Just delete the file "C:\Users\<username>\AppData\Roaming\CUE Tools\LocalDB.xml.z"
just make sure you are not verifying in "only if found" mode.
cdimage.cue: CRC 2C2822C4
EACs "Use C2 pointers" option can decrease the number of retries the ripper makes if the drive reports that data is ok (correct me if i'm wrong), while CUERipper only uses C2 to increase the number of retries if the drive reports that data is not ok. In other words, CUERipper uses C2 pointers while EAC relies on C2 pointers.
drive has no more than 8 megabytes of cache, and invalidates this cache by reading in large non-overlapping chunks, which forces the cache invalidation.
dupes always have the same CTDB TOCID
So CTDB TOCID from .accurip using "only if found" could be used to find possible dupe before further CRC examination, right ? It would be even faster than re-calculating DiscIds/TOCs, no