1,376 (edited by sarami 2018-05-27 10:01:39)

Some fixed.

 /ms

It works now, but the lead-in of 2nd session can't read.
If /ms isn't used, dic skips reading 6750+4500+150=11400 sectors.
(6750 [1min30sec] is the lead-out of 1st session . 4500 [1min] is the lead-in of 2nd session. 150 [2sec] is the pregap of 1st track of 2nd session.)

Hi First Thanks For Creating This Tools For Everyone smile
But I Have a Problem For This Tool, I Use Pioneer DVR-221L , Sony Optiarch AD-7260S
But This Drives Not Copy The My Orginal Ps1 Cd Program Says Cant Read Scrabled Mode
and says İllegal Requiest illegal mode this track
How Can I Copy This My Cd
I Use This Command ?
DiscImageCreator.exe cd E: foo.bin 8 /c2
Thanks For Help smile

1,378

rosewood wrote:

Sample 2:
[CDI] Philips CD-i/Video CD Titel-Neuheiten I/95 (818 0058)
2a. Good dump with 20171010
2b. No dump possible with 20171210

Sample 3 (impossible to dump with either version):
[CDI] Philips CD-i/Video CD Titel-Neuheiten II/95 (818 0089)
3a. No dump possible with 20171010

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

1,379

Dark Frost wrote:

How Can I Copy This My Cd

You either need to buy a specific drive that supports 0xD8 reading command or you can try to use the swapping - http://forum.redump.org/post/60603/#p60603

1,380

F1ReB4LL wrote:

And I've asked to add an automatic 1st pregap and TOC reading into DIC already, but you haven't added that yet

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.

1,381

Pregap/Lead-In sectors are read randomly, you can read the -5000...-1100 area a couple of times and get different sectors each time. I think, DIC needs a special mode to read that area a couple of times and reconstruct the whole lead-in sector-by-sector.

READ_TOC(0x43) doesn't output the data area, though, only subs sad

Dumping lead-out is interesting. Why "6750 sectors"? Lead-out sectors go upto the very end of the disc. If the main data area is small (a few megabytes), the lead-out would be 300 000+ sectors.

1,382

Pregap/Lead-In sectors are read randomly, you can read the -5000...-1100 area a couple of times and get different sectors each time.

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

He preserves the last TOC iteration only (around 10-20 sectors) and the pregap.

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

READ_TOC(0x43) doesn't output the data area, though, only subs

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

Lead-out sectors go upto the very end of the disc. If the main data area is small (a few megabytes), the lead-out would be 300 000+ sectors.

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

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

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 it should work another way, I'll try to describe it in the DIC thread.

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.)

1,383

I checked multi-session disc.

plextor (0xd8)
lead-out of 1st session: all (6750 / 6750 sectors)
lead-in of 2nd session: part (6 /4500 sectors)
pregap of 1st track of 2nd session: part (137 / 150 sectors)

plextor (0xbe)
lead-out of 1st session: all (6750 / 6750 sectors)
lead-in of 2nd session: part (6 / 4500 sectors)
pregap of 1st track of 2nd session: all (150 / 150 sectors)

1,384

sarami wrote:

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.

1,385

sarami wrote:
第1セッションのリードアウト領域の長さは1分30秒と定められている。

Maybe they mean the multisessional discs? And what is PMCD? All the sectors after the user area are marked as 0xAA in the subs and are either empty data or empty audio sectors, they go upto the very end of the disc (except the special cases with the data shifted into the lead-out area, Saturn rings that go after the leadout, etc.)

1,386

Maybe they mean the multisessional discs?

Maybe so.

All the sectors after the user area are marked as 0xAA in the subs and are either empty data or empty audio sectors, they go upto the very end of the disc

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.

PMCD

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.

How should the subs error correction work, IMO:

I'll refer to it.

1,387

sarami wrote:

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.

The key point is to preserve as much data as possible.

sarami wrote:

I'll refer to it.

Basically, that's how the subdump "-fix" option works. For each of the P, R, S, T, U, V, W channels you just need to detect the padding byte for the current sector (if more than 6 bytes are 0x00 - the padding byte is 0x00, if more than 6 bytes are 0xFF - the padding byte is 0xFF), then do a bit compare of the current sector against 000000000000000000000000 or FFFFFFFFFFFFFFFFFFFFFFFF or any other variant, if exists. If a number of mismatching bits is <=FixLevel: fix them, if >FixLevel: reread or skip. If the padding byte can't be detected - reread or skip, for R-W channels that could mean CD+G data.

sarami wrote:

Saturn ring, I don't know the detail. At least, this ring can't be read unless someone hacks sega saturn.

They can be read on any drive that supports swapping, similar to DC rings smile

You can even hack the TOC and burn them on CD-R and you will get the proper burned ring with the same SEGA text.

Post's attachments

ring.7z 197.18 kb, 4 downloads since 2018-05-30 

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

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

1,389

antimatter wrote:

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

Uploaded test version.

F1ReB4LL wrote:

They can be read on any drive that supports swapping

I confirmed getting the similar data. Scrambled data is almost all 0x59 or 0xa8.
If this is really data of the ring, does burned cd-r with this data works in sega saturn without hacking?

1,390

sarami wrote:

I confirmed getting the similar data. Scrambled data is almost all 0x59 or 0xa8.
If this is really data of the ring

- ring's main channel data, when unscrambled, reveals Sub-Header: 00 00 28 00 and EDC set to 0
Sub-Header Submode byte 28h translates into:
00101000b -> Data = 1, Form = 1 (Form2)
- when left scrambled, main channel user data form patterns consisting of A8h and 59h bytes.
those bytes yield somewhat opposite pit/land sequences:
59h producing long continuous runs, A8h - frequent changes
- when interleaved those patterns form visible inscription: 59h being background and A8h data,
with each revolution taking up exactly 21 sector.

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

sarami wrote:

does burned cd-r with this data works in sega saturn without hacking?

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 smile

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.

sarami wrote:
antimatter wrote:

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

Uploaded test version.

It worked, Thank You!

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

Just put 10000 after /c2.

Schrodinger wrote:

Just put 10000 after /c2.

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...

I had cases in the past that on some very scratched discs bad data in sector was returned even if there were no C2 errors...

1,396

reentrant wrote:

I had cases in the past that on some very scratched discs bad data in sector was returned even if there were no C2 errors...

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

It was Plextor 760A wink

1,398

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.

1,399

ok, cp-talk is difficult for me, but I understood the swap command of dic is effective when reads huge lead-out.

swap
---
1. Insert the audio trap disc to a supported drive.
:
:
6. When dumping finished, the drive tray open automatically.
7. The drive tray close automatically after 3000 msec.
8. Read TOC and img is descrambled automatically.

and I may add below.
9. If option(/74) is specified, reads lead-out till the specified time.

Btw, does subdump uses crc6 to fix subR-W of CD+G?

psx-collector wrote:

Maybe it's possible to code an option to let you continue dumping process?

I have worry about spreading the c2 existing image.

reentrant wrote:

some very scratched discs

user7 wrote:

Disc was clearly scratched

Why not polish the disc?

1,400

sarami wrote:
user7 wrote:

Disc was clearly scratched

Why not polish the disc?

The problem is that DIC was spitting out no C2 errors when some of the dumps were clearly bad...