I'm just using CloneCD for now and reading the stuff that's in the TOC.

But Maddog informed me that there's additional hidden data. Some info found on google:

There's data between the two sessions, in the lead-in of session2 actually. Without this data the disc reboot at the "legal stuff" screen. If you look at the cdi image and search for "SEGAKATANA" (beginning of ip.bin very first block of session2, LBA45000) you'll see that there's some data right before it. By inputting this data into the session2 pregap of a cdi image of the disc, and burning it with a compatible drive (that won't assume pregap is full of zeros), you can make the BC! backup boot up to the "insert disc" screen. However once a game disc (gt2/mgs/tekken) is inserted it won't boot it.

There's an hidden session passed the TOC of the disc with only one file named "bleem" in it, consisting of "bleem<NL>" (<NL> is linefeed or carraige return I don't remember). Burning this session with a swap trick, as I tried, doesn't make the game boot the psx disc. As this session is not in Patriot's release we can assume he cracked the code that checks for it.

But protection data between 2 sessions sounds pretty farfetched, maybe it's actually data between rings in the 2nd session, which previous dumps were missing because it wasn't dumped properly.

Plextors indeed seem unable to read the TOC. The Optiarc is reading them fine though:


Only tested the PX-760A so far. If all my Plextors refuse to read them, I'll use an audio trap disc for the first session.
I'm not expecting any problems dumping these discs, it's prolly gonna take a while though to read through all the rings wink And we'll also need to finish our multisession 'standard'.

What about the cuesheet? Can someone check the logs?

Try dumping it at a lower speed with /sf parameter

sarami wrote:

Also fixed.

Fixed where? And what about the wrong track01 size? wink

It's this disc btw: http://redump.org/disc/39048/

The DIC Track01 .bin isn't divisible by 2352, so I guess there's still a bug somewhere.

FILE "dump (Track 1).bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
FILE "dump (Track 2).bin" BINARY
    INDEX 00 00:00:00
    INDEX 01 23:07:05
FILE "dump (Track 3).bin" BINARY
    INDEX 00 00:00:00
    INDEX 01 00:01:74
REM LEAD-OUT 01:30:00
FILE "dump (Track 4).bin" BINARY
    INDEX 00 00:00:00
    INDEX 01 00:01:74

The LEAD-OUT seems to be in the wrong place also?


(1,866 replies, posted in General discussion)

I agree that the hashing is really slow and takes a lot of time, but are we sure it's caused by the display of the progress?

ghost wrote:

ok thanks. And what am I supposed to do with this?
can i fix anything?

you could use it to fix an "empty"/generated .sub file so that it includes the LibCrypt/SecuROM data, either by manually adding the modified (red colored) bytes in the .sub with a hex editor, or by downloading the .sbi and using a tool like sbi2sub.

SBI files are used to store the modified sectors in Q-subchannels (the ones that are shown on the disc page). They are indeed part of the LibCrypt / SecuROM copy protection, but they are separate from the main channel data, so you can't use it to fix anything.
There are some tools that can convert .cue/.bin/.sbi to .ccd/.img/.sub to create working backups. It won't work for newer SecuROM versions because those also rely on "Data position measurement".


(4 replies, posted in Fixes & additions)

Duke 3D fixed. I installed Diablo today from that dump and it really gave me 1.08. Maybe the patch is downloaded during install?


(4 replies, posted in Fixes & additions)

The version is 1.00
contents: english manual

Hi, I double checked and this one is really 1.08. Maybe you linked the wrong disc?

AID_X wrote:

Hello guys! A Murder of Crows posted new dump, but I think is a bad dumped old

data track is same, audio track have 4 byte offset, and not have any diffrents (like a bad dump).
What you think about?

Neither of the dumps are bad. The ringcodes are different, so they are different discs with different mastering.

There are many similar cases, e.g. http://redump.org/disc/20769/ + http://redump.org/disc/61865/

Tbh any dump that goes 1 sector per second can't be good


(1,866 replies, posted in General discussion)


I'd like to know if the TOC/subchannels of multisession discs (and/or rainbow books) really have a "RUN-OUT", "LEAD-OUT" and "LEAD-IN" marked between sessions. If they do, then I wonder why IsoBuster omitted the LEAD-IN.


(1,866 replies, posted in General discussion)

Ok I fixed Magic Carpet according to these specifications (scrambled sector 79916). But is there an easy way (without redumping) to check similar dumps for any descrambled sectors that should have remained scrambled?

