Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: EAC ripping problem -- extremely slow (Read 14350 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

EAC ripping problem -- extremely slow

Reply #25
Any chance it was a copy-protected CD?

It was an MFSL SACD Ultradisc UHR from 2005.

The rest of the tracks gave EAC no troubles (re-reads weren't necessary).

EAC ripping problem -- extremely slow

Reply #26
I saw you added more information to the post that I answered so I thought I'd address more of it here. 

Quote
(unless the drive didn't just badly support C2 but didn't support it AT ALL; should that be the case then the matching CRCs may be explained in terms of consistent errors in both tracks)
Again this wasn't my rip and I do not own this drive but I think it's fair to assume that EAC detected C2 for the drive.  When I check C2 with drives that don't support it I immediately get an error, though this doesn't mean that it will hold true for all drives that don't report C2.

Quote
There is one thing I don't understand though (and which you might be able to shed light on):
...
I don't know what to think of track 3 (suspicious position yet "copy OK")
This is what tipped me off that something peculiar was going on.  It is also why I suggested to pay attention to a suspicious position where no re-reads occur though I am not sure that re-reads didn't actually occur where the suspicious position was.  I should ammend my statement to a suspicious position coupled with "Copy OK"

Quote
(I ask this question because it could be relevant for figuring out whether or not C2 + T&C should indeed be considered unsafe).
This could simply be the case of a very poor implementation of C2 (at least as far as using it with EAC is concerned).  I do not believe that this was the case of a consistent error, rather I believe the drive repeated a sample in place of those it could not read as a pathetic means of error correction.  The rest of the data (before and after the repeated sample) was fine.  I no longer have the files though I wish I had kept them.

I've seen a similar result using EAC's Paranoid mode with my Sony 52X drive: repeated samples in place of data it seemingly could not read.  The drive does not do this in the regular Secure mode with or without C2.

Whatever is going on, I don't consider C2 + T&C as safe for all drives.  This experience has shown me otherwise.  However, I still use C2 + T&C with my Plextor and Sony drives.

EAC ripping problem -- extremely slow

Reply #27
I saw you added more information to the post that I answered so I thought I'd address more of it here. 
I hadn't noticed your reply at all, and hence felt so free to edit. My apologies.

Quote
Quote
There is one thing I don't understand though (and which you might be able to shed light on) [...] I don't know what to think of track 3 (suspicious position yet "copy OK")
This is what tipped me off that something peculiar was going on.  It is also why I suggested to pay attention to a suspicious position where no re-reads occur though I am not sure that re-reads didn't actually occur where the suspicious position was.  I should ammend my statement to a suspicious position coupled with "Copy OK"
My problem is that I don't know how "suspicious position" and "Copy OK" can occur together. Any idea what triggers EAC to write "suspicious position" (EDIT: in secure, not burst, mode), except for read/sync errors?

Quote
Quote
(I ask this question because it could be relevant for figuring out whether or not C2 + T&C should indeed be considered unsafe).
This could simply be the case of a very poor implementation of C2 (at least as far as using it with EAC is concerned).  I do not believe that this was the case of a consistent error, rather I believe the drive repeated a sample in place of those it could not read as a pathetic means of error correction.  The rest of the data (before and after the repeated sample) was fine.  I no longer have the files though I wish I had kept them.
Np, it sounds credible. However when I said "consistent error" I was in fact referring to the drive's output (i.e. after its built-in error correction), which may contain errors that are consistent across multiple reads (and it seems credible that may be what has happened with track 3).

Quote
I've seen a similar result using EAC's Paranoid mode with my Sony 52X drive: repeated samples in place of data it seemingly could not read.  The drive does not do this in the regular Secure mode with or without C2.
BTW - this reminds me of one of my ex-drives: it couldn't overread, and when overreading was forced thru EAC the extracted audio would miss its few last samples and had 2 extra seconds of silence appended.

Quote
Quote
(unless the drive didn't just badly support C2 but didn't support it AT ALL; should that be the case then the matching CRCs may be explained in terms of consistent errors in both tracks)
Again this wasn't my rip and I do not own this drive but I think it's fair to assume that EAC detected C2 for the drive.  When I check C2 with drives that don't support it I immediately get an error, though this doesn't mean that it will hold true for all drives that don't report C2.

(I assumed the opposite, but it's pure speculation as well.)

Good news: according to Feurio's database, the drive in question does not support C2. Seems like my wishful thinking has come true.  This means that consistent errors may account for the matching CRCs (it's not uncommon that several tracks on the same CD suffer from consistent errors) and C2 + T&C might be ok after all (though it's a bit early to conclude, as long as I don't understand the "suspicous position" thing).

EAC ripping problem -- extremely slow

Reply #28
Quote
Good news: according to Feurio's database, the drive in question does not support C2. Seems like my wishful thinking has come true.  This means that consistent errors may account for the matching CRCs (it's not uncommon that several tracks on the same CD suffer from consistent errors). The thesis that C2 + T&C would be unsafe, would mean there is something seriously wrong with our understanding of DAE (insufficient proof in this case imho, though we should keep our eyes wide open).
Not so fast!

Remember, EAC was used to extract the data, not Feurio.  Is it possible that EAC said the drive was capable of providing C2 error information?  Also, the thesis here is that C2 + T&C is not safe for all drives when using EAC.  I still don't believe it is.

We already know that C2 without T&C is not safe for all drives.  Now the question is whether a drive is capable of spitting out a consistent error without re-reads being performed based on EAC's interpretation of the C2 information provided by the drive and whether the same consistent error would have been made had EAC been given the opportunity to read the data at least twice.

Quote
My problem is that I don't know how "suspicious position" and "Copy OK" can occur together. Any idea what triggers EAC to write "suspicious position" (EDIT: in secure, not burst, mode), except for read/sync errors?
I haven't a clue.

Quote
However when I said "consistent error" I was in fact referring to the drive's output (i.e. after its built-in error correction), which may contain errors that are consistent across multiple reads (and it seems credible that may be what has happened with track 3).
Gotcha!

Quote
I've seen a similar result using EAC's Paranoid mode with my Sony 52X drive: repeated samples in place of data it seemingly could not read.  The drive does not do this in the regular Secure mode with or without C2.
Quote
That reminds me of one of my ex-drives: it couldn't overread, and when overreading was forced thru EAC the extracted audio would miss its few last samples and had 2 extra seconds of silence appended.
This was in the middle of a track where EAC had the drive perform re-reads using Paranoid mode.  I have never seen this drive repeat a sample when giving erroneous data in any other mode.