Search options (Page 1 of 4)

Some updates:

- Yes, all Nokia N-Gage discs are eligible, however as there is no system in redump for N-Gage it would either be deemed a PC disc, or added to a Non-Redump DAT (depending on content).

- Only official/licensed gaming peripheral driver discs are eligible (assuming the disc has no other gaming content), a driver disc bundled with a cheap third party controller is generally not eligible. If you have a query about a specific disc in this category, just ask.

I think it is less about being associated with DIC or about active development, just that DIC does have three important differences with redumper:
1. Audio CD splits and write offset detection, which is why we only accept Audio CDs with redumper
2. There is a difference in how Redumper and DIC decide to descramble or not descramble certain invalid/unexpected data sectors. This only affects "edge cases", but it is important as some discs will not match redump hashes as a result (while the dump itself is fine, just post-processing is different). This is a design decision between the two programs, and we have decided to fix upon redumper's handling of it. DIC has changed how it handles different types of invalid/unexpected sectors over time.
3. For the new drives (Mediatek-based blu-ray drives), the leadout sectors are read using a cache read. DIC's current implementation of the cache read is prone to producing a bad dump, while redumper has fixed it (which is why these new drives have become acceptable for new dumps).

For Plextor dumps, DIC remains acceptable for dumps, with the above caveats. We therefore recommend using redumper as a "first step". In an ideal world, everyone could dump with both programs for self-verification, but we cannot force all dumpers to do this.

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