• Registered: 2015-02-24
  • Posts: 101

I've got a couple of the undumped NA discs that I want to dump (Bug! with the SATURN81004R ring code, Gridrunner, etc.)

So far I've tried dumping two discs, both in what appears to be good condition. While DIC reports "No C2 errors" for both, DICUI launches subdump.exe after DIC, and subdump.exe seems to run forever, dumping the subs over and over again. I end up with a number of "[title]_subdump_1.sub", "[title]_subdump_2.sub", "[title]_subdump_3.sub", etc files all the same size (but not with matching hashes).

Is this normal? Looking at the log, it looks like subdump is convinced there are some reading errors, and it's re-reading over and over. But, like I said, these discs are in quite good condition, and DIC reports no C2 errors, so I find this a bit odd.

Drive: PX-760A
Subdump Log (for Bug!): https://www.dropbox.com/s/o7nftgipf184j … p.log?dl=0
Other logs (for Bug!): https://www.dropbox.com/s/6ojbd8b42ijtiqj/BUG.7z?dl=0


Subdump was actually still running when I copied its log file.

  • iR0b0t
  • iR0b0t
  • Administrator
  • Offline
  • From: Research equipment
  • Registered: 2008-02-21
  • Posts: 6,703

It is supposed to make 5 loops and will finish reading at some point for sure.

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)
  • Registered: 2006-12-24
  • Posts: 3,847

It reads the disc subs 5 times, then combines the results and tries to reread the damaged sectors. You can open the logfile with Far Manager or similar and watch the process in real time.

  • Registered: 2015-02-24
  • Posts: 101

iR0b0t wrote:

It is supposed to make 5 loops and will finish reading at some point for sure.

F1ReB4LL wrote:

It reads the disc subs 5 times, then combines the results and tries to reread the damaged sectors. You can open the logfile with Far Manager or similar and watch the process in real time.


Thanks for the responses! Sure enough, I was just impatient. It stopped after 5 passes.


On another note, it looks like the SATURN81004R version of Bug! is actually different from the variant in the database. Track 1 is same size, but CRC differs. Track 2 and many others are a different size. However, build date and version number match http://redump.org/disc/20332/ I'm gonna do some additional checking before I submit, though, so I don't make an ass of myself.

  • From: North East UK
  • Registered: 2016-06-15
  • Posts: 1,063

ooh interested to see if there's any differences. probably not if the header date and build matches but you never know,
they might have actually fixed the issue with cold booting the console with BUG! in the drive.

  • Registered: 2006-12-24
  • Posts: 3,847

It is different, hence the "R" (reprint/revised/whatever).

wiggy2k wrote:

they might have actually fixed the issue with cold booting the console with BUG! in the drive.

I've compared both images before and, IIRC, the only thing that was fixed is the serial number in the header (GM-81004 was fixed to MK-81004). But it's still quite an interesting change to be preserved smile

  • Registered: 2015-02-24
  • Posts: 101

F1ReB4LL wrote:

It is different, hence the "R" (reprint/revised/whatever).

wiggy2k wrote:

they might have actually fixed the issue with cold booting the console with BUG! in the drive.

I've compared both images before and, IIRC, the only thing that was fixed is the serial number in the header (GM-81004 was fixed to MK-81004). But it's still quite an interesting change to be preserved smile

Yeah, I converted both versions into 2048 sector images, and a binary compare indicates only two bytes different, and it is in fact a G changing to an M and a M changing to a K. Just as you remembered.

In any case, I'll hopefully get a change to submit it later in the week.