551 (edited by sarami 2014-12-10 05:06:50)

Thanks test.
Fixed PathTableRecord, DirectoryRecord for except MODE2 disc.

gaijin wrote:

Also one from Teac and Yamaha drives has support 0xD8.

Do you have these drive? If so, could you exec px_d8 and tell me a result?

552 (edited by axisleon 2014-12-10 05:12:06)

TEAC CD-532S  support px_d8 but can not run PR (track info flash continuously when insert CD).

I guess the model support d8 command partial.


DIC not work ofc.  (drive offset +92, native SCSI connection, not via adapter)

axisleon wrote:

DIC not work ofc.  (drive offset +92)

Where does it crash?

In the beginning

----------------------
Drive: TEAC CD-532S (+92)(Overread None)
Tool: DiscImageCreator TestVer.20141209 with new EdcEcc
Material: PC game with single track

drive info
http://wiki.livedoor.jp/zx93/d/CD-532S

px_d8 log

D:\PerfectRip v1.00 b34>px_d8 g: 0
Sector: 0
MSF: 00:02:00
Combined offset: +320 bytes / +80 samples

cmd

DiscImageCreatorT1209.exe cd g: Emergency(Taiwan) 4

DIC log

D:\DIC>DiscImageCreatorT1209.exe cd g: Emergency(Taiwan) 4
OS
        Windows XP Professional Service Pack 3, v.6284 32bit
AppVersion
        x86, AnsiBuild, Dec  9 2014 06:22:11
CurrentDir
        D:\DIC
InputPath
         path: Emergency(Taiwan)
        drive:
          dir:
        fname: Emergency(Taiwan)
          ext:
Start: 2014-12-10(Wed) 15:20:05
[F:ModeSense10][L:109] OperationCode: 0x5a
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-20-00, ILLEGAL_REQUEST - INVALID COMMAND OPERATION CODE
End: 2014-12-10(Wed) 15:20:07

555 (edited by sarami 2014-12-16 16:42:25)

axisleon wrote:

[F:ModeSense10][L:109] OperationCode: 0x5a
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-20-00, ILLEGAL_REQUEST - INVALID COMMAND OPERATION CODE

Fixed that if ModeSense10 is error, exec continuous.
But I don't support this drive because it can't overread.

EDIT: Fixed EccEdc
EDIT: Added: checking of 0x814-0x81b per sector of mode 1 and 0x10-0x17 per sector of mode 2 to EccEdc
EDIT: Fixed: EccEdc changed message

No problem at all.

The drive use for double check the write offset and dump single track ones only.

Thanks for the support.

What does RC option do exactly? I tried dumping a securom 4+ disc and gives me multiple errors instead of 1

558 (edited by sarami 2014-12-21 07:17:51)

I can't say without log. And /rc option is supported RingPROTECH, safedisc now.

Logs: https://www.dropbox.com/s/xny33n13yk9de … e.zip?dl=0

It seems to create a bin, img. What's the problem?
And is this really securom4+? This disc includes CMS16.DLL, CMS32_95.DLL, CMS32_NT.DLL
I think that these file exist in old securom (probably ver1 - ver3).

561 (edited by MrX_Cuci 2014-12-26 10:50:17)

Could be, I'll have to check to make certain.

CDMage reports multiple errors with DIC dump instead of just one. Isobuster, CloneCD dump reports only one error.

EDIT: It's Securom old indeed. http://www.encrypt.ro/cd-encryption/cd- … curom.html The three files exist when installed.

562 (edited by sarami 2015-01-09 12:00:23)

MrX_Cuci wrote:

CDMage reports

I see.
LiveWire_EdcEcc.txt

Number of sector(s) where user data doesn't match the expected ECC/EDC: 4
    Sector: 40947, 41073, 42711, 42837, 

I don't know why these sector doesn't match the expected ECC/EDC

EDIT:
Fixed PathTableRecord, DirectoryRecord

Does DIC autogenerates the sectors wrong in certain cases? http://redump.org/disc/8709/

DIC:

FF FF FF FF FF FF FF FF FF FF FF FF 01 13 01 00 54 40 00 27 51 39 57 2C 
FF FF FF FF FF FF FF FF FF FF FF FF 01 13 01 00 54 41 00 27 51 40 12 C3 
FF FF FF FF FF FF FF FF FF FF FF FF 01 13 01 00 54 42 00 27 51 41 EC 30 
FF FF FF FF FF FF FF FF FF FF FF FF 02 00 00 00 00 00 00 00 00 42 49 F3 
FF FF FF FF FF FF FF FF FF FF FF FF 01 14 00 00 01 71 00 27 51 43 EB A3 
FF FF FF FF FF FF FF FF FF FF FF FF 01 14 00 00 01 70 00 27 51 44 31 15 
FF FF FF FF FF FF FF FF FF FF FF FF 01 14 00 00 01 69 00 27 51 45 8D 12

