I guess we need to do more research.. maybe the SafeDisc scrambled data is also meaningful.. but I always assumed that there could be no good/reliable data hidden behind a C2 error.

sarami wrote:

Logs. https://www.mediafire.com/file/js0a6rkd … 29.7z/file
C2 errors: 1445. vs your dump http://redump.org/disc/31708/ is 722

Yeah but 1 of the 2 sectors is always just 22-23 bits.. do C2 errors take into account offset correction?

For intentional C2 errors like here we always fill with 0x55 pattern.

sarami wrote:

I reported this protection before. http://forum.redump.org/post/54050/#p54050
0xd8 dumping can get the string that is recorded in the disc. But redump db adopts the result of the 0xbe dumping less error count.

Are there C2 errors when dumping this protection?
And what's the explanation for the lower error count? Is the drive correcting bytes in 1 sector when using 0xbe?

The best route might be to find a CodeLock game that's already dumped on eBay US and see if you can verify that. The drive that can verify another dump should also produce a correct dump of the US Tropico. If the error count is the same as your current dump (and twice that of the Europe release) then it could be explained by different mastering.

http://redump.org/discs/quicksearch/cod … ction/only

Surely there's some cheap ones on medimops.de also if you search for the barcodes there (without spaces), but I don't know if they're shipping again to the US (they restricted it because of COVID).

5

(3,100 replies, posted in General discussion)

@sarami any way to get BCA data from gamecube discs with a PC drive?

Silasqwerty wrote:

This entry should have a note made that it contains the main executable that itself contains SafeDisc 3.20.020, but that this disc itself isn't protected by SafeDisc. http://redump.org/disc/64358/

Can you explain this? So is it SafeDisc protected or not? Or does it use a different executable than the "main" one?

7

(3,100 replies, posted in General discussion)

Thx.. same bug perhaps? https://drive.google.com/file/d/1pM0Kmb … 6CCAd/view
http://redump.org/disc/73323/

8

(3,100 replies, posted in General discussion)

Here's 3 logs with bad multisession cuesheets. Is this a bug that is already fixed or a new one?

https://www109.zippyshare.com/v/qX1iHqXW/file.html
https://www109.zippyshare.com/v/j0cYXyUz/file.html
https://www109.zippyshare.com/v/WqOmxrW7/file.html

And this CD-i dump seems to dump correctly with non-plextor and IsoBuster, but messes up with DIC + Plextor:
https://www29.zippyshare.com/v/iP7DufIh/file.html

9

(3,100 replies, posted in General discussion)

sarami wrote:
Jackal wrote:

No, not replaced with 0x55 but they can be "cleaned" somehow. I think the sectors match surrounding sectors except for the random error bytes which need to be cleaned so that they match (besides header). Perhaps it can be accomplished by rereading sectors and keeping the bytes that are most consistent between reads.

Ok, but who guarantees the kept bytes is correct?

If the sectors after "cleaning" the random errors all have data that matches the data in the previous or next sector, it's pretty safe.

10

(3,100 replies, posted in General discussion)

sarami wrote:
rosewood wrote:

Is there anything that be done about this problem or did I miss the solution?

The problem may be that there is not EDC in LBA 16. Perhaps it can read using 0xbe, not 0xa8. I don't fix it yet.

Neon Beast wrote:

The installed game will have these two files

There are some cab and hdr files in the disc. If they are Microsoft cabinet files, you need to use /mscf to detect DiscGuard.
The protection of 7K2 was detected as DiscGuard.

Detected a protected file [IOSLINK.VXD]. LBA 302 to 330
Jackal wrote:

I think there were some sectors without EDC where the random errors needed to be cleaned manually.

According to the 3 logs of Neon Beast, LBA 299 to 1498 do not have EDC. These should be replaced to 0x55 like SafeDisc?

No, not replaced with 0x55 but they can be "cleaned" somehow. I think the sectors match surrounding sectors except for the random error bytes which need to be cleaned so that they match (besides header). Perhaps it can be accomplished by rereading sectors and keeping the bytes that are most consistent between reads.

11

(3,100 replies, posted in General discussion)

Neon Beast wrote:

