Redump Forum

I am trying to use DiscImageCreator to dump the high density area of a retail GD-ROM disc, but I am not having any success.
According to the wiki, it is supported. I have followed the steps for Method 3. I was able to successfully dump it with dcdumper, but would like to dump it DiscImageCreator. My drive is a TSSTcorp SH-D162C aka TS-H352C with Kreon firmware.

bikerspade wrote:I am trying to use DiscImageCreator to dump the high density area of a retail GD-ROM disc, but I am not having any success.
According to the wiki, it is supported. I have followed the steps for Method 3. I was able to successfully dump it with dcdumper, but would like to dump it DiscImageCreator. My drive is a TSSTcorp SH-D162C aka TS-H352C with Kreon firmware.

Code: Select all

D:\tmp\MPF_2.3-net48\ISO\TEST>..\..\Programs\DiscImageCreator_20220707\DiscImageCreator.exe gd H NFL2K1.bin 4 /q
AppVersion
        32 bit, AnsiBuild, 20220707T220452
CurrentDirectory
        D:\tmp\MPF_2.3-net48\ISO\TEST
WorkingPath
         Argument: NFL2K1.bin
         FullPath: D:\tmp\MPF_2.3-net48\ISO\TEST\NFL2K1.bin
            Drive: D:
        Directory: \tmp\MPF_2.3-net48\ISO\TEST\
         Filename: NFL2K1
        Extension: .bin
StartTime: 2022-08-28T22:57:10-0500
Set the drive speed: 705KB/sec
DiskSize of [D:\tmp\MPF_2.3-net48\ISO\TEST]
        Total:  4000650883072 bytes
         Used:  1966136115200 bytes
        ---------------------------
        Space:  2034514767872 bytes
         => There is enough disk space for dumping
[WARNING] /c2 isn't set. The result of dumping may be incorrect if c2 error exists.
This drive can read data sectors at scrambled state [OpCode: 0xbe, C2flag: 0, SubCode: 0]
LBA[045000, 0x0afc8]: [F:ExecSearchingOffset][L:192]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-64-00 = ILLEGAL_REQUEST - ILLEGAL MODE FOR THIS TRACK
lpCmd: be, 04, 00, 00, af, c8, 00, 00, 01, f8, 01, 00
dwBufSize: 2448
Couldn't read data sectors at scrambled state [OpCode: 0xbe, C2flag: 0, SubCode: 1]
Retry 1/10 after 10000 milliseconds

Want to post here as well since we're still looking into things. I don't think DIC works well with non-Plextor drives for Dreamcast games at the moment because these drives lack the ability to find and correct c2 errors. This isn't a problem for DCDumper because it just keeps retrying sections of sectors in passes until it gets a match, but I think if DIC encounters an error in GD mode without C2 or scramble read it seems to stop dumping. I recommend trying to dump using a Plextor for now (still looking into it, unless sarami can think of something)?

Hey sarami, the other thing I wanted to ask that might have been asked already, is it possible to automate LD/HD dumping? In theory, the Low Density is never more than 18000 sectors. The largest track 1 in a non-unlicensed game is Sengoku Turb (Japan), combined with it's track 2 this game's LD is 17848 sectors long, just shy of 18000. No other game is that big. Then you have your High Density data that starts at 45000 and above. If you know the max size of the low density, couldn't you just skip over the security ring and go right to the high density?

If you utilized a drive that could read in scramble mode all the way through, couldn't you just have the drive read the first 18000 sectors as part of the LD area, skip sector reads and go right to 45000 and use that as the High Density? I'm assuming in GD mode, DIC will read the TOC off of the disc itself overriding the TOC that was read by the drive before it was swapped. Couldn't you also do this to the LD area too?

On a related note, we've been dumping a few GD-R/GD-ROMs so far. One thing we're noticing is hat if the drive gets  command to seek to a certain sector on a GD-ROM past a certain point, the drive will freak out and get C2 errors every sector, which will cause the drive up to 30 seconds to read each sector. If you seek before that point and read the disc sequentially, you don't get those errors. However, sometimes the drive will do a reset and will need to re-seek to that specific point, causing an issue that can be seen in both DIC and DCDumper. I think this is why DCDumper has a "fake read" option that will read back 20000 sectors if it gets a read error. This is also probably the reason why DCDumper wants to do the very last section is a very large chunk size. Is there a solution for this as far as DIC goes?

Thank you for the help so far.

ehw wrote:I don't think DIC works well with non-Plextor drives for Dreamcast games at the moment because these drives lack the ability to find and correct c2 errors. This isn't a problem for DCDumper because it just keeps retrying sections of sectors in passes until it gets a match, but I think if DIC encounters an error in GD mode without C2 or scramble read it seems to stop dumping.

Good point, I tried dumping a GD-Rom with DIC on my Samsung drive. After 10 or so attempts I just gave up because there was always at least one error. For DIC GD-Rom dumping, only using Plextors makes sense.

I believe FatArnold dumped all their GD-Roms with 708/DIC back in the day. I tried doing this a long time ago - probably with another PX model and just gave up (which makes sense since so far only 708 is confirmed GD-Rom friendly).

With regards to multisession dumps produced by DiscImageCreator, has anyone been able to mount the bin/cue successfully on a PC where the data track itself is usable and not corrupted? I've been unsuccessful with the latest version of IsoBuster or when opening just the data track by itself.

IsoBuster beta added support for reading some multi-session multi-bin/cue dumps.

I think some multisession dumps need further definition in the cue files before IsoBuster could even adopt whatever the redump cue standard would be.

Further discussion
/viewtopic.php?p=48427#p48427
https://github.com/saramibreak/DiscImag … issues/121

I am trying to dump two DVDs in DIC (one from Call of Duty: World at War and the other from 007: Quantum of solace), but each time these DVDs report read errors when I try to dump them. Both discs are clean and have no scratches or dirt, but both are SafeDisc protected. Is this a program bug or is it different?

sarami, the latest build is not dumping Xbox beta discs which I believe are non-windows native filesystem (here are logs, all other log files were 0kb/blank): https://drive.google.com/file/d/1D23WFY … sp=sharing

however IsoBuster is dumping them fine: https://cdn.discordapp.com/attachments/ … nknown.png

Possible to fix please?

MrPepka wrote:both are SafeDisc protected

I don't know the detail about the SafeDisc DVD.

user7 wrote:the latest build is not dumping Xbox beta discs

The reason is unknown. Try to use 'dvd' command.

user7 wrote:however IsoBuster is dumping them fine

Can IsoBuster dump the xbox disc? I didn't know it.

I'm sorry, you're right - needed dvd command.

>Can IsoBuster dump the xbox disc? I didn't know it.

Only beta DVD-R. Same result as dic.

I just dumped a single layer BD-R that I burned as part of some testing I was doing. I noticed that the _disc.txt file seems to have four times the information, as if it had four layers. I'm not sure where this information is being derived from, since this disc only has... one layer. It was a single layer 25 GB disc. I assume only the first section of information (Layer 0) is valid, so where is the other info being pulled from? Layers 1-3 are for 50/100/128GB discs and I'm not sure why that's being added. Or is that always present in recorded discs?

I've attached the text file and hope you can help.