Search options

Have you tried setting the retries to max and speed to 1x in XBC? Even this might not be enough, of course

Implementing https is so easy. Just put the site behind Cloudflare and turn it on. It's free and provides a lot of other benefits.

Can you please post the source code so we can compile for other platforms?

I think I've gotten closer to the root cause. After redumping the 26 games that had this problem, I noticed that the affected drive begins failing the same way after being used continuously for a certain amount of time. It seems like it's an overheating or mechanical stress issue that affects the drive in such a way that the laser is not refocusing on the second layer fast enough at the layerbreak. As a result the drive is reading zeroes when it should read data. I don't know enough about the drive internals and hardware debugging to completely isolate the issue, but I found that letting the drive cool off is enough to get another clean dump, and if I do a lot of dumps back-to-back it eventually fails consistently.

Therefore, I'm trashing this drive, but we now know what one symptom of a bad drive looks like that is not detected by existing utilities. We have only found one dump so far besides my own that shows this issue, and I already redumped that game, but I will do a deeper dive soon.

I am posting a fix thread now with new checksums for all of the affected games:
http://forum.redump.org/post/59983/#p59983

Still working on figuring this out. I used the same drive to re-dump several of the affected games and they then dumped correctly. Further analysis of my bash history reveals that most of these bad games were dumped back-to-back; I think the drive or laser was in an odd state that persisted across discs.

One suspicion I have is that maybe the Kreon firmware's "error skipping" feature could be a culprit, but I don't know exactly what it does. If it dumps out zero-bytes for what seem to be bad sectors instead of failing, that might be why. FreeCell does not send the cdb command to enable or disable Kreon's error skipping feature so if it's on by default, that could be a problem. According to the NFO the error skipping feature is enabled by default for "360 games" but maybe is on for both? If certain errors that _should_ bubble up do not, FreeCell can have silently corrupted dumps. So if this ends up being the culprit then FreeCell will need a patch to issue that cdb. (It's also possible this has nothing to do with anything and the error skipping feature isn't on by default)

So far I have not reproduced the error condition--every dump I do with the "bad" drive is correct. I've tried continuously looping multiple dumps on all 3 drives at the same time to simulate the conditions and have come up short. It's driving me crazy that I can't get it to happen again.

Affected dumps may be harder to detect than I thought. The most obvious ones just have all zeroes for 2-6 sectors immediately following the layerbreak, but there are some examples where there is a random perforation of zeroes in those sectors instead. This means it may be nearly impossible to detect good vs. bad dumps without a true redump by multiple people. Since we know I'm not the only affected user (h0lylag's NFS dump comes to mind) this could mean that there's a risk to any non-redumped Xbox title in the database today. Scary thought.

Still trying to repro and will update once I have more information

Out of 167 sequential dumps with FreeCell, 31 of them have 0's in the area just after the layerbreak and arguably need to be redumped. That's 18.6% of all of my dumps, or nearly 1 in 5 dumps that have this behavior with FreeCell. Doesn't seem good.

It is likely many of the dumps on Redump need to be analyzed to check for this missing data.

Edit:

Looking in my bash history I can tell that all of these zero-padding-at-the-layerbreak happened on the same drive. I have three identical Kreon drives in my machine and have been dumping games with all three at the same time. So something is up with this specific drive--but it doesn't do it every time. As I mentioned above, I just used the faulty drive to re-dump Toxic Grind and the checksum matched this time.

So there's something up with one of my drives, and at least someone else's drive (h0lylag who dumped NFS and got the zero padding too)

I took a look at the differences between my NFS dump and h0lylag's, and the only difference was about 12K of data immediately following the layerbreak. On h0lylag's dump that area was all 0's, and on mine it was random(?) data. I extracted both images and compared the files and they all are identical.

It made me wonder if he's using XBC or FreeCell. If he's using XBC he may have not noticed those sectors being 0'd out due to a read error (vs. being SS areas). But it looks like based on his posts he has a Kreon drive so it's almost certainly FreeCell. So not sure what happened here.

I haven't looked at the differences on Toxic Grind yet but will take a look.

Just to be clear, all of my dumps are via Kreon+FreeCell with only one exception (a disc that was scratched and was able to read properly in an 0800 drive w/XBC). I actually can't remember which disc that was right now but it wasn't NFS or Toxic Grind.

Is this (still) necessary? I have not had any issue just dumping SS/PFI/DMI and immediately running FreeCell. I hope I have not been making bad dumps but I have verified a couple that matched with this method.

I attempted to tap the eject button twice but the drive tray just ejects. This is on SH-D163B SB01 with Kreon.