Search options (Page 1 of 4)

Tekken Hybrid has BD-Video content that include files that are probably interleaved or non-contiguous, and PS3-ISO-Rebuilder probably doesn't know how to rebuild this. If you created the IRD with MPF (using my program) then the IRD is correct, its just the rebuilding program that can't handle it.
You can try NKit2 to rebuild it instead: https://github.com/Nanook/NKit
This program that is currently in development, sadly I think the beta version is currently only available for download at their discord.

Apologies, that version has a bug. Please try with this later version of MPF: https://github.com/SabreTools/MPF/relea … elease.zip

You can use my program https://github.com/Deterous/LibIRD

If you want a GUI, open MPF and go to Tools->Create PS3 IRD

It's a Canadian release, so I suspect there was both English and French text on the case.

It was my understanding that the first 3 bytes of the DNAS ID is unique to each disc, not just pressing run. Similar to the "Disc ID" for PS3 discs.
DNAS ID began to be used on PS2 discs around 2002.
It is located somewhere near the beginning of the disc, perhaps written in the 'wobble' that Sony likes to use. In any case, it's not readable via normal PC disc drives/commands.

If your interest is in a 'lost CD locator', also checkout my attempt at a complete PS1/PS2 Sony serial index: https://sony.redump.info/

Dumping via PC is preferred, you can get the keys after dumping via PC. Only one recently dumped disc is missing a key (temporarily) anyway.

This is expected and normal. One seems to be the Australian version.
You would submit them both as separate verifications.

I believe Redumper does not work as far back as Windows XP.

You will have to use DiscImageCreator if you want to dump on the Windows XP machine.

Sarami, a verification for http://redump.org/disc/74375/ was recently dumped using 20250101 which had a different pregap for Track 4 (00:02:49). I have attached the logs.

========== TOC with pregap ==========
    Track  1, Ctl 4, Mode 1, Index0   -150, Index1      0
    Track  2, Ctl 0, Mode 0, Index0  44850, Index1  45000
    Track  3, Ctl 0, Mode 0, Index0  62592, Index1  62792
    Track  4, Ctl 0, Mode 0, Index0  68996, Index1  69195
    Track  5, Ctl 0, Mode 0, Index0  79270, Index1  79470
    Track  6, Ctl 0, Mode 0, Index0  95142, Index1  95342
    Track  7, Ctl 0, Mode 0, Index0  99005, Index1  99205
    Track  8, Ctl 0, Mode 0, Index0 101340, Index1 101540
    Track  9, Ctl 0, Mode 0, Index0 103517, Index1 103717
    Track 10, Ctl 0, Mode 0, Index0 107547, Index1 107747
    Track 11, Ctl 0, Mode 0, Index0 109585, Index1 109785

Track 4 Index 0 in _disc.txt returned 68996 (199 sector pregap)

The error count is still 0, as per redump.org rules around what errors get counted (invalid sync sectors are not counted in the error count). The only change is the index 1 position for two tracks.

Redumper is new, that is why it is only recently accepted.

Both tools are dumping the exact same data from the discs, the difference is in how they are doing post-processing.
For the Might & Magic disc, they just split at different locations. DIC has identical pregap lengths for all tracks, Redumper has different pregap for Track 30 and 32. For this disc, it is due to the subcode desync messages, likely needs to be fixed (Redumper currently incorrect splits). I have fixed redump.org hashes to include the DIC splits (Tracks 29-32 have changed).

For the other two discs, they have some invalid sectors (one of which is EDC/ECC error). DIC and Redumper treat these errors differently, hence the different hashes. It is likely that redumper's method here is preferred. These are all the test cases that Redumper uses when determining what to do with invalid/unexpected sectors: https://github.com/superg/redumper/tree … unscramble