Difference between "unrecoverable" and "insecure"?

[pjc2]

I turned on aborting after 1 unrecoverable frame, and now I'm getting some puzzling results:

In one instance, it produced an accurate rip after re-ripping 4 frames, the third of which said:

Re-rip Frame: xxxxxx (00:yy:zz.abc). Insecure (c2 dropped 25) [c2 best match]

But the manual says that the "After Unrecoverable Frames...aborts ripping if the track is insecure."

On a few different discs, I had tracks abort after the first attempted rerip with the following message:

** Reached Maximum 1 Unrecoverable Frames For This Track
Re-rip Frame: xxxxxx (00:yy:zz.abc)

Why the difference? Is this because it was the first re-rip (rather than the third) that was insecure?

Or does the C2-best-match mean that it's considered "recoverable"? (I think when "c2 best match" doesn't appear, it means that C2 dropped all 34 attempted reads. Conversely, I think the "c2 best match" in the first example above indicates that 9 of the reads weren't dropped by C2 -- and were presumably identical.)

[pjc2]

Re: Difference between "unrecoverable" and "insecure"?

Since I didn't get a response, I fiddled with the settings, and I think I've found the answer:

Re-rip Frame: xxxxxx (00:yy:zz.abc). Insecure (c2 dropped 25) [c2 best match]

This is indeed considered recoverable, since out of the 34 attempted rereads, 9 weren't dropped by C2, and most (all?) of those matched. So while it's not "secure" since it doesn't meet the 10-matched threshold, it's still recoverable.

By increasing the maximum number of unrecoverable frames to 2, I was able to see what dBpoweramp considers "unrecoverable":

** Reached Maximum 2 Unrecoverable Frames For This Track
Re-rip Frame: xxxxxx (00:yy:zz.abc). Insecure (c2 dropped 34)
Re-rip Frame: xxxxxx (00:yy:zz.abc)

In this case, all 34 read attempts were thrown out by C2 error detection, so there wasn't any read that was considered valid. Hence the frame is considered unrecoverable.

[Spoon]

Re: Difference between "unrecoverable" and "insecure"?

>9 weren't dropped by C2, and most (all?) of those matched. So while it's not "secure" since it doesn't meet the 10-matched threshold, it's still recoverable.

Correct, this is where the ripper would trust the c2 pointers, it could be wrong though, but unlikely that a consistent error would repeat 9 times and have c2 verification also.