1 Topic by ajshell1

(1 replies, posted in General discussion)

Stop me if you've had this problem before: You want to use a rom manager to manage your personal dumps of CDs with CD audio tracks. But alas, those audio tracks also appear on more than one disc, and they get built into incomplete zip files of dumps you don't own and don't care about, cluttering up your rom folder.

The worst example of this is with Dreamcast discs, where my single Japanese dump also happens to contain a file present in over 300 other dumps: http://redump.org/discs/quicksearch/1859ea65/

Or, some of your dumps get renamed, and now your cuefiles are broken. You could just stick the complete cuefile zip into your ToSort folder in RomVault, but then you'll have to get rid of all the zip files that only contain cues.

It's just a mess in every sense.

So I decided to make a tool to fix it. I call it "datslim": https://gist.github.com/ajshell1/a6b390 … 90d8f1e5aa

(this currently only works on Linux. If you think you can get it to work on Windows, go ahead and try)

Here's how to use it:

1. On the Redump home page, click on "User", and then select "My <System you want> discs".

2. Get that list of discs into a file named "have". This is probably easiest by right-clicking on the page and doing "Save as".

3. Download the .dat file for that corresponding system, and place it in the same folder as "have".

4. Run datslim like this: 

datslim "name of the datfile.dat"

5. Wait. This might take a while depending on how many dumps you have and how many dumps are in the system.

6. When it is done, you will have a new file named "new_<name of the previous datfile>."

Documentation on how it works is in the file itself.


Known bugs:

1. No warnings or indication of use or misuse.

2. Many things are done rather sloppily. This is just a quick-and-dirty hackjob I came up with late last night. If you have any ideas on how to improve things, let me know.

3: It's slow.  I don't know exactly what big O notation this script is using, but it's not a good one. I'm sure there's a better way to do this, but I thought I'd share it as it currently exists.

4. I'm 100% sure it's going to throw a fit with some a special character at some point. It's not an "if", it's a "when". I just haven't found it yet.

5. No Windows port. I don't use Windows, so someone else is going to have to do it. I'll release this script under whatever license you want if you want to make a Windows version.

Go to forum: General discussion

2 Topic by ajshell1

(1 replies, posted in General discussion)

Recently, I got shipped a big stack of 32 French OXM discs to get repaired at my local video rental store.
19 (likely 22 once i get the remaining 3 fixed) match normal European or (Europe, Australia) OXM discs.
7 discs match nothing, so I'll be submitting them soon.
3 however, are somewhat troublesome.

They match the following dumps:

http://redump.org/disc/61036/

http://redump.org/disc/54791/
http://redump.org/disc/16630/

As you can tell, one of these is listed as Australian, while the other two are listed as German.

The Australian one says internally that it is "OXM Euro 24 EU". Or at least that's what UnleashX calls it when I start it.
But the French menu calls it #23.

For the  04/2004 German disc, UnleashX calls it "OXM Euro 27 OZ&EURO", while the French menu calls it #26


As for the 09/2003 German Disc, UnleashX calls it "OXM Euro 20", while the French menu calls it #19

I'm not sure what the proper names for these discs would be given this info.

The German discs are especially troublesome, given that other OXM discs exists in the DB with very similar demo lists: http://redump.org/disc/20666/ and http://redump.org/disc/20659/

Since we don't have a France/Germany region, I think we'd be forced to make those two (Europe) region. Thus, we'd need a way to differentiate between the existing Euro dumps and these new Euro dumps.

Also, one of the new dumps has "Hors-Serie Solutions Numero 08" on the label, but UnleashX calls it "OXM FR Special 10". It has IM00119E as a DMI string. I don't know what to call this one.

Also, keep in mind that all of these were sent to me as loose discs, so I don't know for sure what issue they were released with.

The other six dumps are:

IM02102E
IM02307E
IM04103E
IM04202E
IM04503E
IM04803E

Given the two existing French OXm discs, I think these correspond to:

