https://github.com/hiddenpalaceorg/DriveMemoryDumper

Initial release of my memory dumper.

I pulled this off my DVDRawBruteForce program in case anyone wanted this function separately as it's pretty useful. Providing you know of the first 3 bytes of a SCSI command (preferably 3C) that dumps 16MB of a drive's memory from that specified page.

Usage:
- Run the program
- Input a drive letter (preferably have a disc inserted but it's not necessary)
- Specify the first 3 bytes of a SCSI command (e.g: 3C 02 00, 3C 01 01, 3C 01 00, etc), in this specific format.
- Run!
- The result will be stored in combined_memdump.bin and packaged in an "upload_me" file along with a small log.

I'm not really looking for submissions as that's more for the other program, but feel free to use this for research purposes. We have a great list of drive support already on this sheet, so feel free to see if your drive is there to find the right command to use:

https://docs.google.com/spreadsheets/d/ … fVuRBLyQFA


Note: kinda only works with 3C yet since there are cdb differences with F1 and E7. also, the script will force read lba 0 which might screw with things if you want to dump ram at a given moment with a drive but you can  just remove that part from the script that reads lba 0 if you want just what the drive has at that given moment.

2023-12-10 - new version (dont use this)

- Add interrupt handlers (CTRL+C) for scanning 3c/f1 values just in case drives hang or take too long.
- Added an experimental RAM dumper. This will take the first 3C opcode discovered that returned valid sector data with a valid PSN. This will try to dump 16MB with the command, which should be close to the start of DRAM. This process can also be interrupted with Ctrl+C. Note, how drives handle CDBs with invalid offsets is up to the drives I think. For my PX-716A, it didn't complain when I used a high offset value. Commonly, it should 'loop around' to the start of DRAM if the offset is beyond the size of available RAM but it might be up to the firmware so expect something to happen if they dont.
- Small spelling mistake changes.
- 3C bruteforce values are now stored in an array so that they can have some applicable use.

I expect some drives to not like the ram dumping, but if you have new dumps that aren't on the sheet feel free to test and submit.

EDIT: found a bug, the handlers werent actually returning what was stored in the arrays when the functions ended abruptly. need to make a change in order for that to work. stay tuned

EDIT 2: should be fixed with the following version.
2023-12-11 - new version (dont use this)

- Fix bug with interrupt handlers so that contents of the discovered values array are retained after getting out of the function.
- Potentially fixed a bug where drives that don't rotate back to the beginning of memory when the offset is set too high and thus don't create the files for the memory dump occurs. I couldn't test this personally but I know someone tested a drive that this occurred.
- Moved mem_dump_3c to before bruteforcing f1 just in case bruteforcing f1 writes to cache.
- Reread lba 0 after f1 bruteforcing but before testing other commands just in case bruteforcing f1 wrote to the cache.

EDIT 3: third time's the charm. here's a new version
2023-12-11a - new version (dont use this)

- Have the drive reread LBA 0 each iteration of F1 bruteforcing to see if I can prevent F1 from modifying data already on the cache.
- Change compression from .zip to .7z for better compression ratios.
- Add cleanup function to clear duplicate files.
- Print file hash (SHA256) for every file in the log.

EDIT 4: ugh
2023-12-12 - new version (dont use this)

- Fix bug when no 3C values were found before using the 3C memory dumper.

EDIT 5: ughhh
2023-12-12a - new user (use this)
https://github.com/hiddenpalaceorg/DVDR … 023-12-12a

- Reread LBA 0 because apparently there are values of 'read' buff that can actually alter the cache too! Yay!

New version - 2023-11-26:
https://github.com/hiddenpalaceorg/DVDR … 2023-11-26

No need to retry what you've submitted, but use this version from now on. If anyone could update the linux version that'd be great.

MrPepka wrote:

More logs from two drives (SOHD-167T and SH-216BB)
BTW: Is it possible to add a function to the program code that allows the program to end when the drive is not responding? My SH-216BB hang up when reading 256 sectors (F1 I think). It happened twice and each time I had to restart the drive from the power supply. When the drive was suspended, the program was still waiting for a response from it. It would be nice if the program restarted the drive in such situations, or if the drive stopped responding after some time, it would terminate its operation

Hey out of curiosity what disc did you use in the SOHD-167T? What's "KULTOWE GRY 5"? Is this on redump? Do you have a scan of the disc, specifically the surface?

Curious if this is a recordable disc or something.

Added! Keep them coming. smile

olofolleola4 even submitted quite a few drives too. smile

Thank you!!!

Edness wrote:

12 more drives incoming!  I threw in my SH-D162D flashed with Kreon firmware as well just for kicks - don't know if it's also acceptable here, but the rest are new additions regardless.

Thank you!!! Some good ones in this set. smile

Keep them coming!

Thanks for the submissions everyone!

I added a bunch myself. Keep them coming. tongue

Thanks everyone for the submissions so far! We have 116 drives on the sheet as of writing. smile

Keep em coming.

JustAnyone wrote:

Drive: VAD6038 with 0800 firmware

Is this drive able to read the disc you inserted? It didn't generate a dump for lba 0 so I don't think it was able to read it...

Thanks!!!

Keep them coming guys.

bikerspade wrote:

HL-DT-ST DVDRAM GH22NS50

Thanks! Keep them coming. smile

Thanks! Keep them coming lol.

Edness wrote:
ehw wrote:

I'm not sure whether to trust when the left most byte is different because other bytes within the page might be altered randomly from different runs too. I'm making notes of when this happens in the notes field but I'm looking for when the first 4 bytes are exactly 00 03 00 00 to know that it's workable for sure.

Fair enough, the point I was trying to make was, it may be a good idea to ask the dumper to try again with a different disc, since in his case this only occurred with one specific PC game disc.

Anyway, 6 more drives from me and a few friends, sorted in folders with which disc was used and all.  The _pylinux folder contains the modified version for Linux that jason098 and I did.  smartctl was used to get some drive info, so I ended up making it a part of the script.  So, some folders will have a smartctl.txt file with that info separately from an earlier version, and others will have that info included in logfile.log.

Thanks!!! Keep them coming!!!

That GU90N is really strange. So there are two versions of the GU90N, one is a DVDRAM drive and the other a DVDRW drive? Because both drives gave wildly different results, as if the firmware is completely different for both.

Lugamo wrote:
Lugamo wrote:
ehw wrote:

BTW, if for whatever reason it seems like its way too slow (like 3+ hours) or seems like it stalled, feel free to stop it by using Ctrl+C and upload what you have. Some drives just don't like being bruteforced to that high value. I could probably restrain the values it's bruteforcing with but you never know if a vendor might be sneaky and put something at 3C FF FF or something, lol.

Here you go. I will try with another DVD later.

It has finished, here it is. The dumped disc is Earth 2160.

Thanks! Keep them coming.

MrPepka wrote:
ehw wrote:
MrPepka wrote:

TSST TS-L632H doesn't support or what happens?

Try again? Maybe the drive doesn't like the disc and can't read it.

The same. I tried with 2 different discs, the drive reads them correctly

Not sure what to say...the drive just doesn't like it..

I made a new version to try to deal with the drive timeouts and potential possibility that it clears the cache when it does so. I don't have any drives on hand that does this so it needs testing:
https://github.com/hiddenpalaceorg/DVDR … 023-10-01a

It will reread LBA 0 so it puts it back on the cache again if a specific error is returned from sg_raw. Hopefully this helps a bit...

Edness wrote:

Tested another drive I had laying around, as well as sent this in a chat with a couple of friends who were also interested in it, so there may be more to send soon.  The laptop HP SU-208CB drive I just tested here I'm like 99.1% sure is actually a rebranded TSSTcorp drive, so make of that what you will for which brand to put that under.  I also have a few more to test, those being an assortment of drives in other old PCs but that's for later.

It seemed to completely hang when it got to F1 05.  I couldn't kill the process or anything, so I ended up force shutting it down after like an hour which means it didn't flush anything to the log file either.  But 3C 02 00 got 0x8BC bytes of raw sector data, at least.  I re-ran just the beginning to get the basic drive info at least, but I don't feel like running the whole thing on that crappy laptop again, as it was excruciatingly slow.

Jason098 from the aforementioned group chat modified it slightly to run on Linux since almost everyone in my friend group uses it, which also means the get_dvd_drive_info() function had to be commented out for them.
There's also an odd edge case to consider: one of Jason's discs had "unexpected" data in the 1st byte of the PSN.  AFAIK, normally (if the PFI is anything to go by) the leftmost byte is unused so usually it's just 0x00, but that one disc had "random" values in there like 50030000, 20030001, etc.  It may be better to mask out the 1st byte and only check if the lower 24 bits equal to and increment from 0x030000 instead.  It's possible a field marked as "No" could actually be wrong and mislabelled due to this oddity.

There were some other drive issues he had too, like if the lower nybble of the 3C command ended with 0x0B, the drive would pretty much hang so we had to work around that as well (which I understand he also later brought up to you in another server.)

I'm not sure whether to trust when the left most byte is different because other bytes within the page might be altered randomly from different runs too. I'm making notes of when this happens in the notes field but I'm looking for when the first 4 bytes are exactly 00 03 00 00 to know that it's workable for sure.

Keep them coming lol.

MrPepka wrote:

TSST TS-L632H doesn't support or what happens?

Try again? Maybe the drive doesn't like the disc and can't read it.

MrPepka wrote:

I will also add my logs. I checked on BW-16D1HT, but with firmware 3.10 modded by RibShark

Thanks! For some reason it should've found a working command but I think I might've boo boo'd the addition of a timeout because apparently sometimes when sg_raw timesout it causes the drive to reset which would clear the cache, which means we lose LBA 0 which makes everything after the first timeout potentially useless. I think that might've happened here. Do you remember when you were testing the drive when it exactly started to take a really long time for the progress bar to move?

I might have to revert the timeout thing and just have people CTRL+C it if it starts going really really slow. At least for the time being.

MrPepka wrote:

More logs from two drives (SOHD-167T and SH-216BB)
BTW: Is it possible to add a function to the program code that allows the program to end when the drive is not responding? My SH-216BB hang up when reading 256 sectors (F1 I think). It happened twice and each time I had to restart the drive from the power supply. When the drive was suspended, the program was still waiting for a response from it. It would be nice if the program restarted the drive in such situations, or if the drive stopped responding after some time, it would terminate its operation

It's supposed to timeout as of the latest version after 20 seconds and move on to the next number...

Lugamo wrote:
ehw wrote:

BTW, if for whatever reason it seems like its way too slow (like 3+ hours) or seems like it stalled, feel free to stop it by using Ctrl+C and upload what you have. Some drives just don't like being bruteforced to that high value. I could probably restrain the values it's bruteforcing with but you never know if a vendor might be sneaky and put something at 3C FF FF or something, lol.

Thanks! Added

Here you go. I will try with another DVD later.

Edness wrote:

Here's mine from a TSSTcorp SE-208DB.  Looks like 3C 02 00 returned 0x8BC bytes of scrambled sector data.  So did F1 84, which was offset by about 13.5 sectors (0x7800 bytes).  And F1 8A returned the PFI, funnily enough.
Disc used: [PC] FlatOut 2 (Europe) (En,Fr,De,Es,It) (Xplosiv)

Are PS2 discs also disallowed or not?  At first I started with a PS2 disc since I have way more of those on hand, but shortly after restarted with a PC disc.  I don't know if you look for specific patterns in testing, but my assumption was that maybe you expect the 0th sector to be empty, which is not the case on PS2 discs since those have the PlayStation 2 logo seen when booting a game XORed across the first 12 sectors.

You can use PS2 discs, absolutely. It's just that I've only ever tried standard DVDs that were mastered like a traditional DVD ISO disc, like something with a UDF or ISO partition as some other discs may be harder for older or other drives to read or might not have the same raw data that the program uses to identify it (like weird DRM or something).

Thanks for the submission! big_smile

BTW, new version pushed. This one adds a timeout of 20 seconds per bruteforce'd value to cover moments where it looks like the program is frozen. Hopefully it takes care of that...

I also noticed a small oversight with the F1 progress bar so hopefully that's fixed too.

https://github.com/hiddenpalaceorg/DVDR … 2023-10-01

Lugamo wrote:

Have you considered adding a license?

Dump update: It has been stuck in F1 0C for a while now.

Not really, not interested for something like this.

BTW, if for whatever reason it seems like its way too slow (like 3+ hours) or seems like it stalled, feel free to stop it by using Ctrl+C and upload what you have. Some drives just don't like being bruteforced to that high value. I could probably restrain the values it's bruteforcing with but you never know if a vendor might be sneaky and put something at 3C FF FF or something, lol.

Had a couple of submissions already. Keep them coming! Tell your friends and spread the word and see if we can test as many drives as we can.

Deterous wrote:
ehw wrote:

There was a tool written in the past that used to do just this, however the source was never released

Is there source for the new tool you've just linked?

ehw wrote:

Even if it doesn't look like it's doing anything while it scans for values of 3C, it's working

It would be nice to get an update as to where it's up to in the list of commands (even just "No sectors returned from 3C 08 __", i.e. a message every time a whole chunk of 256 commands were checked with nothing returned), so I can tell that *some* progress is happening and it isn't some hardware issue causing it to freeze.

Source code:
https://github.com/hiddenpalaceorg/DVDRawBruteforce

New release, added a progress bar:
https://github.com/hiddenpalaceorg/DVDR … 2023-09-30

smile

Lugamo wrote:

I got an error that appeared twice saying that "cygwin1.dll" was missing, and then the program closed.

Redownload the zip and try again, it needs cygwin installed and I forgot to include some of the .dlls inside. tongue

So a long time ago, there was some interest in exploring the possibility of dumping DVDs 'raw'. Meaning, scrambled dumps with error detection and correction data along with header information. Some of you may be aware that unlike CDs, drive's don't like to give out data to the user that isn't needed for the typical user, like error correction/detection data. So instead, drives just give you the corrected, 2048 byte user data already processed. This is kind of a problem in some cases as you have to trust that the drive is performing the error correction and detection properly, which occurs either at the firmware level or at the DSP level. Having the ability to look at the raw data has some advantages, but it's limited to how much control the drive gives to the user, which isn't a lot.

Currently we're exploring using the raw information provided by various DVD drives for trying to get as much data from the disc as possible. Since DVD drives traditionally don't like to give you any sector data unless it's 100% 'correct', for bad or hard to read discs it leaves a lot on the table.

Luckily, most drives out there have support for the READ BUFF SCSI command which can help spill some unintended data to the user on request. If you get the parameters just right, you can get the data that was read by the drive before it's returned to the user. Since we know what a raw DVD sector consists of, we can easily find the right parameters needed for the command to find the right combination that returns the data we want.

However, there's a catch.

Because READ BUFF is implemented at the firmware level, despite every drive having some level of support for the command, the command varies from vendor to vendor, drive to drive. So one combination of parameters might not necessarily return the data you want in one drive even if it worked on another drive model. The second issue is that drives will store only what's necessary for the drive's firmware itself to perform what it needs to do on the data that's read from the disc. As such, some drives return variable, but somewhat fixed/standard data sizes per sector. So even if the data is found using READ BUFF, you need to determine how much data is returned per sector that's stored. Sometimes 2366 bytes with some padding are stored, sometimes 2064, etc. Sometimes data can be returned already unscrambled, sometimes data can be stored scrambled but with only error detection data. Sometimes you get everything. It's a mess.

Luckily, we can bruteforce the READ BUFF command and figure out what will give us the expected data. There was a tool written in the past that used to do just this, however the source was never released and doesn't seem to work correctly. It also doesn't take into account the various other memory dumping commands that exist as well, like F1 and E7.

That's where you come in. We have a lot of drives already, but not everything. We would like to create a database and keep track of drives that return raw DVD sector data onto the cache and the SCSI command parameter combo that gives you the data, along with what's actually contained within that data. We made a super streamlined version of the program that you can run on Windows machine that will take care of everything for you. Here's how it works.

1.) Get a DVD, preferably something on Redump.org, and put it in a DVD drive you'd like to test. The disc must be a standard DVD, no Xbox, GC, Wii, etc! A normal PC game on a DVD, PS2, or maybe a DVD Video disc should be okay.
2.) Run the program. The program will ask which drive letter contains the disc to use.
3.) The program will then perform some tests for feature capabilities, and then will begin bruteforcing parameters for various memory dumping commands. The program uses an embedded python script with calls to sg3 tools to issue various SCSI commands to the target drive while the media is inserted.
4.) It may take a while, but when it's done, it will generate an "uploadme.zip" containing memory dump fragments and a log file. Upload the uploadme.zip file here!
5.) I'll look at the dump and I'll add it to the table below.


