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):

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 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:

  1. What's the longest you've ever allowed dBpoweramp to run and seen it ultimately succeed at ripping a bad track?
  2. 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)
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:

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.
After killing my own rip, the log file said this about the track that was taking forever to rip:

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
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.