Le Magazine Officiel Xbox: Le DVD Numéro 20
Le Magazine Officiel Xbox: Le DVD Numéro 22 (confirmed in menu)
Le Magazine Officiel Xbox: Le DVD Numéro 40
Le Magazine Officiel Xbox: Le DVD Numéro 41
Le Magazine Officiel Xbox: Le DVD Numéro 44
Le Magazine Officiel Xbox: Le DVD Numéro 47

Please let me know what you think.

Go to forum: General discussion

3 Topic by ajshell1

(2 replies, posted in General discussion)

So, I just dumped a copy of Carnival Games: Monkey See Monkey Do.

The checksum just so happens to match http://redump.org/disc/23435/.

So, what do I do now? The games have different titles in different regions, despite the disc being identical.

Go to forum: General discussion

4 Reply by ajshell1

(3,516 replies, posted in General discussion)

sarami wrote:
ajshell1 wrote:

For some reason the SCM and the IMG are identical.

Latest test version supported the pregap data track.
http://www.mediafire.com/file/uw3e03kdk … ar.gz/file

========== TOC ==========
    Pregap Track   , LBA        0 -        0, Length        1
      Data Track  1, LBA        1 -   314439, Length   314439
========== FULL TOC ==========
    FirstCompleteSession: 1
     LastCompleteSession: 1
    Session 1, Ctl 4, Adr 1, Point 0xa0, FirstTrack  1, Format: CD-DA or CD-ROM
    Session 1, Ctl 4, Adr 1, Point 0xa1,  LastTrack  1
    Session 1, Ctl 4, Adr 1, Point 0xa2,      Lead-out, MSF 69:54:40 (LBA[314590, 0x4ccde])
    Session 1, Ctl 4, Adr 1, Point 0x01,      Track  1, MSF 00:02:01 (LBA[000151, 0x00097])

I see. So there is a sector in the pregap? Interesting. That also explains why using cdrdao to dump this disc produced a file missing that first sector. Interesting.

Go to forum: General discussion

5 Reply by ajshell1

(3,516 replies, posted in General discussion)

I found a weird bug with my copy of SWAT 2.

For some reason the SCM and the IMG are identical.

This hasn't happened with any other disc I own.

I'm including logs except for the eccedc.txt file, which just says something like:

"LBA[000000, 0000000], MSF[01:82:00], mode 1 User data vs. ecc/edc doesn't match"

for ALL the sectors on the disc.

EDIT: Based on the sector count and ringcodes, it should match or be similiar to http://redump.org/disc/51572/

EDIT2: I just found an old dump I made of the same disc, I can confirm that this disc matches the one I previously linked.

Go to forum: General discussion

6 Reply by ajshell1

(1 replies, posted in General discussion)

I vaguely remember Trurip containing extra info in the dat files. I don't see why we can't do the same.

Go to forum: General discussion

7 Reply by ajshell1

(3,516 replies, posted in General discussion)

Also, dumping a DVD results in the DAT being written to the DMI.bin

https://cdn.discordapp.com/attachments/ … nknown.png

Go to forum: General discussion

8 Reply by ajshell1

(3,516 replies, posted in General discussion)

I think I've found two bugs related to the Linux version of EccEdc.

Firstly, it won't work if you put parantheses in the name of the file you are dumping to (e.g. "FIFA 2003 (USA)" won't work, "FIFA 2003" will work).

Even without the parantheses, EccEdc still fails to do it's job properly. This is what happened after I removed parantheses:

Exec /home/aj/software/DIC_20190210/./EccEdc_linux.out check /home/aj/software/DIC_20190210/Atlantis - The Lost Empire - Trial by Fire.img
argc: 11
Usage
        check <InFileName>
                Validate user data of 2048 byte per sector
        fix <InOutFileName>
                Replace data of 2336 byte to '0x55' except header
        fix <InOutFileName> <startLBA> <endLBA>
                Replace data of 2336 byte to '0x55' except header from <startLBA> to <endLBA>
        write <OutFileName> <Minute> <Second> <Frame> <Mode> <CreateSectorNum>
                Create a 2352 byte per sector with sync, addr, mode, ecc, edc. (User data is all zero)
                Mode    1: mode 1, 2: mode 2 form 1, 3: mode 2 form 2

