3,451 Reply by Nemok

  • Registered: 2023-03-03
  • Posts: 99

I'm a bit confused. I thought that :

- reading forwards was keeping twin #1 and ignoring twin #2 of each duplicated sector since disc drives were considering any repeated sector as erroneous, and so backwards was keeping twin #2 and ignoring twin #1 since twin #2 was read first this way.
- twin sectors were called twins for their identical headers while possibly containing totally different data thus making it possible to hide data in every twin #2.

If so, comparing forwards and backwards images can not reveal twins that happen to contain strictly identical data, if such cases exist. But I don't know that.

sarami wrote:

But Jackal says "Disc has 260 twin sectors in range 329687-329947".

About the principle of that range being larger than the range of sectors with differences you found, I guess it's still possible. But there's a mistake anyway since range 329687-329947 has 261 sectors, not 260...

sarami wrote:

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

"That is the question." Personally for now, I'm just curious about comparisons between forwards and backwards images for other Tages protected discs.

3,452 Reply by sarami

  • Registered: 2011-02-20
  • Posts: 1,734

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?

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

3,453 Reply by Nemok

  • Registered: 2023-03-03
  • Posts: 99

Jackal suggested that 'twindump' might help. I'll look for that program.

3,454 Reply by Jackal (edited by Jackal 2023-12-12 07:30:52)

  • Jackal
  • Moderator (Retired)
  • Online
  • Registered: 2006-12-23
  • Posts: 4,130

Nemok wrote:

But there's a mistake anyway since range 329687-329947 has 261 sectors, not 260...

Hi, I'm not sure what was the case here, but yeah mentioned range is 261.

How I remember it is that you need to end up with an x amount of sequential sectors that differ from the normal read sectors and they are correct with matching ECC/EDC.

If you are getting different results each time, then each of those ranges is either a mixture of normal + twin sectors or there may be corrupted/scrambled sectors. Guess you need to do this manually or make some automated tool that rereads each sector until the twin sector is obtained.

3,455 Reply by sarami

  • Registered: 2011-02-20
  • Posts: 1,734

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.

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

3,456 Reply by Nemok

  • Registered: 2023-03-03
  • Posts: 99

sarami wrote:

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.

Same thing with this disc: http://redump.org/disc/36124/ using this command: "data d: dump.bin 8 0 293587 /be raw /f /r".
A first error happened near the end of the disc where twin sectors are expected :

LBA[288180, 0x465b4]: [F:ProcessReadCD][L:282]
    Opcode: 0xbe
    ScsiStatus: 0x02 = CHECK_CONDITION
    SenseData Key-Asc-Ascq: 03-11-05 = MEDIUM_ERROR - L-EC UNCORRECTABLE ERROR
LBA[288180, 0x465b4]: Read error. padding [2352 bytes]
========== LBA[288180, 0x465b4]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : 00 FF FF FF FF FF FF FF  FF FF FF 00 63 48 50 00   ............cHP.
LBA[288180, 0x465b4] Reread NG

So I started focusing on 287000-289000:
- attempt #1: EC8893EC
- attempt #2: E43FF68D
- attempt #3: 6D3297FE

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

What do you think of using hashes inconsistency to help detect the range of twin sectors by narrowing the suspected range further ?

3,457 Reply by sarami

  • Registered: 2011-02-20
  • Posts: 1,734

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.

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

3,458 Reply by Nemok

  • Registered: 2023-03-03
  • Posts: 99

Thanks for the interesting link. I'll try the specific tool as soon as possible.

sarami wrote:

I'm not sure these ranges are correct.

With successive manual retries, I finally found 287920-288165 to be exact, not 287915-288169.

About DIC, one thing I noticed on a non protected area: output without /r for LBA 1000 to 2000 = output with /r for LBA 1000 to 1999 (and not 1000 to 2000, otherwise output has 1 additional sector). Is it normal ?

3,459 Reply by Nemok (edited by Nemok 2023-12-15 13:21:50)

  • Registered: 2023-03-03
  • Posts: 99

Getting to the point for http://redump.org/disc/36124/

Testing range 287900-288200 with twindump
- 251 twin sectors in 287922-288172
Backwards reading hashing for range B sectors
- identical CRC-32 found : 57A7CE8A

Testing range 287900-288200 with DIC
Forwards and backwards reading comparison
- 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

3,460 Reply by sarami

  • Registered: 2011-02-20
  • Posts: 1,734

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.

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

3,461 Reply by Nemok (edited by Nemok 2023-12-16 04:01:11)

  • Registered: 2023-03-03
  • Posts: 99

Absolutely.
If you need more tests, ask me.

3,462 Reply by sarami

  • Registered: 2011-02-20
  • Posts: 1,734

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

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

3,463 Reply by shfil (edited by shfil 2023-12-16 20:44:25)

  • Registered: 2023-03-02
  • Posts: 57

Hi, what does (*4) mean her e? (Was wondering about compatibility of W1210)
https://github.com/saramibreak/DiscImag … ve.txt#L54

Edit: Sorry, I missed note below. So only PX-W1210TS is supported?

3,464 Reply by sarami

  • Registered: 2011-02-20
  • Posts: 1,734

shfil wrote:

So only PX-W1210TS is supported?

Yes.

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

3,465 Reply by Nemok

  • Registered: 2023-03-03
  • Posts: 99

Glad to see a new /t command !

To summarize what was happening before it

Forwards reading 287900-288200 :

