1

(3,497 replies, posted in General discussion)

Try to use 20240401 version.
https://github.com/saramibreak/DiscImag … g/20240401

"R2C" is different version because file size is different. "R1C" is 417971568, "R2C" is 417969216.

StriderSkorpion wrote:

I mean DIC and redumper had the same results. In both cases, my tracks 22 and 23 are different than the database.

Oh, sorry. Your dump is correct (DB is incorrect). Correct sector size of the track 22 is 1274, and track 23 is 1667.

StriderSkorpion wrote:

The main difference is that track 22 of this one is smaller by 1 sector/2352 bytes than the one on Redump while track 23 is larger by that same amount.

Same issue.
http://forum.redump.org/topic/53719/whi … ct-pregap/

5

(3,497 replies, posted in General discussion)

https://github.com/saramibreak/DiscImag … g/20240401
*2024-04-01
- added output HFS Catalog Files
- added RegenerateToc for dumping CD-i format with multi-track disc
- changed the descrambling range
-- support "audio track, data sector, there is a sync"
-- re-support descrambling the sector that bit 7 .. 5 of the mode byte is used
- changed "subs control" and "subs indexes" to "subs desync"
- changed the control flag of the cue file, it prefers TOC
- changed checking CD+G sector
- fixed to dump the pregap file
- fixed fail to dump GD-ROM
- fixed dumping audio disc (and CD-i Ready) when ASUS BW-16D1HT 3.02 is used
- fixed dumping of the CD-i format with CD-DA
- fixed HFS time
- fixed UDF log

6

(3,497 replies, posted in General discussion)

hkkane wrote:

both doesn't show SecuROM in Copy Protection,

MPF problem? I'm not sure. Try to use old version. https://github.com/SabreTools/MPF/releases

7

(3,497 replies, posted in General discussion)

hkkane wrote:

Why DIC doesn't show SecuROM in Copy Protection section?

Would you upload DIC logs?

8

(3,497 replies, posted in General discussion)

Uploaded test version.
Windows: https://www.mediafire.com/file/eq80y20l … st.7z/file
Linux: https://www.mediafire.com/file/uw3e03kd … ar.gz/file
- changed the descrambling range.
-- support "audio track, data sector, there is a sync" http://forum.redump.org/topic/53678/dis … scrambled/
-- re-support descrambling the sector that bit 7 .. 5 of the mode byte is used. https://github.com/saramibreak/DiscImag … issues/269
- changed "subs control" and "subs indexes" to "subs desync".
-- changed the control flag of the cue file, it prefers TOC. https://github.com/saramibreak/DiscImag … issues/268

bikerspade wrote:

LBA[000000, 0000000]: [F:ReadCDForCheckingSubQ1stIndex][L:974]
    Opcode: 0xbe
    ScsiStatus: 0x02 = CHECK_CONDITION
    SenseData Key-Asc-Ascq: 03-11-05 = MEDIUM_ERROR - L-EC UNCORRECTABLE ERROR
lpCmd: be, 00, 00, 00, 00, 00, 00, 00, 01, f8, 01, 00
dwBufSize: 2448

It's called when dumps the disc that pregap exists in the track 1.

EDIT (2024-03-10)
fixed failed to descramble of the multi-session disc with test version.
EDIT (2024-03-18)
fixed failed to dump GD-ROM with test version.

fuzzball wrote:

Which is the correct pregap?

DIC is correct. In this case, sub P-channel also needs to refer.

10

(3,497 replies, posted in General discussion)

added RegenerateToc for dumping CD-i format with multi-track disc
https://www.mediafire.com/file/eq80y20l … st.7z/file

bikerspade wrote:

It works with build 20230606, so there was a regression at some point afterwards.

Would you try to dump these discs and see if you get the same error?
1. Audio only disc.
2. Data only disc.
3. Data + Audio disc.

11

(3,497 replies, posted in General discussion)

bikerspade wrote:

I saw something odd

Added: show the error message.
Fixed: failed to dump audio disc (and CD-i Ready) when ASUS BW-16D1HT 3.02 is used.
https://www.mediafire.com/file/eq80y20l … st.7z/file

bikerspade wrote:

the following error is produced

3.02 did not occur. 3.10 mod only? I'm not sure.

I asked a similar issue to F1ReB4LL in the past.

F1ReB4LL wrote:
sarami wrote:

