76

(57 replies, posted in General discussion)

So you have the same CMR2 disc? could you post the verification, and the SecuROM data for both offsets?

77

(57 replies, posted in General discussion)

sarami wrote:

The same issue occurs in colin mcrae rally 2.0. http://redump.org/disc/31587/

And confirmed other problem.
_disc.txt

========== LBA[000000, 0000000], Sub Channel ==========
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
    P ff ff ff ff ff ff ff ff ff ff ff ff
    Q 41 01 01 00 00 00 00 00 02 01 38 13
    R 00 00 00 00 00 00 00 00 00 00 00 00
    S 00 00 00 00 00 00 00 00 00 00 00 00
    T 00 00 00 00 00 00 00 00 00 00 00 00
    U 00 00 00 00 00 00 00 00 00 00 00 00
    V 00 00 00 00 00 00 00 00 00 00 00 00
    W 00 00 00 00 00 00 00 00 00 00 00 00
======= Offset(Drive offset data referes to http://www.accuraterip.com) =======
     Combined Offset(Byte)  -2468, (Samples)  -617
    -   Drive Offset(Byte)    120, (Samples)    30
    ----------------------------------------------
           CD Offset(Byte)  -2588, (Samples)  -647
    Overread sector: -2
    Subch Offset: 1

AMSF 00:02:01 is gotten in LBA 0. So The subs is shifted automatically. I think your 2 subs is same.

shifted (The sub of LBA 0 gets from LBA -1, LBA 1 gets from LBA 0 ...)

LBA[000000, 0000000], P[ff], Q[410100371045000002000793]{ Data,      Copy NG,                  Track[01], Idx[00], RMSF[37:10:45], AMSF[00:02:00]}, RtoW[0, 0, 0, 0]
LBA[000001, 0x00001], P[ff], Q[410101000000000002013813]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:00], AMSF[00:02:01]}, RtoW[0, 0, 0, 0]
LBA[000002, 0x00002], P[00], Q[41010100000100000202a221]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:01], AMSF[00:02:02]}, RtoW[0, 0, 0, 0]
LBA[000003, 0x00003], P[00], Q[410101000002000002035cd2]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:02], AMSF[00:02:03]}, RtoW[0, 0, 0, 0]
LBA[000004, 0x00004], P[00], Q[410101000003000002048664]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:03], AMSF[00:02:04]}, RtoW[0, 0, 0, 0]
LBA[000005, 0x00005], P[00], Q[41010100000400000205f191]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:04], AMSF[00:02:05]}, RtoW[0, 0, 0, 0]
LBA[000006, 0x00006], P[00], Q[410101000005000002066ba3]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:05], AMSF[00:02:06]}, RtoW[0, 0, 0, 0]
LBA[000007, 0x00007], P[00], Q[410101000006000002079550]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:06], AMSF[00:02:07]}, RtoW[0, 0, 0, 0]
LBA[000008, 0x00008], P[00], Q[410101000806000012071551]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:08:06], AMSF[00:12:07]}, RtoW[0, 0, 0, 0]
LBA[000009, 0x00009], P[00], Q[41010100000700000208ceee]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:07], AMSF[00:02:08]}, RtoW[0, 0, 0, 0]
LBA[000010, 0x0000a], P[00], Q[41010100000800000209bb36]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:08], AMSF[00:02:09]}, RtoW[0, 0, 0, 0]
LBA[000011, 0x0000b], P[00], Q[41010100000900000210927f]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:09], AMSF[00:02:10]}, RtoW[0, 0, 0, 0]

no shifted

