2,851 (edited by Aringon 2021-05-01 17:17:03)

Aringon wrote:

I used multiple drives to test many times.

Only ASUS BW-16D1HT 3.02?

No, an ASUS and some random drive that I have lying around that won't work with DIC. I don't have a functioning plextor at the moment.

If you're trying to buy a copy of the disc to try yourself, grab the one without the "Fisher-Price New!" logo on the case. A lot of sellers aren't courteous enough to take photos of the disc so you'll likely need to get a sealed copy or something to be sure.

2,852

sarami wrote:

BCD did not matter...
Fixed again.
https://www.mediafire.com/file/eq80y20l … st.7z/file

Next: test4.7z

2,853

sarami wrote:
user7 wrote:

Dumps reliably with Isobuster on two computers.

Does it mean you also have Scooby-Doo! 2.0.0 and dumped it with plextor using DIC?

Shit no I misspoke. I meant to say he dumped with the asus

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

2,854

rosewood wrote:
sarami wrote:

BCD did not matter...
Fixed again.
https://www.mediafire.com/file/eq80y20l … st.7z/file

Next: test4.7z

The subchannel was fixed as I expected.

LBA[011100, 0x02b5c]: Track[01]: SubQ[13-19]:Adr6[cf3cf0cff0fbf000] -> [cf3cf0cff0fff000]

But the fixed sub is not set correctly...

LBA[011100, 0x02b5c]: P[00], Q[46d542f21700fbf00000bccb]{ Data,      Copy NG,                  Unknown Data    [d542f21700fbf000], AMSF[     :00]}, RtoW[0, 0, 0, 0]

Re-uploaded.
https://www.mediafire.com/file/eq80y20l … st.7z/file


Aringon wrote:

If you're trying to buy a copy of the disc to try yourself, grab the one without the "Fisher-Price New!" logo on the case. A lot of sellers aren't courteous enough to take photos of the disc so you'll likely need to get a sealed copy or something to be sure.

Please write down and tell me amazon or ebay link of the disc.

Common Disc Info:
    Title: 
    Media Type: CD-ROM
    Region: 
    Languages:
    Disc Serial:

    Ringcode Information:
        Data Side Mastering Code (laser branded/etched):
        Data Side Mastering SID Code:
        Data Side Toolstamp or Mastering Code (engraved/stamped): 
        Data Side Mould SID Code:
        Data Side Additional Mould:
        Label Side Mould SID Code:
        Label Side Additional Mould: 
    Barcode:

2,855

sarami wrote:

The subchannel was fixed as I expected.

LBA[011100, 0x02b5c]: Track[01]: SubQ[13-19]:Adr6[cf3cf0cff0fbf000] -> [cf3cf0cff0fff000]

But the fixed sub is not set correctly...

LBA[011100, 0x02b5c]: P[00], Q[46d542f21700fbf00000bccb]{ Data,      Copy NG,                  Unknown Data    [d542f21700fbf000], AMSF[     :00]}, RtoW[0, 0, 0, 0]

Re-uploaded.
https://www.mediafire.com/file/eq80y20l … st.7z/file

Next: test5.7z

2,856 (edited by Aringon 2021-05-03 01:46:42)

sarami wrote:

Please write down and tell me amazon or ebay link of the disc.

This should be a 2.0.0 scooby-doo! afaict https://www.ebay.com/itm/203290414531

Alternatively I can just send you a copy if you're down for it. I really don't need 3.

2,857

sarami wrote:

But the fixed sub is not set correctly...

Sorry, still buggy.
Uploaded. https://www.mediafire.com/file/eq80y20l … st.7z/file

2,858

sarami wrote:
sarami wrote:

But the fixed sub is not set correctly...

Sorry, still buggy.
Uploaded. https://www.mediafire.com/file/eq80y20l … st.7z/file

Next: test6.7z

2,859

rosewood wrote:
sarami wrote:
sarami wrote:

