DiscImageCreator (Page 56 of 141)

Are you still here? Any chance for TOC & 1st track pregap dumps?

I checked the lead-in/out and pregap of 1st track once more.

Plextor
lead-in: part (about 1900 sectors)
pregap: all (150 sectors)
lead-out: part (100 sectors)

Lite-on (LH-18Axx, LH-20Axx, DH-20Axx)
lead-in: no
pregap: part (142 sectors)
lead-out: all (6750 sectors)

----
About lead-in:
As I told you, the lead-in can read using READ_TOC(0x43). Not only plextor but all drives can preserve it as the raw binary file like xbox preserves SS.bin, PFI.bin and DMI.bin.

I understand reading is random, but even if reads the disc how many times, it is about 1900 that can get the sectors.

We also need to determine how many sectors preserve because it is impossible to read all lead-in sectors.

Yes. It is valid if you permit not to preserve the main channel. (But I know you don't permit it.)

Yes Lead-out sectors/area exist upto the end of the disc, but acutually recorded data in the lead-out is 6750 (90 sec) + α sectors.

Why α?  http://www.itmedia.co.jp/news/0203/13/cdswhy_2.html

リードアウトは2分といわれていますが、実際の規格は1分36秒で、残りの24秒はマスター情報領域（PMCD）です。しかし、最近のドライブは1分36秒か、もっと短いものが増えている。

But
https://kotobank.jp/word/%E3%83%AA%E3%8 … 83%88-9710
http://yougo.ascii.jp/caltar/%E3%83%AA% … 6%E3%83%88

リードアウト領域には、90秒間の無音データが記録される。

https://astamuse.com/ja/published/JP/No/2001093150

第１セッションのリードアウト領域の長さは１分３０秒と定められている。

I don't know which of 90 sec and 96 sec is correct, but I know almost all drives can't read lead-out and Lite-on can read 6750 sectors.

I think subdump's logic is better/best, but it takes subdump very long time to dump the sub, so I can't use it. (In the first place, I don't know the subdump's logic because this is not open-source.)

How should the subs error correction work, IMO:

1. You define 9 variables: SubRereadNum, CurrentSubReadNum, CurrentSectorNum, FixLevel, QCurrentSector, QNextSector, QGenSector, QEAN, QISRC.
2. From commandline args you read FixLevel (should be between 0 and 96) and SubRereadNum (0 or larger)
3. You read a sector with the LBA = CurrentSectorNum (0 by default) and put its Q-channel into QCurrentSector.
3.1. If QNextSector is null: you read a sector with LBA = CurrentSectorNum + 1, check its Mode (should be 0x01) and Q-CRC and put its Q-channel into QNextSector.
     If Q-CRC is bad or Mode != 1, you read a sector with LBA = CurrentSectorNum + 2, check its Mode and Q-CRC, if both are fine, you substract 1 frame from MSF and AMSF (MSF - 1 and AMSF - 1), fix Q-CRC and write that into Q-NextSector.
     If Q-CRC is bad again or Mode != 1, you read a sector with LBA = CurrentSectorNum + 3, etc.
4. If Q-CRC of QCurrentSector matches, go to p.5.
4.1. If Q-CRC of QCurrentSector doesn't match: QGenSector = QNextSector - 1 frame (MSF - 1, AMSF - 1, fix Q-CRC).
4.2. You do a binary compare (96 bits vs 96 bits) between QCurrentSector and QGenSector and count a number of bits that differ. If their count is <= FixLevel: QCurrentSector = QGenSector and go to p.5.
4.3. If QEAN != null, you do a binary compare between QCurrentSector and QEAN and count a number of bits that differ. If their count is <= FixLevel: QCurrentSector = QEAN and go to p.5.
4.4. If QISRC != null, you do a binary compare between QCurrentSector and QISRC and count a number bits that differ. If their count is <= FixLevel: QCurrentSector = QISRC and go to p.5.
4.5. If still not matched and CurrentSubReadNum < SubRereadNum: clear the drive's cache and go to p.3
5. Write QCurrentSector to the .sub
5.1. If Q-CRC is bad: QNextSector = QNextSector + 1 frame (add + 1 to MSF, add + 1 to AMSF, fix Q-CRC)
5.2. If Q-CRC is good and QCurrentSector mode = 0x01: QNextSector = QCurrentSector + 1 frame
5.3. If Q-CRC is good and QCurrentSector mode = 0x02 (EAN): QEAN = QCurrentSector and QNextSector = QNextSector + 1 frame
5.4. If Q-CRC is good and QCurrentSector mode = 0x03 (ISRC): QISRC = QCurrentSector and QNextSector = QNextSector + 1 frame
5.5. CurrentSectorNum = CurrentSectorNum + 1, CurrentSubReadNum = 0

This way you let users to decide, how many bits are fine to be fixed and how many times it's ok to reread. Don't forget to clear the drive's cache before each rereading, otherwise, you may get the same results every time.

Maybe so.

Even if it is so, it is enough in 90 sec to preserve lead-out. If there are some data except empty and shifted data in lead-out, it's not already lead-out.
Saturn ring, I don't know the detail. At least, this ring can't be read unless someone hacks sega saturn.

https://en.wikipedia.org/wiki/PMCD
http://www.riaj.or.jp/f/pdf/issue/ris/ris105.pdf
http://plexmaster.web.fc2.com/
https://av.watch.impress.co.jp/docs/20020603/dal56.htm
This is the old specification that only Japan? use.

I'll refer to it.

Hi, I am trying to dump an IBM PC game with a Plextor PX-W4824TU and am getting this error:

[L:1149] Internal error. Failed to analyze the subchannel. Track[55]/[61]

Tried DIC test version 20180529 twice & version 20180127 one. Both get the same error.

Here is the complete DIC cmd window:

D:\ReDump\Tomb Raider II (Rayovac)>DiscImageCreator.exe cd K: "Tomb Raider II (Rayovac).bin" 2 /sf /c2 3 /d8 /ns /s 2
AppVersion
        x86, AnsiBuild, May 29 2018 00:58:45
/sf val is omitted. set [60]
/c2 val2 is omitted. set [0]
CurrentDirectory
        D:\ReDump\Tomb Raider II (Rayovac)
WorkingPath
         Argument: Tomb Raider II (Rayovac).bin
         FullPath: D:\ReDump\Tomb Raider II (Rayovac)\Tomb Raider II (Rayovac)
            Drive: D:
        Directory: \ReDump\Tomb Raider II (Rayovac)\
         Filename: Tomb Raider II (Rayovac)
        Extension: .bin
Start time: 2018-05-29(Tue) 17:57:35
Set the drive speed: 0KB/sec
This drive supports [OpCode: 0xd8, SubCode: 0]
This drive supports [OpCode: 0xd8, SubCode: 1]
This drive supports [OpCode: 0xd8, SubCode: 2]
This drive supports [OpCode: 0xd8, SubCode: 8]
Checking reading lead-out -> OK
Checking SubQ adr (Track) 61/61
Checking SubRtoW (Track) 61/61
Reading DirectoryRecord   11/  11
Checking EXE  113
[INFO] Protection can't be detected. /sf, /ss is ignored.
Set OpCode: 0xd8, SubCode: 8(Raw)
SecuROM sector not found
Checking SubQ ctl (Track) 61/61
Creating .scm (LBA) 329840/329840
[L:1149] Internal error. Failed to analyze the subchannel. Track[55]/[61]
End time: 2018-05-29(Tue) 18:18:29

D:\ReDump\Tomb Raider II (Rayovac)>

All 3 created srm files have the same hash.

All 3 DIC logs: https://www.sendspace.com/file/oza1rb
Image of the Disc: https://my.mixtape.moe/yngisl.jpg
Image of the sleeve the disc came in: https://my.mixtape.moe/jcckrg.jpg

http://forum.redump.org/topic/3367/sega-saturn-cp-talk/

The ring should be burned after lead-out, you can't burn session 1 + lead-out + ring properly with the normal CD-R recorder. You can hack the TOC, so the ring would be included into the session 1 or burned as session 2, but that would be wrong for unmodded Saturn. But you can get the same ring text graphics

I've also read that Saturn discs may have some wobble-encoded data near the ring, so it's possible that ring data only isn't enough to beat the protection.

Quick question... How to add more retries? 4000 is not enough. I want to try 10000 or more.

Thanks!

I have an idea... I recently got a disc and it's old CD-R. DIC shows hundreds of C2 errors so it requires lots and lots of retries. I now set up 100000 retries but dumping process already took about three hours. I think I might need several days with lots and lots of retries but it's not a good idea to keep the drive working several days. Already done a couple of sectors after 20000 retries...

Maybe it's possible to code an option to let you continue dumping process? Something like DIC checks log file and the dump and starts more retries if dumping process wasn't done.

Since I already done a couple of very hard sectors, it's not a good idea to stop dumping process but maybe even 100000 retries won't be enough...

Buggy drive with incorrect C2 errors handling, then. That's why EAC has a built-in testing for the C2 errors support.

I've had this happen before too. Eventually I was able to get a match for a rom found on the internet (and later someone verified my dump).

To recap: dumped a few different times with different checksums, no c2 errors after rereads. Disc was clearly scratched.