sarami wrote:
D:\!redump\reentranttools\CDArchive.exe -x g -d "D:\!redump" -e 52767 73504 10 3 10 fb D:\!redump\reentranttools\test.bin

"D:\!redump\reentranttools\test.bin" needs to point to the bin file that was dumped before where the ring sector was skipped and replaced with 0x55. CDArchive.exe will try to extract all 0x55 sectors from the CD.

reentrant, would it be possible to specify drive speed in CDArchive? I'm missing 6 sectors right now and although my drive can extract them first try, they don't match EccEdc. Maybe they would if it was reading them at a slower speed?

reentrant wrote:

231096 - 230946 = 150 = 2sec = pregap. Try to lower it by few hundred sectors. DIC dump is bugged if error range crosses tracks & pregap area...

Ohh, I didn't know about that. Thanks!

Jackal said above that you can cut out a track from the .img with a hex editor, do you know how that works?

reentrant wrote:

What are the values of parameters:  /frs and /fre? Only sectors inside range should be bad. Try smaller range (maybe it cannot cross tracks, dunno).

I uploaded new CDArchive that accepts cue path as argument for -m (merge mode). Sectors are merged to correct track file now.

I used

DiscImageCreator.exe cd G ISO\S3MCD_G.bin 20 /c2 /frs 223000 /fre 231000

to dump. Second track starts at 231096. Thanks for the update!

reentrant wrote:

Run EdcEcc with fixex command. It will replace them with 0x55 and retry...
I have OptiArc 7290.

LBA[230940, 0x3861c], mode 1
LBA[230941, 0x3861d], mode 1
LBA[230942, 0x3861e], mode 1
LBA[230943, 0x3861f], mode 1
LBA[230944, 0x38620], mode 1
LBA[230945, 0x38621], mode 1
LBA[230946, 0x38622], This sector has invalid sync
LBA[230947, 0x38623], This sector has zero sync
LBA[230948, 0x38624], This sector has zero sync
LBA[230949, 0x38625], This sector has zero sync
LBA[230950, 0x38626], This sector has zero sync
LBA[230951, 0x38627], This sector has zero sync
LBA[230952, 0x38628], This sector has zero sync
LBA[230953, 0x38629], This sector has zero sync
LBA[230954, 0x3862a], This sector has zero sync
LBA[230955, 0x3862b], This sector has zero sync
LBA[230956, 0x3862c], This sector has zero sync

Why those sectors are bad? I think EdcEcc will fix also this:
LBA[230946, 0x38622], This sector has invalid sync

I can introduce another command fixex2 which would fix sectors in specific range...


Hey thanks, that helped! Time to reextract those sectors...

I don't really know why those sectors are bad. It happened when I dumped it with /frs and /fre.
Every sector after that range has bad sync. You can see it in the original _EdcEcc.txt

Maybe I blanked it too close to the second track?

I've run into a problem hmm

I'm dumping this disc right now using the method described above.
As you can see from this image, on the outside of the ring, there are some strange spikes that are very hard to read for my Optiarc AD-7280S, even with 50 retries in both directions. I also tried a Plextor 760A drive and an LG.

After letting CDArchive run multiple times, most of the 0x55 sectors outside of the ring have now been extracted and replaced, but many of them now don't match the ecc/edc. I attached my log file so you can check it out.


What do I do now? CDArchive does not extract these sectors again, because they are not 0x55.

7

(1 replies, posted in General discussion)

Hi, I'm all for it!

A few pages are already on the Wiki, you can find them here: http://wiki.redump.org/index.php?title=IBM_PC
But obviously, it would be great to have some reliable info on the other forms of protection out there.

reentrant wrote:

It would be easier if I implement in CDArchive cue file support so that sectors are merged in the right track.
I can do it over weekend...

That would probably make things easier.

I'm actually using this method now for a Ring ProTech disc, and some of the sectors that CDArchive extracts return

User data vs. ecc/edc doesn't match

after merging with the .bin and then checking them with EccEdc.exe.
The problem is now that CDArchive doesn't extract those sectors again. Can EccEdc.exe overwrite them as 0x55?

user7 wrote:

This should go into a guide eventually, if it's not something DIC can implement? sarami?

I guess the problem is that Plextor drives are not suitable for this kind of protection.

Jackal wrote:

Ok so the errors are in the last track?

You need to get a DIC dump with separate .bin tracks when you're going to submit the dump later.
For CDArchive you need to use the combined image (= .img file).. Then after you extracted all the sectors with CDArchive, you add them to the .img image, and you'll need to cut out the last track using a hex editor.

Hey, thanks! I see what you're saying. I actually did extract the sectors from the .img file, and then merged them again, like reentrant said.
But the next step, where I have to check for errors with EccEdc.exe, I can't do that. The fixex parameter needs the .cue file, and that means it tries to check for errors in the datatrack.bin only, not the .img.
Using the _img.cue doesn't work.

Jackal wrote:
_Maki wrote:

[Removed my idiotic first tries]

Two questions. How does this work with multitrack CDs? I have the error range, which goes from 329000 to 336200, but of course, with multiple BINs, this information is useless. I need the range based on which bin tracks are affected, and their range.

Secondly, for testing, I used a small range like 2000 to 3000 on the first BIN, and CDArchive did its thing, but at the end, the SECT folder was empty. Did I do something wrong?

Are you sure your disc is Ring Protech?

And why are you trying sectors 900-2100 with CDArchive if you say the error range is 329000 to 336200?

That was just for tests. I was hoping to use this method for another disc, where the Plextor drive couldn't read part of it, but Optiarc can. But this disc has multiple tracks, so I can't just tell CDArchive to go look at 329000 to 336200 when none of the *.bin files is that long by itself. So I chose a sector near the beginning to see if it would work, and it did, but no Sector files were dumped.

Also, the bad sectors are on the audio part of the disc, so even if I managed to extract the correct range and merge them into the *.bins, EccEdc can't check them, because they are not Mode1 data sectors.

I hope I'm not being too confusing or annoying in general, just trying a few things here...
Unless someone has some ideas, I'll probably just search for a disc in better condition to properly dump it with DIC.

[Removed my idiotic first tries]

Two questions. How does this work with multitrack CDs? I have the error range, which goes from 329000 to 336200, but of course, with multiple BINs, this information is useless. I need the range based on which bin tracks are affected, and their range.

Secondly, for testing, I used a small range like 2000 to 3000 on the first BIN, and CDArchive did its thing, but at the end, the SECT folder was empty. Did I do something wrong?

Thank you so much! I'll do my best to follow these instructions until I get the hang of it. This is gonna be fun! (Seriously, I'm excited.)

Hello everyone,

I'm currently trying to dump a few of my favorite games that are protected by those pesky rings of unread sectors in the disc. I've read up on the general way to go about it, but I do lack the tools and basically instructions to use them. I already own a Plextor drive and an Optiarc, and I'm ready to put the effort into it. But I would obviously appreciate your help. smile