saramibreak
commented
1 year ago - fixed: padding size when DVD was dumped and SCSI error occurred
Closed ehw closed 1 year ago
saramibreak
commented
1 year ago 
ehw
commented
1 year ago Hey, thanks for the quick fix!
I can confirm that DIC is now replacing the entire block with the filler byte when a SCSI error occurs. It's a shame though, since the buffer did include some sectors that were good, but because its mixed with garbage data you can't really check or depend on the integrity of anything in the block. :(
Ironically, that pretty much solves this issue. But I do have one question though - is it possible to have DIC read a DVD one sector at a time rather than by using blocks of sectors? It'd be slower, but at least you can return more data if only some of the LBAs are bad in the block.
saramibreak
commented
1 year ago ehw
commented
1 year ago Thanks for the test version. I'll test it later. :)
I've been thinking I wonder if it might be best to introduce a parameter that lets the user control the size of the block for DVD reads. I can see a scenario someone might want to read 1 sector at a time regardless for certain media outside of using /ps. Some drives might read discs better that way?
saramibreak
commented
1 year ago I can see a scenario someone might want to read 1 sector at a time regardless for certain media outside of using /ps.
In what cases is it necessary?
ehw
commented
1 year ago
- changed: when /ps is used, transfer length is 1
- changed: /ps val accepts from 0x00 to 0xff (Feature Request - DVD mode - Customizable filler byte pattern for /ps #203)
Tested, all of these changes work. Thanks! Feel free to merge.
I can see a scenario someone might want to read 1 sector at a time regardless for certain media outside of using /ps.
In what cases is it necessary?
Off the top of my head if you don't want to substitute sectors and want to read and retry each sector before you reach something thats very hard to read, you can read a bit more as opposed to if you read a fixed block size. There might be some drive specific behavior advantages to having a smaller/bigger block size, especially if you're using a much older DVD drive like one of the first authoring dvd-r drives. But I don't know for a fact though...
Version 20230510T002959
Describe the bug There are two things that I discovered that might need addressing. To discover these issues, I dumped a disc normally with a PX-760A, and then dumped the same disc again after putting a small piece of clear tape on the disc's surface to generate purposeful errors.
When errors occur from the drive in DVD mode, DIC seems to only substitute the reported LBA with a filler byte when /ps is used. Other sectors within the block aren't substituted when an error is reported, resulting in mixed data within the block where some sectors are perfect but others are corrupt. These other sectors go completely unreported.
When DIC dumps a disc in DVD mode, DIC seems to dump the disc in 32 sector sized blocks at a time (?). When DIC encounters an error in DVD mode, DIC will report the LBA that was returned by the drive along with the SCSI error. If the /ps parameter is used, DIC will substitute the affected LBA with a filler byte.
However, it appears that sometimes DIC seems to return corrupt data somehow for certain LBAs rather than fill them with filler bytes. For instance:
The screenshot above displays two dumps side by side in Beyond Compare, a file comparison program. The left panel displays a dump that experienced no issues when dumping (matches redump), and the right panel features a dump that experienced errors while dumping and substituted sectors with errors with a filler byte $AA. In the following screenshot and log snippet, the drive reported an error at LBA 1635392 (0xC7A20000 in the physical .iso file). Because there were no retries and that the /ps 1 parameter was used, DIC filled the sector with $AA as a filler byte. This is normal behavior.
However, at 1635393 (0xC7A20800) which is the next sector, there's a complete mismatch of data. The dump with errors generated garbage and was not filled with a filler byte at all. However, the log file does not indicate that any error occurred at this LBA at all.
This is a major problem because this seems to imply that there are more errors that do not go reported. This also seems to imply that when errors do occur that DIC isn't substituting all the affected sectors with the filler byte.
This issue seems to occur more intensely the more errors are reported by the drive. For instance, an error was reported at LBA 165952 and was filled with filler bytes, but no other neighboring sector was filled.
However, presumably within the same block, at LBA 165968 (0x14428000) just a few sectors later within this block, there is data corruption that was never reported.
According to DIC's logs, the next error reported by the drive occurs at 166016. From the first reported error at 165952 until now, this is what the log consists of giving no indication of what I mentioned before:
Depending on how it reads sectors, whether individually or by block, DIC needs to report every individual sector whether they are okay or if they have an error that warrants a replacement byte. The garbage data is no good at all, and bares zero resemblance at all to the original data. I don't know if this is exactly possible since I think DIC reports errors by block not by sector, so if an error occurs DIC only reports the first sector it sees that is reported by the drive but doesn't know what the status is of the rest of the 31 sectors in the 32 sector block. Some of the data might be good, some of it might be bad, so discarding or filling the entire block may not be a good idea. Ideally, DIC needs to ONLY substitute bad sectors within the block while keeping the good data returned. I don't know if there's a solution to this.
Screenshots
Disc title Official U.S. PlayStation Magazine Demo Disc 53 http://redump.org/disc/14073/
Disc ringcode A0100393415-A511 IFPI L557
URL https://www.ebay.com/itm/403973743964
Log file Here are the full dumps of the disc in question. One dump with tape, and another without. The one without matches the redump entry perfectly and is free from errors. https://www.mediafire.com/file/a2iy30whvyl65np/bug+207+-+tape+and+good+dumps.7z/file