Better ripping without C2 ???

[johannesbb]

I want to rip all my CDs and therefore I started to use dBpoweramp Reference R13 together with a new SATA drive Lite-On iHAS324. I chose this drive, because it supports AccurateRip and C2 pointers and uses no cache (as far as I know).

I use the following settings:
- Ripping method: secure
- Ultra Secure: yes, Enable Ultra Secure Ripping (1,2,1 min/max/end)
- yes, Interpolate Unrecoverable Frames
- yes, Mark Track as Error if Insecure
- Drive Read Cache: (none)
- FUA: no
- yes, C2 Error Pointers for Error Detection
- yes, Query Ripping Results with AccurateRip

Now the rip results are sometimes confusing. For example, yesterday I ripped one CD and got the following results:

Accurate(11)
Accurate(11)
Red cross, red AR(11), Secure
Accurate(11)
Accurate(11)

Ripping the third track again:

Accurate(11)
Accurate(11)
Red cross, red AR(11), Secure , but the CRC number is red
Accurate(11)
Accurate(11)

Now I decided to change the settings to "No C2 Error Pointers for Error Detection". Again ripping the third track, but without C2:

Accurate(11)
Accurate(11)
Accurate(11)
Accurate(11)
Accurate(11)

Nevertheless I am not happy, because now I suspect that something is wrong with the drive or the settings. Should I change the settings of Ultra secure to 2,6,2 min/max/end? Is it only bad luck? Should I forget about it, because "secure" is good enough? Is there some kind of built-in interpolation inside the drive, resulting in three different results? Perhaps the Lite-On drive uses bad C2 implementation? Should I buy another drive to get consistent results? Any SATA drives recommendations?

Any help would be appreciated.

[t10]

Re: Better ripping without C2 ???

Dear Johannsebb,

I have similar problem with you. By the way, how much time for you to rip one CD, I took about 10 mins which setup is similar to yours.

If I take C2 option, it appeared as "inaccurate", but "accurate" if I abondand this option.

It made me confused......

[Spoon]

Re: Better ripping without C2 ???

Some drives have bad c2 implementation, in that if a track rips in burst with no errors, and then with c2 and it finds errors (try the rip multiple times), then the c2 implementation is flawed and should not be used.

[johannesbb]

Re: Better ripping without C2 ???

Thank you very much for your answers.

In my case I did NOT use burst mode, I used Ultra secure in each attempt and changed only C2 yes to C2 no. The C2 did NOT find any error, but it said one track is not accurate but SECURE. Three attempts gave three different CRCs. That is so confusing.

Next time I try to rip several times Ultra secure.

[bhoar]

Re: Better ripping without C2 ???

In my case I did NOT use burst mode, I used Ultra secure in each attempt and changed only C2 yes to C2 no. The C2 did NOT find any error, but it said one track is not accurate but SECURE. Three attempts gave three different CRCs. That is so confusing.

Next time I try to rip several times Ultra secure.

An intriguing idea for spoon: if a disc is found in accuraterip, perhaps there could be an option such that the first pass would *always* be a rip without C2 enabled, even if C2 flags are used in later passes. It would allow for a better chance at the cross-check step to match accuraterip with firmware-limited drives, right? And perhaps for non-accuraterip-listed discs, the same option would make the second pass be non-C2?

In response to the post...

How C2 is supposed to work assuming a reliable read chain: enabling C2 simply adds additional info to the data packets returned by the drive indicating that it either suspects the audio subframe data is good or suspects the audio subframe data is bad. The flags don't guarantee the data is good or bad, though in 99.9...% of the time the flags are probably correct. Note that it does not cause the drive itself to change how the frame is read, nor should it have any impact on the audio data returned.

Bad drive firmware may somehow screw this up. How can this be? Well, firmware is software and software can have usage-specific bugs.

e.g. side-effects of enabling C2 is that the data output from the drive changes from ...datafromframe(n)+datafromframe(n+1)+datafromfra me(n+2)...
to ...datafromframe(n)+c2flagsfromframe(n)+datafromfr ame(n+1)+c2flagsfromframe(n+1)+datafromframe(n+2)+ c2flagsfromframe(n+2)...

This means several things:

1. The data returned is aligned differently.
2. The data returned is larger.
3. Different code routines are used in the drive firmware to create the output data.

It's quite possible that in some corner cases, a drive with poorly written firmware might fail to package or align data correctly when C2 is enabled...essentially it is corrupting the audio data due to dropped, swapped or inserted bytes in the data stream.

The drive company might have done very intensive testing of audio extraction with C2 disabled, but perhaps did not do so with C2 enabled. Or perhaps they did, but the C2-related bug only shows up with certain access patterns (e.g. frame/block alignment is rather unusual with C2 enabled vs. most storage I/O transactions).

That's my gut feeling for what's going on with drives that behave like this. For these drives, it's probably best to disable C2.

However, even with drives that don't corrupt the output data buffers this way (creating false positives when detecting errors or even corrupting audio data only when C2 is enabled), the C2 flags should be used as a hint...and that is what spoon does with his hybrid approach of secure ripping with accuraterip lookups.

-brendan

[Spoon]

Re: Better ripping without C2 ???

C2 either has to work or it does not, if it does not then hiding behind an accuraterip verification would only make spotting when it does not work impossible.

[bhoar]

Re: Better ripping without C2 ???

C2 either has to work or it does not, if it does not then hiding behind an accuraterip verification would only make spotting when it does not work impossible.

But using C2 is more complex than that, though, isn't it? If you get a chance, think again about the results of the approach in my first paragraph above.

Plus, some read-chain implementations are *better* in some drives than others, even aside from poorly constructed firmware that actually introduces problems with C2 enabled: the same scratch might cause one drive to garble three subframes vs. another drive garbling only one; same with reporting the c2 error flags (and not necessarily in the 1:1 ratio one would expect). Some drives just do damaged disc reading better than others...same with c2 flagging.

My point is that you've already got a system that works around the unreliability of secure ripping by using your hybrid of secure ripping techniques tempered with with accuraterip lookups. It wouldn't be outside of that approach to work around bad c2 implementations that lead to failures on 1 out of 10 tracks when you can. You could still note in the rip log that the drive appears to be giving bad data when c2 is enabled, and perhaps this would be useful to mark certain drive/firmware combos as unreliable drives for c2 in AR2.

-brendan