Redump Forum

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

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.

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

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)

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.

sarami wrote:

Code: Select all

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

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

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.

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

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.

Hi, I am trying to dump an IBM PC game with a Plextor PX-W4824TU and am getting this error:
Tried DIC test version 20180529 twice & version 20180127 one. Both get the same error.

Here is the complete DIC cmd window:
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

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?

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.

/viewtopic.php?t=1913

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

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.