Secure-Rip can mean Rip Forever

[Mannacio69]

I am currently ripping a CD whose last four tracks would not validate as secure so I upped to the Ultra-Secure setting. But the first of the four tracks is saying it needs to Re-Rip 2954 frames ans it does them ONE AT A TIME. This 3:52 track will surely exceed the time limit I gave it of 10 minutes and abort. This seems entirely unnecessary. With the memory available in today's PCs ALL of these tracks could be stored and Re-Ripped in just ONE PASS allowing for multiple rerips with interpolation in a very short time. I have updated to the latest version of Dbpoweramp suite and value it's ability to show an accurate and a secure rip. But to take forever to get the latter is just unacceptable. Could this be changed any time soon? (The next of the four tracks needs to Re-Rip 15,716 frames! Not in my lifetime!

[GBrown]

This seems entirely unnecessary. With the memory available in today's PCs ALL of these tracks could be stored and Re-Ripped in just ONE PASS allowing for multiple rerips with interpolation in a very short time.unacceptable.

This is the whole purpose of using dbPoweramp. If there is damage to a disc, the program will do what it can to optimize the drive and speed, and reread the damaged segments to get an accurate rip. No memory or CPU can take care of this if you can't get the data from the disc in the first place.

Try cleaning the disc, hopefully that is all it needs. If there are minor scratches or blemishes you may need to try some polishing. Major damage often cannot be overcome no matter how many times you try to read the disc. And the phenomenon of "Disc Rot" is real too. Sometimes different brands of drives can have varying results as well.

After going through my library of over 800 CD's, I had about a dozen that just wouldn't rip accurately. A few trips to some used shops, and a couple ordered from Discogs was the solution in the end.

[Mannacio69]

Let me clarify for GBrown: Everyone wants the secure rip DbPoweramp provides the only question is - does it do it efficiently? When you are examining one frame at a time, and a frame is ONLY 33 bytes of data why would anyone let the disk spin while examining JUST that one frame. Why not, if there are 1000 defective frames representing 33000 bytes of data, keep all of the potentially errant frames in a table updating the table by adding additional columns with each read and ultimately deriving a corrected value for all 1000 frames with a quick mathematical algorithm applied to all the rows. This could be MUCH faster. And BTW, the discs were clean and had never been used before.

[Spoon]

>corrected value for all 1000 frames with a quick mathematical algorithm applied to all the rows.

When there is a missmatch, a 2nd pass is done, this is used intelligently to try to match, if it is showing 1000 frames needing re-ripping then they need re-ripping.