Update to my last post. I think there's more to this, since my drive got into a state where it wouldn't read the trap disc again and the only thing that resolved it was a full power cycle of the computer.
Re: My TS-H352C drives have stopped reading DC discs properly (7 replies, posted in General discussion)
Re: My TS-H352C drives have stopped reading DC discs properly (7 replies, posted in General discussion)
Pardon the necromancy, but I had a similar issue with a drive I picked up off eBay. I was able to do one rip and then the trap disc stopped working.
I burned a new trap disc at 1x speed and now that disc works. I burned the first one at whatever max speed my Plextor supports. I am not 100% sure if this was the only issue, but the old disc continues to not work and the new one does. On the "old" GD-ROM dumping guide on the wiki, someone wrote that CD-RWs are more durable and may read better and be less susceptible to damage or scratches, so maybe I'll grab a CD-RW to have a more permanent trap disc.
Anyway, if someone finds this searching, try re-burning your trap disc at 1x or on a different media.
The first copy of Official Xbox Magazine Demo Disc 02: January 2002 reads as a blank disc by windows and was in absolute pristine condition. The second copy I got had a few scratches, but not bad at all. Should have dumped ok by any means. It would error out on bad sectors about halfway through. I took it to get resurfaced today and it came out looking great. Tossed it back in to try again and now it fails even earlier. I've tried it before and after resurfacing with DIC and with XBC and my 0800 drive too and it is not reading correctly.
I have Official Xbox Magazine Demo Disc 01 as well that is in really nice condition and the drive times out trying to read it.
I think the discs are just bad? Or rotten I guess.
Have you tried setting the retries to max and speed to 1x in XBC? Even this might not be enough, of course
If you're using FreeCell, there is very limited retry logic. Not sure about DIC
I have found that on really stubborn discs, an 0800 drive + XBC set to 1x and 20x sector retries will often successfully read the disc. I haven't completely controlled for all variables so it's possible the read speed doesn't matter, but this has worked for me specifically on discs that look completely pristine but won't read properly for some reason.
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.
Hashes would be much faster if you run them inline as you rip the disc image. It's already sequential so you can be updating the digest as you read the disc, instead of later when you generate your XML files. This is a savings that adds up very quickly if you are dumping lots of games sequentially.
Can you please post the source code so we can compile for other platforms?
By the way, I wrote something to check the feature set of my drives with Kreon and the "error correction" stuff was explicitly not available on my model. Furthermore I found some posts by Kreon himself explaining that the error correction is just shortening how long the drive will lock up/retry internally before unblocking and returning a sense error. So that wasn't related at all
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:
You could do a test. Scratch the disc and try to read it...
I did try editing sectors.txt to intentionally not provide a few SS areas to see what the drive would do. FreeCell continued to function and the drive returned what appeared to be random data for those sectors. Not sure if the same issue though
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
Thanks for bringing us closer to a solution. I guess you should try to eject and re-insert the disc after closing XBC (for dumping the DMI/PFI/SS) and before starting FreeCell. If that by any chance fixes the problem, then we need to add a check to FreeCell to make sure that the drive is in the correct mode/state before dumping. Otherwise it might be a firmware bug?
Also, it should be easy to find any other bad dumps if someone creates a tool to scan these sectors.
And it would be worth checking out if this issue also affects Xbox 360 in any way (!)
I don't think this would be related to ejecting because it only affected one of my drives, and the routine is identical for all three drives. It seems drive or firmware related.
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.
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)
Alright, checking out Toxic Grind now. This time, it's my dump that has zeroes right after the layerbreak. Looking at Starshadow's copy, his has the random data. In this case it's sectors 1913776-1913795 that are the culprits.
But it gets worse... I just re-ripped it with FreeCell on the same drive and it didn't spit out zeroes for those sectors anymore. The data now is a 1:1 match for Starshadow's dump.
So something seems wrong with FreeCell here. I'm looking at the source code and it doesn't seem to do anything special that might cause this. The code has a simple approach to retrying after any drive errors (5 times) and failing out completely, so an error was not reported by the drive/firmware.
The current FreeCell source is here, for reference:
This is bad because it's not just my dumps that might be inconsistent. Although the zeroed area may vary in size, so far it appears to be localized to some number of sectors immediately following the layerbreak. I don't have a definitive guide to the data layout on the disc, but FreeCell just treats all that stuff as "game data" without differentiating any kind of special padding after the layerbreak. If anyone has additional info it'd be most helpful to debug this.
I'm going to scan all my dumps and check 2-3 sectors after layerbreak to see how many of them have zeroes...
There's also a small possibility there's a bug in the SS sector skipping code in FreeCell but that seems like it'd be deterministic.
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.
I suppose it's safe then. Don't remember why that was needed, it probably had to do with our older dumping method (MineSweeper instead of FreeCell).
I've also noticed on a few discs that FreeCell will fail with a sense error at a fixed location -- this could be from a scratch or similar, but the same disc can be dumped on an 0800 drive with XBC fine. I'm wondering if it's not the firmware that is the issue (Kreon v 0800), but that XBC puts more effort into recovering sectors it cannot read (e.g. by slowing read speed and making many attempts). Assuming this is the case, FreeCell is significantly faster than XBC for dumps due to the way it skips SS areas and would benefit greatly from similar code (I'm happy to add it if the source is out there)
- After you closed Xbox Backup Creator, press the eject button of the drive twice so that it will remount the Xbox partitions.
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.
Well I despair with this game.
This copy couldn't be in any better condition (see picture attached) but still fails with sense error around 15% with one Kreon drive (sh-d162c) and around 35% with another (TS-h353 cross flashed) have tried around 5-6 attempts on each drive so far. Both drives have been fine for dumping other Xbox discs.
Gonna strip an old Xbox down and see if I can get an original Xbox drive attached somehow.
Got the bugger!
Submitting dump data now.
Could you clarify what specifically you did to get this working?
I have a few games exhibiting similar behavior. Dead to Rights and Rally Fusion are two current examples, but there may be more (I have a backlog of 100+ undumped games)
Hi all, can I get setup on the wiki? I'd like to update the missing lists with all the games I've purchased so we don't duplicate work.
I had this exact same problem. Not only did SS on 360 games output an empty SS table, but also on original Xbox. That isn't correctly reflected in the Xbox Backup Creator readme. In both cases you need 0800 v3 (not just any 0800).
Only once I flashed my 16D2S with 0800 v3 (on the other side of the X360USB) did it work as expected. At least now we both have drives that can dump the whole Xbox/Xbox360 lineage correctly!
What's kind of frustrating is that this obviates the need for the X360USB, if you have SATA ports available. You can just use a CK3 Lite. You could even use multiple at the same time...
Don't know if this is already known. You can use any 360 drive now using the USB Pro v2 http://team-xecuter.com/xecuter-x360usb … roduction/
I bought one of these the other day and discovered there are many caveats and gotchas. Stock 16D2S drives don't work out of the box for example -- they dump an incorrect/incomplete SS.bin. You need to flash the drive with 0800 v3 for the drive to properly dump the security sector (not just any 0800). I also tried using a functional BenQ drive and nothing I tried could get that thing to work. Also in the product description for the X360USB they state:
Convert any stock 360 DVD into an 0800 ripping drive without modifying the firmware
But two sentences later, actually, we didn't mean any drive, tee hee:
Even works with Hitachi 0500*! (Liteon DG-16D5S 1175 Support Coming Soon)
I was also confused by this dumping guide, as it doesn't say anything about dumping SS/PFI/DMI in the 0800 section. Being a noob that threw me off, especially because I was able to dump the ISO fine but the SS.bin seemed like gibberish. I thought I was missing some steps.
Anyway, I finally got it working and I'm going to begin dumping this huge stack of games now. Hopefully my info helps someone down the road.