I've got some trouble with the PC game Silver, Italian original version, protected with SecuROM.
Any drive produce a different dump with different hashes on CD2, while CD1 gets dumped correctly.
I did the tests on the 760A, 716A, 716SA and W5224A, all the dumps have 49 errors instead of just 1 like all the SecuROM CDs.
Usurper back in 2017 http://forum.redump.org/post/54720/#p54720 had a similar problem with his German version discs, and somehow you've managed to fix that, hopefully you can do the same for these discs here.
Here's the three set of logs: https://mega.nz/folder/RlEjiQKI#GBRfDCPMCNWzB5f0j2eXdQ
Let me know if you need something more, i will help and do other tests if it's necessary.
EDIT: Added the logs for disc 1 as well, maybe you want to check that too.

Plextor: PX-W4012TU, PX-W5224TA, Premium, PX-716SA, PX-716A || LG GDR-8164B
HP (Toshiba/Samsung): TS-H353A - Kreon FW || Lite-On SOHD-167D
HP (Hitachi/LG): BH40N - crossflashed with LG BH16NS40 FW || Sony Optiarc AD-7280S

3,327

TonyLizard wrote:

all the dumps have 49 errors

It's weird. Your disc is no c2 and no mainError.

TonyLizard wrote:

Let me know if you need something more

Is there executable binary in disc 2? If there is not, it's difficult to find its protection.

3,328

MrPepka wrote:

when I do, DIC dumps the disk, and then hangs on the headquarters
"Rewrited img (LBA) 248676/299058"
And I don't know if I'm doing it right or wrong. This is how I set up this command
/c2 5000 1 248676 252396

Try to reduce the retry count from 5000 to 20 if the app really hangs.

sarami wrote:

Is there executable binary in disc 2? If there is not, it's difficult to find its protection.

Nope... Absolutely nothing, no executables anywhere. It's just a bunch of game folders and a video game trailer.
I did multiple tries with isobuster, too, and apparently the resulting image file is okay, i've got only one error and consistent hashes.
https://i.ibb.co/gb1tTY1/Screenshot-28.png
https://i.ibb.co/JQY1v53/Screenshot-29.png

Plextor: PX-W4012TU, PX-W5224TA, Premium, PX-716SA, PX-716A || LG GDR-8164B
HP (Toshiba/Samsung): TS-H353A - Kreon FW || Lite-On SOHD-167D
HP (Hitachi/LG): BH40N - crossflashed with LG BH16NS40 FW || Sony Optiarc AD-7280S

3,330 (edited by MrPepka 2022-11-30 23:03:26)