LBA[000000, 0x00000], P[ff], Q[410101000000000002013813]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:00], AMSF[00:02:01]}, RtoW[0, 0, 0, 0]
LBA[000001, 0x00001], P[00], Q[41010100000100000202a221]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:01], AMSF[00:02:02]}, RtoW[0, 0, 0, 0]
LBA[000002, 0x00002], P[00], Q[410101000002000002035cd2]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:02], AMSF[00:02:03]}, RtoW[0, 0, 0, 0]
LBA[000003, 0x00003], P[00], Q[410101000003000002048664]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:03], AMSF[00:02:04]}, RtoW[0, 0, 0, 0]
LBA[000004, 0x00004], P[00], Q[41010100000400000205f191]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:04], AMSF[00:02:05]}, RtoW[0, 0, 0, 0]
LBA[000005, 0x00005], P[00], Q[410101000005000002066ba3]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:05], AMSF[00:02:06]}, RtoW[0, 0, 0, 0]
LBA[000006, 0x00006], P[00], Q[410101000006000002079550]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:06], AMSF[00:02:07]}, RtoW[0, 0, 0, 0]
LBA[000007, 0x00007], P[00], Q[410101000806000012071551]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:08:06], AMSF[00:12:07]}, RtoW[0, 0, 0, 0]
LBA[000008, 0x00008], P[00], Q[41010100000700000208ceee]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:07], AMSF[00:02:08]}, RtoW[0, 0, 0, 0]
LBA[000009, 0x00009], P[00], Q[41010100000800000209bb36]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:08], AMSF[00:02:09]}, RtoW[0, 0, 0, 0]
LBA[000010, 0x0000a], P[00], Q[41010100000900000210927f]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:09], AMSF[00:02:10]}, RtoW[0, 0, 0, 0]

I don't know whether should be shifted or not.

CMR2 data: http://redump.org/disc/31587/
and 3 more:
http://redump.org/disc/21540/
http://redump.org/disc/2025/
http://redump.org/disc/31596/

How can we be sure these discs have the correct data? (I dont own any of these discs anymore.. data obtained from CCD images).. The errors seem to be shifted by 9 sectors, so I dont think this is caused by any offset?

78

(57 replies, posted in General discussion)

Usurper is getting weird subs on this disc: http://redump.org/disc/38865/

Subs: https://www.mediafire.com/?vr1ell67xdox99e

psxt001z reports modified sectors on nearly every sector. I added the 11 intentional errors to the dump page, but the data seems shifted and doesn't xor like other discs. Could this be a mastering error?

edit: Here another disc with the same issue: http://redump.org/disc/2086/

Subs: https://www.mediafire.com/?6c8bb9r5z3256id

They seem to have no pregap error, so maybe it's just a different type of SecuROM?

79

(57 replies, posted in General discussion)

More undetected sectors on Shadow Man: http://redump.org/disc/41279/

DIC output attached. It was missing 4x9 sectors (dump page has all sectors added).

TIA

80

(57 replies, posted in General discussion)

Hi, Zapper was missing 1 sector in DIC output: http://redump.org/disc/40768/

MSF: 01:55:27 Q-Data: 410101 01:13:27 00 01:57:27 35db

Maybe there was a random error that caused it to skip this sector?

81

(57 replies, posted in General discussion)

sarami wrote:

Coded: http://www.mediafire.com/file/eq80y20l9 … or_test.7z
  Output in <filename>_subIntention.txt

Tested 3 discs
FIFA 99 http://redump.org/disc/23791/
Die Hard: Nakatomi Plaza http://redump.org/disc/35826/
Unreal Tournament 2004 (USA) (En,Fr,Es,It) (Disc 6) (Play Disc) // This doesn't exist in db.
These subs and logs http://www.mediafire.com/file/ubs6v8rbn … omSubs3.7z