I'm currently running Antergos Linux.

EDIT: Apparently, it works fine when you don't include spaces in the filename

Go to forum: General discussion

9 Reply by ajshell1

(10 replies, posted in General discussion)

Jackal wrote:

Then there's also some moderators (including myself as of lately) who are mainly adding their own dumps and not bothering at all with forum submissions due to late of time. The WIP discs are also packed full. I guess tenyuhuang should be nominated as moderator also for adding all the Chinese stuff.

That also includes myself. I apologize for this. I also agree with Tenyu being added as a mod. And if you looked at the WIP queue, any sensible person would agree.

As far as Sadikyo goes, I'm not entirely sure (EDIT: At least, that was my thought when I started writing this post). I can definitely vouch for his loyalty. I'm just not sure if he has the experience to be a moderator. He only has 139 dumps, all of which are PS1,PS2,PS3,PSP,Saturn or DVD-Video. Granted, these all seem to be rather expensive or rare discs, which I'm appreciative of. However, there are going to be a lot of forum posts for systems other than these. Will he be able to handle discs from other systems without making mistakes?

As far as experience goes, having seen lots of discs DOES have tangible benefits in terms of moderation. For example, a while ago, Profes submitted this disc: http://redump.org/disc/59259/

The mastering code as he submitted it was "#113361   2414874 01"
Having seen discs with a similar ringcode (http://redump.org/disc/45563/ and http://redump.org/disc/21802/), I asked him if there was any tiny text in the form of a date. He looked again, and it turns out that such text was there.

Likewise, when a PC disc with a standard early-2000s Sonopress ringcode pattern gets submitted with the mould SID listed as "IFPI 1OC5", I can instantly tell that it's supposed to be "IFPI 10C5".

Granted those are problems encountered by a PC dumper and moderator. If Sadikyo exclusively goes after Sony systems, he'll have little trouble with their nice and consistent Sony DADC ringcodes. Just as long as he reads up on the patterns that exist in European releases as well before adding them.

However, if Sadikyo does go after all the console dumps in the forums, that'll make my job of adding PC forum dumps easier by making them easier to find. In that regard, I support him being added as a moderator.

But if he does get added as a moderator, I want some some of the moderators to give him lessons on how to be a moderator. I was given almost no instruction on how to actually do a lot of moderator stuff upon being promoted, and I had to ask people to actually figure stuff out.

EDIT: I also recall him complaining about the sorry state of the dump forum than anyone else has in the VGPC Discord, so I get the feeling he'll have the dedication to get through this.

Go to forum: General discussion

10 Reply by ajshell1

(3,516 replies, posted in General discussion)

iR0b0t wrote:

@ajshell1 : It's intentional. It still remains a data sector, which can be mode 0, 1 or 2. All within a data track.

I know. The point is that dumps with SecuROM are supposed to be listed with a single error. Currently, EdcEcc isn't displaying that error.

Go to forum: General discussion

11 Reply by ajshell1

(3,516 replies, posted in General discussion)

Hey sarami. I think I found a bug with EdcEcc. Perhaps "oversight" is a better word than "bug":

My copy of Monsters, Inc: Scare Island produces this when dumped with DIC in the EdcEcc.txt file:

LBA[233309, 0x38f5d], MSF[51:52:59], mode 2 form 1, SubHeader[1](IsInterleaved[00]), [2](ChannelNum[00]), [3](SubMode[00]), Form 1, [4](CodingInfo[00])
LBA[233310, 0x38f5e], MSF[51:52:60], mode 2 form 1, SubHeader[1](IsInterleaved[00]), [2](ChannelNum[00]), [3](SubMode[00]), Form 1, [4](CodingInfo[00])
LBA[233311, 0x38f5f], MSF[51:52:61], mode 2 form 1, SubHeader[1](IsInterleaved[00]), [2](ChannelNum[00]), [3](SubMode[00]), Form 1, [4](CodingInfo[00])
LBA[233312, 0x38f60], MSF[51:52:62], mode 1
LBA[233313, 0x38f61], MSF[51:52:63], mode 2 form 1, SubHeader[1](IsInterleaved[00]), [2](ChannelNum[00]), [3](SubMode[09]), Form 1, Data, End audio, [4](CodingInfo[00])
LBA[233314, 0x38f62], MSF[51:52:64], mode 2 form 1, SubHeader[1](IsInterleaved[00]), [2](ChannelNum[00]), [3](SubMode[00]), Form 1, [4](CodingInfo[00])
LBA[233315, 0x38f63], MSF[51:52:65], mode 2 form 1, SubHeader[1](IsInterleaved[00]), [2](ChannelNum[00]), [3](SubMode[00]), Form 1, [4](CodingInfo[00])
[NO ERROR] User data vs. ecc/edc match all

By way of comparison, here is my dump of Monsters, Inc. Scream Team Training:


LBA[257659, 0x3ee7b], MSF[57:17:34], mode 2 form 1, SubHeader[1](IsInterleaved[00]), [2](ChannelNum[00]), [3](SubMode[09]), Form 1, Data, End audio, [4](CodingInfo[00])
LBA[257660, 0x3ee7c], MSF[57:17:35], mode 1
LBA[257661, 0x3ee7d], MSF[57:17:36], mode 1
LBA[257662, 0x3ee7e], MSF[57:17:37], mode 1
[ERROR] Number of sector(s) where mode is invalid: 1
    Sector: 257659, 
Total errors: 1
Total warnings: 0

Basically, it doesn't notice the Mode 1 sector since Scare Island is normally Mode 2.

Go to forum: General discussion

12 Reply by ajshell1

(24 replies, posted in Guests & account requests)

I'd just like to say that I'm disappointed by your behavior, iR0b0t.

While I do think a modicum of paranoia is appropriate for someone in your position, I'm fairly certain that your paranoia is misdirected in this case.

Go to forum: Guests & account requests

13 Topic by ajshell1

(1 replies, posted in General discussion)

First of all, I want to make one thing perfectly clear:

I WANT "USA, Australia" TO BE ADDED AS A REGION ASAP.

To demonstrate why, let's look at all 18 PC games that are considered "World" dumps: http://redump.org/discs/region/W/system/pc

Now, I've been told elsewhere that "World", at least as No-Intro defined it, is "Japan, USA, Europe". Given the nature of PC stuff, I think "World" should mean "Asia, America(s), Europe".

Age of Mythology Disc 1 and 2: Originally dumped by Nexy as USA, then dumped by Mock. Should be "USA, Australia"

Baldur's Gate: The Original Saga Disc 1 and 2: Dumped by Pikmin as Australia, then dumped by Monocrom. "Australia, Korea" seems a bit specific, so maybe "Australia, Asia"?

Doom 3: Resurrection of Evil: "Regions dumped: USA, Europe, Korea". This is correct.

Grand Theft Auto IV (World) (En,Fr,De,Es,It) (Disc 2) was "USA, Europe", and was then dumped by Pietro, as Brazillian. It is my opinion that in this case, it should just stay "USA, Europe" with "Brazil" in the comments

Grandia II (Install Disc): It says in the comments field "USA + Australia".

Interstate '76 (Disc 1) (Install CD) was "Brazil", but then changed to "World". I don't exactly know what it should be. Jackal might know.

Quake 4 and Quake 4 (Bonus DVD): Was "Australia", then "Europe, Australia", and then "World". So I suspect this is "USA, Europe, Australia". I'd probably change this to "USA, Europe".

Quake II was "Brazil", then dumped by mock. So, "Brazil, Australia", which should probably be "USA, Australia" with "Dumped in Brazil" in the comments.

Red Faction (Disc 2) (Multiplayer Disc) is odd. 3 people have dumped it, and all of them had different disc 1s. Nexy dumped a US copy, Jackal dumped a Europe copy, and Doshin dumped a Australia copy. So, "USA, Europe"

SimAnt and SimLife were both dumped by Puff0rx as "Australia", then changed to world when I dumped an American copy.

SWAT 4 (Disc 2) is was originally Brazil, then dumped in Europe. I'd change this to "America, Europe" with "Brazillian copy" in the comments.

Unreal Tournament (Disc 2) (Extras) was "USA, Europe" until monocrom dumped it. In other words, it's using "World" correctly!

Xbox 360 Accessories 1.2 was added as "World". I don't know what to do with it.

Zork Nemesis: The Forbidden Lands (Disc 2) is undoubtably "USA, Australia". There are American and Australian versions of discs 1 and 3, but disc 2 is listed as "World"


I also own a copy of Marble Drop and Microsoft Flight Simulator 98 that matches Australian dumps. And I won't verify them until the "USA, Australia" region is added.

Go to forum: General discussion

14 Reply by ajshell1

(3,516 replies, posted in General discussion)

Fable: TLC is dumped correctly with this new update. Thank you.

Go to forum: General discussion

15 Reply by ajshell1

(3,516 replies, posted in General discussion)

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

https://cdn.discordapp.com/attachments/ … Disc_1.zip

https://cdn.discordapp.com/attachments/ … ia_USA.zip

Go to forum: General discussion

16 Reply by ajshell1

(3,516 replies, posted in General discussion)

I'd just like to point out that the most recent versions of DIC I tested (The stable one and test version 20181116 95206) still don't detect the SmartE protection on http://redump.org/disc/38957/.

I'm going to test and see if the dump DIC produces matches the DB version.  I doubt it will.

Edit: Nope. No it doesn't.

Also, there's this forom the EdcEcc.txt log:

LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060081, 0x0eab1], MSF[13:23:06], mode 1


