• Registered: 2017-09-21
  • Posts: 378

My dump of Sneak King doesn't match the existing one.
Here is all the info for it:

Game Information:

Game Title: Sneak King
Link: http://redump.org/disc/48917/
Region: USA
Languages: English, no language select menu
Disc Serial: MS-211
Edition: Original
Case Barcode: 0 14633 14663 9


Disc Info:

L0 Video Size: 6832
L1 Video Size: 160
Middle Zone Size: 191312
Game Data Size: 3431264
Total Size: 3820880

Real Layer Break: 1913776

3820880 (100%, 8.26 MB/sec)

CRC32: 069b5905
MD5:   c30724ebcc2db721b601b6bf79c9348e
SHA1:  ff275180aa89968f37c40658352161ff636c3957

DMI.bin 342B8B3F
PFI.bin 8FC52135
SS.bin C5BF1902



Ring Information:

Upper Level Mastering Code: MS21101A-MS-L1 04
Lower Level Mastering Code: MS21101A-MS-L0 07
Upper Level Mastering SID Code: IFPI L270
Lower Level Mastering SID Code: IFPI L270
Upper Level Toolstamp: None
Lower Level Toolstamp: None
Data Side Mould SID Code: IFPI 44F3
Label Side Mould SID Code: None


Security Sector Ranges:

294614-298709
443008-447103
597992-602087
834714-838809
985280-989375
1219428-1223523
1450558-1454653
1606034-1610129
1985972-1990067
2289896-2293991
2526406-2530501
2683252-2687347
2910406-2914501
3145202-3149297
3296476-3300571
3453144-3457239


This disc was sealed in the box when I bought it. The quality of the disc is not the factor for me here. I was using FreeCell-0.2-RC1.exe
Let me know if you need any more info.
I'm going to...acquire...an ISO that matches the DB and compare them in hex editors to see what the difference is.

  • Registered: 2006-12-23
  • Posts: 4,137

Did you try to redump this yet?

  • Registered: 2017-09-21
  • Posts: 378

I've redumped it three times so far and I've gotten the same thing every time.

  • Registered: 2014-10-06
  • Posts: 734

And what's the difference?

  • Registered: 2006-12-23
  • Posts: 4,137

reentrant wrote:

And what's the difference?

Some sectors on his dump have zero bytes where the other dump has data.

  • Registered: 2014-10-06
  • Posts: 734

Any solution?

  • Registered: 2011-02-20
  • Posts: 1,772

@ajshell1
I added xbox dumping in the latest test version of dic (20180611).

DiscImageCreator.exe xbox <driveletter> <filename>

Would you test and report?

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

  • Registered: 2017-09-21
  • Posts: 378

I had previously dumped this with a TS-H353B. I recently got a TS-H352C, so I dumped Sneak King again with the TS-H352C drive, and I got the same checksum (ff275180aa89968f37c40658352161ff636c3957)

As for dumping it with DIC, I can't get it to work with Xbox discs. I get this error:

'[F:ReadDVDForFileSystem][L:711] GetLastError: 121, The semaphore timeout period has expired.

EndTime: 2018/06/15(Fri) 17:57:52"

  • Registered: 2006-12-23
  • Posts: 4,137

I noticed that the ringcodes are different..

Maybe the "Combo disc; works on Xbox 360" thing has something to do with it?
Are there any other cross-compatible discs like that in the db? Maybe worth double checking those too.
Hope limbo43 will be back soon, so we can get this resolved.

10 Reply by sarami (edited by sarami 2018-06-18 18:22:31)

  • Registered: 2011-02-20
  • Posts: 1,772

ajshell1 wrote:

'[F:ReadDVDForFileSystem][L:711] GetLastError: 121, The semaphore timeout period has expired.

This is fixed. Please test 20180619

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

  • Registered: 2011-02-20
  • Posts: 1,772

I dumped this too.

Lower Level Mastering Code: MS21101A-MS-L0 04
Upper Level Mastering Code: MS21101A-MS-L1 04
Lower Level Mastering SID Code: IFPI L780
Upper Level Mastering SID Code: IFPI L779
Lower Level Toolstamp: 0504
Upper Level Toolstamp: 0405
Data Side Mould SID Code: IFPI KK3N
Label Side Mould SID Code: IFPI KKCJ

