No harm in using REM PREGAP then? it's clear that any REM elements are not included in the dump.
126 2019-05-25 08:41:09
Re: [DONE] Discussing the multisession cue (144 replies, posted in General discussion)
127 2019-05-25 06:43:31
Re: [DONE] Discussing the multisession cue (144 replies, posted in General discussion)
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.
128 2019-05-24 14:26:14
Re: How to dump Bleem! Dreamcast discs? (12 replies, posted in General discussion)
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.
129 2019-05-22 18:25:50
Re: How to dump Bleem! Dreamcast discs? (12 replies, posted in General discussion)
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.
130 2019-05-22 17:22:46
Re: How to dump Bleem! Dreamcast discs? (12 replies, posted in General discussion)
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 And we'll also need to finish our multisession 'standard'.
131 2019-05-20 17:59:19
Re: DICGUI question : sub-indexes, safedisc, ... (1 replies, posted in General discussion)
Try dumping it at a lower speed with /sf parameter
132 2019-05-18 07:08:08
Re: [DONE] Discussing the multisession cue (144 replies, posted in General discussion)
Also fixed.
Fixed where? And what about the wrong track01 size?
133 2019-05-17 12:19:16
Re: [DONE] Discussing the multisession cue (144 replies, posted in General discussion)
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 2019-05-12 19:28:29
Re: DiscImageCreator (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 2019-05-12 11:16:54
Re: Hey guys 2 simple questions (6 replies, posted in General discussion)
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 2019-05-12 09:12:54
Re: Hey guys 2 simple questions (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".
137 2019-05-05 15:48:51
Re: [DONE] Discussing the multisession cue (144 replies, posted in General discussion)
Tbh any dump that goes 1 sector per second can't be good
138 2019-05-02 17:09:18
Re: DiscImageCreator (3,493 replies, posted in General discussion)
139 2019-05-02 05:53:30
Re: [DONE] Discussing the multisession cue (144 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.
140 2019-04-26 09:42:10
Re: DiscImageCreator (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 2019-04-25 20:26:47
Re: DiscImageCreator (3,493 replies, posted in General discussion)
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 2019-04-25 18:52:55
Re: DiscImageCreator (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 2019-04-24 05:28:39
Re: [DONE] Database Dump Request (17 replies, posted in General discussion)
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 2019-04-23 18:21:36
Re: DiscImageCreator (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?
145 2019-04-14 20:18:21
Re: [DONE] Discussing the multisession cue (144 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?
146 2019-04-14 09:24:18
Re: Dumping Xbox / Xbox 360 security sector ranges (28 replies, posted in General discussion)
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?
147 2019-04-13 13:35:30
Re: Dumping Xbox / Xbox 360 security sector ranges (28 replies, posted in General discussion)
Requiring manual input of ss ranges is silly, it should allow input from ss_sector_range txt or from ss.bin directly.
148 2019-04-12 09:36:22
Re: [DONE] Discussing the multisession cue (144 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:
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.
149 2019-04-12 06:29:56
Re: [DONE] Discussing the multisession cue (144 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.
150 2019-04-11 05:29:50
Re: [DONE] Discussing the multisession cue (144 replies, posted in General discussion)
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.