No harm in using REM PREGAP then? it's clear that any REM elements are not included in the dump.

Yeah the dump itself seems to be fine now, but there's still 1 problem with the cuesheet: http://redump.org/disc/39048/

Session 1: 0-92629
Session 2: 104030-332133

The cuesheet has:

REM SESSION 01
FILE "dump (Track 1).bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
REM LEAD-OUT 01:30:00
REM SESSION 02
REM LEAD-IN 01:00:00
FILE "dump (Track 2).bin" BINARY
  TRACK 02 MODE2/2352
    INDEX 01 00:00:00
FILE "dump (Track 3).bin" BINARY
  TRACK 03 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:01:74
FILE "dump (Track 4).bin" BINARY
  TRACK 04 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:01:74

The area between the 2 sessions is 92630 - 104029 = 11400 sectors = 02:32:00, so the Track 2 pregap of 2 seconds is still unaccounted for in the cuesheet. How to define it, since it's not included in the dump? PREGAP 02:00 / REM PREGAP 02:00?


@xTMODx do you have this disc also still? http://redump.org/disc/40793/

Or does anyone else have some more discs to test? Just to confirm that there's no weird stuff going on.

The layout seems to be identical for all 3 discs:
0-301 - Session 1 (audio track, all zeroes)
302-11566 - Session 1 lead-out/ Session 2 lead-in? (all readable sectors are zeroes)
11567-11701 - Pregap? (mixed data/audio)
11702-77006 - Session 2 (data track with unreadable rings / error sectors)

So the google source was right, there is some data between the 2 sessions. This data is included separately for now.
It probably needs to be added to the image to get a working backup. Besides inserting the data at offset 710304 of the .img and 28992 of the .sub, this also means that the .ccd needs to be hacked/modified in some way. Hopefully someone (sarami?) knows how to do this.

ps. It would be nice also if someone could test the normal/unmodified dumps on a real console to see what happens.

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:

https://i.imgur.com/ZPNi0aw.png

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

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.

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

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

134

(3,493 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?

135

(6 replies, posted in General discussion)

ghost wrote:

ok thanks. And what am I supposed to do with this?
https://postimg.cc/cK6Dtycv
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.

136

(6 replies, posted in General discussion)

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

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

138

(3,493 replies, posted in General discussion)

http://forum.redump.org/post/69584/#p69584

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.

140

(3,493 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:
http://redump.org/discs/errors/2/system/pc/
http://redump.org/discs/errors/3/system/pc/
http://redump.org/discs/errors/4/system/pc/
http://redump.org/discs/errors/5/system/pc/
http://redump.org/discs/errors/6/system/pc/
http://redump.org/discs/errors/7/system/pc/
http://redump.org/discs/errors/8/system/pc/
http://redump.org/discs/errors/9/system/pc/
http://redump.org/discs/errors/10/system/pc/
http://redump.org/discs/errors/12/system/pc/

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?

141

(3,493 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.

142

(3,493 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.

143

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

144

(3,493 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:

REM SESSION 01
FILE "Track 01.bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
REM RUN-OUT [MSF]
REM LEAD-OUT [MSF]
REM SESSION 02
FILE "Track 02.bin" BINARY
  TRACK 02 MODE2/2352
    INDEX 01 00:00:00
FILE "Track 03.bin" BINARY
  TRACK 03 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:01:74
FILE "Track 04.bin" BINARY
  TRACK 04 AUDIO
    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.

Oops yeah, so IsoBuster seems to use:

REM SESSION 01
(cuesheet for session 1)
REM LEAD-OUT [MSF]
REM SESSION 02
(cuesheet for session 2)

Would this be sufficient for our purposes? I would leave out the REM LEAD-IN because it's not part of the IsoBuster standard and the only purpose anyway is to bridge the gap, which is what LEAD-OUT does also.