Sarami is it possible for DIC to properly dump DVDs that have data in two layers? I am referring to this disc
http://redump.org/disc/8324/
One user investigated the topic with this game on DSC TCRF and it turned out that the disk with this game in the redump is incorrectly dumped (below the user's quote):
"After some assisted investigating, it appears that a properly-dumped copy of Offroad Fury 4 is so rare that the one in redump's database is actually an incorrectly-dumped one containing no data from the second layer.
Upon further investigation, it seems that all copies ever printed and sold on store shelves ever, used a very poor mastering method.
Basically, the game stores the "movies" folder on the second layer, but uses a strange custom programming to treat the second layer as a second filesystem that's designed to be not visible on computers.   Unmodified ISOs play videos despite you not being able to see them - the data is there, but you can't see it, only the PS2 can.
I couldn't view the videos for the longest time, causing a built in video skip feature to activate, because I was repacking the ISO to test debugging features.  Computers can't see the second layer so I was unintentionally stripping the video files off the ISO.  This is also why the internal build on HiddenPalace has the second layer seperate most likely, and why adding the videos back fixes the issue.
I'm adding this fact to my documentation along with more technical info about it for the eventual TCRF pages (coming soon in 2999)"
Would you research this topic? This is a beta version that seems to be properly dumped
http://redump.org/disc/70926/
http://redump.org/disc/70927/

3,331

MrPepka wrote:

Sarami is it possible for DIC to properly dump DVDs that have data in two layers?

Perhaps, it's not possible due to the filesystem problem.

TonyLizard wrote:

I've got some trouble with the PC game Silver, Italian original version, protected with SecuROM.
Any drive produce a different dump with different hashes on CD2, while CD1 gets dumped correctly.
I did the tests on the 760A, 716A, 716SA and W5224A, all the dumps have 49 errors instead of just 1 like all the SecuROM CDs.
Usurper back in 2017 http://forum.redump.org/post/54720/#p54720 had a similar problem with his German version discs, and somehow you've managed to fix that, hopefully you can do the same for these discs here.
Here's the three set of logs: https://mega.nz/folder/RlEjiQKI#GBRfDCPMCNWzB5f0j2eXdQ
Let me know if you need something more, i will help and do other tests if it's necessary.
EDIT: Added the logs for disc 1 as well, maybe you want to check that too.

Quick update to this issue, i've managed to dump the disc correctly (matching isobuster/clonecd/other drives dumps) using the three flags /np /nq /nr instead of the single /ns flag, and then manually extracting the SecuROM sectors from the .sub file, as Jackal instructed me how to do it with "psxt001z --libcrypt" command.
I've added a SILVER.CD2_logs.zip file to the previous mega link if you want to check the logs, it might be useful for you, or at least i hope so.

Plextor: PX-W4012TU, PX-W5224TA, Premium, PX-716SA, PX-716A || LG GDR-8164B
HP (Toshiba/Samsung): TS-H353A - Kreon FW || Lite-On SOHD-167D
HP (Hitachi/LG): BH40N - crossflashed with LG BH16NS40 FW || Sony Optiarc AD-7280S

3,333 (edited by user7 2022-12-15 04:05:27)

Sarami, is there any downside to adding the "/be pack" command when dumping DC HD Area?

Someone recently told me it helped them and I'm thinking of adding it to the default command in the dumping guide.

---

Also, DIC is reporting HD Area data tracks as "AUDIO" in the cues FYI https://drive.google.com/drive/folders/ … GZxPi7Vkvh

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

3,334

user7 wrote:

Sarami, is there any downside to adding the "/be pack" command when dumping DC HD Area?

Due to "/be pack", _mainError.txt is so big size. This option is not need for Plextor.

3,335

sarami wrote:

Due to "/be pack", _mainError.txt is so big size. This option is not need for Plextor.

Can't help at all? Not in any circumstances?

Why? http://forum.redump.org/post/54562/#p54562

Just looking for details to help the dumping guide, thank you.

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

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

BW-16D1HT | PX-W4824TU | PX-W5224A | PX-760A | Pioneer 209DBK | TS-H352C | TS-H353A | Wii

3,337

bikerspade wrote:

LBA 10714 belongs to the track 2 but I think DIC takes it as a part of track 1

Uploaded test version.
https://www.mediafire.com/file/eq80y20l … st.7z/file

user7 wrote:

Can't help at all? Not in any circumstances?

I'm not sure because I don't have GD-R. Can dump GD-R without /be?

That fixed the problem with this disc. Thank you!

BW-16D1HT | PX-W4824TU | PX-W5224A | PX-760A | Pioneer 209DBK | TS-H352C | TS-H353A | Wii

3,339

bikerspade wrote:

That fixed the problem with this disc. Thank you!

Do you upload logs if possible? I want to see if it's fixed as I expected.

sarami wrote:

Do you upload logs if possible? I want to see if it's fixed as I expected.

Logs

BW-16D1HT | PX-W4824TU | PX-W5224A | PX-760A | Pioneer 209DBK | TS-H352C | TS-H353A | Wii

3,341

bikerspade wrote:

Logs

Ok, it was fixed as I expected.

A relatively recent dump of a particular PCECD disc (Metamor Jupiter) produced a bad track split, where the hashes for track 15 and track 16 are incorrect.

Good:

Size       CRC-32      MD5                                 SHA-1
7215936    fef20b14    2693317a11581563a98f9a9e72b45afc    526e924a854386551b61132530554e09ca451351
1782816    45e68246    e04fcddf7ca970d7145150f75a3f87e3    9582d51f818c8b2199cca857d73436050294969e

Bad:

Size       CRC-32      MD5                                 SHA-1
7213584    b4c98d36    b60e8342f0e91616643f05148e7ea8af    65be947f99c19bee9de86c50e6b5998f074d75e7
1785168    f43f7f32    03269f4c740f5682cd16af5327e3ec5d    af1343106597a462eed5d0f9a99109ac92f03a54

Here are the logs: http://forum.redump.org/misc.php?action … download=1

The checksum for the total img file (074a677b) was correct.
Any ideas what could have caused DIC to produce a bad dump of these two tracks?

BW-16D1HT | PX-W4824TU | PX-W5224A | PX-760A | Pioneer 209DBK | TS-H352C | TS-H353A | Wii

3,343

bikerspade wrote:

A relatively recent dump of a particular PCECD disc (Metamor Jupiter) produced a bad track split, where the hashes for track 15 and track 16 are incorrect.

DB is incorrect. The pregap of the track 16 is 00:03:00, not 00:02:74.

LBA[047436, 0x0b94c]: P[00], Q[01150100386600103436d96b]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[15], Idx[01], RMSF[00:38:66], AMSF[10:34:36]}, RtoW[0, 0, 0, 0]
LBA[047437, 0x0b94d]: P[00], Q[0200000000000000003767c1]{Audio, 2ch, Copy NG, Pre-emphasis No, MediaCatalogNumber [0000000000000], AMSF[     :37]}, RtoW[0, 0, 0, 0]
LBA[047438, 0x0b94e]: P[ff], Q[01160000027300103438dcb1]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[16], Idx[00], RMSF[00:02:73], AMSF[10:34:38]}, RtoW[0, 0, 0, 0]

