I'm glad u found out what was going on.. I knew that leaving XBC in the background could somehow affect the dump, so that's why I included this step in the guide:

- After you closed Xbox Backup Creator, press the eject button of the drive twice so that it will remount the Xbox partitions.

Does that leave any other dumps that need to be rechecked?

Just bumping this...

I already went through all of _my_ dumps, but I confirmed a while ago that one of h0lylag's dumps was affected. I also found that out of coincidence, Midtown Madness 3 for Xbox happens to have zeroes right after the layerbreak. It's the only false positive that I know of.

I don't have every disc dump available to me to run my checking script, but I bet there may be at least one other game out there that needs re-dumping. If someone has a full set and can run my script against them all, that'd be good

I'm glad u found out what was going on.. I knew that leaving XBC in the background could somehow affect the dump, so that's why I included this step in the guide:

- After you closed Xbox Backup Creator, press the eject button of the drive twice so that it will remount the Xbox partitions.

Does that leave any other dumps that need to be rechecked?

I remember reading that, but nobody could explain specifically why it was needed, and I can't find anything historical where people discovered the same bug as me. It kind of seems like it mattered at one time. Actually, the partitions are unlocked as expected but the firmware is in a bad state.

Pressing the eject button twice doesn't really do anything on my drives. But actually ejecting the disc and putting it back in is enough to re-cycle the drive state and, as long as XBC isn't open, it should work properly.

I think this is worth documenting at length because it's a serious problem.

I would like to run my script against all the existing dumps in the DB to make sure there's no other dumps affected.

Does that leave any other dumps that need to be rechecked?

So I recompiled FreeCell to announce the reads it is sending to the drive, and the offsets of each read.

FreeCell reads 32 sectors at a time (unless < 32 sectors remain in the current area). What I've discovered is that, on a Kreon drive (TSST SH-D163B at least), if a 32-sector extent is read that crosses the layer break at some point, the sectors past the layerbreak are all zeroes in certain situations.

What are those certain situations? Well, it turns out it has to do with Xbox Backup Creator.

I patched FreeCell to only read a single 32-sector extent that seems to be causing trouble in my dumps (offset @ sector 1913746). This extent crosses the layerbreak and exceeds it by two sectors. Hey, a lot of my bad dumps had exactly 2 sectors of zeroes after the layerbreak...

After a lot of trial-and-error I've discovered that if (a) XBC is not running and (b) I put a disc in and run my special FreeCell instance, the reads are always correct no matter how many times I run them. But then, when I opened XBC and selected the drive (which issues some commands to the drive to check its contents etc.), my reads then broke again! Sectors past the layerbreak  (1913776) are all zeroes!

So, looking back at my old dumps that failed: I have kept XBC open in the background, and if the drive I am using is selected in the dropdown, XBC is watching for changes to that drive and issues its commands as soon as a disc goes in. So, sometimes it's poisoning the drive!

I still don't know what commands XBC is sending that put the drive into this state, but this is definite progress. I am able to reproduce the "read poisoning" issue by opening XBC and clicking around a bit. Once the drive is poisoned, only an eject/reinsert will fix the reads.

So, guess it's not overheating/mechanical fatigue after all. It's probably a firmware bug in Kreon. And it is not getting along with the XBC GUI and something it's doing...

edit: Even just switching from one drive to another, and back, in XBC triggers the poisoning

limbo43 wrote:

I am using Kreon firmware on DG-16D2S drives (three of them). I also have an 0800 drive

I'd thought kreon firmware could use only TSST drive. Do you have TSST drive (TS-H353A, TS-H352C, SH-D162C, SH-D162D, SH-D163A, SH-D163B)? If yes, please test this disc by DiscImageCreator.

Sorry that was a dumb and wrong post I made.

I am using TSST SH-D163B drives with Kreon. I do have a DG-16D2S drive with 0800 firmware that I occasionally use on stubborn discs with XBC.

I did some further investigation just now to rule out any logic errors in FreeCell. It was recompiled with some changes so that the buffers initialized with zeroes were initialized with some other number instead (0x55) and then I redumped the same disc in a loop until the checksum was wrong again. Investigating the bad dump gave me two sectors at layerbreak that were all zeroes, not 0x55, and no sense error was triggered, so... must be firmware.

So these drives are confidently returning between 1 and 3 zeroed-out sectors at the layerbreak some percentage of the time, without a sense error or anything. Really weird.

I did run DIC just once and it worked properly, but since this problem is non-deterministic and seems to be something wrong with the drive firmware, I should be able to reproduce it there too. I'll try to do that now.

Just as a reminder, we already know that at least one unrelated dump in the database suffered from this bug, and it was dumped by a totally different user (h0lylag).

OK, so I'm not sure what's causing this but if I dump the game with an 0800 drive and XBC, I get a checksum that matches OP's.

But with FreeCell, it generates the checksum that is already in the DB (my initial dump). Every time.

Something is wrong here, but not sure what.

Did you try DiscImageCreator also?

Fixed the hashes.. I hope you can find a way to make sure that your other dumps are all correct.

"making it more aggressive to check only 1 sector and running against my whole library i found 2 games that might be bad dumps"

Was Sneak King also detected this way?

But with FreeCell, it generates the checksum that is already in the DB (my initial dump). Every time.

Something is wrong here, but not sure what.

I am using Kreon firmware on DG-16D2S drives (three of them). I also have an 0800 drive

I'd thought kreon firmware could use only TSST drive. Do you have TSST drive (TS-H353A, TS-H352C, SH-D162C, SH-D162D, SH-D163A, SH-D163B)? If yes, please test this disc by DiscImageCreator.

Will keep digging

I am using Kreon firmware on DG-16D2S drives (three of them). I also have an 0800 drive for use with XBC on super stubborn discs where I dial in the speed to 1x. EDIT: Just kidding, I have 3x TSST SH-D163B drives with Kreon and one DG-16D2S drive with 0800

If I can get a copy of your dump I can do a more thorough technical analysis. Is your disc labeled as a combo disc? I didn't think there was more than one version of Sneak King, but maybe there was? Mine was labeled as a combo disc. A combo disc has nothing special going on except that it has an xex on the filesystem as well as an xbe. It's mastered as an original Xbox disc, not as a 360 disc. The backwards compatibility on the 360 takes care of reading the disc properly.

My copy of Sneak King was also sealed in the box.

This fix dump DOES have bytes where limbo43's dump didn't?

So it contradicts earlier findings, where the bad dumps had data and the correct ones didnt.

Then, which sectors are different? Or do you think kreon drive can't dump the combo disc correctly?

So it contradicts earlier findings, where the bad dumps had data and the correct ones didnt.