Spreadsheet:
https://docs.google.com/spreadsheets/d/ … li=1#gid=0

Source code:
https://github.com/hiddenpalaceorg/DVDRawBruteforce

Grab the tool here:
https://github.com/hiddenpalaceorg/DVDR … e/releases

If you guys have any questions feel free to post here. Hopefully the zip files it generates doesn't take up a lot of space, as hopefully you can add the attachments here. But feel free to use another upload site if it becomes too big...

NOTE: if during execution the program takes way too long, feel free to kill it and just upload what it generated. Since it's bruteforcing many combinations of values it could take at least an hour or two depending on how well the drive works.

NOTE2: Even if it doesn't look like it's doing anything while it scans for values of 3C, it's working. So don't kill it right away. It will only print when data is returned by the drive using the SCSI command, not for when the command passes/fails.

EDIT: Program requires cygwin be installed but should have the .dlls needed to use it standalone. Let me know if there are any issues. If you were having issues before and didn't say anything, grab the zip and try it again.

23

(3,493 replies, posted in General discussion)

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

24

(3,493 replies, posted in General discussion)

sarami wrote:
ehw wrote:

Is there something we can do?

You can use /f flag. This is used to control "FlushDriveCache" function.

        /f      Use 'Force Unit Access' flag to delete the drive cache
                        val     delete per specified value (default: 1)

