1,676 (edited by Jackal 2019-01-02 07:50:56)

sarami wrote:

I'm not sure about it, but many sony dadc discs have -647. At least, I hope all 99 modified SecuROM discs are dumped again to get _disc.txt.

Does your Colin McRae Rally 2 disc also have -59 in one mode?
I guess we only need to check a couple discs and if they all have this problem, just fix all -59 discs to -647.
I dont know if this also affects discs with +588 offset which should be 0? Many discs have +588.

Jackal wrote:

SubCode[0] dumps only main-channel. dic only uses this to output offsets in _disc.txt. No problem about sub-channel.
Or does this question mean that SecuROM sector 157 haven't fixed yet?

No, this was the only disc

1,677 (edited by ajshell1 2019-01-03 01:17:25)

I'd just like to point out that the most recent versions of DIC I tested (The stable one and test version 20181116 95206) still don't detect the SmartE protection on http://redump.org/disc/38957/.

I'm going to test and see if the dump DIC produces matches the DB version.  I doubt it will.

Edit: Nope. No it doesn't.

Also, there's this forom the EdcEcc.txt log:

LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060081, 0x0eab1], MSF[13:23:06], mode 1


EDIT2:

I'm getting a similar issue with what appears to be http://redump.org/disc/40523/. The PVD and file size is the same.

LBA[059462, 0x0e846], MSF[13:14:62], mode 1
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059473, 0x0e851], MSF[13:14:73], mode 1

EDIT3:
What seems to be http://redump.org/disc/29992/ but doesn't match has SmartE detected.

LBA[000988, 0x003dc], MSF[00:15:13], mode 1
LBA[000989, 0x003dd], MSF[00:15:14], mode 1 User data vs. ecc/edc doesn't match
LBA[000990, 0x003de], MSF[00:15:15], mode 1 User data vs. ecc/edc doesn't match
LBA[000991, 0x003df], MSF[00:15:16], mode 1 User data vs. ecc/edc doesn't match
LBA[000992, 0x003e0], MSF[00:15:17], mode 1 User data vs. ecc/edc doesn't match
LBA[000993, 0x003e1], MSF[00:15:18], mode 1 User data vs. ecc/edc doesn't match
LBA[000994, 0x003e2], MSF[00:15:19], mode 1 User data vs. ecc/edc doesn't match
LBA[000995, 0x003e3], MSF[00:15:20], mode 1 User data vs. ecc/edc doesn't match
LBA[000996, 0x003e4], MSF[00:15:21], mode 1 User data vs. ecc/edc doesn't match
LBA[000997, 0x003e5], MSF[00:15:22], mode 1 User data vs. ecc/edc doesn't match
LBA[000998, 0x003e6], MSF[00:15:23], mode 1 User data vs. ecc/edc doesn't match
LBA[000999, 0x003e7], MSF[00:15:24], mode 1


EDIT4: More details here: http://forum.redump.org/post/66206/#p66206

1,678

ajshell1 wrote:

I'd just like to point out that the most recent versions of DIC I tested (The stable one and test version 20181116 95206) still don't detect the SmartE protection on http://redump.org/disc/38957/.

All logs of your smartE discs, please.

Jackal wrote:

Does your Colin McRae Rally 2 disc also have -59 in one mode?

According to disc.txt, Colin McRae Rally 2.0 and Diablo II: Lord of Destruction have incorrect main-channel(all zero) on LBA 0 if OpCode[0xd8]: SubCode[0] is used.
SubCode[2] and SubCode[8] are no problem. I think this is a bug of plextor and perhaps this occurs on 99 modified SecuROM discs only.

Also I tried 'cdtoimg d8 hacked' for Colin McRae Rally 2.0. 2 files are uploaded. http://www.mediafire.com/file/763drz13a … mr.7z/file

Btw, old plextors have similar issue about drive offsets. These issues occur on all discs.

  PLEXTOR PX-W820T  : +354(subch is 0x02), +355(subch is 0x00)
  PLEXTOR PX-W8220T : +354(subch is 0x02), +355(subch is 0x00)
  PLEXTOR PX-W124S  : +942(subch is 0x02), +943(subch is 0x00)
  PLEXTOR PX-W1210S : +686(subch is 0x08), +98(subch is 0x00)
  PLEXTOR PX-W1610TA: +686(subch is 0x02), +98(subch is 0x00)
  PLEXTOR PX-W2410TA: +686(subch is 0x02), +98(subch is 0x00)
  PLEXTOR PX-320A   : +686(subch is 0x02), +98(subch is 0x00)
