You are not logged in. Please login or register.
Redump Forum → General discussion → DiscImageCreator
DIC is treating intentional C2 errors (unlicensed) with /sf like regular C2 errors. keeps trying to re-read.
Looks like DUMMY.ZIP is triggering the issue (it's usually BIG.DAT).
Ok, I'll add it.
https://github.com/saramibreak/DiscImag … g/20231201
*2023-12-01
- added support non-plextor and non-lg/asus drive when data/audio command is used (but some drive failed to dump. e.g. SH-216BB)
- added again -D option in install command of makefile for linux
- added parsing PS3_DISC.SFB and PS3UPDAT.PUP
- added detecting protection (DUMMY.ZIP)
- added a flag indicating readable the lead-out sector (Using ASMedia SATA controller and linux, 0xF1 drive can read the lead-out sector using 0xbe)
- added checking if export, import, resource size are correct
- changed if sync or msf or mode is invalid, it skips descrambling
- changed EXELBA_STORE_SIZE
- fixed /be option
- fixed error sector reading
- fixed reading the multiple PARAM.SFO
- fixed reading PARAM.SFO
- fixed the crash when cab file was extracted
- fixed division by zero
- fixed DEBUG build error
- Updated driveOffset.txt
At least with my setup, the latest release is completely unusable: getting c2 errors on every sector, and a warning that the drive does not support subchannel pack mode, while the 20230909 release had no problem (bw-16d1ht + ribshark firmware + sata to usb adapter).
At least with my setup, the latest release is completely unusable: getting c2 errors on every sector, and a warning that the drive does not support subchannel pack mode, while the 20230909 release had no problem (bw-16d1ht + ribshark firmware + sata to usb adapter).
I can confirm this.
@Nemok, Lugamo
Thanks. I fixed it. https://github.com/saramibreak/DiscImag … issues/254
@Nemok, Lugamo
Thanks. I fixed it. https://github.com/saramibreak/DiscImag … issues/254
It works fine.
Raw mode with /c2 is fixed.
Pack mode without /c2 is still broken.
Pack mode without /c2 is still broken.
It's not broken. LG/ASUS does not support the pack mode.
Nemok wrote:Pack mode without /c2 is still broken.
It's not broken. LG/ASUS does not support the pack mode.
How to explain this ? Were previous DIC releases wrong about it ?
How to explain this ? Were previous DIC releases wrong about it ?
See subError.txt. Subchannel are all zero bytes.
LBA[000000, 0000000]: Track[01]: SubQ Reread [crc16 unmatch] -> NG. Fix manually
========== LBA[000000, 0000000]: Sub Channel ==========
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
P 00 00 00 00 00 00 00 00 00 00 00 00
Q 00 00 00 00 00 00 00 00 00 00 00 00
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
LBA[000000, 0000000]: Track[01]: SubQ crc16 is 0. Main-channel may be corrupt
LBA[000000, 0000000]: Track[01]: SubQ[12]:Adr[0] -> [0x01]
LBA[000000, 0000000]: Track[01]: SubQ[13]:PrevTrackNum[01] -> [00]
LBA[000000, 0000000]: Track[01]: SubQ[19-21]:PrevAbs[149, 00:01:74], Abs[0, 00:00:00] -> [150, 00:02:00]
LBA[000000, 0000000]: Track[01]: SubQ[22]:CrcHigh[0000] -> [0xf6]
LBA[000000, 0000000]: Track[01]: SubQ[23]:CrcLow[0000] -> [0xd8]
LBA[000001, 0x00001]: Track[01]: SubQ Reread [crc16 unmatch] -> NG. Fix manually
========== LBA[000001, 0x00001]: Sub Channel ==========
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
P 00 00 00 00 00 00 00 00 00 00 00 00
Q 00 00 00 00 00 00 00 00 00 00 00 00
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
LBA[000001, 0x00001]: Track[01]: SubQ crc16 is 0. Main-channel may be corrupt
LBA[000001, 0x00001]: Track[01]: SubQ[12]:Adr[0] -> [0x01]
LBA[000001, 0x00001]: Track[01]: SubQ[15-17]:PrevRel[0, 00:00:00], Rel[0, 00:00:00] -> [-1, 00:00:255], [L:1421]
LBA[000001, 0x00001]: Track[01]: SubQ[19-21]:PrevAbs[150, 00:02:00], Abs[0, 00:00:00] -> [151, 00:02:01]
LBA[000001, 0x00001]: Track[01]: SubQ[22]:CrcHigh[0000] -> [0xe3]
LBA[000001, 0x00001]: Track[01]: SubQ[23]:CrcLow[0000] -> [0x24]
LBA[000002, 0x00002]: Track[01]: SubQ Reread [crc16 unmatch] -> NG. Fix manually
========== LBA[000002, 0x00002]: Sub Channel ==========
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
P 00 00 00 00 00 00 00 00 00 00 00 00
Q 00 00 00 00 00 00 00 00 00 00 00 00
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
LBA[000002, 0x00002]: Track[01]: SubQ crc16 is 0. Main-channel may be corrupt
LBA[000002, 0x00002]: Track[01]: SubQ[12]:Adr[0] -> [0x01]
LBA[000002, 0x00002]: Track[01]: SubQ[15-17]:PrevRel[-1, 00:00:255], Rel[0, 00:00:00] -> [-2, 00:00:254], [L:1421]
LBA[000002, 0x00002]: Track[01]: SubQ[19-21]:PrevAbs[151, 00:02:01], Abs[0, 00:00:00] -> [152, 00:02:02]
LBA[000002, 0x00002]: Track[01]: SubQ[22]:CrcHigh[0000] -> [0x79]
LBA[000002, 0x00002]: Track[01]: SubQ[23]:CrcLow[0000] -> [0x16]
LBA[000003, 0x00003]: Track[01]: SubQ Reread [crc16 unmatch] -> NG. Fix manuallyIndeed subchannel is zeroed. So pack mode never really was supported even if a dump in this mode could be started. Fine.
Also discovered today :
- Discs with data and audio tracks cannot be dumped anymore using ribshark. DIC throws errors like this one:
LBA[083296, 0x14560]: [F:ReadCDForCheckingSubRtoW][L:1283]
Opcode: 0xbe
ScsiStatus: 0x02 = CHECK_CONDITION
SenseData Key-Asc-Ascq: 03-11-05 = MEDIUM_ERROR - L-EC UNCORRECTABLE ERROR
lpCmd: be, 00, 00, 01, 45, 60, 00, 00, 01, f8, 01, 00
dwBufSize: 2448- DIC often fails to get write-offset on first attempt.
Also discovered today :
Uploaded.
https://github.com/saramibreak/DiscImag … 1842949631
OK those issues are now fixed.
The program gets further but fails at checking subQ address for each track :
LBA[088444, 0x1597c]: [F:ReadCDForCheckingSubQAdr][L:1076]
Opcode: 0xbe
ScsiStatus: 0x02 = CHECK_CONDITION
SenseData Key-Asc-Ascq: 03-11-05 = MEDIUM_ERROR - L-EC UNCORRECTABLE ERROR
lpCmd: be, 00, 00, 01, 59, 7c, 00, 00, 01, f8, 01, 00
dwBufSize: 4896The program gets further but fails at checking subQ address for each track :
Uploaded.
https://github.com/saramibreak/DiscImag … 1844517155
Same behavior unfortunately, though the error has changed a little :
LBA[083196, 0x144fc]: [F:ReadCDForCheckingSubQAdr][L:1080]
Opcode: 0xbe
ScsiStatus: 0x02 = CHECK_CONDITION
SenseData Key-Asc-Ascq: 03-11-05 = MEDIUM_ERROR - L-EC UNCORRECTABLE ERROR
lpCmd: be, 00, 00, 01, 44, fc, 00, 00, 01, f8, 01, 00
dwBufSize: 2448Same behavior unfortunately, though the error has changed a little :
I tried some mixed mode disc, but it's no problem. Could you upload the logs?
Nemok wrote:Same behavior unfortunately, though the error has changed a little :
I tried some mixed mode disc, but it's no problem. Could you upload the logs?
Sure.
Disc tested : http://redump.org/disc/31428/
Log files : https://1drv.ms/u/s!AiA4u0yuSX13pn0G6gM … U?e=BJg5Td
The issue is fixed. Thanks sarami.
What is the current state of Tages support ?
The github page mentions that DIC "can read in reverse, but specifications are not decided". The associated command seems to have been "/r" at one point, as found here: http://wiki.redump.org/index.php?title= … f_Commands, but is not recognized anymore.
The issue is fixed. Thanks sarami.
Thanks several testing.
What is the current state of Tages support ?
The github page mentions that DIC "can read in reverse, but specifications are not decided".
I don't know how redump.org stipulates that twin sectors be preserved.
The associated command seems to have been "/r" at one point, as found here: http://wiki.redump.org/index.php?title= … f_Commands, but is not recognized anymore.
Latest commands list is here. https://github.com/saramibreak/DiscImag … nd-options
I don't know how redump.org stipulates that twin sectors be preserved.
Jackal seems to be the only one who tried to give an example :
http://redump.org/disc/35932/
http://redump.org/disc/34669/
- number of duplicated sectors
- range of duplicated sectors
- type of duplication (twin)
- hashes (with duplicated sectors inserted into the disc image)
- hashes (with duplicated sectors inserted into the disc image)
You dumped http://redump.org/disc/34669/ . How did you get the hashes with duplicated sectors inserted into the disc image?
I did not, my dump only verified the regular hashes. I initially thought that DIC had provided that info found in the comments, whenever the correct argument was given to it. That's why I wanted to try "/r".
Daemon tools pro is supposed to make working dumps of Tages discs but creates non consistent and non standard mds/mdf images, so using these for comparison with regular images to get that info isn't really straightforward.
That's why I wanted to try "/r".
"/r" generates only the forward-image using backward reading.
I dumped Moto Racer 3 (USA) http://redump.org/disc/31578/ with /r. As a result, I found it that 329693 ... 329946 are different sectors. But Jackal says "Disc has 260 twin sectors in range 329687-329947".
Question: Twin sectors of the Tages are always 260 sectors? If yes, where is the evidence to show that it is correct?
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.