EACs Not-So-Secure Mode?, PX230A with & w/o C2 Options

[soulsearchingsun]

Hi.
I'm ripping my cd collection to wavpack compressed images at the moment, but i'm getting a problem with a particular disc. Usually, i try to rip the discs first with my LH GSA-H10N, which is pretty good in terms of speed and secure reading (at least with c2-pointers turned off). If that doesn't work (sync errors), I switch to my PX230A which used to be a good choice for secure ripping.
Now I get strange results with a scratched cd, which is not present in the AR database.

First try, T&C, with c2 pointers:

CODE

     Spitzenpegel 97.7 %
     Bereichsqualität 100.0 %
     Test CRC 12B75EF0
     Kopie CRC 12B75EF0
     Kopie OK

Second try, without c2 pointers:

CODE

     Spitzenpegel 97.7 %
     Bereichsqualität 99.9 %
     Kopie CRC 50EB7785
     Kopie OK

Third try, T&C, with c2 pointers:

CODE

     Spitzenpegel 97.7 %
     Bereichsqualität 100.0 %
     Test CRC 12B75EF0
     Kopie CRC 12B75EF0
     Kopie OK

Fourth try, without c2 pointers:

CODE

     Spitzenpegel 97.7 %
     Bereichsqualität 100.0 %
     Kopie CRC 8A51C3DE
     Kopie OK

So i got the CRC 12B75EF0 four times and two times other CRC results. Why aren't the 'secure' rips consistent, which result should be trusted? I used to believe that ripping without c2-pointers is ALWAYS 'more secure' than ripping with them. Interpreting these results, can secure ripping still be trusted? Has my drive just gone horribly bad?
(Of course, 'caching' is ticked because the PX does so. This can't be the reason)

Another thing is that i can't obviously use my own rips in AR database, right?

Any hints/suggestions?

[greynol]

Why aren't the 'secure' rips consistent, which result should be trusted?

I wouldn't trust any of them at the moment.

I used to believe that ripping without c2-pointers is ALWAYS 'more secure' than ripping with them.

Ripping without C2 pointers is NOT always more secure than ripping with them. I've seen a few instances where ripping with C2 pointers can give an accurate result when ripping without them can't.

Interpreting these results, can secure ripping still be trusted?

Secure ripping has never been a guarantee of accurate ripping.

Has my drive just gone horribly bad?

Doubtful.

Of course, 'caching' is ticked because the PX does so. This can't be the reason

I wouldn't be so sure if I were you:
http://www.digital-inn.de/133067-post36.html

Another thing is that i can't obviously use my own rips in AR database, right?

Unfortunately there really is no mechanism to keep this from happening. If you've previously submitted results for any given disc, it would be preferable to get a match with a confidence greater than 1 (assuming you haven't also submitted from a different computer or OS re-installation) because errors can be consistent. Furthermore, it is possible for errors to be consistent depending on the drive when ripping a disc with a manufacturing defect. This is rare, but such entries do exist in the AR database.

Any hints/suggestions?

Try ripping with the "Drive has 'Accurate Stream' feature" unticked. Try burst mode also. Please use T&C with all attempts to see if you get consistent results as well. This will save me from having to ask you later.

This post has been edited by greynol: Dec 31 2008, 08:07

[bhoar]

I used to believe that ripping without c2-pointers is ALWAYS 'more secure' than ripping with them.

Summary: it's almost always the opposite case when you're dealing with damaged discs and good ripping software...though there is some software out there that may be too trusting of them.

C2 pointers are just additional data that can be used by the requesting application to mark portions of a block as potentially bad and in need of retries. Unless a drive's firmware is horribly broken, turning on C2 support in an application simply means "send that data along too". It should never change drive behavior.

C2 isn't perfect, however...

1. If a drive's firmware is poorly written so that it does not report C2 errors or under reports C2 errors ("misses" actual errors it should detect), then software that trusts C2 flags too much (e.g. Plextools) could be fooled.

2. If a drive's firmware is poorly written in the other direction and over-reports C2 errors (flags errors that aren't there) or reports them on the wrong frames, then software that relies on these might be convinced to waste a lot of time rereading areas of the disc that aren't damaged.

3. And lastly, there's a very small chance an error won't be flagged by C2 through no fault of the drive firmware...it could just be the case that the physical pattern of the damage happens to also map to a correct mathematical solution for the error correcting codes.

Using C2 flags as a one type of hint to the software reread strategy can be useful on getting more secure results.

And as greynol noted, just because you reread an erroneous frame/blockr doesn't mean the error won't repeat itself exactly over and over again (with or without C2 flags)

-brendan

This post has been edited by bhoar: Dec 31 2008, 03:42

[soulsearchingsun]

Of course, 'caching' is ticked because the PX does so. This can't be the reason

I wouldn't be so sure if I were you:
http://www.digital-inn.de/133067-post36.html

Haven't tried -usefua yet. But not defeating cache on a caching drive seems to me like a dirty hack that, by chance, worked in this case.

Any hints/suggestions?

Try ripping with the "Drive has 'Accurate Stream' feature" unticked. Try burst mode also. Please use T&C with all attempts to see if you get consistent results as well. This will save me from having to ask you later.

Did that. Here are the results, as I expected them:

Secure, T&C, without Accurate Stream:

CODE

     Spitzenpegel 97.7 %
     Bereichsqualität 100.0 %
     Test CRC 1E3D8CB8
     Kopie CRC 4542F2DF
     Kopie OK

Fast, T&C:

CODE

     Spitzenpegel 97.7 %
     Test CRC C5C8E6BD
     Kopie CRC 8EFBE12B
     Kopie OK

