How do I configure DBPA for hard to rip CDs?

[Transporter]

I have run the two tests on my current drive. It passed both and said they were available as an option. So I have both "Clear Read Cache w/ FUA" and "C2 Error Pointers for Error Detection" enabled. My drive passed the accurrip test and has an offset assigned.

How should I configure DBPA for the most successful ripping?

I have a few CDs that get full blown errors and the tracks don't rip, not even to insecure. Thoughts/Suggestions?

[Spoon]

Re: How do I configure DBPA for hard to rip CDs?

What are your drives?

[Transporter]

Re: How do I configure DBPA for hard to rip CDs?

What are your drives?

Current drives are HP dvd 840 and Plextor PX-W4012TA

Can you recommend the best drives?
Best internal EIDE
Best internal SATA
Best USB
Best evternal SATA

[Spoon]

Re: How do I configure DBPA for hard to rip CDs?

The HP for sure will not have the FUA cache disable. Perhaps even the Plextor you have (it is old).

[Transporter]

Re: How do I configure DBPA for hard to rip CDs?

The HP for sure will not have the FUA cache disable. Perhaps even the Plextor you have (it is old).

I did the test inside of DBPA and it said it passed the FUA and checked the box. Is it possible to pass and not reallt be able to disable the cache?

[Spoon]

Re: How do I configure DBPA for hard to rip CDs?

Yes

[Porcus]

Re: How do I configure DBPA for hard to rip CDs?

I have a few CDs that get full blown errors and the tracks don't rip, not even to insecure. Thoughts/Suggestions?

First: If they are "defective by design" -- those pesky copy-protected quasi-CDs -- then you must expect errors if you are not using the DbD mode (or maybe Burst).

If the CD is too badly scratched, then if all else fails, try Burst -- or even the DbD mode there too.

The thing about "secure" ripping with error pointers, is that it will dig deeper into the matter to (i) detect and (ii) correct errors. Now the downside is that (i) might discover errors which are truly unrecoverable, but which dBpoweramp would not notice in a burst rip. Hence *if* there are unrecoverable errors -- in which case a "secure" rip is indeed out of the question -- then burst *may* be a better choice, simply because it won't try to achieve the impossible and you might be better off with an incorrect rip interpolated, than with an error resulting in no file.


To wishlist: an option to "fallback to Bursting over unrecoverable errors".