DiscImageCreator

[Nexy]

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

It's been free for personal use for some time now ?

[sarami]

It's been free for personal use for some time now ?

Free version is limited.

Up to 32 commands can be captured
Only the first 8 bytes of each data transfer are captured
Runs only on 32-bt Windows, XP and later

I'm working ASUS on Win10 64bit.

could you check the log for this disc ?

Also try to use subdump.

subdump added.

LBA 91152 is the start address of track 14 on TOC.

Code: Select all

      Data Track 14, LBA    91152 -    93436, Length     2285

But It's the end of address of track 13 on sub.

Code: Select all

LBA[091151, 0x1640f]: P[3f], Q[411301040808002017264de6]{ Data,      Copy NG,                  Track[13], Idx[01], RMSF[04:08:08], AMSF[20:17:26]}, RtoW[0, 0, 0, 0]
LBA[091152, 0x16410]: P[3f], Q[41130104080900201727f796]{ Data,      Copy NG,                  Track[13], Idx[01], RMSF[04:08:09], AMSF[20:17:27]}, RtoW[0, 0, 0, 0]
LBA[091153, 0x16411]: P[00], Q[41140100000100201728797b]{ Data,      Copy NG,                  Track[14], Idx[01], RMSF[00:00:01], AMSF[20:17:28]}, RtoW[0, 0, 0, 0]

It looks like real sub indexes. F1ReB4LL judges it.

re-ripping with my ASUS drive with /be also yielded the correct result.

No need to use /be except plextor.

[nitro322]

re-ripping with my ASUS drive with /be also yielded the correct result.

No need to use /be except plextor.

I don't think I follow.  Without /be on the ASUS, it produces a different file than that ripped by Plextor.  Clearly the same disc producing different output depending on the drive used to rip it is not desired.

[sarami]

To get scrambled sector(s), plextors use 0xd8 while other drives use 0xbe with cdda flag.
If /be is used, 0xbe with all flag is set forcibly. As the result, it can't get scrambled sector(s).
In other words, it can't get correct combined offsets.

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.

If you want to dump mixed mode disc on ASUS, do not use /be.

[Nexy]

I use it on Windows 7 64 bit Enterprise without an issue, and no, it's not an illegal version.

[nitro322]

To get scrambled sector(s), plextors use 0xd8 while other drives use 0xbe with cdda flag.
If /be is used, 0xbe with all flag is set forcibly. As the result, it can't get scrambled sector(s).
In other words, it can't get correct combined offsets.

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.

If you want to dump mixed mode disc on ASUS, do not use /be.

That makes sense.  Thanks for clarifying.

One last question, if you don't mind - for single track discs, would you recommend always setting /be with ASUS drives?  My concern is with discs like that Wing Commander Prophecy example, where I wouldn't know there's a problem unless there's already another good dump that doesn't match.

[sarami]

My concern is with discs like that Wing Commander Prophecy

Is it this disc? https://redump.info/disc/12961/
If yes, as I said, large ofs disc is not supported yet on Asus.
If no, upload logs, please.

[nitro322]

Is it this disc? https://redump.info/disc/12961/
If yes, as I said, large ofs disc is not supported yet on Asus.
If no, upload logs, please.

Yes, that's the disc.  Offset issue noted.  What's odd about that case is that it did get a correct (correct as in matching the plextor, at least) dump with /be, even despite the large offset.

[sarami]

Because data sector can be dumped without offsets using 0xbe opcode. It's normal method. Almost all CD dumping tools (Isobuster, CloneCD etc.) use 0xbe.

[Agent47]

Hi sarami. I ran into some issues dumping a multisession pc disc today with the latest github release where it would timeout around the end of the first session and DIC would just hang.

I used the latest test build you posted in this thread and the dump completed with some errors. I was hoping you could check the logs and let me know if the dump is ok.

The disc in question is the US version of https://redump.info/disc/56890/.

Logs: https://mega.nz/#!HvRjRAzI!g7wn70ZdO0VE … bSJDcT9nb8

If you need any more info let me know. Thanks.