If you use "/f" (no value), app call "FlushDriveCache" per sector.
If you use "/f 1", app calls "FlushDriveCache" per sector.
If you use "/f 2", app calls "FlushDriveCache" per 2 sectors.
If you use "/f 3", app calls "FlushDriveCache" per 3 sectors.
:
:
If you use "/f 10000", app calls "FlushDriveCache" per 10000 sectors.

That worked, thanks! We're doing some more experimentation with GD-ROMs and GD-Rs with various drives so will keep you updated if I find more issues with these...

25

(3,493 replies, posted in General discussion)

Hey sarami, I think I found a bug or two.

We're dumping GD-ROMs with DIC and we're noticing that when we get any sort of seek error while dumping, it continues to have seek errors for the rest of the dump, usually on every sector or so. When this happens the drive slows to a crawl and never seems to get faster again. I thought that it might've had something to do with the disc itself but it seems to be random.

DiscImageCreator.exe" gd G "SONIC2T-708a\SONIC2T.bin" 12 /c2 1000
AppVersion
        32 bit, AnsiBuild, 20220707T220452
/c2 val2 was omitted. set [0]
CurrentDirectory
        D:\Sazpaimon\Downloads\VGPC GD-Rom Dumping Kit
WorkingPath
         Argument: SONIC2T-708a\SONIC2T.bin
         FullPath: D:\Sazpaimon\Downloads\VGPC GD-Rom Dumping Kit\SONIC2T-708a\SONIC2T.bin
            Drive: D:
        Directory: \Sazpaimon\Downloads\VGPC GD-Rom Dumping Kit\SONIC2T-708a\
         Filename: SONIC2T
        Extension: .bin
