I have a CD whose last track takes 5.5 hours to rip in EAC (secure mode, C2 enabled) and produces a .wav file with the last 0:35 of the song replaced with silence. All other tracks are reported good per EAC's AccurateRip report.
I then started a dBpoweramp rip on the same CD using the following settings (more or less taken from this page https://www.dbpoweramp.com/secure-ripper.htm under "The Test" section; I used a lower number of maximum re-reads):
I watched dBpoweramp quickly progress through the tracks that had been AccurateRip-verified by EAC; when dBpoweramp reached Track 14, it got stuck at about 95% and the drive started making the "churning" noises characteristic of re-reads.
I returned 12 hours later to find that dBpoweramp was still trying to rip Track 14 and was still stuck at 95%. Figuring if it hadn't ripped it by this point it probably never would, I killed the operation.
My questions are:
I was reading through the link above and noticed than from among all of the test results, the longest rip time was 107:12 (and even then it looks like it didn't complete successfully):
There were two tracks that the link above claims could not be ripped using dBpoweramp and a specific drive (NEC - 2510A), but does not say whether the rip immediately failed, was allowed to run for a period of time before being killed, or failed in some other manner:
After killing my own rip, the log file said this about the track that was taking forever to rip:
I don't see any mention of the number of bad sectors; where is that reported? I don't think the rip has to complete in order for that information to be available based on the "10,000 frames" note from the link above.
I then started a dBpoweramp rip on the same CD using the following settings (more or less taken from this page https://www.dbpoweramp.com/secure-ripper.htm under "The Test" section; I used a lower number of maximum re-reads):
Code:
Pass 1: AccurateRip Verified Pass 2: Limit Drive Speed (Maximum) Ultra Secure - Enable Ultra Secure Ripping - Minimum Ultra Passes: 6 - Maximum Ultra Passes: 10 - End After Clean Passes: 2 - Maximum Re-Reads 34 times No other options checked.
I returned 12 hours later to find that dBpoweramp was still trying to rip Track 14 and was still stuck at 95%. Figuring if it hadn't ripped it by this point it probably never would, I killed the operation.
My questions are:
- What's the longest you've ever allowed dBpoweramp to run and seen it ultimately succeed at ripping a bad track?
- Is there a certain number of bad sectors beyond which you're pretty much guaranteed to not get a successful rip?
I was reading through the link above and noticed than from among all of the test results, the longest rip time was 107:12 (and even then it looks like it didn't complete successfully):
Track 3: Ripped in 107:12 Track Quality 95% (read error + sync error) Accurate Rip: Not Accurate (confidence 19)
This drive supports C2 and does not cache. Track 3 + 7 could not be ripped (10,000 bad frames per track), so will be excluded.
Code:
Information ripping to FLAC, 'Track 14' to 'C:\Users\hudson4351\Music\Metallica\Hardwired...To Self-Destruct (Deluxe)\14 Metallica - Hardwired.flac' Track 14: ERROR Ripping LBA 342653 to 358409 (3:30) in 12:12:52. Filename: C:\Users\hudson4351\Music\Metallica\Hardwired...To Self-Destruct (Deluxe)\14 Metallica - Hardwired.flac Audio File Passed Verification