In this reserch, I knew there are 3 types(v1.x - v3.x a.k.a OLD, v4.x a.k.a NEW, v5 a.k.a NEW?) at a mininum in CD. But there are yet many version in securom according to this site (http://www.cdmediaworld.com/hardware/cd … urom.shtml),  So We need to continue to test. http://redump.org/discs/quicksearch/sec … ction/only

Thx.. is it also possible to add the pregap sector to the log for SecuROM NEW? or could you give it manually for Die Hard: Nakatomi Plaza?

82

(57 replies, posted in General discussion)

sarami wrote:

Could you maybe add a function to DiscImageCreator to extract the SecuROM data from the disc, or maybe parse it from the .sub?

MSF: 03:09:56 Q-Data: 410101 07:07:56 00 23:09:56 dfde

Should I output the text data like this to file?

Yes

83

(57 replies, posted in General discussion)

sarami wrote:

FIFA99

LBA[040169, 0x09ce9],  Data,      Copy NG,                  Track[01], Idx[01], RMSF[08:55:44], AMSF[08:57:44], RtoW[0, 0, 0, 0]
LBA[040170, 0x09cea],  Data,      Copy NG,                  Track[01], Idx[01], RMSF[08:55:45], AMSF[08:57:45], RtoW[0, 0, 0, 0]
LBA[040171, 0x09ceb],  Data,      Copy NG,                  Track[01], Idx[01], RMSF[08:55:47], AMSF[08:57:47], RtoW[0, 0, 0, 0]
LBA[040172, 0x09cec],  Data,      Copy NG,                  Track[01], Idx[01], RMSF[08:55:48], AMSF[08:57:48], RtoW[0, 0, 0, 0]
LBA[040173, 0x09ced],  Data,      Copy NG,                  Track[01], Idx[01], RMSF[08:55:49], AMSF[08:57:49], RtoW[0, 0, 0, 0]
LBA[040174, 0x09cee],  Data,      Copy NG,                  Track[01], Idx[01], RMSF[08:55:50], AMSF[08:57:50], RtoW[0, 0, 0, 0]
LBA[040175, 0x09cef],  Data,      Copy NG,                  Track[01], Idx[01], RMSF[08:55:51], AMSF[08:57:51], RtoW[0, 0, 0, 0]
LBA[040176, 0x09cf0],  Data,      Copy NG,                  Track[01], Idx[01], RMSF[08:55:52], AMSF[08:57:52], RtoW[0, 0, 0, 0]
LBA[040177, 0x09cf1],  Data,      Copy NG,                  Track[01], Idx[01], RMSF[08:55:53], AMSF[08:57:53], RtoW[0, 0, 0, 0]
LBA[040178, 0x09cf2],  Data,      Copy NG,                  Track[01], Idx[01], RMSF[08:55:54], AMSF[08:57:54], RtoW[0, 0, 0, 0]
LBA[040179, 0x09cf3],  Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:55:54], AMSF[18:57:54], RtoW[0, 0, 0, 0]
LBA[040180, 0x09cf4],  Data,      Copy NG,                  Track[01], Idx[01], RMSF[08:55:55], AMSF[08:57:55], RtoW[0, 0, 0, 0]
LBA[040181, 0x09cf5],  Data,      Copy NG,                  Track[01], Idx[01], RMSF[08:55:56], AMSF[08:57:56], RtoW[0, 0, 0, 0]

LBA[040170] is normal subchannel
LBA[040171] to LBA[040178] (8 sector): RMSF/AMSF is shifted
LBA[040179] is intentional error subchannel
LBA[040180] is normal subchannel
I confirmed this type is repeated 24 times.
coded this. http://www.mediafire.com/file/eq80y20l9 … or_test.7z

I guess that's what is causing the errors in the main dump image? But the protection only scans for the intentional errors I suppose?

Could you maybe add a function to DiscImageCreator to extract the SecuROM data from the disc, or maybe parse it from the .sub?
I don't know if you already added this function for LibCrypt. We will use the same format for SecuROM:

MSF: 03:09:56 Q-Data: 410101 07:07:56 00 23:09:56 dfde

http://i.imgur.com/C21DXDr.png

edit: psxt001z --libcrypt *.sub

seems to work fine for this purspose smile but it only works if the .sub starts at 02:00.

psxt001z by Dremora, v0.20 beta 13 derus fix

