Page 1 of 1
Secure ripping performance
Posted: Mon Jul 24, 2006 4:44 am
I have implemented a prototype secure ripper to see how feasible the implementation would be, from a performance perspective. The ripper only does the following:
- Clears/flushes the drive's cache (2 MB on my test run)
- Reads one sector
- Writes the sector to the output file
As I feared, the performance is abominable. For a track of length 3:56, the estimated time remaining after things got stabilized was over 540 minutes. This is crazy! If I eliminate the cache flushing I was able to rip the same track (reading sector by sector but with no cache flushing) in 2:29. So until I find a reasonable way to set the FUA bit on reads, the secure ripper is probably a no-go.
Has anyone here done any programming using STUC? I think this might be the only way to get access to the MMC commands.
Posted: Mon Jul 24, 2006 8:35 am
Wow! That is a major
Then there must be a simpler and faster way to circumvent the driver cache. But getting there might be hard, since there are so limited documentation and knowledge about it.
Stephen. Have you been in contact with Andre Wiethoff (the EAC developer), to hear if he is willing to share some of his knowledge? http://www.exactaudiocopy.de/eac8.html
Posted: Mon Jul 24, 2006 2:50 pm
Well those figures are ... What was your earlier word, Stephen? Asinine? Yup - right in line with your supposition. I am sorry I asked for the test.
If I may, I would like to echo krmathis. I think you are SO close. As there is no conflict of interest, and perhaps even for the *common* interest, Wiethoff might prove a good move.
Posted: Thu Jul 27, 2006 4:37 am
After some investigation and re-reading of previous e-mails, it seems the only way I can accomplish what I want to do (disable the drive's cache on read) is by sending raw SCSI command descriptor blocks to the drive. Luckily, I only need to send one command (READ 10 or READ 12). Unluckily I've never done any programming like this before.
So, I am in the prototyping phase while I figure out how this may work. Anyone who has experience doing SCSI programming or IOKit programming who could help would be appreciated!
Posted: Thu Jul 27, 2006 1:16 pm
Well, here's my contribution:
Seriously, if I may be allowed to speak for all, thank you.