DiscImageCreator

[sarami]

 I now get another compilation error

fixed typo (off_t -> off64_t)

[Yurgen]

Okay appears to be working, thanks.

There's a couple of minor display bugs in the Linux ARM build.  It still lists itself as an "x86" application in AppVersion, and all the internal text refers to "drive letter" where it actually takes a path to a block device.  Obviously neither of these stop it from working, but it may cause confusion.

[Yurgen]

More problems.  DiscImageCreator runs and produces output and terminates without error, but the ISO it makes is too small.  And suspiciously exactly two gigabytes.  I've checked the filesystem (tried once on exfat, once on ext4) on volumes with enough space.  Those volumes have files larger than 2 gigs on them, so it's not a filesystem issue. The disc should produce an ISO larger than 2.4 gigabytes.  I've verified that the disc and drive are good.  Just using readom creates a file that matches the hash currently in the database of the correct size.

Because it produces a file that's exactly 2^31 bytes in size, this feels like a signed 32-bit integer is being used somewhere where a 64-bit integer is really needed.

Code: Select all

AppVersion
    x86, AnsiBuild, 20211126T142333
valid extension was omitted. -> set .bin
CurrentDirectory
    /media/optical/ps2_isos/DIC
WorkingPath
     Argument: ./Shadow_Hearts.bin
     FullPath: /media/optical/ps2_isos/DIC/./Shadow_Hearts.bin
        Drive: /
    Directory: media/optical/ps2_isos/DIC/./
     Filename: Shadow_Hearts
    Extension: .bin
StartTime: 2021-11-26T16:15:14+0000
          Block Size: 4096
       Flagment Size: 4096
       All Block Num: 0
      Free Block Num: 6896817
 Available Block Num: 0
          I Node Num: 4633490
     Free I Node Num: 0
Available I Node Num: 4277388
      File System ID: 0
          Mount Flag: 1761280
 Max Filename Length: 0
CurrentDriveSize
    Total:  28249362432 bytes
     Used:  17520181248 bytes
    --------------------------
    Space:  10729181184 bytes
     => There is enough disk space for dumping
Set the drive speed: 11080KB/sec
[F:DVDGetRegion][L:406] GetLastError: 0, Success
Reading DirectoryRecord    2/   2
Creating iso(LBA)  1719024/ 1719024
Hashing: PFI.bin
Hashing: DMI.bin
Hashing: Shadow_Hearts.iso
EndTime: 2021-11-26T16:25:00+0000

[sarami]

I don't have ARM machine, so I can't test.

[superg]

sarami, I got "_alt.cue" and "_imgAlt.cue" when dumping "Suikoden Tierkreis: Digital Artbook & Soundtrack" Enhanced CD.
The cue difference is empty TITLE / PERFORMER vs what I think is Japanese encoding.
Can you please take a look?

Logs: https://www.dropbox.com/s/fexbx20talw1h … 29.7z?dl=0

[sarami]

I got "_alt.cue" and "_imgAlt.cue"

CD-TEXT can store 8 languages.

Code: Select all

                     Language code BLOCK 0: 0x09 (English)
                     Language code BLOCK 1: 0x69 (Japanese)
                     Language code BLOCK 2: 0x00 (not applicable)
                     Language code BLOCK 3: 0x00 (not applicable)
                     Language code BLOCK 4: 0x00 (not applicable)
                     Language code BLOCK 5: 0x00 (not applicable)
                     Language code BLOCK 6: 0x00 (not applicable)
                     Language code BLOCK 7: 0x00 (not applicable)

BLOCK 1 language uses _alt.cue, BLOCK 2 language uses _alt2.cue ... BLOCK 7 language uses _alt7.cue

[superg]

CD-TEXT can store 8 languages.
BLOCK 1 language uses _alt.cue, BLOCK 2 language uses _alt2.cue ... BLOCK 7 language uses _alt7.cue

Got it. So I guess for this particular disc English block is empty and all the meaningful data is in the Japanese CD-TEXT block.
My next question is, what encoding gets dumped to the BLOCK 1 cue?
I'm getting garbage there but I don't have JP fonts installed and no Japanese locale. We would need that corrected (I guess manually in a cue sheet) in order to be added to redump.

EDIT: Nevermind, notepad++ displays everything correctly, it was my viewer which had a problem, thank you!

[Nicknine]

https://redump.info/disc/21540/
https://redump.info/disc/7269/

I believe DIC incorrectly identifies these two discs as SecuROM 3 (this game is SecuROM 4). SecuROM sectors table here is nonsense and subIntention log contains "shifted sub" entries, this stuff should only be detected for SecuROM 3 according to the code. There's the intentional error at LBA -1, too, which is a SecuROM 4 attribute.

EDIT: Never mind, it looks like it's the website that's parsing subIntention data incorrectly. I think SBI is correct.

[Jackal]

Hi,

this disc has a strange track01 pregap: https://redump.info/disc/87558/

Logs: https://mega.nz/folder/AYoggTyS#-S138gR9lRjgqzx9d_d-8A

Is it correct?

[sarami]

Is it correct?

SubQ indicates it is correct.

Code: Select all

LBA[000000, 0000000]: P[ff], Q[410100000005000002004cb6]{ Data,      Copy NG,                  Track[01], Idx[00], RMSF[00:00:05], AMSF[00:02:00]}, RtoW[0, 0, 0, 0]
LBA[000001, 0x00001]: P[ff], Q[41010000000400000201f6c6]{ Data,      Copy NG,                  Track[01], Idx[00], RMSF[00:00:04], AMSF[00:02:01]}, RtoW[0, 0, 0, 0]
LBA[000002, 0x00002]: P[ff], Q[41010000000300000202a171]{ Data,      Copy NG,                  Track[01], Idx[00], RMSF[00:00:03], AMSF[00:02:02]}, RtoW[0, 0, 0, 0]
LBA[000003, 0x00003]: P[ff], Q[410100000002000002031b01]{ Data,      Copy NG,                  Track[01], Idx[00], RMSF[00:00:02], AMSF[00:02:03]}, RtoW[0, 0, 0, 0]
LBA[000004, 0x00004]: P[ff], Q[410100000001000002048534]{ Data,      Copy NG,                  Track[01], Idx[00], RMSF[00:00:01], AMSF[00:02:04]}, RtoW[0, 0, 0, 0]
LBA[000005, 0x00005]: P[ff], Q[410101000000000002057897]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:00], AMSF[00:02:05]}, RtoW[0, 0, 0, 0]
LBA[000006, 0x00006]: P[00], Q[41010100000100000206e2a5]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:01], AMSF[00:02:06]}, RtoW[0, 0, 0, 0]
LBA[000007, 0x00007]: P[00], Q[410101000002000002071c56]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:02], AMSF[00:02:07]}, RtoW[0, 0, 0, 0]