Some PC Engine CD have 00:02:74 pregap in track 02 (e.g. http://redump.org/disc/40354/).
These 1st 75 pregaps have "audio" flag in sub Qchannel.

LBA[003434, 0x00d6a]: P[ff], Q[01020000020500004759a14d]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[02], Idx[00], RMSF[00:02:05], AMSF[00:47:59]}, RtoW[0, 0, 0, 0]
LBA[003435, 0x00d6b]: P[ff], Q[01020000020400004760ac66]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[02], Idx[00], RMSF[00:02:04], AMSF[00:47:60]}, RtoW[0, 0, 0, 0]
LBA[003436, 0x00d6c]: P[ff], Q[01020000020300004761db93]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[02], Idx[00], RMSF[00:02:03], AMSF[00:47:61]}, RtoW[0, 0, 0, 0]
LBA[003437, 0x00d6d]: P[ff], Q[0102000002020000476241a1]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[02], Idx[00], RMSF[00:02:02], AMSF[00:47:62]}, RtoW[0, 0, 0, 0]
LBA[003438, 0x00d6e]: P[ff], Q[01020000020100004763bf52]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[02], Idx[00], RMSF[00:02:01], AMSF[00:47:63]}, RtoW[0, 0, 0, 0]
LBA[003439, 0x00d6f]: P[ff], Q[0102000002000000476465e4]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[02], Idx[00], RMSF[00:02:00], AMSF[00:47:64]}, RtoW[0, 0, 0, 0]
LBA[003440, 0x00d70]: P[ff], Q[010200000174000047652fa5]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[02], Idx[00], RMSF[00:01:74], AMSF[00:47:65]}, RtoW[0, 0, 0, 0]
LBA[003441, 0x00d71]: P[ff], Q[410200000173000047660a08]{ Data,      Copy NG,                  Track[02], Idx[00], RMSF[00:01:73], AMSF[00:47:66]}, RtoW[0, 0, 0, 0]
LBA[003442, 0x00d72]: P[ff], Q[41020000017200004767b078]{ Data,      Copy NG,                  Track[02], Idx[00], RMSF[00:01:72], AMSF[00:47:67]}, RtoW[0, 0, 0, 0]
LBA[003443, 0x00d73]: P[ff], Q[41020000017100004768af45]{ Data,      Copy NG,                  Track[02], Idx[00], RMSF[00:01:71], AMSF[00:47:68]}, RtoW[0, 0, 0, 0]
LBA[003444, 0x00d74]: P[ff], Q[410200000170000047691535]{ Data,      Copy NG,                  Track[02], Idx[00], RMSF[00:01:70], AMSF[00:47:69]}, RtoW[0, 0, 0, 0]
LBA[003445, 0x00d75]: P[ff], Q[410200000169000047703a0b]{ Data,      Copy NG,                  Track[02], Idx[00], RMSF[00:01:69], AMSF[00:47:70]}, RtoW[0, 0, 0, 0]

These "audio" sectors should not be descrambled? LBA 3440 have sync, msf and mode, but it's audio in sub Q.

If to follow the red/yellow book standard, the first second (75 sectors) has the same mode as the previous track, should be left scrambled, the rest of pregap (150 sectors) - descrambled. But due to some kind of a mastering error the first second is 74 sectors, not 75, I guess? So the 74 sectors should be left as is and the next 150 sectors descrambled, I think.
If to follow the TOC logic (next track starts at index 01 and index 00 belongs to the previous track) - the entire pregap should be left scrambled.
If to follow the sub logic (next track starts at index 00) - all the pregap sectors should be descrambled if possible.

So, probably it is better to descramble those.

The above case is that track 1 is audio, track 2 is data. But in case of "CD-i / Video CD Titel-Neuheiten II/95", track 1 is data, track 2 is audio.
Then, if to follow the red/yellow book standard, the first second (75 sectors) has the same mode as the previous track, should be descrambled, the rest of pregap (150 sectors) - left scrambled.
If to follow the TOC logic (next track starts at index 01 and index 00 belongs to the previous track) - the entire pregap should be descrambled.
If to follow the sub logic (next track starts at index 00) - all the pregap sectors should be left scrambled if possible.

So, probably it is better to left scrambled those.

13

(3,497 replies, posted in General discussion)

