scsi_wuzzy wrote:

It's a strange drive. Here's a brief discussion about it on the dbpoweramp forums, where a user mentions that it supports only 0xD8, and not 0xBE.

Uploaded test exe (with src)
- changed: from READ_CD(0xbe) to READ_D8(0xd8) or READ12(0xa8)
- fixed: buffer overrun

sarami wrote:

Uploaded test exe (with src)
- changed: from READ_CD(0xbe) to READ_D8(0xd8) or READ12(0xa8)
- fixed: buffer overrun

Thanks for the update. Unfortunately it looks like there are some other obstacles. I had to bypass "ReadDiscInformation" as the Ultraplex doesn't support those commands either.

After doing that, the code crashes after spinning up the drive. I've started looking at the code through the debugger, and it looks like the problem is around lines 234 to 244 of execScsiCmd.cpp:

                    if (!ScsiPassThroughDirect(pDevice, lpCmd, CDB12GENERIC_LENGTH, lpBuf,
                        CD_RAW_SECTOR_WITH_SUBCODE_SIZE, &byScsiStatus, _T(__FUNCTION__), __LINE__)
                        || byScsiStatus >= SCSISTAT_CHECK_CONDITION) {
                        throw FALSE;
                    }
                    LPBYTE lpBuf2 = lpBuf;
                    BYTE lpSubcode[CD_RAW_READ_SUBCODE_SIZE] = { 0 };
                    if (pDevice->byPlexType) {
                        lpBuf2 = lpBuf + pDisc->MAIN.nCombinedOffset;
                        AlignRowSubcode(lpBuf2 + CD_RAW_SECTOR_SIZE - pDisc->MAIN.nCombinedOffset, lpSubcode);
                    }
                    else {
                        AlignRowSubcode(lpBuf2 + CD_RAW_SECTOR_SIZE, lpSubcode);
                    }
//                    OutputCDMain2352(lpBuf2, nLBA);
//                    OutputCDSub96Align(lpSubcode, nLBA);
                    if (nLBA == aLBA[bySession]) {
                        BYTE byCtl = (BYTE)((lpSubcode[12] >> 4) & 0x0f);
                        byMode = GetMode(lpBuf2, byCtl);
                    }

