DiscImageCreator

[sarami]

1. execute ASUS_ODD_FW_Changer_(Modified)
2-1. select DE_ASUS_BC-12D2HT_3.00.bin => Updating Failure #4.
2-2. ASUS-BC-12D2HT-3.01-WM00900-211711151926 => Updating Failure #4.
2-3. select DE_ASUS_BW-16D1HT_3.01.bin => Updating Failure #5.
2-4. select DE_ASUS_BW-16D1HT_3.02.bin => Updating Failure #5.

[RibShark]

1. execute ASUS_ODD_FW_Changer_(Modified)
2-1. select DE_ASUS_BC-12D2HT_3.00.bin => Updating Failure #4.
2-2. ASUS-BC-12D2HT-3.01-WM00900-211711151926 => Updating Failure #4.
2-3. select DE_ASUS_BW-16D1HT_3.01.bin => Updating Failure #5.
2-4. select DE_ASUS_BW-16D1HT_3.02.bin => Updating Failure #5.

In that case first crossflash ASUS-BW-16D1HT-3.10-WM01601-211901041014.bin and then flash desired firmware.

[Jackal]

Can you tell us how the descrambling works again? I mean, for mastering errors, what are the criteria to descramble?

1. Sector needs to be the data [Ctrl byte of subQ is 4 or 6]
2. Sync needs to be valid [00 FF FF FF FF FF FF FF FF FF FF 00]
3-1. If mode is 0x60, 2336 bytes need to be zero.
3-2. If mode is 0x61 and reserved area (from 0x814 to 0x81b) is reversed (all zero), it's descrambled.
3-3. If mode is reversed (0x00 or 0x01 or 0x02), it's descrambled.
3-4. If mode is unknown and msf is reversed and reserved area isn't all zero, it's not descrambled.
3-5. If mode is unknown and msf isn't reversed and reserved area is all zero, it's descrambled.
3-6. If mode is unknown and msf isn't reversed and reserved area is invalid, it's not descrambled.

Ok, so the VOB sectors remain scrambled. Did we cover everything then?

[reentrant]

Descramble algorithm is the most critical aspect and it'd be very troublesome if it had to be changed once again...

Another idea:
Why to replace sector with C2 errors with 0x55 when you could just replace specific bytes with some pattern and leave the good data as is?

Another question:
What if there's a sector with few bits set to 1 in C2 and it's easily correctable by ECC? Should it be replaced with 0x55, fixed or left as is?

A protection is detected with a particular range. The C2 errors within that range are the trigger for replacing sectors with 0x55. There is no good data there.

There's a good data there - bytes which have 0 in C2 map. Bad bytes are marked with 1 in C2 map. I know where this goes - all discs with any protection should be reripped, including safedisc. For me personally 0x55 is fine since it doesn't involve all the hassle. If someone wants pure image he can generate IPS patch and store it in DB.

[Jackal]

Descramble algorithm is the most critical aspect and it'd be very troublesome if it had to be changed once again...

Another idea:
Why to replace sector with C2 errors with 0x55 when you could just replace specific bytes with some pattern and leave the good data as is?

Another question:
What if there's a sector with few bits set to 1 in C2 and it's easily correctable by ECC? Should it be replaced with 0x55, fixed or left as is?

A protection is detected with a particular range. The C2 errors within that range are the trigger for replacing sectors with 0x55. There is no good data there.

There's a good data there - bytes which have 0 in C2 map. Bad bytes are marked with 1 in C2 map. I know where this goes - all discs with any protection should be reripped, including safedisc. For me personally 0x55 is fine since it doesn't involve all the hassle. If someone wants pure image he can generate IPS patch and store it in DB.

Yes there's 312 error bits out of 2352 for each sector that are marked 1? But we don't know if these C2 pointers are in any way reliable or of the rest of the data is even good. I'm just going with Nexy's standpoint that "hard errors" need to be replaced with 0x55, so any protection sectors that are physically unreadable (Rings) or with a fixed amount of C2 error pointers, regardless of how many bits. If someone has a better idea, let us know.

[Nexy]

I just haven't done any testing yet to see if SafeDisc is reliably dumpable and verifyable, I suspect the single byte (312) is like CDS and an intentional weak sector that the hardware can't read correctly.  I can test this with some of my Need For Speed games as I have several copies of the same disc and I now have 10 plextors to do testing with.

I mean that would be a huge pain to redump all safedisc, I'm not opposed to this but I think some people would be. I am more interested in dumping correctly though. It causes a lot of heated argument but we're getting on the same page mostly now. This is not an issue for me because I keep all discs, but this presents a problem where large parts of the db would be instantly invalidated, however I don't have issue with that. I do understand that others will. However I am in favor of as accurate as possible dumping, regardless of having to go do stuff again if it's found wrong. I have been redumping already my entire collection with DIC without a single complaint, and glad to do it. SafeDisc protection does not check for the bad sectors at all, they are just there to prevent copying easily,which is a bit silly since it's been easily defeated since early 2000's, so I don't think it really matters much when it comes to using the images, but is that preservation?

I guess we will have to work with what he have, and we can change things in the future when we have methods and hardware to do better. Eventually we *will* have means to dump entire discs linearly and we'll need a special image format for it. Until then we keep going as we are now.

Anyways back on topic, there should be no "correction" or "fixing" things imo, and that includes subchannel data. Too many discs have intentional errors, and too many drives/windows do not fix these errors when reading the disc, particularly edc/ecc errors.

[reentrant]

How about IPS patches to convert between variants (0x55 and original data)?

DIC could generate it on the fly the same way the EccEdc replaces data with 0x55. The process of 'repairing' current dumps would involve only datting IPS patches not nuking current dumps.

The same way DMI, PFI, SS is handled already for XBOX.

There's a problem with LaserLock and RingProtech. I'm waiting for some HW that handles the rings better. I don't like nuking current dumps but otoh I like when you pull out more valid data from the discs

[sarami]

In that case first crossflash ASUS-BW-16D1HT-3.10-WM01601-211901041014.bin and then flash desired firmware.

I can change the firmware.

Code: Select all

                VendorId: ASUS    
               ProductId: BW-16D1HT       
    ProductRevisionLevel: 3.02
          VendorSpecific: W000800K91HCMA5808  

Uploaded: http://www.mediafire.com/file/eq80y20l9 … st.7z/file
- added: 0xF1 opcode for ASUS BW-16D1HT 3.02

Only 1 sector is overread if combined offset is plus, so offset +588 or more has not supported yet.

Did we cover everything then?

I don't know 3PLock.

[RibShark]

Uploaded: http://www.mediafire.com/file/eq80y20l9 … st.7z/file
- added: 0xF1 opcode for ASUS BW-16D1HT 3.02

Only 1 sector is overread if combined offset is plus, so offset +588 or more has not supported yet.

Thanks! Tested and this seems to work great.

[user7]

Im' getting a crash right before the bin generation on a CD-R press kit (scm / img generate fine), no c2 errors.

https://drive.google.com/file/d/1S0PYwp … sp=sharing