Retry to dump using /c2. I confirmed that DIC-generated .sub (also CloneCD .sub) works by the other CD+G supported player (https://www.vector.co.jp/download/file/ … 27763.html). ares --- I don't know how to read the ccd-img-sub format.

14

(3,497 replies, posted in General discussion)

Uploaded test version. https://www.mediafire.com/file/eq80y20l … st.7z/file

15

(3,497 replies, posted in General discussion)

bikerspade wrote:

Do you know if DiscImageCreator is stripping out subcode channels R through W in the .sub file?
I recently dumped a CD+G disc with both CloneCD and DiscImageCreator. Testing the ccd/img/sub produced by CloneCD on my Sega Saturn produces the graphics I expect. With the ccd/img/sub produced by DiscImageCreator, it does not produce any graphics whatsoever, as though it was a plain audio CD.

Pack mode sub is needed.

    struct _PLXTR_READ_CDDA {
        enum _SUB_CHANNEL_SELECTION {
            NoSub = 0,
            MainQ = 1,        // Main data + Formatted Q sub-channel data
            MainPack = 2,    // Main data + Raw P-Q + Corrected and de-interleaved R-W sub-channel data
            Raw = 3,        // Raw P-W sub-channel data
            MainC2Raw = 8    // Main data + C2 error data + Raw P-W sub-channel data
                            // 4 to 7, 9 to 255 is reserved
        } SUB_CHANNEL_SELECTION, *PSUB_CHANNEL_SELECTION;
    } PLXTR_READ_CDDA, *PPLXTR_READ_CDDA;

Without /c2, you can get the pack mode sub.

16

(3,497 replies, posted in General discussion)

https://github.com/saramibreak/DiscImag … g/20240101
*2024-01-01
- added /t option in the data command for Tages
- fixed fail to dump blu-ray disc except for PS3 (2023-12-01 version bug)
- fixed incorrect Enhanced CD data track (2023-12-01 version bug)
- fixed error handling for merge command
- fixed fail to dump when LG/ASUS drive is used (2023-12-01 version bug)
- fixed parsing PS3UPDAT.PUP (2023-12-01 version bug)
- fixed access outside the array range

17

(3,497 replies, posted in General discussion)

@shfil
Please use this drive rather than those older drives first.

DVD model: PX-760, PX-755, PX-716, PX-714, PX-712, PX-708, PX-704
CD model: Premium2, Premium, PX-W5224, PX-4824, PX-4012

18

(3,497 replies, posted in General discussion)

Nemok wrote:

Is /f usage in /t mandatory ?

No, it's using by default.

Nemok wrote:

_BackToForward.bin
     100127CD, B031FD66, C2DCFD82, 19D8C363, 19D8C363, CF7778EF

Nemok wrote:

_BackToForward.bin
     3095FB60, 3095FB60, 3095FB60, 350C16A4, EEB2A8E7, 3095FB60

I tried MotoRacer 3 (USA) and found that 1st and 2nd twin sector was hard to read, thus it's difficult to get the identical hash.

Nemok wrote:

NB: the error right after the first reread is :

Yes, it often occurs.

19

(3,497 replies, posted in General discussion)

shfil wrote:

So only PX-W1210TS is supported?

Yes.

20

(3,497 replies, posted in General discussion)

Uploaded test version for Tages.
https://github.com/saramibreak/DiscImag … 1858835085

21

(3,497 replies, posted in General discussion)

Nemok wrote:

- 251 twin sectors in 287922-288174 with the 2 last sectors all 0x55
- 251 twin sectors in 287922-288180 with the 8 last sectors all 0x55 or invalid mode
Backwards reading hashing for range B sectors
- no identical CRC-32 found
- hashes inconsistency is not reliable enough to help detect the range of twin sectors

Thanks test. As Jackal says, it needs to reread each sector until the twin sector is obtained.

22

(3,497 replies, posted in General discussion)

I found the explanation at CDFreaks. https://web.archive.org/web/20070615215 … es-blunder

And Jackass writes the memo in the uploaded file.

Notes:
------

I have successfully used this utility to backup XIII CD's 2, 3, and 4
Please see my other program BGEScan if you wish to backup Beyond Good and Evil CD3

You might like to try the following data

Title        Sector Start    Sector End
------------------------------------------
XIII CD2    281170        281424
XIII CD3    274371        274625
XIII CD4    287915        288169

I'm not sure these ranges are correct.

Nemok wrote:

Then narrowing the suspected range to 287500-288500 since:
- 287000-287500 always gives D7F637B0
- 288500-289000 always gives BB08138A

If these sectors matches the forward-sectors, it's not tages sectors.

23

(3,497 replies, posted in General discussion)

PLEXTOR can get the identical hash when uses /f (cache delete), but sometimes returns non-identical hash.
ASUS can't get the identical hash even if uses /f.

24

(3,497 replies, posted in General discussion)

I tried to dump at several time from 329687-329947 using /r
1. CRC32: 26F4EEC3 (ASUS)
2. CRC32: 200728C2 (ASUS)
3. CRC32: 0F5D94C2 (ASUS)
4. CRC32: 5DFECCCA (PLEXTOR)
5. CRC32: 3779DF3B (PLEXTOR)

These are always different hashes. Did Jackal really obtain identical hashes?

25

(3,497 replies, posted in General discussion)

Nemok wrote:

That's why I wanted to try "/r".

"/r" generates only the forward-image using backward reading.

I dumped Moto Racer 3 (USA) http://redump.org/disc/31578/ with /r. As a result, I found it that 329693 ... 329946 are different sectors. But Jackal says "Disc has 260 twin sectors in range 329687-329947".

Question: Twin sectors of the Tages are always 260 sectors? If yes, where is the evidence to show that it is correct?