ambiguous report in log file: accurately ripped but not accurately ripped

[GoogleCodeExporter]

Sometimes I get this sort of thing in the log file. It seems like nonsense - 
how can the rip be both accurate and not accurate???

Track 07
    Pre-gap length : 00:08:02

    CRC32 hash (test run)  : 9E96AF1A
    CRC32 hash             : 973ADECE
        ->Rip may not be accurate.
    CRC32 hash (skip zero) : 40BD3EE2
    AccurateRip signature  : 85F12232
        ->Accurately ripped! (AR2, confidence 4)
    Statistics
        Read error                           : 0
        Jitter error (maybe fixed)           : 0
        Retry sector count                   : 0
        Damaged sector count                 : 0

Original issue reported on code.google.com by mattne...@gmail.com on 13 Sep 2011 at 1:34

[GoogleCodeExporter]

That means there was a problem with a test run but no problem with actual 
ripped data.

You said "sometimes" but I don't think it happens frequently. Do you really 
configure XLD correctly ? For example, using C2 pointer on unreliable drives 
will cause this kind of problem.

Original comment by tmkkmac on 13 Sep 2011 at 4:29

[GoogleCodeExporter]

I didn't say it happened frequently. But it does happen (esp with the XLD 
Secure ripper). In theory this should be impossible: the log should report 
clearly whether the rip is accurate or not.

I'm not using C2 pointers.

Original comment by mattne...@gmail.com on 13 Sep 2011 at 3:15

[GoogleCodeExporter]

The rip is accurate if you trust AccurateRip. May not be accurate if not.

Original comment by tmkkmac on 13 Sep 2011 at 3:31

[GoogleCodeExporter]

Here, it just happened again:


Track 06
    Pre-gap length : 00:04:45

    CRC32 hash (test run)  : 50D16294
    CRC32 hash             : 773D1F6A
        ->Rip may not be accurate.
    CRC32 hash (skip zero) : DB20E199
    AccurateRip signature  : EEFCE97D
        ->Accurately ripped! (AR2, confidence 2)

Part of the problem is that the way XLD writes its logs, the AccurateRip 
signature doesn't match anything (it doesn't match either has or the skip-zero 
hash), so there's no way to know *why* XLD thinks the rip was accurate. It 
would be better if XLD said "I got THIS hash and the AccurateRip database has 
THIS hash" so the user can see they are the same.

Original comment by mattne...@gmail.com on 4 Oct 2011 at 4:14

[GoogleCodeExporter]

What? XLD says "Accurately ripped" only when the database has AR signature 
value calculated in XLD. AR signature shown in the log is a calculated value, 
not a value from the database. It is completely different from CRC32.

Original comment by tmkkmac on 4 Oct 2011 at 4:21

[GoogleCodeExporter]

"AR signature shown in the log is a calculated value". Fine. Calculated when? 
There were two runs: a test run and the second run. The CRC32 hashes differ; 
surely the AccurateRip signatures differ as well. Which one worked correctly? 
And if it's the second one, why is it *always* the second one when this issue 
occurs? That seems very suspicious. What I'm saying is, the log should be 
written in terms that make it clear that XLD knows what it's doing and is 
giving correct and helpful answers that the user can have confidence in. As it 
is, I have no confidence in this track because the report seems meaningless and 
self-contradictory ("not accurate" / "accurately ripped").

Original comment by mattne...@gmail.com on 4 Oct 2011 at 5:22

[GoogleCodeExporter]

The value is always calculated from the data of the 2nd (copy) run when Test & 
Copy mode is enabled.

The first "not accurate" message means that the data from the 1st and 2nd run 
did not match.
The second "accurately ripped" message means that the actually ripped data 
(from the 2nd run) was accurately according to the AR database.
This means that the error occurred in the 1st run, but did not occurred in the 
2nd run (if you trust the AR database).

Original comment by tmkkmac on 4 Oct 2011 at 5:44