Disc:

FF FF FF FF FF FF FF FF FF FF FF FF 01 13 01 00 54 40 00 27 51 39 57 2C
FF FF FF FF FF FF FF FF FF FF FF FF 01 13 01 00 54 41 00 27 51 40 12 C3
FF FF FF FF FF FF FF FF FF FF FF FF 01 14 00 00 01 73 00 27 51 41 8F 62
FF FF FF FF FF FF FF FF FF FF FF FF 02 00 00 00 00 00 00 00 00 42 49 F3
FF FF FF FF FF FF FF FF FF FF FF FF 01 14 00 00 01 71 00 27 51 43 EB A3
FF FF FF FF FF FF FF FF FF FF FF FF 01 14 00 00 01 70 00 27 51 44 31 15
FF FF FF FF FF FF FF FF FF FF FF FF 01 14 00 00 01 69 00 27 51 45 8D 12

As you see, DIC generated the sector wrong, this affected the gap. Other dumping tools don't have any problems.
Shouldn't it read all the sectors as is before fixing, without imagining things?

https://www.sendspace.com/file/z9pw7q - logs and sub

564 (edited by sarami 2015-01-10 21:56:19)

Could you test the latest test version? I have already found the same problem with a diff disc[Midtown Madness (Japan)] and already fixed.

The dump was by GreyFox, will ask him to test again. Same problem with http://redump.org/disc/29126/ (Track 16 pregap, the sector before EAN was altered), also was dumped by him.

The latest beta does crash for me (Win 8.1 64bit and PX-708A) with the following command:

DiscImageCreator.exe cd D filename 4 /c2

Output goes until "Reading lead-out: OK" then it hangs a little and then crashes.

Also: Would it be possible to create betas for x86 and x64?

Could you upload the log and tell me the disc title (with region)?

It is this disc: http://redump.org/disc/327/
Dumps fine with last full release from october. Some beta before the latest (it was from december I think) had an infinite hang but no crash yet (also after the lead-out: OK message).

Attached are all files that were created by DIC.

Post's attachments

crash.7z 8.84 kb, 18 downloads since 2015-01-16 

You don't have the permssions to download the attachments of this post.

http://redump.org/disc/29009/ -- https://www.sendspace.com/file/mn4fu1
8 tracks have incorrect gaps, subchannel is _heavily_ altered, gaps for tracks 5 and 7 are completely wrong, not the same bug as above. Dump was taken using the same version as before, also by GreyFox, but maybe you could take a look at the logs, whether it was fixed in the latest one or not?

The latest beta does crash for me

subchannel is _heavily_ altered, gaps for tracks 5 and 7 are completely wrong

Uploaded. Could you test, please.

Crash is fixed. Thank you. smile

https://www.sendspace.com/file/763hcq -- incorrectly detected CD+G for http://redump.org/disc/34033/ (channel T is filled with 0xFF). There are many discs, where the whole R-W area is padded with 0xFF, will DIC also detect them as CD+G?

573 (edited by sarami 2015-01-28 06:31:57)

Thank's report.
Uploaded
- added: If any of R-W area is padded with 0xff, detect it.
- fixed: cue file for CDTEXT

(channel T is filled with 0xFF). There are many discs

Could you tell me these many discs? Because I don't have a channel T filled disc.

sarami wrote:

Could you tell me these many discs? Because I don't have a channel T filled disc.

I've said "There are many discs, where the whole R-W area is padded with 0xFF" -- many PC games are like that, Nexy and Jackal should know more about them. MrX_Cuci and pablo also reported about these before - http://forum.redump.org/post/47284/#p47284

It seems that "MASTERED BY MAYKING" ones have the channel T filled.

sarami wrote:

- added: If any of R-W area is padded with 0xff, detect it.

Maybe it's better to detect any padding, not only 0xff? If 10 or 11 bytes out of 12 for 1 subchannel are the same = padding. Like, channel T: 08 08 08 08 09 08 08 08 08 08 08 09 => 10 bytes are 08 and 2 bytes are 09 => padded with 0x08. Subdump works this way, btw (if more than 7 bytes out of 12 are the same, it tries to reread the rest).

F1ReB4LL wrote:

I've said "There are many discs, where the whole R-W area is padded with 0xFF"

Oh sorry, I misunderstood. I have already whole R-W area is padded with 0xFF disc.

F1ReB4LL wrote:

Maybe it's better to detect any padding, not only 0xff? If 10 or 11 bytes out of 12 for 1 subchannel are the same = padding. Like, channel T: 08 08 08 08 09 08 08 08 08 08 08 09 => 10 bytes are 08 and 2 bytes are 09 => padded with 0x08.

I haven't supposed these data at the moment. If possible, please give me all subfiles that you perceive these data "padding".