MSF: 01:08:50 Q-Data: 410101 21:06:50 00 05:08:50 0a8f  xor 8001 3237 P1 xor 20 04
MSF: 01:38:50 Q-Data: 410101 11:36:50 00 09:38:50 2096  xor 8001 1edb P1 xor 10 08
MSF: 01:51:22 Q-Data: 410101 01:41:22 00 01:41:22 166b  xor 8001 8e30 P2 xor 08 10
MSF: 01:56:64 Q-Data: 410101 01:54:74 00 01:56:6c 2fd4  xor 8001 0553 P3 xor 10 08
MSF: 02:02:33 Q-Data: 410101 02:10:33 00 02:0a:33 42bc  xor 8001 132c P2 xor 10 08
MSF: 02:50:26 Q-Data: 410101 02:58:26 00 02:58:26 28aa  xor 8001 132c P2 xor 10 08
MSF: 02:55:35 Q-Data: 410101 06:53:35 00 22:55:35 c6a3  xor 8001 c701 P1 xor 04 20
MSF: 03:03:31 Q-Data: 410101 03:41:31 00 03:01:31 dfbd  xor 8001 8c73 P2 xor 40 02
MSF: 03:10:62 Q-Data: 410101 0b:08:62 00 13:10:62 5009  xor 8001 50cf P1 xor 08 10
MSF: 03:24:70 Q-Data: 410101 03:22:71 00 03:24:f0 58f8  xor 8001 bbd8 P3 xor 01 80
Number of modified sectors: 10

And for the SecuROM OLD it outputs 24 * 9 = 216 modified sectors. Added them here as an example: http://redump.org/disc/5331/

And here I only added the 24 intentional errors:  http://redump.org/disc/41170/

Here is SecuROM NEW: http://redump.org/disc/31548/

84

(57 replies, posted in General discussion)

Turns out I did have a SecuROM NEW (5.00.03.0005) game lying around: Sonic Adventure DX: Director's Cut (Disc 1): http://www97.zippyshare.com/v/Yf3QRgpx/file.html

10 errors + 1 in pregap (sector -1), as previously confirmed by gorelord4e..

85

(57 replies, posted in General discussion)

sarami wrote:
Jackal wrote:

Another thing that I noticed is that SecuROM games dumped with DIC using the D8 output often result in a bad dump of the data track (with multiple errors, instead of just the 1 error at the end where mode1=mode2 and vice versa), with shifted sectors.

All disc? or specified disc?

People reported these issues before. Maybe only old SecuROM discs are affected and maybe it explains why subdump is giving me bad dumps on these discs. Did you try to dump FIFA 99 with DIC and subdump to see if you get repeated/shifted sectors?

Jackal wrote:

- Do the t2final.sub errors occur in the same range as documented in DIC? So should the latest DIC and /se parameter dump these errors correctly always?

This range is temporary. Fixed. (LBA  5000 - 18199) or (LBA 40100 - 43799) The more disc test, the more precise.
http://www.mediafire.com/file/eq80y20l9 … or_test.7z

Jackal wrote:

- Can you check the 24 sectors in the t2final.sub to confirm that they are all intentional errors (with XOR 0x0080 or 0x8001)?

I confirmed apparent 16 error, couldn't find the rest.

Did you also include the NFS3 results in the new error range?
There are really 24 errors in the Turok 2 and NFS3 subs.
Turok 2:
41 01 01 18 55 10 00 00 57 10  58 D0
41 01 01 18 58 36 00 01 00 36  37 1E
41 01 01 08 79 65 00 09 05 65  B7 EF
41 01 01 09 09 66 00 09 13 66  3D 76
41 01 01 08 02 43 00 89 04 43  B8 2F
41 01 01 09 24 66 00 09 02 66  76 7F
41 01 01 19 10 20 00 01 12 20  36 14
41 01 01 09 11 59 00 09 13 41  17 22
41 01 01 09 1B 50 00 09 05 50  92 99
41 01 01 09 54 27 00 09 14 27  79 EA
41 01 01 09 36 50 00 09 1C 50  50 39
41 01 01 09 59 31 00 09 23 31  10 83
41 01 01 49 21 49 00 0B 23 49  0B E5
41 01 01 09 23 70 00 09 25 54  FE 81
41 01 01 09 24 25 00 09 26 67  53 C6
41 01 01 09 26 51 00 09 28 D0  B8 35
41 01 01 09 29 33 00 09 31 71  3C 49
41 01 01 09 38 33 00 09 22 33  5D CB
41 01 01 09 32 48 00 09 34 6C  28 7F
41 01 01 09 33 47 00 09 35 05  C6 98
41 01 01 09 35 69 00 09 37 E8  C6 84
41 01 01 09 38 4B 00 09 40 09  B8 31
41 01 01 09 31 51 00 09 51 51  59 98
41 01 01 09 43 26 00 09 C4 26  04 78