Burst, T&C (a lot of timing problems, though):

CODE

     Spitzenpegel 97.7 %
     Test CRC 9B68870C
     Kopie CRC 5C3BCD1E
     Kopie beendet

Never twice the same CRC. Most trustworthy in terms of cosistency are the rips with c2 pointers turned on. I guess I'm gonna do the Test&Copy thing with every disc that is not present in AR from now on. I think I'm giving spoons ripper a try before giving up.

[Raiden]

In situations like these I rip in test & copy burst mode, 4x speed. If the CRCs match I trust the result.

Also, try to compare the waveforms in an audio editor by substacting them from each other, so you can see where they are different. Then check the original waveforms at those points and choose the one that looks smooth. That's usually a good indicator for good interpolation by the drive. Some drives (like my LG) interpolate by doubling the last good sample so it looks like this:

CODE

                        o
                      -
                    -
                  -
-  o    -   o   <- interpolated sample (bad)

instead of this

CODE

                     o
                  -
              o   <- interpolated sample (good)
          -
-  o

[greynol]

Haven't tried -usefua yet. But not defeating cache on a caching drive seems to me like a dirty hack that, by chance, worked in this case.

I wasn't suggesting that you try -usefua. I'm pretty certain it doesn't work with your PX-230A (which is not a real Plextor drive). As far as it being a dirty hack, I'm in no way suggesting that people go ripping discs with caching drives without flushing. This was just a matter of further diagnosing your problem and satisfying my own curiosity. That link has given me reason believe that there's something not quite right with using C2 pointers while flushing with EAC. I wanted to know if this disc of yours also exploits this vulnerability.

So what were your results with C2 pointers and no flushing? Were they the same as with C2 pointers and with flushing?

I guess I'm gonna do the Test&Copy thing with every disc that is not present in AR from now on. I think I'm giving spoons ripper a try before giving up.

Both sound like excellent ideas. I would also try this disc with a different drive. I'd also play around with the speed selection as Raiden is suggesting, but I wouldn't put all of my faith in matching CRCs in burst mode either.

1. If a drive's firmware is poorly written so that it does not report C2 errors or under reports C2 errors ("misses" actual errors it should detect), then software that trusts C2 flags too much (e.g. Plextools) could be fooled.

EAC has this problem also.

Using C2 flags as a one type of hint to the software reread strategy can be useful on getting more secure results.

This is another downside with EAC. C2 pointers are exclusively relied upon to detect errors in order to perform re-reads, yet when performing re-reads it no longer uses them.

In this particular situation, however, it looks like the drive is not telling EAC that there were any errors, and according to Spoon, C2 pointers are highly reliable with this drive.

This post has been edited by greynol: Dec 31 2008, 20:00

[soulsearchingsun]

I'm pretty certain it doesn't work with your PX-230A

Yeah, thats right.

So what were your results with C2 pointers and no flushing? Were they the same as with C2 pointers and with flushing?

Here they come, yet another pair of unique CRCs

CODE

     Spitzenpegel 97.7 %
     Bereichsqualität 99.9 %
     Test CRC E714BE5A
     Kopie CRC E4E77E13
     Kopie OK

What I'm a bit surprised about is the fact that all that 'offline' secure ripping is about consistency. If eac consistently reads a sector x times, it is considered secure. But ripping twice, I'm getting different results where each one is consistent with itself. Thats a bit weird, is it? It looks almost like reripping introduces errors that were not there before. If you look a the two different results without c2 pointers, I'd like to think eac simply doesn't flush the cache (which is improbable).

In this particular situation, however, it looks like the drive is not telling EAC that there were any errors, and according to Spoon, C2 pointers are highly reliable with this drive.

Lets believe in this reliability for a moment: in fact, I'm playing already around with the speed selection by chosing wheter eac should exploit c2 pointers or not. This, and that being the only CRC I'm getting more than a single time I'm pretty convinced that these are the 'securest' rips. There simply are no read errors because of the fast ripping speed. Sounds conflicting, but as with burning, maybe slower not always gives higher quality.

[greynol]

But ripping twice, I'm getting different results where each one is consistent with itself. Thats a bit weird, is it?

I'm not sure what you mean by "consistent with itself". In the case of C2 pointers and no flushing, it's almost like ripping in burst mode. The only thing read twice is two sectors for every 2MB of data for synchronization purposes, and in the case with a caching drive and no flushing, these two sectors are not really being read twice. What surprises me is that the track quality is different: there was a set of re-reads with C2, no flush whereas no re-reads with C2, flush. Were they just at the very end of the track?

If you look a the two different results without c2 pointers, I'd like to think eac simply doesn't flush the cache (which is improbable).

Unless the drive is caching more than 2MB, though I've not seen this reported with the PX-230A.

Sounds conflicting, but as with burning, maybe slower not always gives higher quality.

This is absolutely correct. Some drives are more accurate when ripping at higher speeds.

Try a different drive.

[bhoar]

Lets believe in this reliability for a moment: in fact, I'm playing already around with the speed selection by chosing wheter eac should exploit c2 pointers or not.

Minor correction here, probably with very little impact on the discussion, but nonetheless...

You're "playing around with" the extraction time, not the speed selection.

The speed selection is essentially a user settable (maximum) speed the disc should be spun at. Turning on C2 should have no impact on that.

Some drives will lock to this speed setting, while others take the value as the maximum speed allowed and will sometimes/often automatically adjust their speed up and down below that threshold for unbalanced, damaged or badly pressed discs.

-brendan