You are not logged in. Please login or register.
Redump Forum → General discussion → DiscImageCreator
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
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.
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
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 233633But, 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.
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..
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).
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.
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.
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.
Crash seems to be resolved. Thanks.
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.
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.
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.:)
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.
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.
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.
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...
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
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.
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.
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:59Edit: 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
DEMy 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: NoUploaded. 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.
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: NoUploaded. 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 61So, 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.
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
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 0px_d8 i 0 2px_d8 i 0 1However, 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.
px_d8 i 0px_d8 i 0 2px_d8 i 0 1
How about the result of px_d8 details in 1210S and other plextor?
Sector: ??
MSF: ??:??:??
Combined offset: ??? bytes / ??? samples
Redump Forum → General discussion → DiscImageCreator
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.