Barcode: None

Hash of Freecell
CRC32: 069b5905
MD5:   c30724ebcc2db721b601b6bf79c9348e
SHA1:  ff275180aa89968f37c40658352161ff636c3957

Hash of XBC
SS.bin: 6000002B

Hash of DIC
    <rom name="Sneak King (USA).iso" size="7825162240" crc="069b5905" md5="c30724ebcc2db721b601b6bf79c9348e" sha1="ff275180aa89968f37c40658352161ff636c3957" />
        <rom name="SS.bin" size="2048" crc="6000002b" md5="9b87d7bcfdb8e1e2f95ee24199b3311f" sha1="b52cb0042a3fdda18929b801357369f654faeb2b"/>
        <rom name="PFI.bin" size="2048" crc="8fc52135" md5="51badb1da2cc5fb0b272061dab9ef75b" sha1="1b1c6e61835799dd182dea5b3f3f35447216a8ac"/>
        <rom name="DMI.bin" size="2048" crc="342b8b3f" md5="2c771c7a86e09253c389940513736e6c" sha1="da2578b3df46cdd7fadcdf2c9946bc65c8610c49"/>

Security Sector Ranges
same as ajshell1

Post's attachments

Sneak King_log.7z 10.28 kb, 25 downloads since 2018-06-26 

You don't have the permssions to download the attachments of this post.
DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

  • Registered: 2011-02-20
  • Posts: 1,772

Summary of this problem.
----
http://forum.redump.org/post/59692/#p59692

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.

http://forum.redump.org/post/59700/#p59700

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.

http://forum.redump.org/post/59984/#p59984

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.

http://forum.redump.org/post/59705/#p59705

Also, it should be easy to find any other bad dumps if someone creates a tool to scan these sectors.

If the research of limbo43 is correct, it easy to use the sector view of isobuster and check 1913776-1913795.

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

  • Registered: 2006-12-23
  • Posts: 4,137

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.

  • Registered: 2011-02-20
  • Posts: 1,772

Jackal wrote:

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.

Jackal wrote:

Some sectors on his dump have zero bytes where the other dump has data.

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

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

  • Registered: 2014-10-06
  • Posts: 734

Any updates?

16 Reply by limbo43 (edited by limbo43 2018-08-12 20:39:49)

  • Registered: 2017-03-19
  • Posts: 77

The copy I dumped did not suffer from the zeroes-after-layerbreak issue I described in the above posts. Using Freecell this is a silent failure for whatever reason. I wrote a utility in python a while back that checks for these sectors. Every time I dump a game now, I have that tool run afterwards and if there's a problem I redump the disc. Usually the second dump is correct, although there have been times where I had to do it three times in a row. I'm sure now that it is some kind of fatigue issue on the drive, whether from heat or vibration or whatever. Letting it sit for a minute between dumps is usually enough to avoid it.

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.

17 Reply by limbo43 (edited by limbo43 2018-08-09 22:02:25)

  • Registered: 2017-03-19
  • Posts: 77

The OP has a barcode included for NBA Live 2004. This game doesn't have a barcode... is that just a typo/misprint?

Will keep digging

  • Registered: 2011-02-20
  • Posts: 1,772

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.

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

  • Registered: 2017-03-19
  • Posts: 77

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.

  • Registered: 2006-12-23
  • Posts: 4,137

limbo43 wrote:

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?

21 Reply by limbo43 (edited by limbo43 2018-08-12 20:50:36)

  • Registered: 2017-03-19
  • Posts: 77

sarami wrote:
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).

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

limbo43: btw, any chance for the box serials for your dumps? XXX-XXXXX on the box sides (sometimes also on the disc fronts).

23 Reply by limbo43 (edited by limbo43 2018-08-12 22:58:37)

  • Registered: 2017-03-19
  • Posts: 77

edit: will update in a bit

24 Reply by limbo43 (edited by limbo43 2018-08-12 23:23:39)

  • Registered: 2017-03-19
  • Posts: 77

Progress. Holy shit.

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

  • Registered: 2006-12-23
  • Posts: 4,137

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?