DiscImageCreator

[sarami]

4.1. If Q-CRC of QCurrentSector doesn't match: QGenSector = QNextSector - 1 frame (MSF - 1, AMSF - 1, fix Q-CRC).
  4.2. You do a binary compare (96 bits vs 96 bits) between QCurrentSector and QGenSector and count a number of bits that differ. If their count is <= FixLevel: QCurrentSector = QGenSector and go to p.5.

1. What FixLevel? Default of subdump is 96?
2. If QNextSector is 1st pregap sector, Is QGenSector really correct?
3. If QCurrentSector is track 1 and QNextSector is track 2, is QGenSector really correct?
4. If QCurrentSector is index 1 and QNextSector is index 2, is QGenSector really correct?
5. If QCurrentSector is ctl 0 and QNextSector is ctl 4, is QGenSector really correct?

4.3. If QEAN != null, you do a binary compare between QCurrentSector and QEAN and count a number of bits that differ. If their count is <= FixLevel: QCurrentSector = QEAN and go to p.5.
  4.4. If QISRC != null, you do a binary compare between QCurrentSector and QISRC and count a number bits that differ. If their count is <= FixLevel: QCurrentSector = QISRC and go to p.5.

6. If adr of QCurrentSector is 1 but actually QCurrentSector is EAN sector, is the adr really fixed?
7. If adr of QCurrentSector is 3 but actually QCurrentSector is EAN sector, is the adr really fixed?
8. If adr of QCurrentSector is 2 but actually QCurrentSector is ISRC sector, is the adr really fixed?
9. If adr of QCurrentSector is 2 but actually QCurrentSector is normal sector, is the adr really fixed?

10. Does this algo support all SecuROM (at least 4 patterns) and Libcrypt?

[sarami]

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.

[user7]

Returning to the conversation about PS4 kiosk discs (BD-R):

I bought some retail PS4 discs to test dumping, the result was great, they dumped fine and the non-missing ones verified redump entries properly.

However...

Back to dumping PS4 official kiosk discs, which are on BD-Rs, different hashes and iso sizes are returned every dump.

Near the last 5-10% of the dump the dumping sector progress slows WAY down and starts sputtering even a little bit. My discs are in perfect condition so that's not the problem. I'm guessing these require some kind of encryption / keys? Maybe they even use BD-Video keys? Anyone have experiencing dumping encrypted BD-Video can advise so I can test?

[sarami]

Back to dumping PS4 official kiosk discs, which are on BD-Rs, different hashes and iso sizes are returned every dump.

I dumped with ISO Buster twice, different checksums and different sizes both times, discs are in flawless condition.

I have no idea about this problem now. Is the other general BD-Rs same result, not PS4 official kiosk discs?

[user7]

Official Kiosk discs are BD-Rs. Same as Wii U did with CAT-R for their kiosk discs. I guess they didn't want to spend money pressing kiosk discs.

