0xbe can be trusted to retrieve correct information from perfectly standard non-protected single-session single-track mode 1 CD-ROMs with no mastering error only, problem is you just can not guess, and that's part of the reason why it will never be "enough" for building a database. From personal experience, 0xbe drives gave matching results for more than 90% of PC games, including mode 1 + audio discs with the help of EAC.

2

(2 replies, posted in General discussion)

Interesting!

You also mentioned on github that IRDs were "useful for decrypting ISOs after they have been dumped on a PC blu-ray drive". I didn't know that, actually so far I only used the key directly with the old command-line tool PS3Dec.

So do you plan on adding ISO decryption functionality to IRDKit ?

I don't have the disc at home right now, so it will take a while (at the very least 6 months).

I don't have the disc at home right now, so it will take a while (at the very least 6 months).

5

(3,506 replies, posted in General discussion)

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

6

(3,506 replies, posted in General discussion)

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

7

(3,506 replies, posted in General discussion)

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

8

(3,506 replies, posted in General discussion)

Absolutely.
If you need more tests, ask me.

9

(3,506 replies, posted in General discussion)

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

10

(3,506 replies, posted in General discussion)

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 ?

11

(3,506 replies, posted in General discussion)

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 ?

12

(3,506 replies, posted in General discussion)

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

13

(3,506 replies, posted in General discussion)

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.

14

(3,506 replies, posted in General discussion)

I did not, my dump only verified the regular hashes. I initially thought that DIC had provided that info found in the comments, whenever the correct argument was given to it. That's why I wanted to try "/r".

Daemon tools pro is supposed to make working dumps of Tages discs but creates non consistent and non standard mds/mdf images, so using these for comparison with regular images to get that info isn't really straightforward.

15

(3,506 replies, posted in General discussion)

sarami wrote:

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

Jackal seems to be the only one who tried to give an example :
http://redump.org/disc/35932/
http://redump.org/disc/34669/

- number of duplicated sectors
- range of duplicated sectors
- type of duplication (twin)
- hashes (with duplicated sectors inserted into the disc image)

16

(3,506 replies, posted in General discussion)

What is the current state of Tages support ?

The github page mentions that DIC "can read in reverse, but specifications are not decided". 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.

17

(3,506 replies, posted in General discussion)

The issue is fixed. Thanks sarami.

18

(3,506 replies, posted in General discussion)

sarami wrote:
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?

Sure.

Disc tested : http://redump.org/disc/31428/
Log files : https://1drv.ms/u/s!AiA4u0yuSX13pn0G6gM … U?e=BJg5Td

19

(3,506 replies, posted in General discussion)

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

LBA[083196, 0x144fc]: [F:ReadCDForCheckingSubQAdr][L:1080]
    Opcode: 0xbe
    ScsiStatus: 0x02 = CHECK_CONDITION
    SenseData Key-Asc-Ascq: 03-11-05 = MEDIUM_ERROR - L-EC UNCORRECTABLE ERROR
lpCmd: be, 00, 00, 01, 44, fc, 00, 00, 01, f8, 01, 00
dwBufSize: 2448

20

(3,506 replies, posted in General discussion)

OK those issues are now fixed.

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

LBA[088444, 0x1597c]: [F:ReadCDForCheckingSubQAdr][L:1076]
    Opcode: 0xbe
    ScsiStatus: 0x02 = CHECK_CONDITION
    SenseData Key-Asc-Ascq: 03-11-05 = MEDIUM_ERROR - L-EC UNCORRECTABLE ERROR
lpCmd: be, 00, 00, 01, 59, 7c, 00, 00, 01, f8, 01, 00
dwBufSize: 4896

21

(3,506 replies, posted in General discussion)

Indeed subchannel is zeroed. So pack mode never really was supported even if a dump in this mode could be started. Fine.

Also discovered today :

- Discs with data and audio tracks cannot be dumped anymore using ribshark. DIC throws errors like this one:

LBA[083296, 0x14560]: [F:ReadCDForCheckingSubRtoW][L:1283]
    Opcode: 0xbe
    ScsiStatus: 0x02 = CHECK_CONDITION
    SenseData Key-Asc-Ascq: 03-11-05 = MEDIUM_ERROR - L-EC UNCORRECTABLE ERROR
lpCmd: be, 00, 00, 01, 45, 60, 00, 00, 01, f8, 01, 00
dwBufSize: 2448

- DIC often fails to get write-offset on first attempt.

22

(3,506 replies, posted in General discussion)

sarami wrote:
Nemok wrote:

Pack mode without /c2 is still broken.

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

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

23

(15 replies, posted in General discussion)

For anyone that still tries to get the best DPM approximation possible.

I have written a small bash script program that moves the DPM content into an old format MDS container (convert). This allows manual editing of the DPM values with Advanced MDS editor 0.5.5 and BWA edit 1.1 since these are incompatible with what the latest Alcohol releases create. The edited DPM content may then be put back inside its new format container (rebuild).

24

(3,506 replies, posted in General discussion)

Raw mode with /c2 is fixed.
Pack mode without /c2 is still broken.

25

(3,506 replies, posted in General discussion)

At least with my setup, the latest release is completely unusable: getting c2 errors on every sector, and a warning that the drive does not support subchannel pack mode, while the 20230909 release had no problem (bw-16d1ht + ribshark firmware + sata to usb adapter).