Page 1 of 1

Cactus Data Shield dumping - ok to submit with --force-qtoc?

Posted: Sun Jul 07, 2024 5:02 am
by HeroponRikiBestest
I have a specific disc with Cactus Data Shield 200.0.4 (3.0 build 16a) https://vgmdb.net/album/8245.

Dumping it on my plextor with normal settings has issues, as the disc TOC for the audio tracks is not read correctly.

(I apologize for the force stop and refine in the plextor logs; at the moment, there's an oversight in redumper where the multisesison gap is not jumped on 4824, a PR for this is already pending at https://github.com/superg/redumper/pull/172. This does not result in bad dumps, this just means you have to manually stop and start again when you hit the multisession gap on those drives.)

Plextor Try 1:

Code: Select all

disc TOC:
  session 1
    track 1 { audio }
      index 01 { LBA:      0, MSF: 00:02:00 }
    track 2 { audio }
      index 01 { LBA:  21703, MSF: 04:51:28 }
    track 3 { audio }
      index 01 { LBA: [  1500 ..  43084], length:  41585, MSF: 00:22:00-09:36:34 }
    track A { audio }
      index 01 { LBA:  66213, MSF: 14:44:63 }
  session 2
    track 4 {  data }
      index 01 { LBA:  77613, MSF: 17:16:63 }
    track A {  data }
      index 01 { LBA: 332850, MSF: 74:00:00 }
Resulting hashes:

Code: Select all

<rom name="moongate (Track 1).bin" size="50739696" crc="b057117e" md5="c83acd4d7d7e43e49e44e974bef8426f" sha1="e4d6c4d741c0d769d6b5ba3dadfc5fa4f41505f4" />
<rom name="moongate (Track 2).bin" size="305760" crc="d1333447" md5="4db7edf10b983b933f179fa937db6948" sha1="06a0dbe39d196bb8d5fead64ca0408f942c91233" />
<rom name="moongate (Track 3).bin" size="104687520" crc="fee187b7" md5="47fa55baa280b0771a0d30bf66e72d75" sha1="1410f248ed7c9c3d3d2c0aa1dd72b87b311b4696" />
<rom name="moongate (Track 4).bin" size="600317424" crc="08dc195a" md5="9a7c77f0b185e10339c87e268e5d34b0" sha1="c7e04ac79931c45439c92500e11f4f6c0265c7ca" />
Plextor Try 2:

Code: Select all

disc TOC:
  session 1
    track 1 { audio }
      index 01 { LBA:      0, MSF: 00:02:00 }
    track 2 { audio }
      index 01 { LBA: [   750 ..  21702], length:  20953, MSF: 00:12:00-04:51:27 }
    track 3 { audio }
      index 01 { LBA: [  1500 ..  43084], length:  41585, MSF: 00:22:00-09:36:34 }
    track A { audio }
      index 01 { LBA:  66213, MSF: 14:44:63 }
  session 2
    track 4 {  data }
      index 01 { LBA:  77613, MSF: 17:16:63 }
    track A {  data }
      index 01 { LBA: 332850, MSF: 74:00:00 }
Resulting hashes:

Code: Select all

<rom name="moongate (Track 1).bin" size="1764000" crc="286a29d6" md5="2f6c5e46a9e965207ff29f19a1c07ad9" sha1="3b4bce39afded0529fdc73b24fbb6eac9beee2d5" />
<rom name="moongate (Track 2).bin" size="1764000" crc="d5e0b9a5" md5="7315842ba4df84066a78735ddc0e63e9" sha1="4b14d1e4ba424e5fdeb309052542cfc738babe2b" />
<rom name="moongate (Track 3).bin" size="152204976" crc="8bb750fd" md5="9ad71a453412cf0689f9e7c20c05fb68" sha1="0148af83c423b9e86f0767c72c29742367613ad5" />
<rom name="moongate (Track 4).bin" size="600317424" crc="08dc195a" md5="9a7c77f0b185e10339c87e268e5d34b0" sha1="c7e04ac79931c45439c92500e11f4f6c0265c7ca" />
If I dump on my asus, it reads the TOC correctly, and dumps properly, with matching hashes, each time.

ASUS:

Code: Select all

disc TOC:
  session 1
    track 1 { audio }
      index 01 { LBA:      0, MSF: 00:02:00 }
    track 2 { audio }
      index 01 { LBA:  21703, MSF: 04:51:28 }
    track 3 { audio }
      index 01 { LBA:  43085, MSF: 09:36:35 }
    track A { audio }
      index 01 { LBA:  66213, MSF: 14:44:63 }
  session 2
    track 4 {  data }
      index 01 { LBA:  77613, MSF: 17:16:63 }
    track A {  data }
      index 01 { LBA: 332850, MSF: 74:00:00 }
Resulting hashes:

Code: Select all

<rom name="moongate (Track 1).bin" size="50739696" crc="b057117e" md5="c83acd4d7d7e43e49e44e974bef8426f" sha1="e4d6c4d741c0d769d6b5ba3dadfc5fa4f41505f4" />
<rom name="moongate (Track 2).bin" size="50208144" crc="554f3d6c" md5="ebe6b24ae40a3e50ed9be7184fe716f1" sha1="0047e6650d7162de6e950ead0c142fb1d97d9b89" />
<rom name="moongate (Track 3).bin" size="54785136" crc="4dcc5621" md5="64913ea9a80c753c47a222c999383e59" sha1="d450b9926fc80849d3394034cb00800a13701ddd" />
<rom name="moongate (Track 4).bin" size="600317424" crc="08dc195a" md5="9a7c77f0b185e10339c87e268e5d34b0" sha1="c7e04ac79931c45439c92500e11f4f6c0265c7ca" />
Moreover; when dumping on plextor, if i split with `--force-qtoc`, it produces identical, correct dumps each time, matching what my ASUS was already producing. Both of the earlier plextor dumps produce

Code: Select all

<rom name="moongate (Track 1).bin" size="50739696" crc="b057117e" md5="c83acd4d7d7e43e49e44e974bef8426f" sha1="e4d6c4d741c0d769d6b5ba3dadfc5fa4f41505f4" />
<rom name="moongate (Track 2).bin" size="50208144" crc="554f3d6c" md5="ebe6b24ae40a3e50ed9be7184fe716f1" sha1="0047e6650d7162de6e950ead0c142fb1d97d9b89" />
<rom name="moongate (Track 3).bin" size="54785136" crc="4dcc5621" md5="64913ea9a80c753c47a222c999383e59" sha1="d450b9926fc80849d3394034cb00800a13701ddd" />
<rom name="moongate (Track 4).bin" size="600317424" crc="08dc195a" md5="9a7c77f0b185e10339c87e268e5d34b0" sha1="c7e04ac79931c45439c92500e11f4f6c0265c7ca" />
from splitting with `--force-qtoc`. As far as I understand, this is just down to how some drives handle TOC reading (although I'm sure CDS specifically is manipulating things), there was one non-protected disc for non-game I had a similar issue with, and bikerspade has mentioned something similar happening on his 5224.

TL;DR: For this Cactus Data Shield protected disc (and any others that might suffer similar issues, CDS varies quite a bit between versions), is it okay for me to submit via dumps run with `--force-qtoc`? It seems to produce the correct output. I apologize if there's already a verdict on these kinds of issues, but as mentioned, I've only ever ran into this sort of thing one time before.

Re: Cactus Data Shield dumping - ok to submit with --force-qtoc?

Posted: Wed Jul 10, 2024 7:31 am
by HeroponRikiBestest
Additionally, if at all relevant, it also dumps properly on my plextor with the new --force-refine option added with https://github.com/superg/redumper/pull/162 using the toc from an immediately-cancelled ASUS dump (as in, let redumper generate the toc, but cancelled before it dumped any sectors)