StartTime: 2022-08-22T11:06:39-0400
Set the drive speed: 2116KB/sec
DiskSize of [D:\Sazpaimon\Downloads\VGPC GD-Rom Dumping Kit\SONIC2T-708a]
        Total: 14000516493312 bytes
         Used:  5671329619968 bytes
        ---------------------------
        Space:  8329186873344 bytes
         => There is enough disk space for dumping
This drive supports [OpCode: 0xd8, SubCode: 0]
This drive supports [OpCode: 0xd8, SubCode: 1]
This drive supports [OpCode: 0xd8, SubCode: 2]
This drive supports [OpCode: 0xd8, SubCode: 8]
Checking SubQ adr (Track)  3/ 3
Checking SubRtoW (Track)  3/ 3
Reading DirectoryRecord    2/   2
Set OpCode: 0xd8, SubCode: 8(Raw)
Creating .scm from 44999 to 549150 (LBA) 431408 LBA[431409, 0x69531] Detected C2 error 847 bit
LBA[439363, 0x6b443]: [F:FlushDriveCache][L:220]
        Opcode: 0xa8
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-00 = MEDIUM_ERROR - NO SEEK COMPLETE
LBA[439364, 0x6b444]: [F:FlushDriveCache][L:220]
        Opcode: 0xa8
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-00 = MEDIUM_ERROR - NO SEEK COMPLETE
LBA[439364, 0x6b444]: [F:FlushDriveCache][L:220]
        Opcode: 0xa8
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-00 = MEDIUM_ERROR - NO SEEK COMPLETE

