26

(3,521 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.

27

(3,521 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

28

(3,521 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

29

(3,521 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.

30

(3,521 replies, posted in General discussion)

shfil wrote:

So only PX-W1210TS is supported?

Yes.

31

(3,521 replies, posted in General discussion)

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

32

(3,521 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.

33

(3,521 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.

34

(3,521 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.

35

(3,521 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?

36

(3,521 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?

37

(3,521 replies, posted in General discussion)

Nemok wrote:

- hashes (with duplicated sectors inserted into the disc image)

You dumped http://redump.org/disc/34669/ . How did you get the hashes with duplicated sectors inserted into the disc image?

38

(3,521 replies, posted in General discussion)

Nemok wrote:

The issue is fixed. Thanks sarami.

Thanks several testing.

Nemok wrote:

What is the current state of Tages support ?

The github page mentions that DIC "can read in reverse, but specifications are not decided".

I don't know how redump.org stipulates that twin sectors be preserved.

Nemok wrote:

The associated command seems to have been "/r" at one point, as found here: http://wiki.redump.org/index.php?title= … f_Commands, but is not recognized anymore.

Latest commands list is here. https://github.com/saramibreak/DiscImag … nd-options

39

(3,521 replies, posted in General discussion)

Uploaded.
https://github.com/saramibreak/DiscImag … 1847278623

40

(3,521 replies, posted in General discussion)

Nemok wrote:

Same behavior unfortunately, though the error has changed a little :

I tried some mixed mode disc, but it's no problem. Could you upload the logs?

41

(3,521 replies, posted in General discussion)

Nemok wrote:

The program gets further but fails at checking subQ address for each track :

Uploaded.
https://github.com/saramibreak/DiscImag … 1844517155

42

(3,521 replies, posted in General discussion)

Nemok wrote:

Also discovered today :

Uploaded.
https://github.com/saramibreak/DiscImag … 1842949631

43

(3,521 replies, posted in General discussion)

Nemok wrote:

How to explain this ? Were previous DIC releases wrong about it ?

See subError.txt. Subchannel are all zero bytes.

LBA[000000, 0000000]: Track[01]: SubQ Reread [crc16 unmatch] -> NG. Fix manually
========== LBA[000000, 0000000]: Sub Channel ==========
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
    P 00 00 00 00 00 00 00 00 00 00 00 00
    Q 00 00 00 00 00 00 00 00 00 00 00 00
    R 00 00 00 00 00 00 00 00 00 00 00 00
    S 00 00 00 00 00 00 00 00 00 00 00 00
    T 00 00 00 00 00 00 00 00 00 00 00 00
    U 00 00 00 00 00 00 00 00 00 00 00 00
    V 00 00 00 00 00 00 00 00 00 00 00 00
    W 00 00 00 00 00 00 00 00 00 00 00 00
LBA[000000, 0000000]: Track[01]: SubQ crc16 is 0. Main-channel may be corrupt
LBA[000000, 0000000]: Track[01]: SubQ[12]:Adr[0] -> [0x01]
LBA[000000, 0000000]: Track[01]: SubQ[13]:PrevTrackNum[01] -> [00]
LBA[000000, 0000000]: Track[01]: SubQ[19-21]:PrevAbs[149, 00:01:74], Abs[0, 00:00:00] -> [150, 00:02:00]
LBA[000000, 0000000]: Track[01]: SubQ[22]:CrcHigh[0000] -> [0xf6]
LBA[000000, 0000000]: Track[01]: SubQ[23]:CrcLow[0000] -> [0xd8]
LBA[000001, 0x00001]: Track[01]: SubQ Reread [crc16 unmatch] -> NG. Fix manually
========== LBA[000001, 0x00001]: Sub Channel ==========
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
    P 00 00 00 00 00 00 00 00 00 00 00 00
    Q 00 00 00 00 00 00 00 00 00 00 00 00
    R 00 00 00 00 00 00 00 00 00 00 00 00
    S 00 00 00 00 00 00 00 00 00 00 00 00
    T 00 00 00 00 00 00 00 00 00 00 00 00
    U 00 00 00 00 00 00 00 00 00 00 00 00
    V 00 00 00 00 00 00 00 00 00 00 00 00
    W 00 00 00 00 00 00 00 00 00 00 00 00
LBA[000001, 0x00001]: Track[01]: SubQ crc16 is 0. Main-channel may be corrupt
LBA[000001, 0x00001]: Track[01]: SubQ[12]:Adr[0] -> [0x01]
LBA[000001, 0x00001]: Track[01]: SubQ[15-17]:PrevRel[0, 00:00:00], Rel[0, 00:00:00] -> [-1, 00:00:255], [L:1421]
LBA[000001, 0x00001]: Track[01]: SubQ[19-21]:PrevAbs[150, 00:02:00], Abs[0, 00:00:00] -> [151, 00:02:01]
LBA[000001, 0x00001]: Track[01]: SubQ[22]:CrcHigh[0000] -> [0xe3]
LBA[000001, 0x00001]: Track[01]: SubQ[23]:CrcLow[0000] -> [0x24]
LBA[000002, 0x00002]: Track[01]: SubQ Reread [crc16 unmatch] -> NG. Fix manually
========== LBA[000002, 0x00002]: Sub Channel ==========
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
    P 00 00 00 00 00 00 00 00 00 00 00 00
    Q 00 00 00 00 00 00 00 00 00 00 00 00
    R 00 00 00 00 00 00 00 00 00 00 00 00
    S 00 00 00 00 00 00 00 00 00 00 00 00
    T 00 00 00 00 00 00 00 00 00 00 00 00
    U 00 00 00 00 00 00 00 00 00 00 00 00
    V 00 00 00 00 00 00 00 00 00 00 00 00
    W 00 00 00 00 00 00 00 00 00 00 00 00
LBA[000002, 0x00002]: Track[01]: SubQ crc16 is 0. Main-channel may be corrupt
LBA[000002, 0x00002]: Track[01]: SubQ[12]:Adr[0] -> [0x01]
LBA[000002, 0x00002]: Track[01]: SubQ[15-17]:PrevRel[-1, 00:00:255], Rel[0, 00:00:00] -> [-2, 00:00:254], [L:1421]
LBA[000002, 0x00002]: Track[01]: SubQ[19-21]:PrevAbs[151, 00:02:01], Abs[0, 00:00:00] -> [152, 00:02:02]
LBA[000002, 0x00002]: Track[01]: SubQ[22]:CrcHigh[0000] -> [0x79]
LBA[000002, 0x00002]: Track[01]: SubQ[23]:CrcLow[0000] -> [0x16]
LBA[000003, 0x00003]: Track[01]: SubQ Reread [crc16 unmatch] -> NG. Fix manually

44

(3,521 replies, posted in General discussion)

Nemok wrote:

Pack mode without /c2 is still broken.

It's not broken. LG/ASUS does not support the pack mode.

45

(3,521 replies, posted in General discussion)

@Nemok, Lugamo
Thanks. I fixed it. https://github.com/saramibreak/DiscImag … issues/254

46

(3,521 replies, posted in General discussion)

https://github.com/saramibreak/DiscImag … g/20231201
*2023-12-01
- added support non-plextor and non-lg/asus drive when data/audio command is used (but some drive failed to dump. e.g. SH-216BB)
- added again -D option in install command of makefile for linux
- added parsing PS3_DISC.SFB and PS3UPDAT.PUP
- added detecting protection (DUMMY.ZIP)
- added a flag indicating readable the lead-out sector (Using ASMedia SATA controller and linux, 0xF1 drive can read the lead-out sector using 0xbe)
- added checking if export, import, resource size are correct
- changed if sync or msf or mode is invalid, it skips descrambling
- changed EXELBA_STORE_SIZE
- fixed /be option
- fixed error sector reading
- fixed reading the multiple PARAM.SFO
- fixed reading PARAM.SFO
- fixed the crash when cab file was extracted
- fixed division by zero
- fixed DEBUG build error
- Updated driveOffset.txt

47

(53 replies, posted in General discussion)

https://github.com/saramibreak/UmdImage … s/tag/v1.6
## v1.6 (2023-12-01)
- added: support to dump PFI.bin

48

(53 replies, posted in General discussion)

https://www.mediafire.com/file/905y99zq … st.7z/file
Added: support to dump PFI.bin

49

(53 replies, posted in General discussion)

Edness wrote:

On PS2 the (DNAS) Disc ID is also 5 bytes long. 

Edness wrote:

PS3's Disc ID being 16 bytes long

How do we get it?

50

(53 replies, posted in General discussion)

unsigned char bufSPK[0x4000] = {};
void* p1 = _sceUmdManSPKGetMKI();
memcpy(bufSPK, p1, 0x4000);

It crashed by memcpy.

Edness wrote:

Normally it's supposed to just be a separate 5 byte buffer that's passed to the ReadMKI function anyway, so I'm not expecting much to be written there.

5 bytes = 40 bits. DVD has 40 bits key of CSS, so I've expected that UMD also has some kind of 40 bits key (media key?).

SPK is SPecial Key? SPecific Key?