Hi, I have this Chinese release of Heroes of Might and Magic III, I got two copies with identical ring codes, but hashes don't match, and I can't get a consistent dump. It has DiscGuard protection, don't know if this is causing the problem.
Dumped with the latest test build.
Logs: https://mega.nz/folder/XzB3SYyL#0g-CNMwckW9kQgmEFv-iRQ

DiscGuard needs a special treatment. I think there were some sectors without EDC where the random errors needed to be cleaned manually. Maybe reentrant remembers.

http://redump.org/discs/quicksearch/dis … tion/only/

Neon Beast wrote:

I tried on this one, but IsoBuster still not working.

You need to open the .cue directly with IsoBuster. The screenshots shows an Alcohol drive as source and not the cuesheet.

Can you post a screenshot?

MrPepka wrote:

Oh, for the sake of clarity, those malfunctioning drives are the ones below:
http://redump.org/disc/69762/
http://redump.org/disc/69693/

Again, both dumps are fine. No errors and everything reads fine.

REM SESSION 01
FILE "Wszystko Gra - Gazeta Uczy i Bawi - Kwiecien 2002 (Poland) (Track 1).bin" BINARY
  TRACK 01 AUDIO
    INDEX 01 00:00:00
FILE "Wszystko Gra - Gazeta Uczy i Bawi - Kwiecien 2002 (Poland) (Track 2).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Wszystko Gra - Gazeta Uczy i Bawi - Kwiecien 2002 (Poland) (Track 3).bin" BINARY
  TRACK 03 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
REM SESSION 02
FILE "Wszystko Gra - Gazeta Uczy i Bawi - Kwiecien 2002 (Poland) (Track 4).bin" BINARY
  TRACK 04 MODE2/2352
    PREGAP 02:32:00
    INDEX 01 00:00:00
REM SESSION 01
FILE "FrogMan + Tajemnicza Wyspa (Poland) (Track 1).bin" BINARY
  TRACK 01 AUDIO
    INDEX 01 00:00:00
REM SESSION 02
FILE "FrogMan + Tajemnicza Wyspa (Poland) (Track 2).bin" BINARY
  TRACK 02 MODE2/2352
    PREGAP 02:32:00
    INDEX 01 00:00:00

Neon Beast wrote:

Hi, I have some multisession CDs that have data track in session 2, I can mount cuesheets with Alcohol but not the ccd file, and I can't get access to session 2, also IsoBuster fails to identify them as multisession CDs. I tried your method with no luck, am I doing it wrong? Here are some of un-modified cuesheets

You need to download the cuesheets from redump. The ones that are generated by the dumping tool aren't compatible. And then add the PREGAP 02:32:00 line like above.

MrPepka wrote:

I checked the CD Maniak Wydanie Specjalne 2/2008 and there, adding a PREGAP line to the cue file does nothing, IsoBuster still doesn't detect files on this CD (except for the fairy tale on the audio track).

There are no problems here:

REM SESSION 01
FILE "CD Maniak Wydanie Specjalne 2-2008 (Poland) (Track 1).bin" BINARY
  TRACK 01 AUDIO
    INDEX 01 00:00:00
REM SESSION 02
FILE "CD Maniak Wydanie Specjalne 2-2008 (Poland) (Track 2).bin" BINARY
  TRACK 02 MODE2/2352
    PREGAP 02:32:00
    INDEX 01 00:00:00

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

I checked a CD from Gazeta Wyborcza (the one with the Speedway Championship game, for example)

You'll have to be more specific and provide a link to the disc.

The dumps themselves should all be fine and there's no sign of any corruption.

Someone pointed out in Discord that the multisession cuesheets for IBM PC aren't functional. It's true that virtual drive software like Daemon Tools doesn't support multisession cue's, but IsoBuster also fails to parse the filesystem correctly when loading the .cue.

The problem is that IsoBuster assumes that SESSION 02 starts the sector after SESSION 01 ends, but in fact there's 11400 sectors in between the sessions that aren't included in the image.

So to fill this void we would need to add this line to the cuesheet: PREGAP 02:32:00

Mounts with Daemon Tools without error (but no multisession). Opens in IsoBuster and parses filesystem correctly:

