Page 149 of 354

Re: DiscImageCreator

Posted: Tue Jul 24, 2018 10:16 am
by 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?

Re: DiscImageCreator

Posted: Wed Jul 25, 2018 10:50 pm
by sarami
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.

Re: DiscImageCreator

Posted: Sun Jul 29, 2018 10:12 pm
by 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?

Re: DiscImageCreator

Posted: Sun Jul 29, 2018 10:18 pm
by sarami
user7 wrote:Back to dumping PS4 official kiosk discs, which are on BD-Rs, different hashes and iso sizes are returned every dump.
user7 wrote: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?

Re: DiscImageCreator

Posted: Sun Jul 29, 2018 10:32 pm
by 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.

Re: DiscImageCreator

Posted: Mon Jul 30, 2018 1:21 am
by 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.
user7 wrote: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.)

Re: DiscImageCreator

Posted: Mon Jul 30, 2018 8:43 am
by F1ReB4LL
sarami wrote: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).
sarami wrote: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.

Re: DiscImageCreator

Posted: Mon Jul 30, 2018 10:56 am
by 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?

Re: DiscImageCreator

Posted: Mon Jul 30, 2018 12:02 pm
by 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.

Re: DiscImageCreator

Posted: Tue Jul 31, 2018 8:49 am
by F1ReB4LL
sarami wrote: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.