Search options (Page 2 of 3)

A simple windows batch script that will recompress .zip to .7z (depending on where 7-zip was installed, you may need to edit the paths):

@echo off
for %%F in (*.zip,*.rar) do ( "C:\Program Files\7-Zip\7z.exe" x -y -o"%%F_tmp" "%%F" * & pushd %%F_tmp & "C:\Program Files\7-Zip\7z.exe" a -y -r -t7z -mx9 -md1024m -mfb256 ..\"%%~nF".7z * & popd & rmdir /s /q "%%F_tmp" )

Or the following, which will automatically split the 7-zip into 2000000-byte chunks that can be directly attached to the post:

@echo off
for %%F in (*.zip,*.rar) do ( "C:\Program Files\7-Zip\7z.exe" x -y -o"%%F_tmp" "%%F" * & pushd %%F_tmp & "C:\Program Files\7-Zip\7z.exe" a -y -r -t7z -mx9 -md1024m -mfb256 -v2000000b ..\"%%~nF".7z * & popd & rmdir /s /q "%%F_tmp" )

The following issue was encountered with DiscImageCreator 20230606:
http://forum.redump.org/topic/52776/ss- … ke-france/

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

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