LBA 47437 belongs to the track 16.

3,344

sarami wrote:
bikerspade wrote:

A relatively recent dump of a particular PCECD disc (Metamor Jupiter) produced a bad track split, where the hashes for track 15 and track 16 are incorrect.

DB is incorrect. The pregap of the track 16 is 00:03:00, not 00:02:74.

LBA[047436, 0x0b94c]: P[00], Q[01150100386600103436d96b]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[15], Idx[01], RMSF[00:38:66], AMSF[10:34:36]}, RtoW[0, 0, 0, 0]
LBA[047437, 0x0b94d]: P[00], Q[0200000000000000003767c1]{Audio, 2ch, Copy NG, Pre-emphasis No, MediaCatalogNumber [0000000000000], AMSF[     :37]}, RtoW[0, 0, 0, 0]
LBA[047438, 0x0b94e]: P[ff], Q[01160000027300103438dcb1]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[16], Idx[00], RMSF[00:02:73], AMSF[10:34:38]}, RtoW[0, 0, 0, 0]

LBA 47437 belongs to the track 16.

sarami, LBA 047437 belongs to track 15. First of all, standard says that if track or index ends with Q without positional information it belongs to the current track, not to the next one. I'm too lazy to search through it but trust me.
Next, check P values from your subchannel decode, P[00] for LBA 047437 shows that it belongs to the previous track.
The dump in DB is correct.

3,345

superg wrote:

it belongs to the current track, not to the next one.

No. See other tracks.

LBA[000000, 0000000]: P[ff], Q[010101000000000002005a28]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[01], Idx[01], RMSF[00:00:00], AMSF[00:02:00]}, RtoW[0, 0, 0, 0]
LBA[000001, 0x00001]: P[00], Q[01010100000100000201e058]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[01], Idx[01], RMSF[00:00:01], AMSF[00:02:01]}, RtoW[0, 0, 0, 0]
LBA[003364, 0x00d24]: P[00], Q[010101004464000046644b69]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[01], Idx[01], RMSF[00:44:64], AMSF[00:46:64]}, RtoW[0, 0, 0, 0]
LBA[003365, 0x00d25]: P[00], Q[01020000027400004665d274]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[02], Idx[00], RMSF[00:02:74], AMSF[00:46:65]}, RtoW[0, 0, 0, 0]
LBA[003366, 0x00d26]: P[ff], Q[0102000002730000466685c3]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[02], Idx[00], RMSF[00:02:73], AMSF[00:46:66]}, RtoW[0, 0, 0, 0]

     :
     :

LBA[136098, 0x213a2]: P[ff], Q[013501061417003016482f95]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[35], Idx[01], RMSF[06:14:17], AMSF[30:16:48]}, RtoW[0, 0, 0, 0]
LBA[136099, 0x213a3]: P[ff], Q[01360100000000301649cc7e]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[36], Idx[01], RMSF[00:00:00], AMSF[30:16:49]}, RtoW[0, 0, 0, 0]
LBA[136100, 0x213a4]: P[00], Q[01360100000100301650e537]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[36], Idx[01], RMSF[00:00:01], AMSF[30:16:50]}, RtoW[0, 0, 0, 0]
LBA[138279, 0x21c27]: P[00], Q[013601002905003045540ab3]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[36], Idx[01], RMSF[00:29:05], AMSF[30:45:54]}, RtoW[0, 0, 0, 0]
LBA[138280, 0x21c28]: P[00], Q[01370000027400304555f71f]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[37], Idx[00], RMSF[00:02:74], AMSF[30:45:55]}, RtoW[0, 0, 0, 0]
LBA[138281, 0x21c29]: P[ff], Q[01370000027300304556a0a8]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[37], Idx[00], RMSF[00:02:73], AMSF[30:45:56]}, RtoW[0, 0, 0, 0]

