76

(6 replies, posted in General discussion)

Maybe this could be an option for server fees, but this is for iR0b0t to decide, because he's the one paying for the server fees atm. Purchasing games for dumping seems like a legal grey area though, because you use donations to add hashes and info to a database, but somehow these dumps also end up on people's HDD's. MAME has been doing succesful fundraisers though for purchasing and dumping rare games, but privately and not via Patreon.

Another thing is that dumping rare games doesn't have to be a loss-making enterprise. I have dumped plenty of rare games and either sold them on (also with profit) or used my legal right to return the games for a refund. I think most of the remaining dumpers have either found ways to get and dump games as cheap as possible, or they really buy the games for their own collection. Donation money should only be used for buying games and selling them again after dumping, and not to fund private collections.

And the final argument is that, even if we got $1000 per month for dumping Saturn games or whatever, we would need trustworthy dumpers with a proven track record and with a lot of spare time who are able to deliver these dumps in a certain timeframe. Most active dumpers just don't have the time to do a lot of dumps each week.

77

(1,229 replies, posted in General discussion)

sarami wrote:

Uploaded 20170507 https://github.com/saramibreak/DiscImag … r/releases
- added: /np /nq option
- changed: Option name /g -> /nr, /l -> /nl, /se -> /ns
- changed: Some log message
- changed: Disabled SSE2 of vcxproj (for old cpu)
- changed: MaximumTransferLength is limited to 64KB (can't read 128KB)
- improved: Checking argument (check command-length)
- improved: Subchannel ripping of SecuROM
- fixed: Reading DirectoryRecord
- fixed: Output unnecessary hash

http://forum.redump.org/post/54643/#p54643
I'll try slowly. I installed Visual Studio 2017 and VirtualBox, Vagrant (box with bento/ubuntu-16.04) in host PC, and installed gdb and gdbserver, g++ in guest PC.

cool thanks for all your hard work.. I don't know where we would be without DIC

78

(4 replies, posted in Guests & account requests)

A short introduction would be nice. What are you hoping to contribute?

Hi,

just wait a bit longer please. I guess ir0b0t didn't have time yet to read your post (he's the only one approving accounts atm)

80

(57 replies, posted in General discussion)

ssjkakaroto wrote:
Jackal wrote:

Re-Volt already had the correct data. The latest change only affected some discs. All those discs are fixed now:

Re-Volt only had the correct data because I sent you the sub file from cdtool or have you forgotten? DIC wasn't able to create the intention file for it, now it can.

Ok, I thought you redumped it specifically because of 20170423 test version.

81

(57 replies, posted in General discussion)

ssjkakaroto wrote:

Tried again with the new version. Here's the intention file output: https://pastebin.com/6L0DfLeK

Re-Volt already had the correct data. The latest change only affected some discs. All those discs are fixed now:

http://redump.org/disc/31596/
http://redump.org/disc/12832/
http://redump.org/disc/31587/
http://redump.org/disc/2086/
http://redump.org/disc/41903/
http://redump.org/disc/21540/
http://redump.org/disc/2025/
http://redump.org/disc/39955/
http://redump.org/disc/38865/
http://redump.org/disc/20125/

82

(57 replies, posted in General discussion)

Hi, could you post fixed SecuROM data for Colin 2 plz.

83

(57 replies, posted in General discussion)

ssjkakaroto wrote:

Subintention file was still blank with the test version using the following command line: DiscImageCreator cd k Re-Volt 4 /d8 /c2 /ns /s 2

dunno what /ns does, but for SecuROM you need /se

84

(1,229 replies, posted in General discussion)

Hi,

is it possible to make DiscImageCreator Wine-compatible, or even make a native Linux binary? I don't know how much of the code is Windows-specific.

Not for me, but on some other forums people mentioned that they couldn't get it to work with Wine, so just wondering.

85

(57 replies, posted in General discussion)

@sarami,

the latest version is unable to detect the sectors for these discs (subIntention.txt = empty):

http://redump.org/disc/19786/
http://redump.org/disc/20713/

All PSX ITA have the same capitalization.

87

(1 replies, posted in News)

Just to clear up some confusion, Redump.org is and always will be a public preservation project that is open to new contributors.

New accounts can be requested here: http://forum.redump.org/forum/13/guests … -requests/

For dumping CD's (with DiscImageCreator), the main hurdle is the need for a genuine Plextor drive. Over the years, we have been able to accomodate new dumpers by offering them locally bought Plextor/Plexwriter drives at affordable prices (around 20-30 EUR including shipping). We are still offering these services, so if you are a prospective dumper aiming to make a lot of contributions, but in need of an affordable Plextor drive, feel free to contact us.

Other media types and systems such as XBOX (360), GC/Wii, DC, PS3 each have their own set of tools and equipment that are needed for dumping. Instructions for these systems can be found in the stickied topics in the General discussion forum: http://forum.redump.org/forum/7/general-discussion/

Undumped lists for various systems (not always complete or up-to-date) can be found in our Wiki: http://wiki.redump.org/index.php?title= … yet_dumped

88

(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?

89

(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?

90

(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?

91

(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

92

(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?

93

(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?

94

(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

95

(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/

96

(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..

97

(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.

98

(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?

99

(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)