Jackal wrote:

- Did you also check the Track01 pregap of your discs for intentional errors?

I checked this. http://redump.org/disc/8632/ But I couldn't find apparent error.

gorelord4e says that sector -1 should have an error, for SecuROM v3 discs at least, but we need to check other versions too. These 2 old version discs don't seem to have any errors in pregap.

86

(57 replies, posted in General discussion)

NFS3 sub (again, 24 intentional error sectors): http://www75.zippyshare.com/v/LYV46pWC/file.html
subdump (-mode 6 -rereadnum 25 -speed 4 -flushspeed 4 -fix 2): http://www87.zippyshare.com/v/hI5Ag4zn/file.html

I also checked both games for intentional errors in the Track01 pregap, but did not find any.. I hope sarami can check the pregap of newer SecuROM discs, but it seems unlikely that intentional errors are placed there, because many drives can't even read the pregap?

87

(57 replies, posted in General discussion)

@sarami,

here is the data track .sub for Turok 2 - Seeds of Evil (Europe) (En,Fr,Es,It) - http://redump.org/disc/5331/ - http://www90.zippyshare.com/v/RHIsgwRc/file.html
I dumped it from 2 discs using CDTool (001b and 100b modes) with 2 drives, Sony Optiarc & Plextor Premium. Then I cleaned random errors with CDGTool and by comparing the dumps.
The end result is a .sub with 24 sectors containing modified Q-channel bytes. I'm pretty sure that this dump is fully correct now.

The thing that bothers me is that subdump -i ?: -f test.sub -mode 6 -rereadnum 25 -speed 4 -flushspeed 4 -fix 2 and even without -fix 2 gives a totally different output on these sectors with no modified bytes, but instead repeated sectors! Here is the plextor subdump dump with above parameters and -fix 2 (also verified from 2 discs): http://www24.zippyshare.com/v/obES60fB/file.html

Another thing that I noticed is that SecuROM games dumped with DIC using the D8 output often result in a bad dump of the data track (with multiple errors, instead of just the 1 error at the end where mode1=mode2 and vice versa), with shifted sectors. So it seems that D8 reading mode has problems with these discs, and it also results in bad subchannels.

I also tried subdump after swapping with an audio disc, but the issues remain. The only conclusion I can reach so far is that subdump and the recommended parameters used by rawdump are not safe for archiving these discs and the resulting output is incorrect. Also, Rawdump claims that "SecuROM Has 10 errors in Q-channel + 1 Q-channel error in the last sector of pregap", but the old version (also on FIFA 99) apparently has 24 errors.

Questions:
- Do the t2final.sub errors occur in the same range as documented in DIC? So should the latest DIC and /se parameter dump these errors correctly always?

/se     Not fix SubQ (RMSF, AMSF, CRC) (RMSFs 01:06:50 - 04:02:74)
                                            or (RMSFs 08:55:50 - 09:38:74)
                        For intentional subchannel error of a SecuRom

- Can you check the 24 sectors in the t2final.sub to confirm that they are all intentional errors (with XOR 0x0080 or 0x8001)?
- Did you also check the Track01 pregap of your discs for intentional errors?

Since this protection is so similar to LibCrypt, I think it might be a good idea to preserve these modified bytes on the dump page. But first we need to do more tests and come up with a foolproof method for dumping these sectors.
If it turns out that there is no reliable dumping method, or if sectors from the pregap are also needed, then I guess Daemon Tools' SecuROM emulation remains the only solution for us.

