You are not logged in. Please login or register.
Redump Forum → Posts by sarami
-For those corrupted sectors, replace everything except the sync and header fields with 0x55 bytes.
I coded that unreadable sector is replaced at 0x55.
up to sector 359847
My PX-755 is same too.
PX-755A has a hardcoded limit?
At least, I don't code like this. How about in dctools?
Thank's test and report. Uploaded 20141017
The drives are all NTFS.
Really? I don’t understand a cause at this time.
[L:1165] Internal error. Failed to analyze the subchannel. Track[31]/[35]
Uploaded.
Still not sorting correctly.
Probably I understood a cause.
Is Your HDD FAT?
If you can, you should use NTFS.
http://msdn.microsoft.com/en-us/library … 85%29.aspx
The order in which the search returns the files, such as alphabetical order, is not guaranteed, and is dependent on the file system. If the data must be sorted, the application must do the ordering after obtaining all the results.
The order in which this function returns the file names is dependent on the file system type. With the NTFS file system and CDFS file systems, the names are usually returned in alphabetical order. With FAT file systems, the names are usually returned in the order the files were written to the disk, which may or may not be in alphabetical order. However, as stated previously, these behaviors are not guaranteed.
I'll support a sort when I have time.
F1ReB4LL wrote:pablogm123 wrote:Still?
Tested the last version (Test(20140823)) -- yes, c2 rereading is still broken, acts absolutely the same (see the report above).
Might have run across this problem too. Had issue this week where a psx disk i was dumping had exactly 1 c2 error which dic said was fixed after rereading, but hashes were different from database
Uploaded latest test ver. Plz test it.
EDIT:Re-uploaded. (Because dbg code existed)
Jackal wrote:Did you even read the forum? e.g. http://forum.redump.org/topic/10483/discimagecreator/
Of course, this is what I'm pointing when I say efforts are being done.
So far the problem with this tool is that it focuses on Windows.
I don't have Unix-like OS(Linux, BSD, OS-X...). So, I don't support at the present moment.
pablogm123 wrote:Still?
"Test(20140804)" is weird and takes 6-7 hours to dump a CD on 40x speed, previous ones were much, much faster.
Fixed. (fua became effective internally, whether to use of /f option or not.)
/m If MCN sector exists in the last sector of the track, use this
For WonderMega Collection [Mega-CD]On Mega CD and Saturn titles MCN is always in the last sector of the track. Only PCE titles have MCN in the first sector of the track. You should treat MCN sectors as the last sector of the track by default. And "/m" parameter should be for PCE discs, where "MCN sector exists in the first sector of the track".
Indeed? Fixed it.
====== Check SubP to W, OperationCode: 0xbe, Subcode: 1(=Raw) ======
Sub Channel LBA 0
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
P ff ff ff ff ff ff ff ff ff ff ff ff
Q 41 01 01 00 00 00 00 00 02 00 28 32
R 00 00 00 00 00 00 00 00 00 00 00 00
S 00 00 00 00 00 00 00 00 00 00 00 03
T 00 00 00 00 00 00 00 00 00 00 00 02
U 00 00 00 00 00 00 00 00 00 00 00 00
V 00 00 00 00 00 00 00 00 00 00 00 00
W 00 00 00 00 00 00 00 00 00 00 00 02====== Check SubP to W, OperationCode: 0xd8, Subcode: 0x08(=Raw) ======
Sub Channel LBA 0
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
P ff ff ff ff ff ff ff ff ff ff ff ff
Q 41 01 01 00 00 00 00 00 02 00 28 32
R 00 00 00 00 00 00 00 00 00 00 00 01
S 00 00 00 00 00 00 00 00 00 00 00 03
T 00 00 00 00 00 00 00 00 00 00 00 02
U 00 00 00 00 00 00 00 00 00 00 00 00
V 00 00 00 00 00 00 00 00 00 00 00 03
W 00 00 00 00 00 00 00 00 00 00 00 00
I uploaded exe including this function.
I am wondering if this pattern could be predictable. And the reason of its existance: intentional, an accidental mastering artifact...?
I don't know this pattern in detail too...
And
To: axisleon
subject: DC ripping is very slow
Improved it. Please test.
Could you finally fix the rereading for C2 errors? It doesn't work in the Test (20140720) version, it doesn't work in the Release(20140621), only works in the old 2013 releases.
I'll check it.
DiscImageCreatorToTestD8FUA.exe cd H: dump 40 /c2 1024 1024 4
If you use FUA, please use /f option.
A bug was able to reappear when I uninstalled SPTD.(http://www.duplexsecure.com/en/downloads)
CacheExplorer 0.8 - spath@cdfreaks.com
Drive on H is PLEXTOR CD-R PX-W5224A 1.04
[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh A8h(FUA) 28h(FUA) D4h(FUA) D5h(FUA) D8h(FUA)CacheExplorer 0.8 - spath@cdfreaks.com
Drive on M is PLEXTOR DVDR PX-755A 1.08
[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh A8h(FUA) 28h(FUA) D4h(FUA) D5h(FUA) D8h(FUA)And I uploaded exe to test.
http://www.mediafire.com/download/dqzkl … stD8FUA.7z
To test, I changed below.
(SCSIOP_PLEX_READ_CD is 0xd8, CDB_FORCE_MEDIA_ACCESS is 0x08)
BOOL ReadCDForFlushingDriveCache(
PDEVICE pDevice,
INT nLBA
)
{
#if 0
CDB::_READ12 cdb = { 0 };
cdb.OperationCode = SCSIOP_READ12;
cdb.ForceUnitAccess = CDB_FORCE_MEDIA_ACCESS;
cdb.LogicalUnitNumber = pDevice->address.Lun;
cdb.LogicalBlock[0] = HIBYTE(HIWORD(nLBA + 1));
cdb.LogicalBlock[1] = LOBYTE(HIWORD(nLBA + 1));
cdb.LogicalBlock[2] = HIBYTE(LOWORD(nLBA + 1));
cdb.LogicalBlock[3] = LOBYTE(LOWORD(nLBA + 1));
#else
CDB::_PLXTR_READ_CDDA cdb = { 0 };
cdb.OperationCode = SCSIOP_PLEX_READ_CD;
cdb.Reserved0 = CDB_FORCE_MEDIA_ACCESS;
cdb.LogicalUnitNumber = pDevice->address.Lun;
cdb.LogicalBlockByte0 = HIBYTE(HIWORD(nLBA + 1));
cdb.LogicalBlockByte1 = LOBYTE(HIWORD(nLBA + 1));
cdb.LogicalBlockByte2 = HIBYTE(LOWORD(nLBA + 1));
cdb.LogicalBlockByte3 = LOBYTE(LOWORD(nLBA + 1));
cdb.TransferBlockByte3 = 1;
#endif
BYTE byScsiStatus = 0;
if (!ScsiPassThroughDirect(pDevice, &cdb, CDB12GENERIC_LENGTH, NULL,
0, &byScsiStatus, _T(__FUNCTION__), __LINE__)
|| byScsiStatus >= SCSISTAT_CHECK_CONDITION) {
return FALSE;
}
return TRUE;
}Result:
I understood that I did not work as expected.
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA) 197/222682[F:ReadCDForFlushingDriveCache][L:516] OperationC
ode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA) 198/222682[F:ReadCDForFlushingDriveCache][L:516] OperationC
ode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA) 199/222682[F:ReadCDForFlushingDriveCache][L:516] OperationC
ode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA) 200/222682[F:ReadCDForFlushingDriveCache][L:516] OperationC
ode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA) 201/222682[F:ReadCDForFlushingDriveCache][L:516] OperationC
ode: 0xd8If you think that FUA exists in 0xd8 command, please teach me it except for CacheExplorer.
C:\>cachex.exe -i g: CacheExplorer 0.8 - spath@cdfreaks.com Drive on G is PLEXTOR DVDR PX-755A 1.08 [+] Buffer size: 2048 kB, read cache is enabled [+] Supported read commands: BEh A8h(FUA) 28h(FUA) D4h(FUA) D5h(FUA) D8h(FUA) C:\>
Does your PX-755 supports D4h(FUA) D5h(FUA) too?
My PX-755
OS: Win7 pro sp1 64bit, firmware: official
CacheExplorer 0.8 - spath@cdfreaks.com
Drive on M is PLEXTOR DVDR PX-755A 1.08
[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh 28h(FUA) D8hIt is repeated, CacheExplorer uses SPTI interface in "unreliable" manner.(= it has a defect.)
This tool doesn't get sense data, so an error doesn't show even if it failed to read.
In other words it is displayed when supported in spite of what doesn’t support it.
Probably you need XP/2003 to get D8h(FUA).
If so, I can code it but I can't test. Because I don't have already WinXP 
Every real Plextor drive I own supports D8h (FUA).
I don’t know whether it supports D8h(FUA) from this post.
Please use -i command and show "[+] Supported read commands:"
void InitSPTDStructureForREAD(unsigned char CDBLength, unsigned int NbSectors)
{
// fill in sptd structure
sptd.Length = sizeof(sptd);
sptd.PathId = 0; // SCSI card ID will be filled in automatically
sptd.TargetId = 0; // SCSI target ID will also be filled in
sptd.Lun = 0; // SCSI lun ID will also be filled in
sptd.CdbLength = CDBLength; // CDB size
sptd.SenseInfoLength = 0; // Don't return any sense data
sptd.DataIn = SCSI_IOCTL_DATA_IN; // There will be data from drive
sptd.DataTransferLength = 2448 * NbSectors; // Size of data
sptd.TimeOutValue = 60; // SCSI timeout value
sptd.DataBuffer = (PVOID)(DataBuf);
sptd.SenseInfoOffset = 0;
}I understood that CacheExplorer doesn't use senseinfo.
http://forum.duplexsecure.com/showpost. … ostcount=2
To make it short: this tool uses SPTI interface in "unreliable" manner: it sends
IOCTL_SCSI_PASS_THROUGH_DIRECT requests without specifying sense info buffer and uses REQUEST SENSE command in case of error. It is not a good way to work with SPTI - it may be ok only if you know device returns no error.
For proper operation on all Windows platforms IOCTL_SCSI_PASS_THROUGH_DIRECT must specify non-zero SenseInfoOffset and SenseInfoLength in SCSI_PASS_THROUGH_DIRECT structure.
I think so.
If CacheExplorer uses a sense info and specifies ReadD4, ReadD5 ReadD8(FUA), it will probably return a sense info below.
ScsiStatus: 02-CHECK_CONDITION
SenseData Key:Asc:Ascq 05:24:00, ILLEGAL_REQUEST - INVALID FIELD IN CDBpablogm123 wrote:Yes, I understand... no FUA for D8 command
sptd.Cdb[0] = 0xD8;
sptd.Cdb[1] = (FUAbit << 3);
sptd.Cdb[2] = byte((TargetSector>>24)&0xFF); // msb
sptd.Cdb[3] = byte((TargetSector>>16)&0xFF);
sptd.Cdb[4] = byte((TargetSector>>8)&0xFF);
sptd.Cdb[5] = byte((TargetSector)&0xFF); // lsb
sptd.Cdb[6] = byte((NbSectors>>24)&0xFF); // msb
sptd.Cdb[7] = byte((NbSectors>>16)&0xFF);
sptd.Cdb[8] = byte((NbSectors>>8)&0xFF);
sptd.Cdb[9] = byte((NbSectors)&0xFF); // lsbTaken from http://club.myce.com/attachments/f61/20 … hexsrc.zip
FUAbit == "True", if 0xD8(FUA) is supported by the drive, so, sptd.Cdb[1] = 1 << 3 = 1*2*2*2 = 8.
Tested PX-W5224A
CacheExplorer 0.8 - spath@cdfreaks.com
Drive on H is PLEXTOR CD-R PX-W5224A 1.04
[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh A8h(FUA) 28h(FUA) D8hAccording to src, if it support fua, show "D8h(FUA)".
If a plextor drive that supported fua exists, I'll code it.
I understood that PX-708 didn't support speedread.
http://ysscdr.web.fc2.com/px708a/px708a_02.htm
Fixed.
[F:SetSpeedRead][L:672] OperationCode: e9
"SpeedRead" doesn't support in PX-708??
If you have already installed plextools professional xl, please confirm "Enable SpeedRead CD/DVD".
If PX-708 is supported, I'll buy it to test.
Why subcodes of those discs are extracted in packed mode? Mine are extracted in raw mode, always.
http://forum.redump.org/post/48058/#p48058
and tested below. (0xd8, 0x08 gets main+C2+sub)
Disc is "Ore no Shikabane wo Koete Yuke"
Drive is PX-5224
====== Check SubP to W, OperationCode: 0xbe, Subcode: 1(=Raw) ======
Sub Channel LBA 0
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
P ff ff ff ff ff ff ff ff ff ff ff ff
Q 41 01 01 00 00 00 00 00 02 00 28 32
R 00 00 00 00 00 00 00 00 00 00 00 00
S 00 00 00 00 00 00 00 00 00 00 00 03
T 00 00 00 00 00 00 00 00 00 00 00 02
U 00 00 00 00 00 00 00 00 00 00 00 00
V 00 00 00 00 00 00 00 00 00 00 00 00
W 00 00 00 00 00 00 00 00 00 00 00 02
====== Check SubP to W, OperationCode: 0xbe, Subcode: 4(=Pack) ======
Sub Channel LBA 0
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
P ff ff ff ff ff ff ff ff ff ff ff ff
Q 41 01 01 00 00 00 00 00 02 00 28 32
R 00 00 00 00 00 00 00 00 00 00 00 00
S 00 00 00 00 00 00 00 00 00 00 00 00
T 00 00 00 00 00 00 00 00 00 00 00 00
U 00 00 00 00 00 00 00 00 00 00 00 00
V 00 00 00 00 00 00 00 00 00 00 00 00
W 00 00 00 00 00 00 00 00 00 00 00 00
====== Check SubP to W, OperationCode: 0xd8, Subcode: 0x02(=Pack) ======
Sub Channel LBA 0
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
P ff ff ff ff ff ff ff ff ff ff ff ff
Q 41 01 01 00 00 00 00 00 02 00 28 32
R 00 00 00 00 00 00 00 00 00 00 00 00
S 00 00 00 00 00 00 00 00 00 00 00 00
T 00 00 00 00 00 00 00 00 00 00 00 00
U 00 00 00 00 00 00 00 00 00 00 00 00
V 00 00 00 00 00 00 00 00 00 00 00 00
W 00 00 00 00 00 00 00 00 00 00 00 00
====== Check SubP to W, OperationCode: 0xd8, Subcode: 0x03(=Pack) ======
Sub Channel LBA 0
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
P ff ff ff ff ff ff ff ff ff ff ff ff
Q 41 01 01 00 00 00 00 00 02 00 28 32
R 00 00 00 00 00 00 00 00 00 00 00 00
S 00 00 00 00 00 00 00 00 00 00 00 00
T 00 00 00 00 00 00 00 00 00 00 00 00
U 00 00 00 00 00 00 00 00 00 00 00 00
V 00 00 00 00 00 00 00 00 00 00 00 00
W 00 00 00 00 00 00 00 00 00 00 00 00
====== Check SubP to W, OperationCode: 0xd8, Subcode: 0x08(=Raw) ======
Sub Channel LBA 0
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
P ff ff ff ff ff ff ff ff ff ff ff ff
Q 41 01 01 00 00 00 00 00 02 00 28 32
R 00 00 00 00 00 00 00 00 00 00 00 01
S 00 00 00 00 00 00 00 00 00 00 00 03
T 00 00 00 00 00 00 00 00 00 00 00 02
U 00 00 00 00 00 00 00 00 00 00 00 00
V 00 00 00 00 00 00 00 00 00 00 00 03
W 00 00 00 00 00 00 00 00 00 00 00 00Result:
0xd8 command to get main+c2+sub(pack) directly doesn't exist.
If you get those, app needs to get main+c2 using 0xd8 and 0x08, and needs to get sub using 0xd8 and 0x02 or 0x03.
By the way, possible texts you could enhance, so that they sound more natural:
Thanks for native speaker 
I still get the invalid request error aswell. Different disc (dumps 100% btw)
added log to console. Please retest and show me a console log.
certain discs manufactured by Sony DADC in Japan (IFPI 45xx) have a weird pattern in the R-W subcodes, last byte of R-W frames are filled with 0x1, 0x2 or 0x3 values.
I'll confirm later too.
Tests of extracting that burned CD, discimagecreator vs. PerfectRip (raw and packed mode). Definitely, discimagecreator erases that pattern, like packed mode of PR does (here is the drive itself misscorrecting that pattern).
About r to w without cd-g disc, it replace at all zero at the present.
And C2 file is 588 bytes bigger than expected.
Fixed.
About MotorMash
LBA[147329, 0x23f81], Track[03]: PrevTrackNum[03] -> [02]
There is wrong Subdata of tracknum of LBA 147328.
Fixed probably.
20140628
- improved: fix Adr 2 of SubQ(Sub[19] & 0x0f => 0 and Sub[20] => 0)
20140630
- improved: Adr fix logic
I tested Read(12)[0xA8] command for CD.
Audio Sector => SenseData Key:Asc:Ascq 05:64:00, ILLEGAL_REQUEST - ILLEGAL MODE FOR THIS TRACK
Data Sector => get only user data (2048 byte). couldn't get sync header, ecc/edc, c2, sub etc...
When I set a transfer Length to 0, an error didn't appear.
20140627
- added: /f option of cd command (But I don't know whether or not a cache is clear.)
- added: Output log of mode sense (page code: 0x2a)
- added: fix AFrame of Adr 2, 3 of SubQ(=MCN, ISRC)
- improved: Adr 2 of SubQ(=MCN)(check whether or not adr is correct.)
I tested Read(12)[0xA8] command for CD.
Audio Sector => SenseData Key:Asc:Ascq 05:64:00, ILLEGAL_REQUEST - ILLEGAL MODE FOR THIS TRACK
Data Sector => get only user data (2048 byte). couldn't get sync header, ecc/edc, c2, sub etc...
In short, for audio tracks and pure audio discs could exist some chance of implementing this way of defeating cache, but for data tracks ripped via the D8 command absolutely no.
Oh, I see. I'll try it.
An option to eject the tray
added.
An option to spin up the disc
added. But couldn't change a reading speed.
Does the software support the Plextor 716-AL drive? It keeps exiting on me with:
Edited the 1st post. Please show the 1st post again.
uploaded 20140621
- include WIP fixes
- added: plextor unique command
- updated: driveOffset.txt (and sent a mail to AccurateRip about PX-716)
about protected disc(or corrupted sectors): I pushed to Todo.txt
about FUA: See KnownIssue.txt
Redump Forum → Posts by sarami
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.