Redump Forum

1-bit errors are fixed automatically

if (these sectors have 1-bit error) {
        QCurrentSector = QGenSector
    }

Who fixes the 1-bit error of QCurrentSector? Isn't it fixed by changing each bit to opposite?
I can't understand how to use the FixLevel/[FixLevel] bits.

sarami wrote:I can't understand how to use the FixLevel/[FixLevel] bits.

FixLevel = 1

if (Q-CRC of QCurrentSector is bad) {
    create QGenSector1 from QNextSector - 1
   
    compare 96bits of QCurrentSector and QGenSector1
   
    if (the difference is 1-bit) {
        QCurrentSector = QGenSector1
    }
    else {
       create QGenSector2 from QPrevSector + 1

       compare 96bits of QCurrentSector and QGenSector2

       if (the difference is 1-bit) {
        QCurrentSector = QGenSector2
       }
       else {   
          try to change each bit to opposite (Max 96 times)    // for the case when QCurrentSector and QGenSector are different
          if not success {     
             reread sector (*1)
          }
       }
    }

FixLevel = 2

if (Q-CRC of QCurrentSector is bad) {
    create QGenSector1 from QNextSector - 1
   
    compare 96bits of QCurrentSector and QGenSector1
   
    if (the difference is 2-bit or less) {
        QCurrentSector = QGenSector1
    }
    else {
       create QGenSector2 from QPrevSector + 1

       compare 96bits of QCurrentSector and QGenSector2

       if (the difference is 2-bit or less) {
        QCurrentSector = QGenSector2
       }
       else {   
          try to change each bit to opposite (Max 96*96? times)    // for the case when QCurrentSector and QGenSector are different
          if not success {     
             reread sector (*1)
          }
       }
    }

FixLevel = 3

if (Q-CRC of QCurrentSector is bad) {
    create QGenSector1 from QNextSector - 1
   
    compare 96bits of QCurrentSector and QGenSector1
   
    if (the difference is 3-bit or less) {
        QCurrentSector = QGenSector1
    }
    else {
       create QGenSector2 from QPrevSector + 1

       compare 96bits of QCurrentSector and QGenSector2

       if (the difference is 3-bit or less) {
        QCurrentSector = QGenSector2
       }
       else {   
          try to change each bit to opposite (Max 96*96*96? times)    // for the case when QCurrentSector and QGenSector are different
          if not success {     
             reread sector (*1)
          }
       }
    }

sarami wrote:Who fixes the 1-bit error of QCurrentSector? Isn't it fixed by changing each bit to opposite?

Comparing QCurrentSector and QGenSector1 and QCurrentSector and QGenSector2 are 2 operations, changing the bits is 96^FixLevel operations, much longer. So it's faster to compare with the generated sector first. Maybe also worth to add a flag not to use the bit changing, if the difference between QCurrentSector and QGenSector1 or QCurrentSector and QGenSector2 is FixLevel+1 ... FixLevel+9 bits then not to use the bits changing for this sector.

For example:

FixLevel = 1

compare 96bits of QCurrentSector and QGenSector1

QCurrentSector = 0101010101
QGenSector1 =  0111010111

Difference: 2 bits. 2 bits is between "FixLevel+1 ... FixLevel+9", so you don't change the bits, you reread the sector.
   
Or:

FixLevel = 1

compare 96bits of QCurrentSector and QGenSector1

QCurrentSector = 010101010101
QGenSector1 = 101010101010

Difference: 12 bits. 12 bits is more than FixLevel+9, so we assume the sector is probably of a different type than generated sector and we're trying to change the bits before rereading.

Back to the PS4 Kiosk discussion, I've been able to get ISO Buster to output the disc i'm testing with repeatable hashes 3 or 4 times. DIC still outputting different hashes each time. Perhaps DIC isn't reading the sectors correctly or reporting read errors properly, or maybe ISO Buster just keeps making the same mistakes and so the result is the same hashes...

Up http://www.mediafire.com/file/eq80y20l9 … r_test.7z.
> create QGenSector1 from QNextSector - 1
> create QGenSector2 from QPrevSector + 1
added.
Others haven't added yet.

user7 wrote:maybe ISO Buster just keeps making the same mistakes and so the result is the same hashes...

How about other tool except DIC and IsoBuster?

>How about other tool except DIC and IsoBuster?

I also dumped with IMG Burn and Dvdisaster once, both gave different hashes than the rest (and sizes I believe).

sarami, thank you so much for your work on DiscImageCreator. I am an Xbox1/Xbox360 addict, and have heaps of old games to rip.

I'm posting here at request of dizzzy from the discord server to share a little discovery I made ripping my retail copy of Halo 2:

Discord Server: August 3rd 2018 wrote:[6:46 PM] andoryuu3 [USA]: Does anyone know off hand if there is a way for sarami's  DiscImageCreator to preserve random padding in Xbox 1 dumps?
[6:59 PM] dizzzy [USA]: Not sure, I read your post about that. DIC produces the same hashes as Xbox Backup Creator tho
[9:00 PM] andoryuu3 [USA]: Well apparently I was wrong about FreeCell/XBC (the post was actually about these two), which is fine. But when I tested ripping Halo 2 via DIC with my SATA Kreon drive (J), it only produced an image about 2.6GB in size. The command I used was simply "DiscImageCreator.exe xbox J: Halo2.iso"
[9:01 PM] andoryuu3 [USA]: So either a major glitch happened due to read errors, or DIC doesn't seem to do random padding. FreeCell/XBC does though

DiscImageCreator is supposed to preserve random padding right? I ask because without it some Xbox 1 games won't run at all.

Thanks again for your work!

What is random padding?

He got a 2.6GB image instead of the standard 7825162240-bytes one.

>andoryuu3
Only Halo2? or all xbox disc you have? or all DVD you have?

And please read 1st post. /viewtopic.php?p=23214#p23214

sarami wrote:

bparker wrote:Hi @sarami, could you push your current code with the linux support to github so I can take a look at some of the issues? Thanks!

Uploaded in test branch.

Thanks, how do we build this for Linux? I don't see a Makefile anywhere.