But the fixed sub is not set correctly...

Sorry, still buggy.
Uploaded. https://www.mediafire.com/file/eq80y20l … st.7z/file

Next: test6.7z

This is the last (perhaps).
https://www.mediafire.com/file/eq80y20l … st.7z/file

2,860 (edited by rosewood 2021-05-04 06:03:21)

sarami wrote:

This is the last (perhaps).
https://www.mediafire.com/file/eq80y20l … st.7z/file

Let's hope so. This title has been dumped more often than anything else wink
test7.7z

2,861

rosewood wrote:
sarami wrote:

This is the last (perhaps).
https://www.mediafire.com/file/eq80y20l … st.7z/file

Let's hope so. This title has been dumped more often than anything else wink
test7.7z

Ok. Adr6 has been fixed. Thanks for all testing.

Hey sarami, can you please check these logs as I have these discs with SecuROM (unknown version, but the scan reveals it) that will dump without the intentional SecuROM error. Thank you.

https://mega.nz/file/VuQUCZJD#2c6T_Z0j2 … eteBQ-kaHU
https://mega.nz/file/xrYCiRwI#xYCAN7HpN … p637oGeekM

Salviamo la cultura videoludica italiana.

2,863

LoStraniero91 wrote:

without the intentional SecuROM error.

Yes, there is not SecuROM error in _subError.txt. Probably, it is deactivated.

sarami wrote:
LoStraniero91 wrote:

without the intentional SecuROM error.

Yes, there is not SecuROM error in _subError.txt. Probably, it is deactivated.

Very weird indeed. First log is for Might & Magic VI and with PCem it acts just like other old SecuROM games: it just hangs when launching it. Second log is Jeff Wayne and it runs fine. Do you need more data/logs for them?

Salviamo la cultura videoludica italiana.

2,865 (edited by sarami 2021-05-07 16:48:34)

LoStraniero91 wrote:

First log is for Might & Magic VI and with PCem it acts just like other old SecuROM games: it just hangs when launching it.

1. What is the region? GER, JPN, KOR, and USA don't have the protection. http://redump.org/discs/system/pc/letter/m/?page=3
2. How about other emulators or virtual machines (Virtual Box, VMware)?

sarami wrote:
LoStraniero91 wrote:

First log is for Might & Magic VI and with PCem it acts just like other old SecuROM games: it just hangs when launching it.

1. What is the region? GER, JPN, KOR, and USA don't have the protection. http://redump.org/discs/system/pc/letter/m/?page=3
2. How about other emulators or virtual machines (Virtual Box, VMware)?

1. Both games have 2 discs and are ITA.
2. Other emulatos won't work, VMWare only supports Direct3D acceleration/emulation starting from Windows XP. But I do have a PC with W98.

Also, I can do further tests because these games were sent by McNelly and he had issues with them and this pesky SecuROM. It's just confusing and I hope to be done with them in short time.

Salviamo la cultura videoludica italiana.

2,867 (edited by LoStraniero91 2021-05-09 11:47:19)

Ok sarami I have some updates:

