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.
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. 
