Mark Track Error if Insecure

[bhoar]

Spoon,

A suggestion for a change of behavior with the "Mark Track Error if Insecure" feature. I wanted to use the Insecure=Track Error flag as a trigger for Rejects in the batch ripper, but the current behavior turned out to make it less than usable.

Currently, if this feature is enabled the following scenario can occur:

--
Secure/Ultrasecure ripping is enabled (with no set "stop when..." thresholds) and 1000+ frames are detected as problematic (either due to C2 error flags or different values on separate passes). The cd ripper then spends a couple of hours reading and rereading the problem frames. Finally after the last frame is reread...the track is marked as error and the audio data is not saved.
--

This seems to me to be non-optimal. I believe there either one of these behaviors would be better (in order of preference):

1. Exactly as above, but track audio should be saved even though that track is marked as Error.

2. As soon as the first separate frame reread fails to find a "secure" match after reading the max rereads count, the rereads should stop, the audio data not saved and the track should be marked as error. At this point, it is known that the track will be insecure...so why bother going past this point if the audio data is going to be thrown out anyway?

The effect of number 2 can be triggered by making adjustments to the unrecoverable frames setting. So, I think #1 is best.

Thoughts?

-brendan

[Spoon]

Re: Mark Track Error if Insecure

Do you use R13.1? the audio should be saved (I would have to check) in that even on error, as long as not overwriting.

[bhoar]

Re: Mark Track Error if Insecure

Do you use R13.1? the audio should be saved (I would have to check) in that even on error, as long as not overwriting.

Yes, 13.1. It may have been overwriting older files, but when Error was returned after 1000+ frame rereads, the final file there was a truncated file (~20k or so).

-brendan