The call to ScsiPassThroughDirect seems to only read 2448 bytes into lpbuf (if I'm understanding the ioctl call correctly -- DataTransferLength is only 2448. But then lpbuf2 is lpbuf + combined offset, and combined offset on this disc is 9160 bytes. lpbuf2 then goes past the end of the lpbuf array.

I'll continue playing with it to see if I can get anything going.

I think there are some other issues at play, but that's one I thought should be noted.

scsi_wuzzy wrote:

Unfortunately it looks like there are some other obstacles. I had to bypass "ReadDiscInformation" as the Ultraplex doesn't support those commands either.

- fixed: alway return TRUE

scsi_wuzzy wrote:

The call to ScsiPassThroughDirect seems to only read 2448 bytes into lpbuf (if I'm understanding the ioctl call correctly -- DataTransferLength is only 2448. But then lpbuf2 is lpbuf + combined offset, and combined offset on this disc is 9160 bytes. lpbuf2 then goes past the end of the lpbuf array.

sorry, fixed. Could you test again.

Thanks for the update. Strange problem now, which I've not been able to find the root of.

The full MSF of the full TOC gotten from the Ultraplex seems to be wrong. The LBA addresses seem to match those the PX-716AL gets though.

First, the LBAs from the disc logs (PX-716AL followed by Ultraplex 40):

      Data Track  1, LBA        0-   19784, Length    19785
      Data Track  2, LBA    19785-   98116, Length    78332
     Audio Track  3, LBA    98117-   99021, Length      905
     Audio Track  4, LBA    99022-   99923, Length      902
     Audio Track  5, LBA    99924-  100771, Length      848
     Audio Track  6, LBA   100772-  101774, Length     1003
     Audio Track  7, LBA   101775-  102984, Length     1210
     Audio Track  8, LBA   102985-  112584, Length     9600
     Audio Track  9, LBA   112585-  122184, Length     9600
     Audio Track 10, LBA   122185-  131784, Length     9600
     Audio Track 11, LBA   131785-  141384, Length     9600
     Audio Track 12, LBA   141385-  150984, Length     9600
     Audio Track 13, LBA   150985-  160584, Length     9600
     Audio Track 14, LBA   160585-  169734, Length     9150
     Audio Track 15, LBA   169735-  172289, Length     2555
     Audio Track 16, LBA   172290-  181545, Length     9256
     Audio Track 17, LBA   181546-  188175, Length     6630
     Audio Track 18, LBA   188176-  194850, Length     6675
     Audio Track 19, LBA   194851-  201526, Length     6676
     Audio Track 20, LBA   201527-  208202, Length     6676
     Audio Track 21, LBA   208203-  233632, Length    25430
                                            Total    233633
============================ TOC on SCSIOP_READ_TOC ===========================
      Data Track  1, LBA        0-   19784, Length    19785
      Data Track  2, LBA    19785-   98116, Length    78332
     Audio Track  3, LBA    98117-   99021, Length      905
     Audio Track  4, LBA    99022-   99923, Length      902
     Audio Track  5, LBA    99924-  100771, Length      848
     Audio Track  6, LBA   100772-  101774, Length     1003
     Audio Track  7, LBA   101775-  102984, Length     1210
     Audio Track  8, LBA   102985-  112584, Length     9600
     Audio Track  9, LBA   112585-  122184, Length     9600
     Audio Track 10, LBA   122185-  131784, Length     9600
     Audio Track 11, LBA   131785-  141384, Length     9600
     Audio Track 12, LBA   141385-  150984, Length     9600
     Audio Track 13, LBA   150985-  160584, Length     9600
     Audio Track 14, LBA   160585-  169734, Length     9150
     Audio Track 15, LBA   169735-  172289, Length     2555
     Audio Track 16, LBA   172290-  181545, Length     9256
     Audio Track 17, LBA   181546-  188175, Length     6630
     Audio Track 18, LBA   188176-  194850, Length     6675
     Audio Track 19, LBA   194851-  201526, Length     6676
     Audio Track 20, LBA   201527-  208202, Length     6676
     Audio Track 21, LBA   208203-  233632, Length    25430
                                            Total    233633

But, when we look at the MSF addresses, the results from the Ultraplex look way off while the ones from the PX-716AL look reasonable. Pasted below (PX-716AL first).

========================= FULL TOC on SCSIOP_READ_TOC =========================
    FirstCompleteSession: 1
     LastCompleteSession: 1
    Session 1, FirstTrack  1, Format: CD-DA or CD-ROM
    Session 1,  LastTrack 21
    Session 1,      Leadout, MSF 51:57:08 (LBA[233783, 0x39137])
    Session 1,     Track  1, MSF 00:02:00 (LBA[000150, 0x00096])
    Session 1,     Track  2, MSF 04:25:60 (LBA[019935, 0x04ddf])
    Session 1,     Track  3, MSF 21:50:17 (LBA[098267, 0x17fdb])
    Session 1,     Track  4, MSF 22:02:22 (LBA[099172, 0x18364])
    Session 1,     Track  5, MSF 22:14:24 (LBA[100074, 0x186ea])
    Session 1,     Track  6, MSF 22:25:47 (LBA[100922, 0x18a3a])
    Session 1,     Track  7, MSF 22:39:00 (LBA[101925, 0x18e25])
    Session 1,     Track  8, MSF 22:55:10 (LBA[103135, 0x192df])
    Session 1,     Track  9, MSF 25:03:10 (LBA[112735, 0x1b85f])
    Session 1,     Track 10, MSF 27:11:10 (LBA[122335, 0x1dddf])
    Session 1,     Track 11, MSF 29:19:10 (LBA[131935, 0x2035f])
    Session 1,     Track 12, MSF 31:27:10 (LBA[141535, 0x228df])
    Session 1,     Track 13, MSF 33:35:10 (LBA[151135, 0x24e5f])
    Session 1,     Track 14, MSF 35:43:10 (LBA[160735, 0x273df])
    Session 1,     Track 15, MSF 37:45:10 (LBA[169885, 0x2979d])
    Session 1,     Track 16, MSF 38:19:15 (LBA[172440, 0x2a198])
    Session 1,     Track 17, MSF 40:22:46 (LBA[181696, 0x2c5c0])
    Session 1,     Track 18, MSF 41:51:01 (LBA[188326, 0x2dfa6])
    Session 1,     Track 19, MSF 43:20:01 (LBA[195001, 0x2f9b9])
    Session 1,     Track 20, MSF 44:49:02 (LBA[201677, 0x313cd])
    Session 1,     Track 21, MSF 46:18:03 (LBA[208353, 0x32de1])
========================= FULL TOC on SCSIOP_READ_TOC =========================
    FirstCompleteSession: 1
     LastCompleteSession: 1
    Session 1, FirstTrack  1, Format: CD-DA or CD-ROM
    Session 1,  LastTrack 33
    Session 1,      Leadout, MSF 81:87:08 (LBA[371033, 0x5a959])
    Session 1,     Track  1, MSF 00:02:00 (LBA[000150, 0x00096])
    Session 1,     Track  2, MSF 04:37:96 (LBA[020871, 0x05187])
    Session 1,     Track  3, MSF 33:80:23 (LBA[154523, 0x25b9b])
    Session 1,     Track  4, MSF 34:02:34 (LBA[153184, 0x25660])
    Session 1,     Track  5, MSF 34:20:36 (LBA[154536, 0x25ba8])
    Session 1,     Track  6, MSF 34:37:71 (LBA[155846, 0x260c6])
    Session 1,     Track  7, MSF 34:57:00 (LBA[157275, 0x2665b])
    Session 1,     Track  8, MSF 34:85:16 (LBA[159391, 0x26e9f])
    Session 1,     Track  9, MSF 37:03:16 (LBA[166741, 0x28b55])
    Session 1,     Track 16, MSF 39:17:16 (LBA[176791, 0x2b297])
    Session 1,     Track 17, MSF 41:25:16 (LBA[186391, 0x2d817])
    Session 1,     Track 18, MSF 49:39:16 (LBA[223441, 0x368d1])
    Session 1,     Track 19, MSF 51:53:16 (LBA[233491, 0x39013])
    Session 1,     Track 20, MSF 53:67:16 (LBA[243541, 0x3b755])
    Session 1,     Track 21, MSF 55:69:16 (LBA[252691, 0x3db13])
    Session 1,     Track 22, MSF 56:25:21 (LBA[253896, 0x3dfc8])
    Session 1,     Track 23, MSF 64:34:70 (LBA[290620, 0x46f3c])
    Session 1,     Track 24, MSF 65:81:01 (LBA[298576, 0x48e50])
    Session 1,     Track 25, MSF 67:32:01 (LBA[303901, 0x4a31d])
    Session 1,     Track 32, MSF 68:73:02 (LBA[311477, 0x4c0b5])
    Session 1,     Track 33, MSF 70:24:03 (LBA[316803, 0x4d583])

The results from the Ultraplex seem to skip some track numbers, and also thinks the disc is 81+ minutes long.

When I look at the TOC with EAC the Ultraplex matches the PX-716AL.

I'm not sure what's going on here.

605 (edited by sarami 2015-03-09 06:27:38)

Somehow Ultraplex seems to get the fulltoc data as "hexadecimal"
  PX-716AL: LastTrack 21, Ultraplex: LastTrack 33(=0x21)
  PX-716AL: Leadout, MSF 51:57:08, Ultraplex: Leadout, MSF 81:87:08(=0x51:0x57:0x08)
   :
   :
I coded to convert hexadecimal to decimal these value. Could you test again..

sarami wrote:

Somehow Ultraplex seems to get the fulltoc data as "hexadecimal"

Ahh, I should've spotted that. I looked at the bits to see if maybe it was some kinda byteswapping being done, but it didn't occur to me that it might be returning hex. Good catch!

Thanks again. We're close now, I think. The lead-out is read as well as the scrambled sectors.

However, there's a segfault during the WriteCueForFirst() function:

    if (pDisc->SCSI.pszTitle[0][0] != 0) {
        _TCHAR str[META_CDTEXT_SIZE] = { 0 };
#ifdef UNICODE
        MultiByteToWideChar(CP_ACP, 0, 
            pDisc->SCSI.pszTitle[0], META_CDTEXT_SIZE, str, META_CDTEXT_SIZE);
#else
        strncpy(str, pDisc->SCSI.pszTitle[0], META_CDTEXT_SIZE);
#endif
        _ftprintf(fpCue, _T("TITLE \"%s\"\n"), str);
    }

pDisc->SCSI.pszTitle == 0, because pDevice->bCanCDText == FALSE, so the pszTitle array isn't initialized. Same problem exists with pszPerformer, etc. I bypassed it by checking first if pDisc->SCSI.pszTitle == 0, and similar for other psz* variables. I'm not sure if that's the best solution, though.

One other problem which I haven't looked into yet is, after reading all the scrambled sectors for a PSX disc, an error is presented:

[L:1542] Internal error. Failed to analyze the subchannel. Track[01]/[63]

The read successfully completed on the one data-only disc I tried (VIS disc, Mode 1), but I noticed the hash is different each time. I noticed the same thing happens with the PX-716AL too. The scrambled files mostly match between the two (I don't know how many bytes differed, but it was a small enough number that I could go through all of them in a hex editor).

sarami wrote:

Your disc is needed by subdump.exe ripping. Please report to F1ReB4LL.

Yeah, 02:01 confirmed. My disc is a bit scratched - https://www.sendspace.com/file/1nfovg - either the gap misdetected due to that or simply overlooked something. Cue was locked on Jan 09 2012, 02:19, that's before the DIC and only a few weeks after the trurip's leak, most likely used PerfectRip or manual splitting&descrambling.

scsi_wuzzy wrote:

pDisc->SCSI.pszTitle == 0, because pDevice->bCanCDText == FALSE, so the pszTitle array isn't initialized. Same problem exists with pszPerformer, etc. I bypassed it by checking first if pDisc->SCSI.pszTitle == 0, and similar for other psz* variables. I'm not sure if that's the best solution, though.

Uploaded.

scsi_wuzzy wrote:

One other problem which I haven't looked into yet is, after reading all the scrambled sectors for a PSX disc, an error is presented:

Please all log file.

609 (edited by scsi_wuzzy 2015-03-10 10:32:39)

Crash seems to be resolved. Thanks.

sarami wrote:

Please all log file.

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

Disc is Nights into Dreams (US). I can upload logs from the PX-716AL too if you want to compare.

Edit: Went ahead and uploaded the logs from the PX-716AL:
https://www.sendspace.com/file/7kzsm4

- fixed: If ModeSense failed, set drive buffer size manually. (Ultraplex is 512)
Could you test again and upload all log of Ultraplex.

sarami wrote:

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.

scsi_wuzzy wrote:

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.

scsi_wuzzy wrote:

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.

scsi_wuzzy wrote:

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.:)

sarami wrote:

fixed: MINIMUM_DRIVE_BUF_SIZE is from 256 to 512.

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

[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).

- fixed: IsValidSubQTrack()

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.

616 (edited by sarami 2015-03-15 13:45:04)

scsi_wuzzy wrote:

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

Thanks. Uploaded.

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.

scsi_wuzzy wrote:

I started doing tests on an old Nakamichi.

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

scsi_wuzzy wrote:

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.

http://forum.redump.org/topic/2468/offs … 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...

sarami wrote:
scsi_wuzzy wrote:

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.

http://forum.redump.org/topic/2468/offs … 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

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.

sarami wrote:

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

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.

scsi_wuzzy wrote:

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.

620 (edited by scsi_wuzzy 2015-03-17 02:16:35)

sarami wrote:

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():

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:

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:

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

621 (edited by sarami 2015-03-17 08:55:37)

scsi_wuzzy wrote:

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".

I found this page.
https://msdn.microsoft.com/en-us/librar … s.85).aspx
And I understood that 1210S didn't support ReadBufferCapacity according to your drivelog.

    FeatureRealTimeStreaming
                StreamRecording: No
            WriteSpeedInGetPerf: No
               WriteSpeedInMP2A: Yes
                     SetCDSpeed: Yes
        ReadBufferCapacityBlock: No

Uploaded. But I don't know why SetCDSpeed fails on 1210S...

EDIT: remove some declspec(align(4) in struct.h. changed message when it failed re-read.
EDIT: I had made a silly mistake regarding reread from 20150227. fixed it.

622 (edited by scsi_wuzzy 2015-03-20 05:50:10)

sarami wrote:

I found this page.
https://msdn.microsoft.com/en-us/librar … s.85).aspx
And I understood that 1210S didn't support ReadBufferCapacity according to your drivelog.

    FeatureRealTimeStreaming
                StreamRecording: No
            WriteSpeedInGetPerf: No
               WriteSpeedInMP2A: Yes
                     SetCDSpeed: Yes
        ReadBufferCapacityBlock: No

Uploaded. But I don't know why SetCDSpeed fails on 1210S...

EDIT: remove some declspec(align(4) in struct.h. changed message when it failed re-read.
EDIT: I had made a silly mistake regarding reread from 20150227. fixed it.

1210S works with this release, but I've just noticed that its hashes don't match the other drives. It didn't in the last version either, but I didn't notice it then.

It looks like some kind of offset problem? First row in HxD when I load the .scm file produced by the 40TS is

00 FF FF FF FF FF FF FF FF FF FF 00 01 82 00 61

So, that is at offset 0x0 in the 40TS .scm. But, for the 1210S, it occurs at 0x930. Likewise, the data at 0x10 in the 40TS file occurs at 0x940 in the 1210S data. Everything seems to be offset by 0x930.

Ultraplex Logs: https://www.sendspace.com/file/jkiijq

1210S Logs: https://www.sendspace.com/file/zfqvcc

On another note, C2 error re-reading does indeed seem to work properly on this version.

Edit: Just realized 0x930 = 2352 bytes = 1 sector.

623 (edited by sarami 2015-03-29 04:07:00)

It may be this.
DiscImageCreator\Doc\KnownIssue.txt

. Reading with/without subcode, differ offset. (firmware bug?)
  PLEXTOR PX-W2410TA: +686(with), +98(without)
  PLEXTOR PX-320A   : +686(with), +98(without)

fixed: reading a subcode on ReadCDForSearchingOffset().
If my thought is right, "Combined Offset (Byte)" of disclog.txt increases 2352(0x930) byte in your 1210S. If so, to get right "CD offset", it needs to fix driveOffset.txt manually for these drives .

EDIT:
fixed: doesn't work startstop command from 20150227

sarami wrote:

It may be this.
DiscImageCreator\Doc\KnownIssue.txt

. Reading with/without subcode, differ offset. (firmware bug?)
  PLEXTOR PX-W2410TA: +686(with), +98(without)
  PLEXTOR PX-320A   : +686(with), +98(without)

fixed: reading a subcode on ReadCDForSearchingOffset().
If my thought is right, "Combined Offset (Byte)" of disclog.txt increases 2352(0x930) byte in your 1210S. If so, to get right "CD offset", it needs to fix driveOffset.txt manually for these drives .

I think maybe there's some other issue? If I understand correctly, for some drives the offset changes depending on if subcode reading is on or off. If that were the case, these px_d8 commands would result in differing data:

px_d8 i 0
px_d8 i 0 2
px_d8 i 0 1

However, the actual sector data is the same among all of them, and the only difference is the subcode data. If the offset changed, I think it should be seen in the sector data?

I tried manually changing the offset in the text file to +686 or -490 (+/- 2352 bytes), but that didn't alter the resulting image (hashes were the same). Perhaps I've misunderstood something.

scsi_wuzzy wrote:
px_d8 i 0
px_d8 i 0 2
px_d8 i 0 1

How about the result of px_d8 details in 1210S and other plextor?
  Sector: ??
  MSF: ??:??:??
  Combined offset: ??? bytes / ??? samples