Search options (Page 4 of 5)

TSSTcorp DVD+-RW TS-H653G

With this drive, bruteforce.py became stuck after several hours so I killed it and copied the console output to the log file manually (killing the process did not flush any of the log output to it).

PIONEER BD-RW BDR-209D

HL-DT-ST DVDRAM GH22NS50

Please double-check your mastering code. Can you provide a photo showing that is "MK81014P623 P7H" and not "MK81014P263 P7H"?

Can you provide your DIC logs for your PSX disc?

I've recently encountered an issue where DiscImageCreator is failing to report DVD read errors on multiple discs, while Isobuster and redumper both report read errors. I believe these read errors are resulting from hardware failures from my internal DVD drive, and not disc errors (they are flawless discs and read without errors on other drives). I have experienced these symptoms with builds 20220707, 20230303, and 20230413. This results in 2048-byte blocks containing NULL bytes instead of the correct bytes.

In DIC code, I see that it doesn't directly check ScsiStatus, but rather:

if (swb.SenseData.SenseKey == SCSI_SENSE_NO_SENSE &&
    swb.SenseData.AdditionalSenseCode == SCSI_ADSENSE_NO_SENSE &&
    swb.SenseData.AdditionalSenseCodeQualifier == 0x00) {
    bNoSense = TRUE;
}
...
if (bNoSense) {
    *byScsiStatus = SCSISTAT_GOOD;
}

Is it possible that because DIC doesn't directly check ScsiStatus, that it is missing some bad reads?

Attached are logs for the GOOD and BAD dump from DiscImageCreator for a specific disc with the failing drive (both report no errors in the log).

Here is another audio CD where the universal hash of redumper does not match DIC.
This disc has a lead-in bin (Track 0), although the disc is assigned a write offset value of 0.
Redumper log
DIC logs (attached)

Redumper snip:

non-zero  TOC sample range: [   -88200 .. +38099460]
non-zero data sample range: [   -11571 .. +38099460]
Universal Hash (SHA-1): fb488cc91335022ae2e48a15f0b7f969d8cc7359

detecting offset
audio silence detection... done
Perfect Audio Offset (silence level: 0): [-88200 .. -11571]
warning: fallback offset 0 applied
disc write offset: +0
warning: lead-in contains non-zero data (session: 1, sectors: 20/20)

DIC snip:

========== Hash(Universal Whole image) ==========
     1st non-zero byte position:      1 sector +    0 byte
    Last non-zero byte position:  64794 sector + 2351 byte
        <rom name="" size="152397840" crc="70bd1516" md5="3f9dce45601fc49f11edb08380df1780" sha1="69fe434ea59e9ea61610c3565f2fc83f772a8d34"/>

That fixed the issue, thanks!

As a reminder to whoever adds the account, please make sure to update the free-form dumper text of Cyril XD on this once the account is created: http://redump.org/disc/20034/

Logs

Hi sarami,

I think I found a bug in DIC.
I have this CD-R audio CD.

DIC logs

DIC determines an incorrect track 1 / track 2 boundary.
This is what IsoBuster shows for the disc.

DIC produces the following:

<rom name="PGS - Promo Disc (USA) (Track 1).bin" size="25552128" crc="169df37b" md5="e3428a7bb35692ea9625202190220206" sha1="42da4a8b5171e1b3b66a0511611ac2671e402b13" />
<rom name="PGS - Promo Disc (USA) (Track 2).bin" size="28602672" crc="42f4fccc" md5="1c2daf66fa7b437808da638622c8bdf4" sha1="60d20f2c386c74531dd12c8b91ad174e92690d1f" />

FILE "PGS - Promo Disc (USA) (Track 1).bin" BINARY
  TRACK 01 AUDIO
    INDEX 01 00:00:00
FILE "PGS - Promo Disc (USA) (Track 2).bin" BINARY
  TRACK 02 AUDIO
    INDEX 01 00:00:00

This is what I think DIC should produce instead:

<rom name="PGS - Promo Disc (USA) (Track 1).bin" size="25199328" crc="f6d1e0ec" md5="35e6f50c3e0ec2628dd14ee3495600ff" sha1="4b3312cfd071c7010d4a3c6949216ffad764bfc2" />
<rom name="PGS - Promo Disc (USA) (Track 2).bin" size="28955472" crc="92541dae" md5="11a72eb9f5c78491d5af695711379466" sha1="46372e3a0fabea96d0ee9e3620fddb47f0dbb60e" />

FILE "PGS - Promo Disc (USA) (Track 1).bin" BINARY
  TRACK 01 AUDIO
    INDEX 01 00:00:00
FILE "PGS - Promo Disc (USA) (Track 2).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00

LBA 10714 belongs to the track 2 but I think DIC takes it as a part of track 1 and just goes 150 sectors deeper than needed
similar issue is LBA 23025, it's part of lead-out if you carefully pay attention