REM SESSION 01
FILE "Bajki na CD 5-2008 (Poland) (Track 1).bin" BINARY
  TRACK 01 AUDIO
    INDEX 01 00:00:00
REM SESSION 02
FILE "Bajki na CD 5-2008 (Poland) (Track 2).bin" BINARY
  TRACK 02 MODE2/2352
    PREGAP 02:32:00
    INDEX 01 00:00:00

Default redump .cue: Mounts with Daemon tools and opens with IsoBuster, but the disc size is 11400 sectors too short and IsoBuster is unable to show the correct filesystem for session 2, because it's missing the area between the 2 sessions:

REM SESSION 01
FILE "Bajki na CD 5-2008 (Poland) (Track 1).bin" BINARY
  TRACK 01 AUDIO
    INDEX 01 00:00:00
REM SESSION 02
FILE "Bajki na CD 5-2008 (Poland) (Track 2).bin" BINARY
  TRACK 02 MODE2/2352
    INDEX 01 00:00:00

IMO iR0b0t should add the PREGAP 02:32:00 line for generated multisession CD cuesheets, so that we at least can access the session 2 filesystem with the correct start address and have the correct disc length.

17

(2 replies, posted in Verifications)

It should be 06, not 60.

It's not a Brazilian disc.. or did you submit a verification with different ringcode that isn't processed yet?

This is Europe / UK region despite having ESRB rating and USA barcode. There's several copies on ebay UK with an ELSPA sticker and UK addressed registration card.

20

(3,100 replies, posted in General discussion)

sarami wrote:
Jackal wrote:

Can the shifted offset be explained by ASUS drive or a Linux bug?

I have no idea about it. Which sector is shifted?

The audio data is shifted 1 sample (4 bytes) between the 2 dumps.

21

(3,100 replies, posted in General discussion)

@sarami could you have a look at this plz: http://forum.redump.org/post/93954/#p93954

Can the shifted offset be explained by ASUS drive or a Linux bug?

22

(3,100 replies, posted in General discussion)

sarami wrote:
NovaAurora wrote:

Same # of errors reported, same hashes.

These errors are all lead-in sectors of the 2nd session. DIC does not support generating ecc/edc yet when unreadable sectors are generated.

The problem is that EccEdc is checking the .img image and is reporting errors on the area that isn't included in the splitted .bin dump.
EccEdc should always scan only the .bin data tracks and nothing else.
We also get discs where it reports 225 errors but this is actually 3 seconds scrambled data inside the audio Track02.

And you get bogus "errors" like this inside audio tracks:
LBA[019483, 0x04c1b], audio
LBA[019484, 0x04c1c], MSF[00:00:00], zero sync
LBA[019485, 0x04c1d], audio

23

(11 replies, posted in News)

Jackal wrote:
RibShark wrote:

Was that confirmed to be a drive issue? As far as I knew, the last word from that from Sarami was that it was a different master. Additionally, who is to say that the Plextor is correct vs the non-Plextor in that case.

It was this disc I think: http://redump.org/disc/65563/
The ringcodes seem to be identical. As soon as DopefishJustin received his/her Plextor drive, we will know if the Plextor dump matches the db dump or if it's a different disc and it matches the ASUS one.

Turns out the ASUS dump was correct. There were still some issues left related to the last sectors. @reentrant have those been fixed now?

24

(11 replies, posted in News)

RibShark wrote:

Was that confirmed to be a drive issue? As far as I knew, the last word from that from Sarami was that it was a different master. Additionally, who is to say that the Plextor is correct vs the non-Plextor in that case.

It was this disc I think: http://redump.org/disc/65563/
The ringcodes seem to be identical. As soon as DopefishJustin received his/her Plextor drive, we will know if the Plextor dump matches the db dump or if it's a different disc and it matches the ASUS one.

25

(11 replies, posted in News)

RibShark wrote:

The issue is not with the scrambled reading but with the cache trick used to read the lead-out on positive combined offset discs. Any discs with offsets below -6 should be fine even with audio tracks.

We've also seen dumps recently where audio tracks had a shifted offset compared to Plextor dumps, so we shouldn't downplay these issues and take a firm stand. The bottom line is that non-Plextor dumping is experimental and there is always the risk of new problems arising due to different disc or drive factors (besides the main channel offset).