EDIT2:

I'm getting a similar issue with what appears to be http://redump.org/disc/40523/. The PVD and file size is the same.

LBA[059462, 0x0e846], MSF[13:14:62], mode 1
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059473, 0x0e851], MSF[13:14:73], mode 1

EDIT3:
What seems to be http://redump.org/disc/29992/ but doesn't match has SmartE detected.

LBA[000988, 0x003dc], MSF[00:15:13], mode 1
LBA[000989, 0x003dd], MSF[00:15:14], mode 1 User data vs. ecc/edc doesn't match
LBA[000990, 0x003de], MSF[00:15:15], mode 1 User data vs. ecc/edc doesn't match
LBA[000991, 0x003df], MSF[00:15:16], mode 1 User data vs. ecc/edc doesn't match
LBA[000992, 0x003e0], MSF[00:15:17], mode 1 User data vs. ecc/edc doesn't match
LBA[000993, 0x003e1], MSF[00:15:18], mode 1 User data vs. ecc/edc doesn't match
LBA[000994, 0x003e2], MSF[00:15:19], mode 1 User data vs. ecc/edc doesn't match
LBA[000995, 0x003e3], MSF[00:15:20], mode 1 User data vs. ecc/edc doesn't match
LBA[000996, 0x003e4], MSF[00:15:21], mode 1 User data vs. ecc/edc doesn't match
LBA[000997, 0x003e5], MSF[00:15:22], mode 1 User data vs. ecc/edc doesn't match
LBA[000998, 0x003e6], MSF[00:15:23], mode 1 User data vs. ecc/edc doesn't match
LBA[000999, 0x003e7], MSF[00:15:24], mode 1


