26 Reply by ehw

(3,509 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.

Go to forum: General discussion

27 Reply by ehw

(73 replies, posted in General discussion)

Sorry for the bump but does anyone still have a copy of the source code for this program? It seems to have been lost to time...

Go to forum: General discussion

28 Reply by ehw

(3,509 replies, posted in General discussion)

superg wrote:
ehw wrote:

Hey sarami I have a question about your .c2 format.

According to your readme, 1 bit inside the .c2 file represents 1 byte in the disc image. But there isn't any additional information besides that. I can assume that 0 means no c2 error and 1 means c2 error, but I'm having a difficult time trying to determine how the bits correlate to the exact locations of the bytes in the disc image.

Please see my reply here: http://forum.redump.org/post/99760/#p99760

ehw wrote:

I assume that the bits correlate to the bytes in LSB order. So since $01 is 00000001 in binary, there should be an error that affects just 1 byte around 0x618-0x61F, in this case the c2 error should be on 0x61F. But when comparing both image dumps, there are TWO bytes that differ rather than one.

C2 is usually big endian (MSB) with some drive exceptions.
Also, you see two damaged bytes per 1 C2 bit set only for sectors that are scrambled, I guess this is how scrambling implemented on hardware level.

Talk to me on Discord (superg#9200)

Thanks for the response. smile

That's a little concerning. I assumed each bit .c2 would map directly to the bytes in the .scm since those two files are always generated first by DIC but I wasn't aware they could be offset by drive...

If you look at the Beyond Compare image there are actually some groups of 8 bytes where only one of the bytes is different. For instance, the 5th byte (at 0x91C) in the group of 8 bytes at 0x918 in the .scm file apparently correlates to 0x123 in the .c2 file. In dump 1, the value at 0x123 in the .c2 file is $0F (00001111) and in dump 2 this value is $0D (00001101). I did descramble the two .scm dumps I was comparing using ISOBuster and the placement of the byte differences are the same as in the scrambled, just the values are obviously different. I descrambled the file by saving the CD image as a .bin (Extract CD image -> Raw .bin).

Go to forum: General discussion

29 Reply by ehw

(3,509 replies, posted in General discussion)

Hey sarami I have a question about your .c2 format.

According to your readme, 1 bit inside the .c2 file represents 1 byte in the disc image. But there isn't any additional information besides that. I can assume that 0 means no c2 error and 1 means c2 error, but I'm having a difficult time trying to determine how the bits correlate to the exact locations of the bytes in the disc image.

For instance, let's say I had two incomplete dumps that have c2 errors in both, like this:

https://i.imgur.com/lXPQHId.png

According to the .c2 for one dump, I have one C2 error ($01) somewhere in the 8 bytes that should correlate to 0xC3 in this .c2 file. In the other dump, there are no errors for this equivalent area as the byte is set to $00. If you take 0xC3 and multiply it by 8, you should get the address for the group of 8 bytes this error represents, which in this case is 0x618 in the image file.

https://i.imgur.com/RtJMP96.png

I assume that the bits correlate to the bytes in LSB order. So since $01 is 00000001 in binary, there should be an error that affects just 1 byte around 0x618-0x61F, in this case the c2 error should be on 0x61F. But when comparing both image dumps, there are TWO bytes that differ rather than one.

I don't think I understand how the .c2 file actually correlates to the image file. Can you explain how?

Go to forum: General discussion

30 Topic by ehw

(1 replies, posted in General discussion)

Hey everyone.

I'm curious if anyone has ever done any extensive research into the capabilities of various drives when it comes to discs that are hard to read or discs that contain a lot of defects/scratches.

A while back, I was in the market for some drives that, while incompatible with DIC, I could still get at least some kind of dump from some of the harder to read CD-Rs that I have. I have a lot of prototypes on various brands of recordable media, but the issue is that I don't have a single drive that can read a problematic disc consistently at all. Most of the discs appear completely fine on the surface (zero scratches at all), but sometimes the amount of errors can be alarming. There are some drives that fare better than others, but to my knowledge I don't think there was ever research done as to what drive can handle problematic discs the best - either due to great hardware (laser stength?) or great firmware.

I brought this up with olofolleola4 over a year a go, and he recommended these drives for scratched discs:

BenQ 5224W:
ALi M5501
ALi M55U3
OPU: Sony KRS-340C

BenQ 5224WU:
ALi M5501
ALi M55U3
OPU: Sony KRS-340C

Philips PCRW5232:
ALi M5501
ALi M55U3
OPU: Sony KRS-350C

BenQ 5232X:
ALi M5505
OPU: Sony KRS-360C
Source: https://club.myce.com/t/benq-5224w-wu-5 … /314586/15

Plextor PX-230A:
ALi M5505
OPU: Sony KRS-360C
Source: https://diit.cz/clanek/plextor-px-230a-52x32x52-ide

Basically ALi chipset according to public knowledge, but I haven't confimed that myself.

Anything that uses the ALi chipset seems great for discs with scratches. For discs that are hard to read, he recommended these:

Regarding "hard-to-dump", based on my LaserLock tests, these ones seems to be the best ones to use:
#1: Toshiba DVD-ROM SD-R2102
#2: Lite-On DVD SOHD-167T
#3: GoldStar CD-ROM CRD-8322B
#4: Toshiba DVD-ROM SD-M1401
#5: Plextor DVDR PX-708A

Source: http://wiki.redump.org/index.php?title= … ofolleola4

A while back I also found this thread that ranked a few drives that were good at reading heavily scratched discs:
https://forum.dbpoweramp.com/showthread … S-ON-GOING

Of course, not every drive is the same and there are many contributing factors at the end of the day. But still, I'm curious if there really is a drive out there that seems to be a decent all around solution for discs that are just difficult to read because of issues in regards to the media itself.

Go to forum: General discussion

31 Topic by ehw

(0 replies, posted in General discussion)

Hey all.

I've been researching various ways game discs can verify themselves for incorrect sectors/data, but I can't seem to make heads or tails about Xbox discs in general. From my understanding, Xbox Game Discs utilize encryption and security sectors for its 'Xbox' game partitions. I'm not sure if maybe perhaps Xbox partitions might have something similar to the Wii H3 tables where there is a hash for every file on the partition, or something similar. Is there anyway to hypothetically verify that the contents of a disc dump are okay post dump by utilizing the data that's included on the disc? Are there any tools that do this already?

I can't seem to find much documentation on game discs specifically aside from this:
https://xboxdevwiki.net/Xbox_Game_Disc

Go to forum: General discussion

32 Reply by ehw

(3,509 replies, posted in General discussion)

Hello sarami,

I'm having issues dumping a PS1 proto burnt on a Philips CD-R from the 90s. I keep getting C2 errors pretty much around the same area no matter which drive I try, somewhere torward the edge of the disc. I could create a dump using CloneCD which doesn't report issues with the recommended settings. I dumped the disc twice with Redump's old recommended CloneCD profile and the .img has the same checksum every time. I was able to somehow make a dump with DIC with my LG WH14NS40 with Asus BW-16D1HT 3.02 firmware flashed but the checksums on the .img didn't match CloneCD. There were definitely many errors that were reported by DIC with the LG drive. The surface of the disc is spotless with very little on it. I have another Philips CD-R with a slightly newer build of the same game (I believe it matches the PAL final exactly) and it also spawns C2 errors. This kind of makes me believe this could be some kind of mastering issue?

Here are some logs:

PX-4012:
http://www.mediafire.com/file/pwp45r62g … ).zip/file

PX-760a:
http://www.mediafire.com/file/smadk5sts … ).zip/file

WH14NS40 (flashed with ASUS):
http://www.mediafire.com/file/3hnb026uc … ).zip/file

I used DIC version 20200921 via the latest DICUI. I tried setting the C2 reread to 1000 and it still couldn't get past the first C2 error.

By the way, I've been meaning to ask, are there recommended command parameters/settings to handle CD-Rs? CD-Rs in general are always tricky to dump with DIC and was curious if you could recommend a setting that could work for most of them?

Go to forum: General discussion

33 Reply by ehw

(3,509 replies, posted in General discussion)

sarami wrote:
ehw wrote:

I'm having issues dumping an Amiga CD-32 prototype but I'm experiencing this error in mainError.txt in each attempt I try:

Because this sector has c2 error.

Thanks for the reply.

We had other discs do the same thing within the same session and the issue seemed to fix itself with a powercycle. I heard PX-716UFs had some stability issues like this, so maybe that's what it was.

Go to forum: General discussion

34 Reply by ehw

(3,509 replies, posted in General discussion)

Hello!

I'm having issues dumping an Amiga CD-32 prototype but I'm experiencing this error in mainError.txt in each attempt I try:

LBA[001773, 0x006ed]: Track[01]: This sector is data, but sync is invalid
========== LBA[001773, 0x006ed]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : 70 25 00 00 F5 18 00 00  7A 0C 00 00 00 00 00 00   p%......z.......

Here are the output files.
https://www.mediafire.com/file/tbrbb69g … ad.7z/file

Go to forum: General discussion

35 Topic by ehw

(0 replies, posted in General discussion)

Hey everyone, I wanted to bring this to your attention as it seems pretty interesting to note.

We've been dumping a bunch of PS2 prototypes recently, and some of them are almost perfect matches for the final retail version. The only difference is that all the DVD-R based prototypes contain CDVDGEN metadata in each dump that contains product code, CDVDGEN version used, publisher/developer, burn date, and even information about the specific burner model that was used to author the disc (including bios version and date). This data seems to start at $7000 in each .iso dump. For instance, in the Silent Hill 2 v0.10 prototype (http://redump.org/disc/65658/), the disc contains this information starting at the offset mentioned earlier:

SLUS-20228                      KCE TOKYO                       KCE TOKYO                       20010713PlayStation Master Disc 2

Then at $7300, there's this:

HOEI    DSR-8000dp      2.8fDVD-R   DVR-S2012.12CDVDGEN 1.20                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    SLUS-20228                      KCE TOKYO                       KCE TOKYO                       20010713PlayStation Master Disc 2

I figure maybe this information might be important to note?

CD-R based prototypes seem to have something similar in a different location. For instance, in the European prototype of Polaroid Pete (http://redump.org/disc/53336/), there's this at $80b8:

SLES-50557                      IREM SOFTWARE ENGINEERING INC.  IREM SOFTWARE ENGINEERING INC.  20020109PlayStation Master Disc 2.0.

And this at $83B8:

SONY    CD-R   CDU920S  2.0c18 Jan 1996 CDW1.01 CDVDGEN 1.31

Incidentally, we discovered a second copy of this same exact prototype on another CD-R and dumping that with DICUI produced the same exact dump, byte for byte, with identical metadata as well.

Although I'm not sure if it's always CDVDGEN metadata, since I assume you could author prototypes using any kind of tool. From what I've seen, this seems to only affect PS2 games but I suppose PS1 games might be worth checking as well.

I thought I should bring this up as this might be important to note.

Go to forum: General discussion

36 Reply by ehw

(1 replies, posted in General discussion)

Double post. But just an update.

I realized that rom-properties (an open source tool you can grab here: https://github.com/GerbilSoft/rom-properties) can scan an Xbox ISO and tell you information about the default.xbe that's used. If you had a folder of isos you can run this against the folder using a wildcard, and pipe the output to a text file, you'll get the build dates for all the games so far in the set. Of course, there are games that have multiple .xbes, but this at least takes care of default.xbe.

Unfortunately I don't think many people have an entire set to scan this tool against. Would anyone be willing give it a shot?

Go to forum: General discussion

37 Topic by ehw

(1 replies, posted in General discussion)

Hey all. This is just a suggestion for the Redump database.

Currently we report EXE dates for PS1/PS2 games based off of the file time stamps on the default executable the game is loading. While other systems (especially ones that don't conform to traditional disc based file systems) may not always report the same information, I did notice that Microsoft Xbox games do contain this information in every default.xbe as part of the standard certificate information.

https://github.com/Cxbx-Reloaded/XbSymb … /Xbe.h#L71

For example, in "Tim Burton's The Nightmare Before Christmas: Oogie's Revenge" (NTSC/US), at 0x114 in the .xbe - the dwTimeDate information is stored in four bytes little endian. In this case, my copy is 42E44C54 big endian, or Jul 24 21:20:04 2005.


Regardless, I think this information is useful for differentiating between different versions of games. This information is especially crucial for us, since we work with prototypes of games a lot and the information from the comparable retail version isn't readily available.

If you're interested in seeing this information for yourself, I would recommend XBE Explorer which you can grab at the bottom:

http://dxbx-emu.com/downloads/

It'd be nice if this information could be gathered with a script on an entire set and just imported into Redump.org's database. Maybe eventually DICUI could also have the means of getting this information as well to make submissions easier too...

Go to forum: General discussion

38 Reply by ehw

(5 replies, posted in Guests & account requests)

Can vouch for this user. He also recently dumped the Silent Hill 2 v0.10 prototype using DICUI. smile

Go to forum: Guests & account requests