Jeff Wayne works fine with PCem, probably a false positive.
But M&MIV is weird: I have installed the game on the 98 machine and it simply refuses to run even with the disc (not the one I've sent you the logs, but the "Play Disc"). But there's a catch: if I enable the SecuROM emulation in Daemon Tools, the game will boot with the bin/cue image. Seems like they screwed up the SecuROM protection while mastering the discs (it's a released by Wanted Games). There's no SecuROM sector but there are some leftovers that will still cause issues.

Salviamo la cultura videoludica italiana.

2,868

- improved: multi sector reading of the 0xf1 drive
https://www.mediafire.com/file/eq80y20l … st.7z/file
added argument in /mr

Retry 20 times

DiscImageCreator.exe cd f E:\!redump\zzz.bin 0 /c2 /mr 20

Retry 100 times

DiscImageCreator.exe cd f E:\!redump\zzz.bin 0 /c2 /mr 100

Default retry times are 50.

DiscImageCreator.exe cd f E:\!redump\zzz.bin 0 /c2 /mr

2,869

Hi Sarami,

Just wondering if you could make DIC save the console output into a log file automatically, like the one below?
I know all the necessary information can be found in other files but this could give us a quick overview of the whole dumping process. What do you think?


EBE_A.log:

# DiscImageCreator.exe cd j EBE_A.bin 8 /c2 /s 2
AppVersion
        x86, AnsiBuild, 20210301T232713
/c2 val1 was omitted. set [4000]
/c2 val2 was omitted. set [0]
CurrentDirectory
        D:\Program\Media\Dumping\DiscImageCreator\Release_ANSI
WorkingPath
         Argument: EBE_A.bin
         FullPath: D:\Program\Media\Dumping\DiscImageCreator\Release_ANSI\EBE_A.bin
            Drive: D:
        Directory: \Program\Media\Dumping\DiscImageCreator\Release_ANSI\
         Filename: EBE_A
        Extension: .bin
StartTime: 2021-04-12T20:31:53+0800
Set the drive speed: 1411KB/sec
This drive supports [OpCode: 0xd8, SubCode: 0]
This drive supports [OpCode: 0xd8, SubCode: 1]
This drive supports [OpCode: 0xd8, SubCode: 2]
This drive supports [OpCode: 0xd8, SubCode: 8]
Checking reading lead-out -> OK
Checking SubQ adr (Track) 25/25
Checking SubRtoW (Track) 25/25
Checking Pregap sync, msf, mode (LBA)  -2245
Set OpCode: 0xd8, SubCode: 8(Raw)
Checking SubQ ctl (Track) 25/25
Creating .scm (LBA) 265829/265829
No C2 errors
Copying .scm to .img
Descrambling data sector of img:  66611/ 66611
Exec ""D:\Program\Media\Dumping\DiscImageCreator\Release_ANSI\EccEdc.exe" check "D:\Program\Media\Dumping\DiscImageCreator\Release_ANSI\EBE_A.img""
FILE: D:\Program\Media\Dumping\DiscImageCreator\Release_ANSI\EBE_A.img
Checking sectors: 265828/265828
[ERROR] Number of sector(s) where user data doesn't match the expected ECC/EDC: 75
Total errors: 75
Total warnings: 0
Creating cue and ccd (Track) 25/25
Creating bin (Track) 25/25
Hashing: EBE_A.scm
Hashing: EBE_A.img
Hashing: EBE_A (Track 01).bin
Hashing: EBE_A (Track 02).bin
Hashing: EBE_A (Track 03).bin
Hashing: EBE_A (Track 04).bin
Hashing: EBE_A (Track 05).bin
Hashing: EBE_A (Track 06).bin
Hashing: EBE_A (Track 07).bin
Hashing: EBE_A (Track 08).bin
Hashing: EBE_A (Track 09).bin
Hashing: EBE_A (Track 10).bin
Hashing: EBE_A (Track 11).bin
Hashing: EBE_A (Track 12).bin
Hashing: EBE_A (Track 13).bin
Hashing: EBE_A (Track 14).bin
Hashing: EBE_A (Track 15).bin
Hashing: EBE_A (Track 16).bin
Hashing: EBE_A (Track 17).bin
Hashing: EBE_A (Track 18).bin
Hashing: EBE_A (Track 19).bin
Hashing: EBE_A (Track 20).bin
Hashing: EBE_A (Track 21).bin
Hashing: EBE_A (Track 22).bin
Hashing: EBE_A (Track 23).bin
Hashing: EBE_A (Track 24).bin
Hashing: EBE_A (Track 25).bin
EndTime: 2021-04-12T20:41:01+0800

2,870 (edited by Jackal 2021-05-17 20:21:28)

DopefishJustin submitted a verification for this disc: http://redump.org/disc/65563/

The audio tracks all seem to the data starting 4 bytes later than Nexy's Plextor dump. So the offset difference is 1 sample.

It was dumped with ASUS BW-16D1HT . Logs: http://interbutt.com/misc/WARCRAFT2_X_logs.zip

We need to know if this is a problem with the ASUS drives. I've warned before that we can't really trust them because it's all just experimental and never fully tested, yet DIC keeps supporting them and now perhaps the DB is being filled with bad dumps that are done with these drives.

edit: And here another ASUS dump: http://forum.redump.org/post/89943/#p89943 where all tracks match this dump http://redump.org/disc/71231/ except the last track. Could it be cut off data? Or just a different pressing?

I have both Plextor PX760 and Asus BW-16D1HT and I've been dumping discs with both of them since quite some time. After dumping few hundreds discs (with both of them for comparision) I can say that Asus is not 100% reliable with positive combined offset discs where data is taken from cache.

From time to time last few samples are bad (for example if combined offset is X samples I get X last samples bad). I haven't debugged if it's firmware issue or DIC bug). Most of the time reripping the disc 2nd time produces correct dump.

http://forum.redump.org/post/89943/#p89943 -> I have this issue. Most probably bad dump. Rerip.

> The audio tracks all seem to the data starting 4 bytes later than Nexy's Plextor dump

Haven't observed it. Probably different master disc.

Example off hand (Asus):

LBA[378268, 0x5c59c], mode 1
LBA[378269, 0x5c59d], mode 1
LBA[378270, 0x5c59e], mode 1
LBA[378271, 0x5c59f], mode 1 User data vs. ecc/edc doesn't match
[ERROR] Number of sector(s) where user data doesn't match the expected ECC/EDC: 1
    Sector: 378271, 

If you see this in console:

========== Reading 378251 - 378271 INTO CACHE ==========
01 Cache LBA 378251, SubQ Trk 01, AMSF 84:05:27
02 Cache LBA 378252, SubQ Trk 01, AMSF 84:05:28
03 Cache LBA 378253, SubQ Trk 01, AMSF 84:05:29
04 Cache LBA 378254, SubQ Trk 01, AMSF 84:05:30
05 Cache LBA 378255, SubQ Trk 01, AMSF 84:05:31
06 Cache LBA 378256, SubQ Trk 01, AMSF 84:05:32
07 Cache LBA 378257, SubQ Trk 01, AMSF 84:05:33
08 Cache LBA 378258, SubQ Trk 01, AMSF 84:05:34
09 Cache LBA 378259, SubQ Trk 01, AMSF 84:05:35
10 Cache LBA 378260, SubQ Trk 01, AMSF 84:05:36
11 Cache LBA 378261, SubQ Trk 01, AMSF 84:05:37
12 Cache LBA 378262, SubQ Trk 01, AMSF 84:05:38
13 Cache LBA 378263, SubQ Trk 01, AMSF 84:05:39
14 Cache LBA 378264, SubQ Trk 01, AMSF 84:05:40
15 Cache LBA 378265, SubQ Trk 01, AMSF 84:05:41
16 Cache LBA 378266, SubQ Trk 01, AMSF 84:05:42
17 Cache LBA 378267, SubQ Trk 01, AMSF 84:05:43
18 Cache LBA 378268, SubQ Trk 01, AMSF 84:05:44
19 Cache LBA 378269, SubQ Trk 01, AMSF 84:05:45
20 Cache LBA 378270, SubQ Trk 01, AMSF 84:05:46
21 Cache LBA 378271, SubQ Trk aa, AMSF 84:05:47
22 Cache LBA 378272, SubQ Trk aa, AMSF 84:05:48 [Lead-out]
23 Cache LBA 378273, SubQ Trk aa, AMSF 84:05:49 [Lead-out]
24 Cache LBA 378274, SubQ Trk aa, AMSF 84:05:50 [Lead-out]
25 Cache LBA 378275, SubQ Trk aa, AMSF 84:05:51 [Lead-out]
26 Cache LBA 378276, SubQ Trk aa, AMSF 84:05:52 [Lead-out]
27 Cache LBA 378277, SubQ Trk aa, AMSF 84:05:53 [Lead-out]
28 Cache LBA 378278, SubQ Trk aa, AMSF 84:05:54 [Lead-out]
29 Cache LBA 378279, SubQ Trk aa, AMSF 84:05:55 [Lead-out]
30 Cache LBA 378280, SubQ Trk aa, AMSF 84:05:56 [Lead-out]
31 Cache LBA 378281, SubQ Trk aa, AMSF 84:05:57 [Lead-out]
32 Cache LBA 378282, SubQ Trk aa, AMSF 84:05:58 [Lead-out]
33 Cache LBA 378283, SubQ Trk aa, AMSF 84:05:59 [Lead-out]
34 Cache LBA 378284, SubQ Trk aa, AMSF 84:05:60 [Lead-out]
35 Cache LBA 378285, SubQ Trk aa, AMSF 84:05:61 [Lead-out]
36 Cache LBA 378286, SubQ Trk aa, AMSF 84:05:62 [Lead-out]
37 Cache LBA 378287, SubQ Trk aa, AMSF 84:05:63 [Lead-out]
38 Cache LBA 378288, SubQ Trk aa, AMSF 84:05:64 [Lead-out]

Better watch out for bad dumpies...

IMHO audio tracks made with Asus and positive offset discs should be temp banned unless fully resolved smile

Post's attachments

Przechwytywanie.PNG 29.71 kb, 12 downloads since 2021-05-18 

You don't have the permssions to download the attachments of this post.

2,872

reentrant wrote:

IMHO audio tracks made with Asus and positive offset discs should be temp banned unless fully resolved smile

Please test by the latest version. https://www.mediafire.com/file/eq80y20l … st.7z/file

2,873

IMHO audio tracks made with Asus and positive offset discs should be temp banned unless fully resolved smile

Positive write offset or combined offset?

@sarami any theory on why the offset might be shifted with 1 sample?

Nexy is gone so I guess we either need a Plextor dump from the new dumper or someone else to confirm (the disc is on ebay)

2,874

Jackal wrote:

@sarami any theory on why the offset might be shifted with 1 sample?

reentrant wrote:

Probably different master disc.

I think so, too.

Jackal wrote:

edit: And here another ASUS dump: http://forum.redump.org/post/89943/#p89943 where all tracks match this dump http://redump.org/disc/71231/ except the last track. Could it be cut off data? Or just a different pressing?

It seems these last 24 bytes are obtained.

0910 : FB FF FE FF FA FF FD FF  FB FF FC FF FB FF FD FF   ................
0920 : FB FF FB FF FA FF FC FF  FA FF FC FF F9 FF FB FF   ................
========== Cached Main Channel [Lead-out] ==========
========== LBA[245056, 0x3bd40]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : F9 FF F9 FF F9 FF FB FF  F6 FF FA FF F6 FF F9 FF   ................
0010 : F7 FF F8 FF F6 FF F9 FF  00 00 00 00 00 00 00 00   ................
0020 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0030 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................

Which byte of sector is different?

2,875 (edited by reentrant 2021-05-18 18:09:38)

Jackal: combined offset (if > 0 cache is used).

I replicated the issue locally (last few samples are bad - 6 in my case). Disc is 0 offset (combined 6). I have also modified DIC to dump the cache from Asus drive to clearly see what the drive returns.

Result:
Cache dumps contain scrambled data so I took last 6 samples of scm file and tried to bin search cache files. I got a hit. The bad samples were present in cache dumps. This means that the drive is returning bad data.

It took like 10 dumps to hit bad data in cache.