Redump Forum

NovaAurora wrote:Same # of errors reported, same hashes.

These errors are all lead-in sectors of the 2nd session. DIC does not support generating ecc/edc yet when unreadable sectors are generated.

sarami wrote:

NovaAurora wrote:Same # of errors reported, same hashes.

These errors are all lead-in sectors of the 2nd session. DIC does not support generating ecc/edc yet when unreadable sectors are generated.

The problem is that EccEdc is checking the .img image and is reporting errors on the area that isn't included in the splitted .bin dump.
EccEdc should always scan only the .bin data tracks and nothing else.
We also get discs where it reports 225 errors but this is actually 3 seconds scrambled data inside the audio Track02.

And you get bogus "errors" like this inside audio tracks:
LBA[019483, 0x04c1b], audio
LBA[019484, 0x04c1c], MSF[00:00:00], zero sync
LBA[019485, 0x04c1d], audio

Jackal wrote:And you get bogus "errors" like this inside audio tracks:
LBA[019483, 0x04c1b], audio
LBA[019484, 0x04c1c], MSF[00:00:00], zero sync
LBA[019485, 0x04c1d], audio

The control flag of subchannel of the 19484 is incorrect.

Positive SecuROM 4 detection with DIC and PID, 0 Errors reported by DIC. 1 Error detected by CDMage in track 1.

Logs: https://cdn.discordapp.com/attachments/ … N_logs.zip

@sarami could you have a look at this plz: /viewtopic.php?p=73432#p73432

Can the shifted offset be explained by ASUS drive or a Linux bug?

NovaAurora wrote:Positive SecuROM 4 detection with DIC and PID, 0 Errors reported by DIC. 1 Error detected by CDMage in track 1.

Logs: https://cdn.discordapp.com/attachments/ … N_logs.zip

Ah sorry, EccEdc only checks 4th from the last sector but should check 4th from the last data sector. I'll fix it.

Jackal wrote:Can the shifted offset be explained by ASUS drive or a Linux bug?

I have no idea about it. Which sector is shifted?

sarami wrote:

Jackal wrote:Can the shifted offset be explained by ASUS drive or a Linux bug?

I have no idea about it. Which sector is shifted?

The audio data is shifted 1 sample (4 bytes) between the 2 dumps.

Trying to dump a PC CD and it took like 3 hours to dump with Plextor+MPF and failed

https://www.mediafire.com/file/26pbe3na … H.zip/file

I dumped it with Plextor+CloneCD and it worked fine, and CloneCD verified to another drive fine. CDMage shows zero errors.

I'm not sure what is wrong with MPF here that it took so long and that it failed. Should I submit the Plextor+CloneCD dump, or should I only submit dumps that verified with Plextor+MPF?

---

Another disc dumped fine with Plextor+MPF, shows it uses SecuROM, and has 1 error. I tried dumping it with MPF on another drive but MPF went for 3 hours and I finally stopped it and used CloneCD. Is MPF supposed to work to verify on non-Plextor drives, or should I be using CloneCD for the non-Plextor verification?

hiker13526 wrote:Trying to dump a PC CD and it took like 3 hours to dump with Plextor+MPF and failed

Important to note that MPF is not DIC. DIC is what MPF uses but MPF has much more attached like BOS (Protection scanning)
Protection scanning can take a VERY long time sometimes in recent versions. If it goes over 30 minutes I'd recommend disabling it in the settings and scanning it manually with PID (Protection ID). https://protectionid.net/

NovaAurora wrote:

hiker13526 wrote:Trying to dump a PC CD and it took like 3 hours to dump with Plextor+MPF and failed

Important to note that MPF is not DIC. DIC is what MPF uses but MPF has much more attached like BOS (Protection scanning)
Protection scanning can take a VERY long time sometimes in recent versions. If it goes over 30 minutes I'd recommend disabling it in the settings and scanning it manually with PID (Protection ID). https://protectionid.net/

Almost all the time was spent in the DIC terminal, not the MPF scanner.