Some of the dumps that need to be checked:
Chasm - The Rift (Europe) (Sold Out Software)
Cyberwar (USA) (Disc 1)
Cyberwar (USA) (Disc 2)
Cyberwar (USA) (Disc 3)
MER Innebandy (Sweden)
PowerHouse (Europe) (En,Fr,De,Es)
Push-Over (Europe) (En,Fr,De,Es) (Hit Squad - Regenerator)
SimCity 2000 (Germany)
Steel Panthers (Germany)
Trolls (Europe) (1995)

More on this list, but it's outdated: http://forum.redump.org/topic/16655/ibm … to-redump/

I guess we can find most of them this way:

Also, maybe a stupid question, but can we be sure that the offset of this dump is correct? http://redump.org/disc/19878/
Logs attached. The previous (old) dump of this disc was submitted with +0 offset and different Track02 pregap (and the old audio is off by 285 samples compared to the new dump). Most likely it was a dumping error, but there were some cases where different reading modes would give different offsets (588 samples difference with some SecuROM discs), so can we be sure that there is no drive/firmware bug here?


(1,866 replies, posted in General discussion)

F1ReB4LL wrote:
Jackal wrote:

If I remember correctly, we agreed before that all sectors inside a data track with a valid sync should always be descrambled?

Shouldn't all 16 bytes be correct for descrambling? What's the point in descrambling the sector with non-existant "E1" and "C1" modes?

It's a data sector inside a data track, why not descramble? The sync is valid so the sector is assumed to be intact.

I'm fine with discussing and maybe coming to a new method, but then we also have to fix old dumps that were processed differently.


(1,866 replies, posted in General discussion)

KailoKyra dumped this disc: http://redump.org/disc/3927/ but it wasn't matching the database, because DIC is not descrambling any of the last 3 sectors.

Attached the 3 last data sectors for this disc and the DIC log:

If I remember correctly, we agreed before that all sectors inside a data track with a valid sync should always be descrambled? But still DIC is not descrambling the first 2 sectors. The third and last sector has an invalid sync and shouldn't be descrambled.


(11 replies, posted in General discussion)

A Murder of Crows wrote:
iR0b0t wrote:

10. Total CRC-32

I cannot do a database dump of it, Total CRC-32 is not stored within the database, its generated on the fly each time you review a disc page.

hmm. this presents a problem. We're working on trying to build a scraper for this but had really hoped grabbing the CRC-32 would have been far easier for the verification process.

If this is for a personal list of sorts then you're better off making one manually in Excel (I've been doing the same to keep track of my IBM PC collection). There would be no benefit in automating anything, you only have to update the list when a new dump is added to the db.


(1,866 replies, posted in General discussion)

Olo dumped a disc at 8x speed, but the SecuROM data was messed up:

Data from DIC dump:
MSF: 01:08:58 Q-Data: 610101 01:06:59 00 01:08:59 b0a7

correct (unmodified) data:
MSF: 01:08:58 Q-Data: 610101 05:06:58 00 21:08:58 b0a7

And this one was not detected for some reason at 8x, but at 4x it is:
MSF: 01:08:52 Q-Data: 610101 01:06:53 00 01:08:53 6d32

Is it normal that higher speed can cause so many errors? Any way to optimize this?

Having trouble understanding your post and the need for having a REM LEAD-IN.
The REM LEAD-OUT is part of a standard and can be used to define a gap between the splitted track files in order for mounted/burned images to get the correct sector addressing.
What does adding REM LEAD-IN do to improve on this?
Once the standard is broken, we might as well abandon REM LEAD-OUT and REM RUN-OUT and use 'REM GAP' or something instead?

sarami wrote:
where ss.bin is a raw dump (2064 bytes) of data @PSN 0xFD21E

We may get the ss.bin by xbox raw dumping without kreon drive... I'll try it.

Yeah I guess we never tried that before.. Can PSN 0xFD021E be approached as a sector number?

Requiring manual input of ss ranges is silly, it should allow input from ss_sector_range txt or from ss.bin directly.

https://github.com/libyal/libodraw/blob … t.asciidoc
Looking there and also at other example cuesheets, IsoBuster seems to use only REM LEAD-OUT and REM RUN-OUT. With separate files for each track it would look like this:

FILE "Track 01.bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
FILE "Track 02.bin" BINARY
  TRACK 02 MODE2/2352
    INDEX 01 00:00:00
FILE "Track 03.bin" BINARY
    INDEX 00 00:00:00
    INDEX 01 00:01:74
FILE "Track 04.bin" BINARY
    INDEX 00 00:00:00
    INDEX 01 00:01:74

The run-out data is considered not to be stored in the file specified by the FILE command if the FILE command was specified after the REM SESSION command.

I'd say go with the IsoBuster standard. If it has REM LEAD-IN [MSF] and REM LEAD-OUT [MSF] then fine. Adding custom stuff isn't going to help us in any way.