On a separate subject, Wii U CAT-R discs must be dumped on Wii U kiosk machines since they use a special Dev key (they're essentially no different than burnt dev discs in that regards).

I wonder if PS4 has a similar mechanism, but no key is required for dumping regular PS4 retail discs, so not sure...

I can send you a PS4 kiosk disc if you wish to investigate.

[sarami]

Uploaded test version. http://www.mediafire.com/file/eq80y20l9 … r_test.7z.
added: Output PARAM.SFO into _disc.txt -> I only checked PS3 discs.

Official Kiosk discs are BD-Rs

Firstly, I want to know whether or not general BD-Rs output different checksums and sizes. (I can't test it because I don't have BD-R drive.)

[F1ReB4LL]

1. What FixLevel? Default of subdump is 96?

FixLevel defines an acceptable level of errors. More errors than FixLevel - reread, do not fix. Each channel is 12 bytes/96 bits. 'Default' for subdump is 1 (it's not changeable). 1-bit errors are fixed automatically; if any of the channels from the read sub sector is different to the generated one in 2 or more bits - subdump rereads that sector (then counts the different bits and accepts the rereading results if the number of different bits lowered).

2. If QNextSector is 1st pregap sector, Is QGenSector really correct?
3. If QCurrentSector is track 1 and QNextSector is track 2, is QGenSector really correct?
4. If QCurrentSector is index 1 and QNextSector is index 2, is QGenSector really correct?
5. If QCurrentSector is ctl 0 and QNextSector is ctl 4, is QGenSector really correct?

No, that's why we check for Q-CRC. Even if the QCurrentSector is different to QNextSector, but QCurrentSector's Q-CRC is good, you continue to read.
Of course, you can try to generate all kinds of sectors and compare against them.

6. If adr of QCurrentSector is 1 but actually QCurrentSector is EAN sector, is the adr really fixed?
7. If adr of QCurrentSector is 3 but actually QCurrentSector is EAN sector, is the adr really fixed?
8. If adr of QCurrentSector is 2 but actually QCurrentSector is ISRC sector, is the adr really fixed?
9. If adr of QCurrentSector is 2 but actually QCurrentSector is normal sector, is the adr really fixed?

Same, it checks for Q-CRC and rereads, if it doesn't match.

And I've remembered one more important step. When we're trying to fix 1-bit errors in subdump, we're just trying to change each bit to opposite. Like, for "001101010101" Q-sector with failed Q-CRC, we're checking the validity of Q-CRC for "101101010101", "011101010101", "000101010101", etc. So you don't need to know the sector type to fix 1-bit Q-channel errors. Not sure if it's effective for 2-bits errors and above (too many variants to check).

10. Does this algo support all SecuROM (at least 4 patterns) and Libcrypt?

Subdump - no, but you can add additional Q-CRC checks for these.

Also I forgot to mention the P and R-W channels fixing. Subdump analyzes the channel and if 7 or more bytes are equal, we define it as a 'padding byte' for this channel of this sector, then we compare 12 bytes of the read sector with the generated sector with all 12 bytes = padding byte, then we compare the difference in bits with the FixLevel value. CD+G channels won't have any 'padding' bytes, so they won't be fixed, just ignored. There are many PSX discs with 0x01, 0x02, 0x03 bytes in R-W, this pattern should be implemented somehow to avoid the unwanted fixes.

[sarami]

Like this?

Code: Select all

if (Q-CRC of QCurrentSector is bad) {
    create QGenSector from QNextSector - 1
    
    compare 96bits of QCurrentSector and QGenSector
    
    if (these sectors have 1-bit error) {
        try to change each bit to opposite (Max 96 times?)
    }
    else if (these sectors have 2 or more bit errors) {
        reread sector (*1)
    }
}

Question
(*1). How many times subdump reread the sector? If it can't get the good Q-CRC, is the sector written to file with being bad?

[user7]

Near sector it slowed down/chopping progress: 22600000/23652352

I dumped the same disc twice with the new test build.

dump 1:
<rom name="dump1.iso" size="48440016896" crc="eeb8ef26" md5="e94131750b44decbab717a68165d355c" sha1="db7fe92fbe5d337ec1f9f5e464ab76f543963e42" />

dump 2:
<rom name="dump2.iso" size="48440016896" crc="8f96853a" md5="2a08985a14c6362c65645dee4aed3e91" sha1="ed0b1a3b22221335eb2b569d10d9a6a59cee77e1" />

Hmmm at least the sizes are the same.

[F1ReB4LL]

Like this?

Code: Select all

if (Q-CRC of QCurrentSector is bad) {
    create QGenSector from QNextSector - 1
    
    compare 96bits of QCurrentSector and QGenSector
    
    if (these sectors have 1-bit error) {
        try to change each bit to opposite (Max 96 times?)
    }
    else if (these sectors have 2 or more bit errors) {
        reread sector (*1)
    }
}

More like:

Code: Select all

if (Q-CRC of QCurrentSector is bad) {
    create QGenSector from QNextSector - 1
    
    compare 96bits of QCurrentSector and QGenSector
    
    if (these sectors have >[FixLevel]-bit error) {
        QCurrentSector = QGenSector
    }
    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)
    }
}

Or:

Code: Select all

if (Q-CRC of QCurrentSector is bad) {
    create QGenSector1 from QNextSector - 1
    
    compare 96bits of QCurrentSector and QGenSector1
    
    if (these sectors have >[FixLevel]-bit error) {
        QCurrentSector = QGenSector1
    }
    else {
       create QGenSector2 from QPrevSector + 1

       compare 96bits of QCurrentSector and QGenSector2

       if (these sectors have >[FixLevel]-bit error) {
        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)
          }
       }
    }

Comparing with both QNextSector-1 and QPrevSector+1 would help with pregap areas.

Also, you can try to change not only 1 bit to opposite, but [FixLevel] bits, should be something like 96^2 variants for FixLevel=2, etc., but I don't know about the speed of such calculations.

Question
(*1). How many times subdump reread the sector? If it can't get the good Q-CRC, is the sector written to file with being bad?

Defined by -rereadnum commandline option.