3,126 (edited by NovaAurora 2021-11-08 06:57:20)

We've been discussing how to handle Audio CDs with data in the lead-in/lead-out when dumped at the default offset of DIC (See: http://redump.org/disc/28088/), and would like to ask if it's possible to:

*Scan lead-in and lead-out for non-zero data
*Calculate required offset to include data
*Prompt user (Y/N) if they would like to offset correspondingly
or
*a flag for this option, which MPF can implement as a default flag for Audio CDs (With a warning when flag not present)

Please let us know how you feel about implementing this or if there are any issues with this method.

PX-W4012TA ☆ PX-716A ☆ LG WH16NS40 (JB7) ☆ TS-H352C
Wii ☆ Wii U ☆ PSP ☆ SOHD-167T ☆ 209DBK ☆ X360 HDDVD

3,127 (edited by sarami 2021-11-13 01:33:52)

https://github.com/saramibreak/DiscImag … /issues/95
If non-zero byte exists in the 1st lead-out, fix the combined offset.
If non-zero byte exists in LBA -1, check only.

3,128 (edited by Jackal 2021-11-16 19:40:20)

Latest DIC still outputting incorrect multisession cuesheets? http://forum.redump.org/topic/41246/ibm … intergame/

And DIC or MPF are always scanning the .img instead of the .bin files, resulting in an incorrect error count for multisession discs. The gap between the sessions should not be included in the error count, because it's not included in the .bin tracks.

User was using outdated July version, latest DIC has a fixed cuesheet, but it is still scanning the .img instead of .bin as mentioned above.

PX-W4012TA ☆ PX-716A ☆ LG WH16NS40 (JB7) ☆ TS-H352C
Wii ☆ Wii U ☆ PSP ☆ SOHD-167T ☆ 209DBK ☆ X360 HDDVD

I mentioned this in another thread, but it might be more of interest to those in this thread:

I believe the Vinpower variant of the WH16NS48 (SVC Code 40) firmware (version 1.D3) may potentially be a good firmware for scrambled dumping on SVC Code NS40 drives. (Drives that, AFAIK, generally can't run the BW-16D1HT firmware, because it's designed for drives with SVC Code NS50.) This is a firmware that is somewhat popular in the disc burning community, because, unlike other firmwares, it supports doing quality scans on BD, BD-R, and BD-RE discs. As a bonus, it looks like it also supports scrambled reads via 0xBE and supports 0xF1 for reading from the cache. DIC doesn't currently have the drive in the database of 0xF1 capable drives, but I did a build of DIC with this drive added to the 0xF1 capable list and was able to dump a 0 offset disc (one that requires /mr in order to fetch lead-out sectors), and the dump matched the dump I previously made with my BW-16D1HT drive.

Maybe this is common knowledge, but I thought I'd mention it, because I didn't see this firmware mentioned in the Wiki and DIC doesn't recognize it. In fact, DIC doesn't even know the offset (+6 samples), because the WH16NS48 isn't in the driveOffsets.txt.

3,131

Jackal wrote:

scanning the .img instead of the .bin files, resulting in an incorrect error count for multisession discs.

https://www.mediafire.com/file/eq80y20l … st.7z/file
- changed: do not check 11400 sectors of lead-in and lead-out

3,132 (edited by user7 2021-11-19 23:24:40)

Old and new DIC builds, I'm getting an error with a particular disc in good-enough condition. It's a later Xbox (OG) kiosk disc.

https://drive.google.com/file/d/1t5gf0r … sp=sharing

---

Also the feature to calculate enough free space is broken. I tried dumping a PS3 disc with 119GB free on my hard drive and I got an error. Neat feature though.

All my posts and submission data are released into Public Domain / CC0.

3,133 (edited by scsi_wuzzy 2021-11-20 04:07:56)

user7 wrote:

Old and new DIC builds, I'm getting an error with a particular disc in good-enough condition. It's a later Xbox (OG) kiosk disc.

I can't recall if this was the same error that my drives threw, but I've had a couple of Xbox discs, in great condition by all appearances, that wouldn't read. I suspect there was some manufacturing error that might have resulted in some discs having a short life. I know that at least one of the discs worked when it was new, but it no longer does. I also noticed that, when I scanned the disc in my flatbed scanner, the scan had lots of tiny little black spots, as if maybe the reflective layer has oxidized in some spots?

3,134

scsi_wuzzy wrote:
user7 wrote:

Old and new DIC builds, I'm getting an error with a particular disc in good-enough condition. It's a later Xbox (OG) kiosk disc.

I can't recall if this was the same error that my drives threw, but I've had a couple of Xbox discs, in great condition by all appearances, that wouldn't read. I suspect there was some manufacturing error that might have resulted in some discs having a short life. I know that at least one of the discs worked when it was new, but it no longer does. I also noticed that, when I scanned the disc in my flatbed scanner, the scan had lots of tiny little black spots, as if maybe the reflective layer has oxidized in some spots?

I've seen instances of chemical failure before on Xbox discs - not seeing any indicators here. I might send this to a friend to test on his 0800.

All my posts and submission data are released into Public Domain / CC0.

3,135

