DiscImageCreator

[scsi_wuzzy]

Could you test again and upload all log of Ultraplex.

Process completed this time, and the hashes seem to match the PX716AL. Very cool. Reading is much slower than in the last version. My guess is this is due to the additional read commands used for subcode reading (which weren't being run before, since the buffer was 0 < MINIMUM_DRIVE_BUF_SIZE).

I've uploaded the logs. Disc is same as before (US version of Saturn game Nights into Dreams). https://www.sendspace.com/file/encme9

I've got some other SCSI drives I'll try to get tested eventually (Some old Nakamichi, Toshiba, other Plextor models, Yamaha, etc) and report results.

[sarami]

The disc that failed when I tested it yesterday was a single track disc (US version of Ace Combat 3). However, I tried on a multi trakc disc (Japan version of Ace Combat 1), and the px_d8 works.

I'll update the document until next release.

Reading is much slower than in the last version. My guess is this is due to the additional read commands used for subcode reading (which weren't being run before, since the buffer was 0 < MINIMUM_DRIVE_BUF_SIZE).

- fixed: MINIMUM_DRIVE_BUF_SIZE is from 256 to 512.

I've got some other SCSI drives I'll try to get tested eventually (Some old Nakamichi, Toshiba, other Plextor models, Yamaha, etc) and report results.

Thank you in advance.

[scsi_wuzzy]

fixed: MINIMUM_DRIVE_BUF_SIZE is from 256 to 512.

Reading is much faster again, but the PX-40TS now fails with

Code: Select all

[L:1500] Internal error. Failed to analyze the subchannel. Track[13]/[21]

Disc is again "Nights into Dreams". Logs:

https://www.sendspace.com/file/5rfqs3

I've verified this failure is related to changing MINIMUM_DRIVE_BUF_SIZE. Changing it back to 256 gets rid of the error (though it is again slow).

[sarami]

- fixed: IsValidSubQTrack()

[scsi_wuzzy]

Looks like it's working. Reads are quite fast, and process completed. Logs:

https://www.sendspace.com/file/5h0vgy

I noticed the /c2 option wasn't working, though, since bC2ErrorData == FALSE. Setting it to true seems to make it work (No C2 errors reported on a clean disc, and many reported on a scratched disc). I ripped the Nights disc with a modified copy using /c2. Here are the logs from that, if you want to see them:

https://www.sendspace.com/file/txd2a9

Thanks for the updates. I started doing tests on an old Nakamichi. It works with px_d8, but not when reading subcodes. I've posted a question elsewhere on the forum to hopefully determine exactly how px_d8 does subcode reading, so maybe I can troubleshoot it. I've not tested it with DIC yet.

[sarami]

I noticed the /c2 option wasn't working, though, since bC2ErrorData == FALSE.

Thanks. Uploaded.

Code: Select all

LBA[201301, 0x31255], Audio, 2ch, Copy NG, Pre-emphasis No, Track[19], Idx[01], RMSF[01:26:00], AMSF[44:46:01], RtoW[0, 0, 0, 0]
LBA[201302, 0x31256], Audio, 2ch, Copy NG, Pre-emphasis No, MediaCatalogNumber [0000000000000], AMSF[     :02], RtoW[0, 0, 0, 0]
LBA[201303, 0x31257], Audio, 2ch, Copy NG, Pre-emphasis No, Track[19], Idx[01], RMSF[00:03:00], AMSF[44:46:03], RtoW[0, 0, 0, 0]
LBA[201304, 0x31258], Audio, 2ch, Copy NG, Pre-emphasis No, Track[19], Idx[01], RMSF[00:03:01], AMSF[44:46:04], RtoW[0, 0, 0, 0]
 :
 :

There is incorrect RMSF. Probably fixed.

I started doing tests on an old Nakamichi.

If you can, could you test other old plextor scsi drive too

It works with px_d8, but not when reading subcodes. I've posted a question elsewhere on the forum to hopefully determine exactly how px_d8 does subcode reading, so maybe I can troubleshoot it.

/viewtopic.php?t=1252 … d-command/
px_d8 is created by Truong Hi and Dremora. Dremora github: https://github.com/Dremora
But px_d8 code didn't exist in this github...

[Jackal]

It works with px_d8, but not when reading subcodes. I've posted a question elsewhere on the forum to hopefully determine exactly how px_d8 does subcode reading, so maybe I can troubleshoot it.

/viewtopic.php?t=1252 … d-command/
px_d8 is created by Truong Hi and Dremora. Dremora github: https://github.com/Dremora
But px_d8 code didn't exist in this github...

Here are source codes:
https://www.mediafire.com/?gww1d86dcnkldng
https://www.mediafire.com/?yubde72u3b3xz5e

[scsi_wuzzy]

Here are source codes:
https://www.mediafire.com/?gww1d86dcnkldng
https://www.mediafire.com/?yubde72u3b3xz5e

Thanks! That's very useful. Looks like it just reads the subcodes using a 0xd8 read with different parameters in the CDB. Interesting that old Nakamichi doesn't support those parameters. I'll have to see if it supports any of the other ways to read subcode.

If you can, could you test other old plextor scsi drive too

I did some preliminary tests with the PX-W1210S. This drive has some weird quirks too, just like the 40TS. For some reason it returns 0 for SCSI.wCurrentMedia. I added code to set the media type to ProfileCdrom to bypass that issue. The other issue is that the call to ReadBufferCapacity results in a drive reset, causing subsequent drive operations to error due to drive not ready. I solved this by bypassing the ReadBufferCapacity call and hard-coding the buffer size (4096 KB, according to Plextools).

After these changes, the drive read my Nights disc without issue, with hashes that match the 716AL.

I haven't had a chance to test your latest version on the 40TS. Hopefully I can do that later in the week.

[sarami]

I did some preliminary tests with the PX-W1210S. This drive has some weird quirks too, just like the 40TS. For some reason it returns 0 for SCSI.wCurrentMedia. I added code to set the media type to ProfileCdrom to bypass that issue. The other issue is that the call to ReadBufferCapacity results in a drive reset, causing subsequent drive operations to error due to drive not ready. I solved this by bypassing the ReadBufferCapacity call and hard-coding the buffer size (4096 KB, according to Plextools).

Uploaded. Could you test and upload log.

[scsi_wuzzy]

Uploaded. Could you test and upload log.

My apologies, but I wasn't clear before about the ReadBufferCapacity() problem on the 1210S. For some reason, the 1210S resets itself if a SCSIOP_READ_BUFFER_CAPACITY is issued to it. When it resets itself, it is unresponsive for some seconds and the following SCSI commands fail with either "UNIT_ATTENTION - POWER ON, RESET, OR BUS DEVICE RESET OCCURRED" or "LUN NOT READY - BECOMING READY". So I think the work-around for this drive requires not issuing SCSIOP_READ_BUFFER_CAPACITY at all. As a quick hack, I simply modified exec():

Code: Select all

if (devData.byPlxtrType != PLXTR_DRIVE_TYPE::PXW1210S) { ReadBufferCapacity(&devData); }

Though it would probably make more sense for such code to be in the ReadBufferCapacity() call or somewhere else besides exec().

Log from 1210S: https://www.sendspace.com/file/wvxsro

Log from Ultraplex: https://www.sendspace.com/file/zfwbap

The Ultraplex got a couple C2 errors, but it threw an error when trying to re-read. Well, two errors actually. One because of the failure to set speed (which we already knew about), and then a second error when trying to actually read. I'll have to double check, but I think the 716AL also fails on re-read with the same error. I included the stdout in the 7z archive with the Ultraplex logs, because I'm not sure if that error is visible in the logs.

Oh, and here's the stdout when I run the latest test release on the 1210S:

Code: Select all

C:\Users\User\Downloads\Test_ANSI>DiscImageCreator.exe cd h nights1210 0
OS
        Windows 7 Professional Service Pack 1 32bit
AppVersion
        x86, AnsiBuild, Mar 16 2015 19:57:32
CurrentDir
        C:\Users\User\Downloads\Test_ANSI
InputPath
         path: nights1210
        drive:
          dir:
        fname: nights1210
          ext:
Start: 2015-03-16(Mon) 19:48:54
[F:ReadBufferCapacity][L:600] GetLastError: 1117, The request could not be perfo
rmed because of an I/O device error.

[F:SetCDSpeed][L:705] OperationCode: 0xbb
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 06-29-00, UNIT_ATTENTION - POWER ON, RESET, OR BUS DEVIC
E RESET OCCURRED
[F:ReadDiscInformation][L:538] OperationCode: 0x51
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 02-04-01, NOT_READY - LUN_NOT_READY - BECOMING_READY
[F:ReadTOC][L:137] OperationCode: 0x43
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 02-04-01, NOT_READY - LUN_NOT_READY - BECOMING_READY
End: 2015-03-16(Mon) 19:48:59

Edit: Just double checked and the 716AL fails on re-read as well:

Code: Select all

Reread times    1, ErrSectorNum  229/ 229[F:ProcessReadCD][L:167] OperationCode:
 0x36
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-20-00, ILLEGAL_REQUEST - INVALID COMMAND OPERATION CO
DE