(6 replies, posted in General discussion)

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.


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


(100 replies, posted in General discussion)

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


(1,956 replies, posted in General discussion)



(100 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,956 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,956 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,956 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.


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


(1,956 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?


(100 replies, posted in General discussion)

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.


(100 replies, posted in General discussion)

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.


(100 replies, posted in General discussion)

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.


(100 replies, posted in General discussion)

Oops yeah, so IsoBuster seems to use:

(cuesheet for session 1)
(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.


(100 replies, posted in General discussion)

This is how we've been dealing with multisession discs so far:


So what's wrong with using the IsoBuster "standard"? it contains all the relevant information for a functional image? It seems overkill to define lead-out etc, when all other dumps have them excluded.

Did a first test on Kreon drive today with CloneCD. It would skip through the first couple error sectors, but would stop reading and start making noises as soon as it reached the first ring. So a different drive or custom tools would be needed to dump this data. Will try some other drives later with disc swap.

user7 wrote:

>Preservation enthusiasts will do the needed dumps sooner or later, but there should be a proper software for that.


Not everyone wants to waste time and cash for pointless, unverifiable sectors.

There are yellow Xbox 360 dumps that nobody cares to fix, and many Xbox NTSC discs that nobody wants to buy - http://wiki.redump.org/index.php?title= … sing_Dumps (because the PAL discs are already dumped). So, don't expect anyone to to buy and redump 4.000 discs, even if it's confirmed that the missing data can be dumped/verified.

"the data is not useful" - agreed
"its not fully retrievable" - yes, if you're talking about the physical rings that are unreadable, but we don't know yet how many sectors can't be retrieved because of this.
"and the result will be no dumps verify" - tests need to be done in order to confirm this

F1ReB4LL started a discussion on discord about Xbox / Xbox 360 dumping.

Our current dumping method skips through the full range of every security sector range and fills this data with zeroes.
For Xbox1 discs, it's 16 x 4096 sectors and for Xbox 360 it's 2 x 4096? with each sector being 2048 bytes.

The argument is that this is not in line with the "redump dumping method" and that all data within the main reading area of the disc should be preserved.

Arguments against the current method:
- Fails to preserve all the (readable) data that is located in the security sector ranges.

Arguments in favor of the current method:
- It might be difficult or impossible to dump the missing data. Reading through the physical rings could take a lot of time, and different drives and/or discs could give different results (with some drives being able to read more sectors at the start and end of each ring than others), meaning it could be difficult to verify a dump that is done this way.
- The Xbox console itself blocks out access to the full range of every security sector. Dumping a game on an actual console (using dvd2xbox) results in the drive giving read errors in the the same sectors that are currently skipped on the PC dumping method.
- The data inside the security sector ranges seems to be random garbage that has no meaning or purpose.

I'm aiming to do some tests soon to see how long it would take to do a full dump using different drives and if the results are different between different drives. I only have 1 Xbox1 disc here ATM and it seems to have 5 physical rings, whereas the Xbox 360 discs that I have all seem to have 2 rings (one close to the center and one near the outer edge of the disc). It remains to be seen if all Xbox1 discs have 5 physical rings.

Hope sarami can have a look at this, but for the ring sections you'll need something other than a plextor / DIC.

Please supply the full ringcode.

@user7 it was speculation, they can be removed from the wiki when dumped


(5 replies, posted in Fixes & additions)

Is http://redump.org/disc/2434/ actually a Demo and Multi5 language? Because the DL-DOL-DVJP-NOE did have that.

The No-Intro rules aren't suited for Chinese releases.. games can have really weird box titles that are completely different from the (often English) ingame title.