Jackal wrote:

I dont know if this also affects discs with +588 offset which should be 0? Many discs have +588.

Sega Saturn discs of +588 offset have a duplicated sector in lead-in. Due to this sector, the offset is shifted by 1 sector. If you worry about it, you can check the lead-in sectors.

1,679

Logs
https://cdn.discordapp.com/attachments/ … Disc_1.zip

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

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

1,680

Test version
20190103 (Windows)
http://www.mediafire.com/file/eq80y20l9 … or_test.7z
20190103 (Linux)
http://www.mediafire.com/file/uw3e03kdk … x_test.tar

fixed: detecting smartE

1,681

Fable: TLC is dumped correctly with this new update. Thank you.

1,682 (edited by wiggy2k 2019-01-09 01:45:47)

What does this mean ?

LBA[004903, 0x01327]: Track[02]: Invalid sync. Skip descrambling
========== LBA[004903, 0x01327]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0010 : 00 00 00 00 00 00 00 00  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   ................
.
.
Repeated.
.
.
.
.

LBA[004977, 0x01371]: Track[02]: Invalid sync. Skip descrambling
========== LBA[004977, 0x01371]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0010 : 00 00 00 00 00 00 00 00  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   ................
0040 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................

i assume the dump is still good?

Was from this disc: http://forum.redump.org/topic/20520/pcf … chan-kick/

The full logs: https://1fichier.com/?khesqgz83urpjavks6kd

1,683

wiggy2k wrote:

i assume the dump is still good?

Most likely those are audio pregap sectors that are somehow marked as data in subs, so they are expected to be in data format with the proper headers, but they aren't there, so the tool reports about undescrambleable sectors.

1,684

Ok not sure if this has been mentioned but I noticed the new /74 flag in the newer version of DIC and was wondering how one would use it exactly to dump the ring data. I tried it just as part of the normal dumping but it didn't seem to do anything. Do I have to use a swap disc or something?

1,685

Test version
20190115 (Windows)
http://www.mediafire.com/file/eq80y20l9 … or_test.7z
20190115 (Linux)
http://www.mediafire.com/file/uw3e03kdk … x_test.tar

fixed: subs indexes if sub vs. toc is desync http://forum.redump.org/topic/20625/tur … r-lair-us/
fixed: /74 is only used by swap command

1,686

sarami wrote:

fixed: subs indexes if sub vs. toc is desync http://forum.redump.org/topic/20625/tur … r-lair-us/

What was wrong with it and what exactly was fixed?

1,687

F1ReB4LL wrote:
sarami wrote:

fixed: subs indexes if sub vs. toc is desync http://forum.redump.org/topic/20625/tur … r-lair-us/

What was wrong with it and what exactly was fixed?

INDEX of (Subs indexes).cue and (Subs indexes)_img.cue was incorrect.

1,688

So we need to redump all the desynced PCEs now? smile

1,689

2018-05-22 is no problem. 2018-05-23 - 2019-01-03 is bad.

1,690

Track checksums are good, only cues may be wrong? 00:03:05 => 00:03:06 was the only change.

sarami wrote:

2018-05-22 is no problem. 2018-05-23 - 2019-01-03 is bad.

Only http://forum.redump.org/topic/19964/add … ne-ii-usa/ may be affected, then

1,691

F1ReB4LL wrote:

Track checksums are good, only cues may be wrong? 00:03:05 => 00:03:06 was the only change.

sarami wrote:

2018-05-22 is no problem. 2018-05-23 - 2019-01-03 is bad.

Only http://forum.redump.org/topic/19964/add … ne-ii-usa/ may be affected, then


I actually own Final Zone II..dumping now with the new version

1,692

Thanks test but problems still exist.

LBA[124763, 0x1e75b]: Track[48]: Subchannel & TOC doesn't sync. LBA on TOC[111288, 0x1b2b8], prevIndex[00]
LBA[124763, 0x1e75b]: Track[48]: Index is changed from [00] to [01] [L:966]

LBA[199341, 0x30aad]: Track[55]: Subchannel & TOC doesn't sync. LBA on TOC[189939, 0x2e5f3], prevIndex[00]
LBA[199341, 0x30aad]: Track[55]: Index is changed from [00] to [01] [L:966]

Reuploaded.
http://www.mediafire.com/file/eq80y20l9 … st.7z/file

1,693

Redumped both games with the test DIC.  Uploaded to my normal spot with test suffix on the zips.

1,694

Thx, it seems good.