Page 115 of 354
Re: DiscImageCreator
Posted: Mon Oct 30, 2017 6:00 pm
by F1ReB4LL
sarami wrote:Uploaded test version.
- improved: Rewrote the C2 error recovering logic
Code: Select all
/c2 Continue reading CD to recover C2 error existing sector
val1 value to reread (default: 10, min: 2, max: 255)
val2 first LBA to reread (default: 0)
val3 last LBA to reread (default: end-of-sector)
I don't understand the current logic, it rereads all the sectors now, not only the ones with C2 errors? Works very slow and ineffective. Took 6 hours, ended with the same bad results as before. DIC from 2013 dumps the same disc in 30 minutes with no errors. Why not to rollback to the old error correction, if it works fast and gives better results?
Re: DiscImageCreator
Posted: Wed Nov 01, 2017 9:19 pm
by sarami
Updated.
Code: Select all
/c2 Continue reading CD to recover C2 error existing sector
val1 value to reread (default: 255)
val2 0: reread sector c2 error is reported (default)
1: reread all (or from first to last) sector
val3 first LBA to reread (default: 0)
val4 last LBA to reread (default: end-of-sector)
val3, 4 is used when val2 is 1
----
it rereads all the sectors now, not only the ones with C2 errors?
As I already said in PM, the c2 error report of the drive isn't completely reliable as far as I see the log of A Murder of Crows, so I check all sectors if even one c2 error exists. But when val2 is "0", only rereads sector c2 error is reported.
Why not to rollback to the old error correction
The old logic saw the sector all-bytes matched for two consecutive as the correct sector, but it could get the incorrect sector all-bytes matched for two consecutive.
So my bad disc couldn't get the all recovered sector. Your disc is nothing but getting the correct sector by accident.
iR0b0t wrote:I will recheck --- b) Dump with "/c2 /q /p" parameters --- later again.
I confirmed that 0xd8 with 08(Main+C2+Sub) couldn't get the pregap sector properly if first track is the data.
If resolves this, when reads the pregap sector of the first track, it has to use 0xd8 with 02(Main+Sub).
EDIT:
Sorry. 20171102 version wasn't uploaded. Uploaded as 20171106. I confirmed my damaged disc is recovered all using this version.
EDIT2:
ajshell1 wrote:However, I have never had any sucess in trying to use two instances of DIC at once.
Please tell me the procedure in detail.
Re: DiscImageCreator
Posted: Tue Nov 14, 2017 11:41 pm
by battosai121
Not Really sure what the problem is but on the newer version of this including the test version it errors out on dumping discs for me, but older version do work.
Code: Select all
LBA[268743, 0x419c7]: [F:GetLBAForSubChannelOffset][L:58]
Opcode: 0xbe
ScsiStatus: 0x02 = CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-21-00 = ILLEGAL_REQUEST - LOGICAL BLOCK ADDRESS OUT OF RANGE
lpCmd: be, 04, 00, 04, 19, c7, 00, 00, 01, f8, 04, 00
dwBufSize: 2448
OK
Checking SubQ adr (Track) 1/ 1
Checking SubRtoW (Track) 1/ 1
Reading DirectoryRecord 5/ 5
Set OpCode: 0xbe, SubCode: 1(Raw)
Checking SubQ ctl (Track) 1/ 1
[F:ProcessReadCD][L:1462] GetLastError: 87, The parameter is incorrect.
Please wait for 40000 milliseconds until the device is returned
Re: DiscImageCreator
Posted: Wed Nov 15, 2017 12:22 pm
by sarami
Updated test version. Test and upload the log please.
Re: DiscImageCreator
Posted: Wed Nov 15, 2017 3:12 pm
by olofolleola4
I want to start off by giving sarami and all contributors to DiscImageCreator kudos and a warm thank you for all the work you do!
I've experienced a bug, tested with the latest version and test version (no idea if it's present in earlier versions).
DIC doesn't recognize that
The Elder Scrolls III: Tribunal has a SafeDisc 2.xx.xxx protection, and therefor it cannot get dumped properly (it founds a load of C2 errors, naturally).
I'll include the compressed archive with the files from the latest test version of DIC before I canceled the dumping of that disc.
Cheers!
Re: DiscImageCreator
Posted: Wed Nov 15, 2017 11:36 pm
by sarami
Thx.
_volDesc.txt
Code: Select all
:
Length of Directory Record: 34
Extended Attribute Record Length: 0
Location of Extent: 335260
Data Length: 2048
Recording Date and Time: 2002-10-31 16:31:47 -05:00
File Flags: 2 (Visible, Directory, Disassociated, File has't record format, Owner/Group ID has't, Final Directory Record)
File Unit Size: 0
:
Code: Select all
========== LBA[000020, 0x00014]: Path Table Record ==========
Length of Directory Identifier: 1
Length of Extended Attribute Record: 0
Position of Extent: 335260
Number of Upper Directory: 1
Directory Identifier:
:
This disc points 335260 sector as the position of root directory, but this sector is all zero byte, so dic can't read the directory record and can't detect the protect.
I think the correct position of root dir is 21 or 22 or 23 or 24.
Can Isobuster read the directory correctly?
Re: DiscImageCreator
Posted: Thu Nov 16, 2017 2:11 pm
by olofolleola4
sarami wrote:Thx.
_volDesc.txt
Code: Select all
:
Length of Directory Record: 34
Extended Attribute Record Length: 0
Location of Extent: 335260
Data Length: 2048
Recording Date and Time: 2002-10-31 16:31:47 -05:00
File Flags: 2 (Visible, Directory, Disassociated, File has't record format, Owner/Group ID has't, Final Directory Record)
File Unit Size: 0
:
Code: Select all
========== LBA[000020, 0x00014]: Path Table Record ==========
Length of Directory Identifier: 1
Length of Extended Attribute Record: 0
Position of Extent: 335260
Number of Upper Directory: 1
Directory Identifier:
:
This disc points 335260 sector as the position of root directory, but this sector is all zero byte, so dic can't read the directory record and can't detect the protect.
I think the correct position of root dir is 21 or 22 or 23 or 24.
Can Isobuster read the directory correctly?
IsoBuster doesn't show any directory record at sector 335260, it's all zero byte.
I can see the start of a directory record from sector 20-->23.
If you need any screenshots or anything else, just ask for it
Re: DiscImageCreator
Posted: Thu Nov 16, 2017 8:48 pm
by F1ReB4LL
https://redump.info/disc/45930/ and
https://redump.info/disc/45931/ are undumpable with DIC (including the recent versions, as I understand) -
https://www.sendspace.com/file/31jg9r
Digital Pinball: Necronomicon: Revelations was already reported before, though.
Also, please fix the .dat file generator for Subs Indexes dumps. It doesn't add Subs Indexes .bin files into the .dat anymore, that's not correct. Maybe worth to make a normal dat for normal bins and additional (Subs Indexes).dat for (Subs Indexes).bin files, then?
Re: DiscImageCreator
Posted: Fri Nov 17, 2017 2:33 am
by sarami
Digital Pinball: Necronomicon: Revelations was already reported before, though.
I showed the way to deal to him at that time. (try to use "/s 2" and/or "/f" or change the reading speed or change the drive)
This is definitely the problem of the drive(or disc) that returns the corrupted subchannel, but I don't know why the drive(or disc) returns such the corrupted those.
So I consider these options are enabled if there are some corrupted those.
It doesn't add Subs Indexes .bin files into the .dat anymore
Firstly, are "Subs Indexes" needed? I know that this is used for some pc-engine CDROM^2, but redump'org adopts "TOC Indexes".
BTW, is your pocket fighter recovered using the latest test version? If there is any of the problem, plz tell me.
I asked A Murder of Crows for testing too about ten days ago, but it seems he is busy, haven't reported yet.
Re: DiscImageCreator
Posted: Fri Nov 17, 2017 12:17 pm
by F1ReB4LL
sarami wrote:Digital Pinball: Necronomicon: Revelations was already reported before, though.
I showed the way to deal to him at that time. (try to use "/s 2" and/or "/f" or change the reading speed or change the drive)
This is definitely the problem of the drive(or disc) that returns the corrupted subchannel, but I don't know why the drive(or disc) returns such the corrupted those.
So I consider these options are enabled if there are some corrupted those.
While I could agree about Wangan here, Pinball subdump is errorless, so it's not the disc's fault.
sarami wrote:It doesn't add Subs Indexes .bin files into the .dat anymore
Firstly, are "Subs Indexes" needed? I know that this is used for some pc-engine CDROM^2, but redump'org adopts "TOC Indexes".
I'm adding all the PCE (Subs Indexes) dumps as hidden entries, so these are needed. Will probably make them yellow/visible later, dunno, need to consult with iR0b0t.