redump.info Forum

RibShark wrote:0xF1 can support multiple sector overreads:
"F1 06 00 00 00 00 00 00 0b 00" = last read sector
"F1 06 00 00 0b 00 00 00 0b 00" = last read sector + 1
"F1 06 00 00 16 00 00 00 0b 00" = last read sector + 2
and so on.

Then, how about the last read sector + 3, + 4, + 5 ...?
I tried "F1 06 00 00 21 00 00 00 0b 00", but it couldn't get the last read sector + 3.

+1764 is enough for 99.9% of discs if more won't work, there's only a few discs in db with larger offset.

I have read 30+ sectors into the lead out with 0xF1, not sure why you can't unless the lead out on your disc doesn't contain many sectors.

RibShark wrote:I have read 30+ sectors into the lead out with 0xF1, not sure why you can't unless the lead out on your disc doesn't contain many sectors.

30 would be +17640 ?
What insane discs are you dumping?

RibShark wrote:I have read 30+ sectors into the lead out with 0xF1, not sure why you can't unless the lead out on your disc doesn't contain many sectors.

Would you upload your code that can read 30+ sectors and upload the 30+ sectors?

He told me he didn't have code, and that he just edited the command in the buffer with bushound.

Also latest version will crash if the drive tray is open.

sarami, could you check the log for this disc ?
/viewtopic.php?t=21995 … rihen-jpn/

- with desync so tracks with sub indexes created
- track 14 is reported as Audio when, I think, it must be mode 2 like all the other tracks (a movie .dat file points to the track 14 LBA)

Madroms wrote:could you check the log for this disc ?

Also try to use subdump.

Nexy wrote:he just edited the command in the buffer with bushound.

Could he really get the scrambled sector data by the method? I can't use bushound readily because it's really expensive.

Hi, sarami.  There's been some discussion in one of the discord channels this morning about an apparent bug in DiscImageCreator, at least as far as support for the ASUS BW-16D1HT goes.  The quick background is that we noticed a discrepancy between how my ASUS drive rips disc 1 of Wing Commander: Prophecy and previous dumps with Plextor drives.  Ripping my own disc with a Plextor yielded the same results as the other Plextors, and re-ripping with my ASUS drive with /be also yielded the correct result.  So at RoyBatty's request I started using /be as a default option.

Today, I noticed that using that option results in mismatches in ripped audio tracks.  As a specific example, when ripping this Quake II disc:
https://redump.info/disc/43204/

if I omit /be, all ripped tracks match the redump entry.  If I include /be, the data track matches, but all audio tracks have different checksums.  I've observed this on two other discs as well.

For your reference, here are the logs and stdout from two rips, the first without /be, the second with:
https://www.legroom.net/public/q2-c2-4000-0-s-2.txz
https://www.legroom.net/public/q2.txt
https://www.legroom.net/public/q2-c2-4000-0-be-s-2.txz
https://www.legroom.net/public/q2-be.txt

Please let me know if you need any additional details.

sarami wrote:

Madroms wrote:could you check the log for this disc ?

Also try to use subdump.

subdump added.