user7 wrote:

Also the feature to calculate enough free space is broken. I tried dumping a PS3 disc with 119GB free on my hard drive and I got an error.

'bd' command supposes BDXL-R QL.

user7 wrote:

Old and new DIC builds, I'm getting an error with a particular disc in good-enough condition. It's a later Xbox (OG) kiosk disc.

LBA[1913094, 0x1d3106]: [F:ReadXBOXDirectoryRecord][L:1192]
    Opcode: 0xa8
    ScsiStatus: 0x02 = CHECK_CONDITION
    SenseData Key-Asc-Ascq: 03-02-00 = MEDIUM_ERROR - NO SEEK COMPLETE

Kreon does not support this disc?

3,136

sarami wrote:
user7 wrote:

Also the feature to calculate enough free space is broken. I tried dumping a PS3 disc with 119GB free on my hard drive and I got an error.

'bd' command supposes BDXL-R QL.

Is there an alternative command or I can't dump PS3 discs anymore?

All my posts and submission data are released into Public Domain / CC0.

I think the issue is this part of the code:

    if ((*pExecType == cd && ui64Avail.QuadPart > 3000000000) ||
        (*pExecType == swap && ui64Avail.QuadPart > 3000000000) ||
        (*pExecType == data && ui64Avail.QuadPart > 3000000000) ||
        (*pExecType == audio && ui64Avail.QuadPart > 3000000000) ||
        (*pExecType == gd && ui64Avail.QuadPart > 4000000000) ||
        (*pExecType == dvd && ui64Avail.QuadPart > 9000000000) ||
        (*pExecType == xbox && ui64Avail.QuadPart > 9000000000) ||
        (*pExecType == xboxswap && ui64Avail.QuadPart > 9000000000) ||
        (*pExecType == xgd2swap && ui64Avail.QuadPart > 9000000000) ||
        (*pExecType == xgd3swap && ui64Avail.QuadPart > 9000000000) ||
        (*pExecType == sacd && ui64Avail.QuadPart > 9000000000) ||
        (*pExecType == bd && ui64Avail.QuadPart > 130000000000)
        ) {
        OutputString("\t => There is enough disk space for dumping\n");

All values are hardcoded instead of being calculated per disk.

3,138

I get the following errors when attempting to build from source with GNU Make 4.2.1 on ARM, default settings.  Am I missing deps?  Or some environment variable?

g++ -c -o calcHash.o calcHash.cpp -include _linux/defineForLinux.h -std=c++11 -O2 -Wall -Wextra -Wno-unknown-pragmas -Waggregate-return -Wcast-align -Wcast-qual -Wconditionally-supported -Wdisabled-optimization -Wdouble-promotion -Wfloat-equal -Wformat=2 -Wformat-signedness -Winit-self -Winline -Winvalid-pch -Wlogical-op -Wmissing-include-dirs -Wmultichar -Wnoexcept -Woverlength-strings -Wpacked -Wpointer-arith -Wredundant-decls -Wshadow -Wstack-protector -Wstrict-aliasing=2 -Wstrict-null-sentinel -Wswitch-default -Wswitch-enum -Wtrampolines -Wvariadic-macros -Wvector-operation-performance -Wwrite-strings -Wunused-macros -I. -I_external -I_linux
In file included from <command-line>:
./_linux/defineForLinux.h:26:9: error: ‘_W64’ does not name a type
 typedef _W64 int INT_PTR, * PINT_PTR;
         ^~~~
./_linux/defineForLinux.h:27:9: error: ‘_W64’ does not name a type
 typedef _W64 unsigned int UINT_PTR, * PUINT_PTR;
         ^~~~
./_linux/defineForLinux.h:29:9: error: ‘_W64’ does not name a type
 typedef _W64 long LONG_PTR, * PLONG_PTR;
         ^~~~
./_linux/defineForLinux.h:30:9: error: ‘_W64’ does not name a type
 typedef _W64 unsigned long ULONG_PTR, * PULONG_PTR;
         ^~~~
./_linux/defineForLinux.h:40:9: error: ‘ULONG_PTR’ does not name a type; did you mean ‘ULONG_MAX’?
 typedef ULONG_PTR DWORD_PTR, *PDWORD_PTR;
         ^~~~~~~~~
         ULONG_MAX
make: *** [makefile:67: calcHash.o] Error 1

G++ version:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/8/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Raspbian 8.3.0-6+rpi1' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-support --enable-plugin --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --disable-werror --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 8.3.0 (Raspbian 8.3.0-6+rpi1) 

3,139

Yurgen wrote:

I get the following errors when attempting to build from source with GNU Make 4.2.1 on ARM, default settings.  Am I missing deps?  Or some environment variable?

removed _W64
https://github.com/saramibreak/DiscImageCreator

3,140

Thanks for thew quick reply.   I now get another compilation error when the makefile reaches sha1.cpp.  Looks like more type errors:

g++ -c -o _external/sha1.o _external/sha1.cpp -include _linux/defineForLinux.h -std=c++11 -O2 -Wall -Wextra -Wno-unknown-pragmas -Waggregate-return -Wcast-align -Wcast-qual -Wconditionally-supported -Wdisabled-optimization -Wdouble-promotion -Wfloat-equal -Wformat=2 -Wformat-signedness -Winit-self -Winline -Winvalid-pch -Wlogical-op -Wmissing-include-dirs -Wmultichar -Wnoexcept -Woverlength-strings -Wpacked -Wpointer-arith -Wredundant-decls -Wshadow -Wstack-protector -Wstrict-aliasing=2 -Wstrict-null-sentinel -Wswitch-default -Wswitch-enum -Wtrampolines -Wvariadic-macros -Wvector-operation-performance -Wwrite-strings -Wunused-macros -I. -I_external -I_linux
g++ -c -o _linux/defineForLinux.o _linux/defineForLinux.cpp -include _linux/defineForLinux.h -std=c++11 -O2 -Wall -Wextra -Wno-unknown-pragmas -Waggregate-return -Wcast-align -Wcast-qual -Wconditionally-supported -Wdisabled-optimization -Wdouble-promotion -Wfloat-equal -Wformat=2 -Wformat-signedness -Winit-self -Winline -Winvalid-pch -Wlogical-op -Wmissing-include-dirs -Wmultichar -Wnoexcept -Woverlength-strings -Wpacked -Wpointer-arith -Wredundant-decls -Wshadow -Wstack-protector -Wstrict-aliasing=2 -Wstrict-null-sentinel -Wswitch-default -Wswitch-enum -Wtrampolines -Wvariadic-macros -Wvector-operation-performance -Wwrite-strings -Wunused-macros -I. -I_external -I_linux
_linux/defineForLinux.cpp: In function ‘void _splitpath(const char*, char*, char*, char*, char*)’:
_linux/defineForLinux.cpp:36:28: warning: cast from type ‘const char*’ to type ‘char*’ casts away qualifiers [-Wcast-qual]
  char* CopyOfPath = (char*)Path;
                            ^~~~
_linux/defineForLinux.cpp: At global scope:
_linux/defineForLinux.cpp:409:7: error: ambiguating new declaration of ‘off_t SetFilePointerEx(int, LARGE_INTEGER, void*, int)’
 off_t SetFilePointerEx(int fd, LARGE_INTEGER pos, void* a, int origin)
       ^~~~~~~~~~~~~~~~
In file included from <command-line>:
./_linux/defineForLinux.h:2445:9: note: old declaration ‘off64_t SetFilePointerEx(int, LARGE_INTEGER, void*, int)’
 off64_t SetFilePointerEx(int fd, LARGE_INTEGER pos, void* a, int origin);
         ^~~~~~~~~~~~~~~~
_linux/defineForLinux.cpp: In function ‘int GetDiskFreeSpaceEx(LPCSTR, PULARGE_INTEGER, PULARGE_INTEGER, PULARGE_INTEGER)’:
_linux/defineForLinux.cpp:447:3: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘__fsblkcnt64_t’ {aka ‘long long unsigned int’} [-Wformat=]
   "          Block Size: %lu\n"
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   "       Flagment Size: %lu\n"
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   "       All Block Num: %lu\n"
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   "      Free Block Num: %lu\n"
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   " Available Block Num: %lu\n"
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   "          I Node Num: %lu\n"
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   "     Free I Node Num: %lu\n"
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   "Available I Node Num: %lu\n"
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   "      File System ID: %lu\n"
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   "          Mount Flag: %lu\n"
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   " Max Filename Length: %lu\n"
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_linux/defineForLinux.cpp:459:5:
   , buf.f_blocks, buf.f_bfree, buf.f_bavail
     ~~~~~~~~~~~~
_linux/defineForLinux.cpp:447:3: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘__fsblkcnt64_t’ {aka ‘long long unsigned int’} [-Wformat=]
_linux/defineForLinux.cpp:447:3: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 6 has type ‘__fsblkcnt64_t’ {aka ‘long long unsigned int’} [-Wformat=]
_linux/defineForLinux.cpp:447:3: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 7 has type ‘__fsfilcnt64_t’ {aka ‘long long unsigned int’} [-Wformat=]
_linux/defineForLinux.cpp:447:3: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 8 has type ‘__fsfilcnt64_t’ {aka ‘long long unsigned int’} [-Wformat=]
_linux/defineForLinux.cpp:447:3: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 9 has type ‘__fsfilcnt64_t’ {aka ‘long long unsigned int’} [-Wformat=]
make: *** [makefile:67: _linux/defineForLinux.o] Error 1

3,141

Yurgen wrote:

 I now get another compilation error

fixed typo (off_t -> off64_t)

3,142

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.

3,143

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.

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

3,144

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

3,145

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

3,146

superg wrote:

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

CD-TEXT can store 8 languages.

                     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

3,147 (edited by superg 2021-11-30 03:40:43)

sarami wrote:

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!

3,148 (edited by Nicknine 2021-11-30 20:26:18)

http://redump.org/disc/21540/
http://redump.org/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.

3,149

Hi,

this disc has a strange track01 pregap: http://redump.org/disc/87558/

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

Is it correct?

3,150

Jackal wrote:

Is it correct?

SubQ indicates it is correct.

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]