<![CDATA[Redump Forum — Cactus Data Shield dumping - ok to submit with --force-qtoc?]]> 2024-07-10T12:31:33Z PunBB http://forum.redump.org/topic/56433/cactus-data-shield-dumping-ok-to-submit-with-forceqtoc/ <![CDATA[Re: Cactus Data Shield dumping - ok to submit with --force-qtoc?]]> 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)

]]> http://forum.redump.org/user/63003/ 2024-07-10T12:31:33Z http://forum.redump.org/post/118875/#p118875 <![CDATA[Cactus Data Shield dumping - ok to submit with --force-qtoc?]]> 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:

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:

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

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:

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

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:

<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 

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

]]> http://forum.redump.org/user/63003/ 2024-07-07T10:02:07Z http://forum.redump.org/post/118807/#p118807