Tomorrow I will post the results of another disc ( http://redump.org/disc/41170/ )

F1ReB4LL wrote:

I've thought "psxt001z.exe --fix" should never be used?

Correct, but it shouldn't make a difference for these 3 dumps (single track + EDC)

89

(2 replies, posted in Guests & account requests)

AKuHAK wrote:

Hi all.

I have collected some bioses (dumped with ps2idetn) from PlayStation 2 that missed in redump database.
So I have SCPH-39008 with dvd rom 2.16R, SCPH-50002 with dvd rom 3.00A, SCPH-79010, SCPH-90008 (v2.30) and DESR-5700 bootrom and dvdrom dumps.
Im collecting info about ps2 so if redump guys have ps2ident reports i can exchange it for my dumps.

Best regards,
AKuHAK

Hi,

we don't have any PS2Ident reports, because most dumps were made before that tool existed. I do corresponded with SP193 every now and then to synchronize our databases and track down any corrupt dumps.

If those dumps that you have originate from your own, unmodified consoles, then we can add them. Otherwise we have no way to verify that the dumps are really correct. Modchips are known to corrupt the BIOS.
SCPH-39008 is not in the PS2Ident database yet. If this is your console, then please dump it with modchip disabled and send info/dumps to SP193.
SCPH-50002 also not in PS2Ident database, but if it doesn't match one of the versions in our datfile, it's probably corrupt. 3.00A DVD ROM also sounds fishy, because 3.00A = Asian and SCPH-50002 = European.
SCPH-79010 BIOS is probably corrupt (the one in the PS2Ident DB has comment "Console is modded").
SCPH-90008 BIOS should match "ps2-0230e-20080220", but the one in PS2Ident DB doesn't, so probably also corrupted.
DESR-5700 also isn't listed in the PS2Ident DB. If you have this model, then please submit your info/dumps to SP193.

Could you write down the ranges and sector count like you did before but after the fixes?

And you should always have /RC switch enabled for DIC when dumping error sectors! so that the user data gets the 0x55 pattern like CDM/CloneCD does. If you forgot this in previous dumps then plz fix them.

I will post my results later this week or early next week, when my copy arrives.

edit: Added my dump.. You should redump your disc with CDM/CloneCD because IsoBuster replaces error sectors with non-error sectors.

sarami wrote:
Jackal wrote:

CodeLock and LaserLock are similar in that you try to get as many readable sectors as possible with one or more non-plextor drives until you get consistent results. CodeLock patterns can vary: http://redump.org/discs/quicksearch/cod … tion/only/

Ripping the CodeLock by plextor with 0xd8, the strange string can be seen.

beware the jabberwock my son the jaws that bite the claws that snatch

CDManipulator and CloneCD recognize the sector including this string as error sector.
Game: Rune http://redump.org/disc/31708/
hex editor of sector 2327 http://www.imagebam.com/image/0b922f533425871
Left is ripped by plextor PX-W5224A with 0xd8, right is ripped by TSSTcorp DVD-ROM TS-H353A.
Do you think this CDM/CloneCD (right) images are correct? If you so, what is the reason?

I don't know which dump is 'correct', but if I had to choose between 2 dumps with different error count, I would pick the one with the least amount of errors.. Especially if only 1 brand (Plextor) gives different results for whatever reason and most other drives give consistent results.

TheRetroPirate wrote:

Why is that?

Anyway I made a small python script to compare my 5 dumps of track 1 so far.
And there are indeed 12 ranges with bad sectors.

Bad blocks found:  732
Bad range:  1 :  (2137, 2194) :  57
Bad range:  2 :  (2509, 2571) :  62
Bad range:  3 :  (2810, 2871) :  61
Bad range:  4 :  (3187, 3244) :  57
Bad range:  5 :  (3559, 3621) :  62
Bad range:  6 :  (3936, 3993) :  57
Bad range:  7 :  (4308, 4370) :  62
Bad range:  8 :  (4687, 4745) :  58
Bad range:  9 :  (4984, 5046) :  62
Bad range:  10 :  (5360, 5422) :  62
Bad range:  11 :  (5735, 5797) :  62
Bad range:  12 :  (6261, 6319) :  58

The error count seems to be 1 more for each range than what you calculated?
If 2137 is the first error and 2194 the last, then the total errors in that range is 58.

And please check with your Plextor drive if the start of each error range is the same everywhere as those combined results? It's possible that one of the non-Plextor drives starts 1 sector earlier on some ranges. I don't know why this happens, but I've seen this happen on some drives (my Plextor drives and the Optiarc one always give the same start sector for each range).
As for the end sectors, you can't say for sure if the current results are final, unless you do a manual check. It's possible that some sectors are readable but only after multiple retries. It's really tricky.
It would probably be a good idea if I purchase this game as well, so that we can verify these results. Is this the disc that you're trying to dump? http://ogdb.eu/imageview.php?image_id=1 … mp;limit=0 (with the same ringcode?)
Or maybe you have one of the other LaserLock titles that is already dumped, and you could try to verify it. Then we'll know for sure that your method is reliable.

edit: I just bought Outcast, so we should be able to compare results by the end of the week.

TheRetroPirate wrote:

So basically read the data track as many times as possible with different drives and do a sector compare?
I could use a python script to compare the single sectors, the sectors which never match must be the bad ones.

It won't work unless you browse back manually after each error range.

CodeLock and LaserLock are similar in that you try to get as many readable sectors as possible with one or more non-plextor drives until you get consistent results. CodeLock patterns can vary: http://redump.org/discs/quicksearch/cod … tion/only/
LaserLock usually has around 12 unreadable areas of 78-82 errors. See the comments for some examples: http://redump.org/discs/quicksearch/las … tion/only/
For such discs I use CDTool to browse back manually from the end of each error area and recover as many readable sectors as possible (going back and forth between sectors and rereading sectors multiple times until the drive is able to read them) and inject them into the non-plextor CDM/clonecd data track dump image with a hex editor. For LaserLock discs this means several hours of manual work for each disc and you would need a drive with a powerful laser to grab all readable sectors (Sony Optiarc 7280 gives me the best results, but surely other Optiarc and other brands could work fine too.. it's a process of trial and error).

You cant dump such discs reliably with DIC.. I'll write some instructions later

96

(7 replies, posted in News)

Last November 17, the server HDD failed and our hoster apparently provided zero effort in recovering any data. Daily backups were still on the same HDD, so the last backup that was in possession of the admins was from November 3.
After some weeks of radio silence, our admin iR0b0t finally informed us of the situation. It then took him another 2 months to finally bring back the site again on February 5. It still remains unclear why it took him so long to bring back the site, but what matters now is that the site is back up and that steps have been taken to prevent this from happening again: We are on a better server now with RAID1 and daily backups. On behalf of iR0b0t, Jesus, God, Satan, the Deutsche Post and everybody else involved in this calamity, we wish to apologize for the sudden downtime and thank you for your patience.

We want to ensure you guys that redump.org is here to stay. It's now been 10 years since we started our journey (nostalgia trip) and a lot has happened in those 10 years: Many people have come and gone and a lot of new systems and information have been added over the years. Many thousands of hours have been put into creating a database with information on many thousands of video game-related optical discs. Cataloging and preserving this history seemed like an impossible task when whe initially started out, and even though the project always remained somewhat small and obscure, we can still conclude that a lot of things have been accomplished in those 10 years and that many of the games that we love and cherish are now preserved in our database. Many systems can now be considered "reference sets" and have regions now that are probably over 95% complete, including PlayStation, PlayStation 2, Gamecube (Europe and USA) and Xbox (Europe). The (Japan) region continues to catch up, thanks to a small group of dedicated dumpers who continue to add new dumps each week. Then there's also IBM PC, our largest and most convoluted system, which also continues to have a steady stream of rare and not-so-rare discs added to the db each week.

A huge thanks goes out to all the people who contributed to our database over the past 10 years, and we look forward all the new contributions from new and existing members in the years to come.

Can you check the error count with cdmage and look for a copy protection (by scanning the game exe with protection ID)?

Offset is not an issue when DIC is used

98

(3 replies, posted in General discussion)

http://forum.redump.org/topic/2468/offs … d-command/

This will give you the combined offset, so you'll have to subtract the read offset

Yeah, about time that you get a plextor like everyone else

If one of the 2 images has fewer cdmage errors then the one with more errors must be wrong

It's not PC Gamer.. a lot of PC Gamer discs are already in the db.

"CD Gamer Issue 65: January 1999"

or what iR0b0t said