Search options (Page 2 of 32)

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

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

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.

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

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

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.

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.

@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?

Positive write offset or combined offset?

@sarami any theory on why the offset might be shifted with 1 sample?

Nexy is gone so I guess we either need a Plextor dump from the new dumper or someone else to confirm (the disc is on ebay)

I'm not a coder, but it seems like you are trying to combine sectors from cache reads based on the assumption that they are all data sectors with correct sync/header? How will it handle audio sectors or mastering errors safely?

So the logic before the 2020-11-01 version was to look at P-channel when Q-channel wasn't available? I agree with F1ReB4LL that it's best to stick with this logic, unless there is such a thing as a P-Q offset

I don't understand the new fix. With the new fix, the Quake track04 pregap would become 02:00? This seems wrong, when the other tracks are all 01:74.

Very strange difference. Same ringcode, 2 different dumps:

http://redump.org/disc/25734/ - logs from 2017: http://www.mediafire.com/file/ce4b73luc … fo.7z/file and 2019: http://www.mediafire.com/file/qonu94lfb … se.7z/file (.cue not included but matches db)

http://redump.org/disc/73543/ - new logs: http://www.mediafire.com/file/pkf96uk40 … en.7z/file + http://www.mediafire.com/file/1nw1uf9iy … ck.7z/file (slower speed and /s 2)