EDIT4: More details here: http://forum.redump.org/post/66206/#p66206

Go to forum: General discussion

17 Reply by ajshell1

(3,516 replies, posted in General discussion)

sarami, do you think you could get your CSS tool to be able to detect RCE protection? Currently that CSS tool outputs all DVD-Video information needed except for RCE protection info. It would be great if we could get DIC/CSS to detect it without the need to use DVDDecrypter.

Go to forum: General discussion

18 Reply by ajshell1

(7 replies, posted in General discussion)

iR0b0t wrote:

Right now its okay to not have it checked, but on the long term we should find a way to include it into the logs without having to run the dvd-decrypter.

I absolutely agree

Go to forum: General discussion

19 Topic by ajshell1

(0 replies, posted in General discussion)

It has recently come to my attention that some visual novels were released in the UMD-Video format rather than on the standard PSP-game format. Games like these are called "UMD-PG" (which stands for "Players Game"

An example of this would be Aki No Urara No Akaneiro Shoutengai
http://datomatic.no-intro.org/index.php … amp;n=0351

With this in mind, I think we should add the UMD-Video category.

Besides, we're datting CD-i VIdeo discs, so we might as well dat standard UMD-Video discs as well.

Once the system gets set up, I'd be willing to moderate the platform.

EDIT: This seems to be a rather complete list of UMD-PG games: https://vndb.org/r?q=umd-pg;fil=;s=released;o=d;p=1

Many thanks to rockleevk for bringing this format to my attention

Go to forum: General discussion

20 Reply by ajshell1

(7 replies, posted in General discussion)

Okay. Serious question for everyone:

Does anyone care if people don't specifiy if discs have RCE protection?

Because DICUI doesn't specifiy if it has it or not.

I'm convinced that it's rare enough that we probably won't every run into one, and that the only reason we've marked it in some discs is because DVD Decrypter included it in their scan

I'd love to hear the insight of other people

Go to forum: General discussion

21 Reply by ajshell1

(7 replies, posted in General discussion)

It seems as though I'm a mod now.

Thank you.

Go to forum: General discussion

22 Reply by ajshell1

(3 replies, posted in General discussion)

do_0m wrote:

Was there a third user in the nNASOS thread trying to implement their own version? I can't remember.


nNASOS is a thing.

https://cdn.discordapp.com/attachments/ … S_v1.8.zip

Go to forum: General discussion

23 Reply by ajshell1

(66 replies, posted in General discussion)

F1ReB4LL wrote:
Jackal wrote:

That's just a technicality. If you create 2 different sets of dump files with different .cue and filenames, and 2 archives for a single disc, this will be a bigger issue than what we have now.

A single set, a single archive, just 2 cues.

Like, Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA).LD.cue with the tracks 1 and 2 and Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA).HD.cue with the tracks 3, 4 and 5. You can mount the LD to some virtual drive and work with it exactly like you would work with a normal GD inserted into a PC drive. Emu devs may support either running the HD cue only or some kind of auto-mounting the LD cue additionally when the HD cue is selected.


So like this?

My concern is that "Track 3" is actually "Track 1" in the HD cue. That'll get confusing fast.

Go to forum: General discussion

24 Reply by ajshell1

(3,516 replies, posted in General discussion)

sarami wrote:

Uploaded, please test.
20181116 (Windows)
http://www.mediafire.com/file/eq80y20l9 … or_test.7z
20181116 (Linux)
http://www.mediafire.com/file/uw3e03kdk … x_test.tar

Test complete. The new dump with that test version of DIC produces a bin file with the exact same checksum as an older version of DIC, and it doesn't reread all those errors. Thank you very much.

Go to forum: General discussion

25 Reply by ajshell1

(3,516 replies, posted in General discussion)

I think I found an issue with SafeDisc Lite discs (or at least with an undumped copy of MS Train Simulator I got recently). DIC recognizes the protection when using the /sf flag, and all the errors that show up are 312 bit, but when the last sector is dumped, DIC decides to try and reread all the sectors that have intentional errors. And when it reaches the maximum number of retries for one of those errored sectors, DIC doesn't cancel the dump like normal, but then proceeds to reread the next intentionally errored sector the same way. When the last sector is done, it just descrambles the .scm like normal.

Go to forum: General discussion