DiscImageCreator

[reentrant]

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.

/viewtopic.php?p=69657#p69657 -> 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):

Code: Select all

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:

Code: Select all

========== 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

[sarami]

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

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

[Jackal]

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

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)

[sarami]

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

Probably different master disc.

I think so, too.

edit: And here another ASUS dump: /viewtopic.php?p=69657#p69657 where all tracks match this dump https://redump.info/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.

Code: Select all

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?

[reentrant]

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.

[reentrant]

W8. I have found where the problem is. The drive returns the data that is sometimes shifted by 1 sector.

Look at those 2 dumps:
lgcache_all_0_378251_OK - cache dump starting with sector 378251. It's good cache.
lgcache_all_0_378251_BAD - cache dump starting with sector 378251. It's bad cache.

The data in bad one is shifted by 0xB00 bytes = 1 cache sector.

So the real solution has to analyze cache dump and find proper starting offset of data. Right now it assumes the offset is 0. In case of audio tracks MSF is not available so subchannel data has to be taken into account.

[RibShark]

We should really add to the guides to always dump CDs with audio tracks twice, preferably with separate drives. This would solve most issues.

But yeah, the cache reading is not ideal, and I really hope a better solution to reading the lead-out appears (through firmware modification perhaps).

[NovaAurora]

LoStraniero pointed me here.

Latest DIC included with MPF, only one sector being detected for SecuROM 4.84.76. Apparently it's supposed to have more than that. Here's the logs, I was told to attach those.

https://cdn.discordapp.com/attachments/ … T_logs.zip

[DopefishJustin]

DopefishJustin submitted a verification for this disc: https://redump.info/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.

For the record I am using an LG WH16NS40 cross-flashed to ASUS firmware as described at https://wiki.redump.info/index.php?title= … 2_firmware

I dumped the disc twice before submitting and have now dumped it a third time, with matching results each time. The other two discs in the set also have audio tracks and matched existing dumps when read with the same drive: /viewtopic.php?t=31019 … t-2-discs/

I have ordered a PX-W5224TA and will compare when that arrives.

[sarami]

Latest DIC included with MPF, only one sector being detected for SecuROM 4.84.76. Apparently it's supposed to have more than that. Here's the logs, I was told to attach those.

Do you have other SecuROM discs? I hope you dump them.