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
