Search options

The 5 games in redump I know of with Copy Blockbuster (there don't seem to be any more, thankfully? Other than undumped regional versions)

Pizza Syndicate (specifically just Germany and Italy):
http://redump.org/disc/40426/
http://redump.org/disc/76708/
Gute Zeiten, schlechte Zeiten Vol. 2 (Germany)
http://redump.org/disc/108209/
Gute Zeiten, schlechte Zeiten - Fun Pack (Germany)
http://redump.org/disc/108206/
Pizza Syndicate - Mission CD - Mehr Biss (Germany)
http://redump.org/disc/97572/
Swing Plus - Total Mindcontrol (Germany)
http://redump.org/disc/97593/

I first noticed these games because they all (aside from base Pizza Syndicate) have a ton of errors, but around the same amount, and a second data track that's exactly 11133 sectors.

Not sure if Copy Blockbuster is specifically an in-house thing or some protection offered by another company; either way, only these 5 Software 2000 games seem to use it. Brief writeup from a user about how it works (mainly details software side of things, but does describe some relevant stuff for redump) https://cohost.org/caralynx/post/305509 … ration-piz (IA link if cohost isn't working: https://web.archive.org/web/20241126023 … ration-piz ).

When I brought them up, MoriGM mentioned that he had Swing Plus, but couldn't submit it to redump due to some descramble errors. Upon DMing him about it, it turns out that DiC 2021, DiC 2024, and redumper all produce different hashes. Despite this, each dumping program is always consistent with itself between dumps. He dumped four different times on redumper and they all matched each other, and did not seem to have C2/read errors. Most notably, his DiC 2021 dump matched the existing dump. He also reports having the exact same ringcode as the existing Swing Plus dump, so it's definitely the same disc.

I reached out to the person who wrote that cohost post, and they told me this:

This seems to be consistent with Mori's logs (attached to this post). This also indicates that the existing Pizza Syndicate germany and italy dumps probably also need to be redumped, despite apparently having 0 errors.

I understand that it might not be viable to get usurper to redump all of their discs, but at the very least, it would be nice to have a decision so Mori can submit his Swing Plus disc, and also so it can be noted that all the others need redumping.

Tl;dr these 5 games use copy protection involving intentional MSF errors and a few other quirks, and it appears that older DiC, newer DiC, and redumper all split them differently, so they all likely need to be redumped, and a decision should be made on how to actually properly split these dumps.

(DiC 2024 logs (too large to attach to forum post): https://mega.nz/file/DA1n2BjB#1h7ftSPCG … 8SBpMLeUjY )

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.