This occurs with a TS-H353A and PX-708A, which was recently confirmed to read GD-ROMs as well. This is occurring on our Sonic Adventure 2 GD-ROM, Sonic Adventure 2 The Trial GD-ROM, and a copy of Flag to Flag. So it doesn't seem unique to a particular disc or drive...

It seems to occur randomly. I was able to dump Sonic Adventure 2 alright without seek errors occurring. If it finishes dumping when it encounters seek errors, it does affect the final output (which still gets descrambled)
https://i.imgur.com/RBM3Zqa.png

Is there something we can do? Let me know if you need more logs/info.

Also, somewhat unrelated to dumping GD-ROMs, I'm noticing that DIC will still descramble and generate images if it encounters "This sector is data, but sync is invalid" errors. I'm not sure why, DIC doesn't reread these sectors that were read with sync issues. DIC retries when it encounters C2 errors, but not these kind of errors. When these errors occur, it results in detectable errors in the final dump. I know some games can be mastered with intentional errors, but what about a scenario where the drive is at fault? Couldn't DIC compensate by rereading sectors that spawn an error for sanity checks?

Here's an example we encountered. We were dumping a CD-R of "Arcade's Greatest Hits Williams" for the PSX. DIC was able to dump the entire disc and correct any C2 errors. But the EccEdc log still reports errors. We dumped the disc twice and there are unique errors in each dump, despite the dump finishing. Here are the logs:
https://www.mediafire.com/file/1042qzolb28tcnp/Arcade's+Greatest+Hits+Williams+PSX_logs.zip/file
https://www.mediafire.com/file/sq7jnsy0rwlov79/Arcade's+Greatest+Hits+Williams+PSX+[DUMP+2]_logs.zip/file

I've encountered issues like this on other drives, even Plextor drives. I think when this occurs its due to the drive itself, or the adapter if one is used. But can DIC do something in scenarios like this? Couldn't it just reread the sector again if it encounters a sync error and see if it still occurs?

Hope this helps.