It's not always but P channel of 1st sector of the track and 2nd sector of the track is different typically.

3,346

sarami wrote:
superg wrote:

it belongs to the current track, not to the next one.

No. See other tracks.
It's not always but P channel of 1st sector of the track and 2nd sector of the track is different typically.

I understand your point that P change is not always an indicator of a track change, no objections here. However this is supplemental thing here.

Main problem is that Mode 2 Q (MCN) @ LBA 47437 separates track 15 and track 16. Here are the reasons why MCN should always belong to the previous track:

1. When playing the music, ordinary audio CD player plays it from left to right, MCN/ISRC frames repeat each 1/100 frames and are informational. Current track number is stored as a current state of audio player and it switches only when it changes in in Mode 1 Q which will happen after the MCN/ISRC as current track information is not stored in Mode 2 or Mode 3 Q.

2. New track always starts from Mode 1 Q. I think I saw that somewhere in rainbow books, unfortunately I cannot find it right now. Although this statement is implied throughout documentation, for instance open MMC-3 working draft page 26:
"4.2.3.4.3 ADR=3 (0011b) – Mode-3 Q"
"The ISRC may only change immediately after the Track Number (TNO) has been changed."

I understand you're trying to do some guesswork based on 150 standard gap size or even establishing that P is shifted 1 sector for each track so start is always shifted in relation to that or something but that is unsafe.

3,347

This is a similar case. Please understand this is not special.

[PCE] Madou Monogatari I - Honoo no Sotsuenji (Japan)
http://redump.org/disc/37150/

LBA[183031, 0x2caf7]: P[ff], Q[01210100317000404231bc6d]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[21], Idx[01], RMSF[00:31:70], AMSF[40:42:31]}, RtoW[0, 0, 0, 0]
LBA[183032, 0x2caf8]: P[ff], Q[020000000000000000323764]{Audio, 2ch, Copy NG, Pre-emphasis No, MediaCatalogNumber [0000000000000], AMSF[     :32]}, RtoW[0, 0, 0, 0]
LBA[183033, 0x2caf9]: P[00], Q[012201000001004042336c90]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[22], Idx[01], RMSF[00:00:01], AMSF[40:42:33]}, RtoW[0, 0, 0, 0]

[PCE] Cosmic Fantasy 3 - Bouken Shounen Rei (Japan)
http://redump.org/disc/2416/

LBA[142873, 0x22e19]: P[ff], Q[41370000000000314673bc02]{ Data,      Copy NG,                  Track[37], Idx[00], RMSF[00:00:00], AMSF[31:46:73]}, RtoW[0, 0, 0, 0]
LBA[142874, 0x22e1a]: P[ff], Q[420000000000000000746d7c]{ Data,      Copy NG,                  MediaCatalogNumber [0000000000000], AMSF[     :74]}, RtoW[0, 0, 0, 0]
LBA[142875, 0x22e1b]: P[00], Q[413701000001003147002c45]{ Data,      Copy NG,                  Track[37], Idx[01], RMSF[00:00:01], AMSF[31:47:00]}, RtoW[0, 0, 0, 0]

LBA[261585, 0x3fdd1]: P[00], Q[01950100136900580960087c]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[95], Idx[01], RMSF[00:13:69], AMSF[58:09:60]}, RtoW[0, 0, 0, 0]
LBA[261586, 0x3fdd2]: P[00], Q[020000000000000000615df2]{Audio, 2ch, Copy NG, Pre-emphasis No, MediaCatalogNumber [0000000000000], AMSF[     :61]}, RtoW[0, 0, 0, 0]
LBA[261587, 0x3fdd3]: P[ff], Q[019600000273005809625f79]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[96], Idx[00], RMSF[00:02:73], AMSF[58:09:62]}, RtoW[0, 0, 0, 0]