redump.info Forum

Setting drive speed is also easy to do with OptiDriveControl, I've used it for over a decade to set the speed with other tools that don't support it like IsoBuster.

It would indeed be nice if the tool had an option to do so.

I would like the iterative process to be automated as well, this shouldn't be too hard to accomplish by merging good sectors after dump, then running EccEdc and getting a new range, cleaning up a temp folder, and repeating with the new range until all are dumped or a threshold reached.

I think it may also help to perform seeks between re-read attempts after a re-read threshold is reached, I have used this method to dump problem sectors with ISOBuster by seeking sector 150 or some sector near the end of the disc and retrying.

Is it possible to defeat/dump the cache ala EAC? Perhaps this would also help.

OK so I bought 7290H5 to dump laserlock discs with it. The disc in question is this one https://redump.info/disc/12951/ , which when I originally dumped had too many errors and got marked red. Well I've been trying to dump this disc all day now with marginal success. I got the best dump using clone CD which took several hours and resulted in a dump with 972 errors instead of 1440 previous plextor dump or more than 10000 as with DIC.

I ended up finding the patent for laserlock and seeing how it works, and according to the patent document there are sections with extended "lands" on each side of the readable area between them, this is the "ring" you see. There are 5 "zones" on the discs, there is the 2 normal zones "1 and 2" which are the start and end of the discs. Then 2 more zones "2 and 3" which are these areas of extended "lands" and finally the protected zone "4" which is between the 2 and 3 zones. The protection check routine is supposed to use an angle to move the head or calculate the "good" area of the disc to be read, and this seems to hold true given my findings.

The interesting bit is the errors seem to follow a distinct pattern of a range of "bad" sectors which cannot be read, 1 sector which has no ECC/EDC data in it, and then a block of good sectors, and then rinse and repeat with the larger "good" zone between.

Now I have tried this tool with no positive results in recovering the "bad" sectors at all, not with 10 re-reads, 50 or even 1000. It fails always which leads me to believe that these sectors are indeed extended "lands" and are not readable by any means on any drive. I will attach the EccEdc check log of the dump which more clearly represents what I meant by the pattern, which is very obvious.

New discovery! Plextor 716A at 4x read speed was suddenly able to easily read the "difficult" LaserLock sectors for both me and Nexy.

Yep can confirm. Wasted money buying an Optiarc for that, but at least it can do the initial dump faster than the plextor can.

Good to know, i'll try to dump my laserlock games with my PX-716SA when i'll be back home next month.

Updated version of application in attachment.

Usage:
CDArchive --mode=<mode> <additional params specific for mode>

Mode you are interested in is: 'ext'

Example: CDArchive.exe --mode=ext --extrdrive=F --extrsectdir=PathToWhereToDumpSectors --extrstart=1000 --extrend=2000 --exttrefcue=PathToCue

Other parameters are default. Feel free to change them.

This version supports handling DVDs with rings with --extrdiscmode=dvd. If you want to do this craft this cue:

FILE "FILE.ISO" BINARY
  TRACK 01 MODE3/2048
    INDEX 01 00:00:00

Let me know how it works

Updated version of application in attachment.

Fixed: various bugs

More debug output

More debug output #2

Guys, I have just seen ringed discs dumping guide and one small step is missing:
- it's necessary to use eccedc with parameter -fixex at the end of dumping process. This is needed because cdmage has a bug. If you attempt to repair all the sectors in an image, the sectors which are already filled with 0x55 pattern, they will be erroneously damaged by filling reserved field with 0x00 value (8 bytes IIRC). EccEcc with fixex command restores full 2352 bytes with 0x55 value. It's not a critical bug (images can be repaired at any time, but it's better to have it correct in first place).