Redump Forum

The one without /ms (or both if you want, we may need both at a later time)

Thanks; submitted here:
/viewtopic.php?t=16773 … on-thread/

Olo dumped a disc at 8x speed, but the SecuROM data was messed up:

Data from DIC dump:
MSF: 01:08:58 Q-Data: 610101 01:06:59 00 01:08:59 b0a7

correct (unmodified) data:
MSF: 01:08:58 Q-Data: 610101 05:06:58 00 21:08:58 b0a7

And this one was not detected for some reason at 8x, but at 4x it is:
MSF: 01:08:52 Q-Data: 610101 01:06:53 00 01:08:53 6d32

Is it normal that higher speed can cause so many errors? Any way to optimize this?

[ERROR] Number of sector(s) where bad MSF: 2
        Sector: 14098, 14099,
[ERROR] Number of sector(s) where user data doesn't match the expected ECC/EDC: 1
        Sector: 14097,
[ERROR] Number of sector(s) where sync(0x00 - 0x0c) is zero: 1
        Sector: 901,

In fact, the damaged sectors are 14097, 14098, 14099 and 14100. Why does it say 901 instead of 14100? DIC is probably using a wrong algorithm to show the sector numbers.

F1ReB4LL wrote:In fact, the damaged sectors are 14097, 14098, 14099 and 14100. Why does it say 901 instead of 14100? DIC is probably using a wrong algorithm to show the sector numbers.

Replace EccEdc.exe with this
http://www.mediafire.com/file/2quudw2bl … st.7z/file

Jackal wrote:Olo dumped a disc at 8x speed, but the SecuROM data was messed up

If random error also exists in SecuROM data, it's difficult to fix.

KailoKyra dumped this disc: https://redump.info/disc/3927/ but it wasn't matching the database, because DIC is not descrambling any of the last 3 sectors.

Attached the 3 last data sectors for this disc and the DIC log:

If I remember correctly, we agreed before that all sectors inside a data track with a valid sync should always be descrambled? But still DIC is not descrambling the first 2 sectors. The third and last sector has an invalid sync and shouldn't be descrambled.

Descramble algorithm: https://github.com/saramibreak/DiscImag … output.cpp
Line 1699

It's very complex...

Jackal wrote:If I remember correctly, we agreed before that all sectors inside a data track with a valid sync should always be descrambled?

Shouldn't all 16 bytes be correct for descrambling? What's the point in descrambling the sector with non-existant "E1" and "C1" modes?

F1ReB4LL wrote:

Jackal wrote:If I remember correctly, we agreed before that all sectors inside a data track with a valid sync should always be descrambled?

Shouldn't all 16 bytes be correct for descrambling? What's the point in descrambling the sector with non-existant "E1" and "C1" modes?

It's a data sector inside a data track, why not descramble? The sync is valid so the sector is assumed to be intact.

I'm fine with discussing and maybe coming to a new method, but then we also have to fix old dumps that were processed differently.

Some of the dumps are here: /viewtopic.php?t=12070 … to-redump/

TRUSTEDME + HARD groups. These are the suspicious ones that were picked up last time...