Well I tried with a previous version of DICGUI and the scan seemed smarter and took less time.

The outcome of copy protection was :

Copy Protection: D:\00000001.TMP: SafeDisc v1 or greater
D:\00000002.TMP: SafeDisc v2 or greater
D:\rFactor.exe: SafeDisc 4.85.000

OK... I kept it runnin and now I see some progress :

0,00%: D:\00000001.TMP -
0,03%: D:\00000002.TMP -

So it's just taking really A WHILE to perform this step. :-)


I'm currently dumping one of my PC game which is on a DVD disc : rFactor Special Edition 2008.

The dumping goes fine until I reach the following step :

Running copy protection scan... this might take a while!
0,00%:  -

This operation indeed takes a while. It's about 1 hour that it stays at the same stage.
Is it normal ? This is the first time I experience this.



(2,819 replies, posted in General discussion)


I just dumped a PC game : http://forum.redump.org/topic/22515/pc- … sc-french/

Due to C2 errors, DICGUI shall not have created the .cue, .bin, ...
However, as you can see, all these files, incl. the submissionInformation have been produced.

As discussed on discord, I'm reporting this here.


Yesterday I dumped PC game « Red Alert 2 » in French : http://forum.redump.org/topic/22515/pc- … sc-french/

The dumping reported numerous c2 errors which - as far as I understand - are due to the Safedisc protection. The dumping then took a very long time.

This is also the first time I come across a file with « sub indexes ».

I checked the crc32 of the .bin and (sub-indexes).bin files and they were equal.

Can someone explain me what is the purpose of the « sub indexes » version of the file ?

After dumping a game, I basically keep all the files and delete the .scm and .img as I’m using the .cue + .bin combo.

—> Should I just keep the .bin and drop the (sub indexes).bin ?
—> Shall I keep the .img so that the combo ccd/img/sub can be used ? (in case data contained in the sub is required to run the game)



(1 replies, posted in General discussion)

Issue solved !
I discovered that tool VMP2MCR (Windows) was the faulty part.
Basically, if after converting the first part, you open the part 2 and click convert, the part2 input file was not loaded and part1 was still converted (into part 2).
So the end-result was the 5 parts 1 were merged together.
The solution was to close VMP2MCR after a part was converted and the reopen the application to convert the next part.
Now I get the proper CRC32 !


(1 replies, posted in General discussion)


I've dumped the PS1 Bios from my PSP. I don't know if there is any use of it here.
Anyway, here's the dump info:

Title    SCPHXXXX.bin
CRC32    cc82b93b
MD5    32c04484c234fd09d79625e9fe2ec232
SHA-1    b8c96eefcaedd3f8ae2a58d71671364703caaa25
Size    524288
Dump method
PSP3004 with CFW (6.61 PRO-C2_22-01-2015)
Dumper BIOS 2.6
BIOSmerge 0.2
Dump date    07-Apr-2019

What is interesting is that when I run BIOS dumper on my PSP, it shows the following information :

Region : NTSC J
BIOS version : 4.5
CRC32 : 5660F34F
Date : 05/25/00

I think the difference can come from the file size.
Mine is 524288 byte.
On the Internet, I see a reference of this BIOS and size seems to be 145 KB.

Does anyone have tried the same operation ?
What is the hash obtained ?