- "cd d: dump.bin 8 /be raw /c2" + manual work         C3E9D88B    no errors
- "data d: dump.bin 8 287900 288200 /be raw"          C3E9D88B    no errors
- "data d: dump.bin 8 287900 288200 /be raw /c2"     C3E9D88B    no errors
- "data d: dump.bin 8 287900 288200 /be raw /c2 /f"    variable        all 0x55 (288173-288183)
- "data d: dump.bin 8 287900 288200 /be raw /f"          variable        all 0x55 (288173-288183)

Backwards reading 287900-288200 :

- "data d: dump.bin 8 287900 288200 /be raw /r"          variable *    no errors
- "data d: dump.bin 8 287900 288200 /be raw /r /f"       variable        all 0x55 + invalid mode (288173-288183)

Forwards reading 287922-288172 :

- "cd d: dump.bin 8 /be raw /c2" + manual work        DA3582FC        no errors
- "data d: dump.bin 8 287922 288172 /be raw /c2"    DA3582FC        no errors

Backwards reading 287922-288172 :

- "data d: dump.bin 8 287922 288172 /be raw /r"         variable **    no errors ***
- "data d: dump.bin 8 287922 288172 /be raw /r /f"      variable        all 0x55 (288173) ***

* often C3E9D88B
** often DA3582FC
*** most of the time

What is happening now with it

- "data d: dump.bin 8 287900 288200 /be raw /t"

Takes forever to get passed 288173-288183 for each retry round, but should be able to finish with enough time

- "data d: dump.bin 8 287922 288172 /be raw /t"

_Forward.bin
     DA3582FC (match)
_BackToForward.bin
     100127CD, B031FD66, C2DCFD82, 19D8C363, 19D8C363, CF7778EF
-> Identical hash found
     19D8C363 (2 out of 6 attempts) but always with one error right after the first reread

- "data d: dump.bin 8 287922 288162 /be raw /t"

Seems to work pretty well if the last twin sectors are ignored

_Forward.bin
     BA7E0D0B (match)
_BackToForward.bin
     3095FB60, 3095FB60, 3095FB60, 350C16A4, EEB2A8E7, 3095FB60
-> Identical hash found
     3095FB60 (4 out of 6 attempts) with no errors

3,466 Reply by Nemok

  • Registered: 2023-03-03
  • Posts: 99

1. The BW-16D1HT is usually having a hard time with /f
2. I'm guessing /t implicitly uses /f for backwards reading

Is /f usage in /t mandatory ?

NB: the error right after the first reread is :

LBA[288173, 0x465ad]: [F:ProcessReadCD][L:335]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-11-05 = MEDIUM_ERROR - L-EC UNCORRECTABLE ERROR

3,467 Reply by sarami

  • Registered: 2011-02-20
  • Posts: 1,734

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.

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

3,468 Reply by Nemok

  • Registered: 2023-03-03
  • Posts: 99

Anyway, this is an awesome feature, well done sarami!

Maybe we should start a dedicated thread so that everybody can post their widest range with BadSectorCnt=0, identical hash, drive info, for every Tages disc...

3,469 Reply by shfil

  • Registered: 2023-03-02
  • Posts: 57

sarami, btw have you seen this info? Seems like plextor as well as other companies have agreed to block reading discs with Cactus or safedisc 2.0. (Seems like it's a change in firmware and newer revisions (TLA) are not able to be flashed with older firmware.)

PX-W2410 (from link)
    TLA#0000 - copies everything
    TLA#0100 - doesn't copy CDS 100 and some CDS 200
    TLA#0101 - doesn't copy 100 i 200 and there are problems with copying games

https://www.cdrinfo.pl/news/tla-w-plext … 2410-1385/

Here about safedisc 2.0. List of good firmwares (Plextor intentionally has removed it from website):
Plextor PX-W1210A 1.01 i 1.04
Plextor PX-W124 - 1.04
Plextor PX-W8432 - 1.05
PX-W8220T - 1.04
(Newer TLA aka revision may be not able to use old firmware)

https://www.cdrinfo.pl/newsy/archiwum/2001_02.php

I wonder, if there are potentially more drivers which could be used for redump.

3,470 Reply by sarami

  • Registered: 2011-02-20
  • Posts: 1,734

@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
DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

3,471 Reply by shfil

  • Registered: 2023-03-02
  • Posts: 57

I do have PX-4012 and Premium. Just recently was looking at getting information about replacement lasers for plextors, and this seemed interesting for me.

3,472 Reply by sarami

  • Registered: 2011-02-20
  • Posts: 1,734

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

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

3,473 Reply by bikerspade (edited by bikerspade 2024-01-02 17:25:36)

  • Registered: 2020-09-18
  • Posts: 962

The following issue was encountered with DiscImageCreator 20230606:
http://forum.redump.org/topic/52776/ss- … ke-france/

Post's attachments

SOVIETSTRIKE_SS_logs.7z.001 1.91 mb, file has never been downloaded. 

SOVIETSTRIKE_SS_logs.7z.002 1.14 mb, file has never been downloaded. 

You don't have the permssions to download the attachments of this post.
BW-16D1HT | PX-W4824TU | PX-W5224A | PX-760A | PX-712A | Plextor Premium | Pioneer 209DBK | TS-H352C | TS-H353A | Wii
  • Registered: 2020-09-18
  • Posts: 962

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.

BW-16D1HT | PX-W4824TU | PX-W5224A | PX-760A | PX-712A | Plextor Premium | Pioneer 209DBK | TS-H352C | TS-H353A | Wii

3,475 Reply by sarami

  • Registered: 2011-02-20
  • Posts: 1,734

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.

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website