(8 replies, posted in General discussion)

Does your tool dump these properly? http://redump.org/discs/system/psp/status/3/

also, does your tool dump the same way as PSP Filer, or is there a chance that dumps with your tool are more complete?

sorry if any of these questions are stupid or already answered


(4 replies, posted in General discussion)

It's a DVD-Video disc that just happens to have some Xbox compatible demo files on them, so DVD-Video is the primary format.

Could you double check for any toolstamps or IFPI codes on the disc?

The 635930 serial on the label seems to indicate some sort of rerelease, but the ringcode has 633830, which matches this serial: https://www.ebay.com/itm/Star-Wars-Dark … 3106179540

So I'm guessing that 633830 was the first release serial, and they used some of the first print discs for the subsequent releases? Anyway, would be great if someone could buy the 633830 serial one, to confirm that it's the same disc.

The game sold close to a million copies, so there could be a dozen or more prints. Here's one with yet another ringcode that isn't in the db: https://www.ebay.com/itm/283035766632

edit: This websites claims that the 633830 one is also a rerelease, so it's getting really confusing: https://ogdb.eu/index.php?section=game&gameid=72484


(3 replies, posted in Dumps)

Could you try to obtain (for completion's sake):
RCE Protection:
Copyright Protection System Type:
Encrypted Disc Key:
Player Key:
Decrypted Disc Key:

using http://www.dvddecrypter.org.uk/ + http://qpxtool.sourceforge.net/download.html



(72 replies, posted in General discussion)

IIRC PSP dumping is different from normal dumping. Instead of reading a range of sectors, the PSP is accessing the data through the filesystem.. So the last sectors of a PSP dump could be erroneous and some tools are known to create bad dumps. I don't think the PSP Filer developer can do anything about this, because he's restricted to what the PSP allows? Maybe there are any optical drives that can be hacked/modified into reading UMD discs? tongue


(0 replies, posted in Dumps)

Dumper: emuLOAD. Asked repeatedly for scans/pictures because ringcodes are incomplete. Moving data to the forum until this is resolved.

Title: Stonekeep

Region: UK

Language: English

Serial: CD-ICD-045-EME

: 3: 1
ifpi 2307

Comments: "Bundled Software"

Edition: Bundle Version OEM

0320 : 20 20 20 20 20 20 20 20  20 20 20 20 20 31 39 39                199
0330 : 39 30 37 32 31 31 35 34  36 33 34 30 30 00 31 39   9072115463400.19
0340 : 39 39 30 37 32 31 31 35  34 36 33 34 30 30 00 30   99072115463400.0
0350 : 30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 00   000000000000000.
0360 : 30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30   0000000000000000
0370 : 00 01 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................

ClrMamePro data:
size 646811760 crc f3d49b03 md5 f9f9c3b05ba37cad7b3313c2b5416c5f sha1 7243d42ed2b9a1b76ec917c21299f2181ca5dfd6
size 44624496 crc 123994dd md5 bd9c9dab93c2e49faccd06be9b570b2d sha1 b3a0bd8264ce6e83254b0ca62f5a10bb80b1140e

CATALOG 0000000000000
FILE "Track 01.bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
FILE "Track 02.bin" BINARY
    INDEX 00 00:00:00
    INDEX 01 00:02:00

Write offset: 0

Dumper: Billy. Asked repeatedly for scans/pictures because ringcodes are incomplete. Moving data to the forum until this is resolved.

Category: Bonus Discs

Region: Europe

Languages: Czech, Danish, Dutch, English, Finnish, French, German, Hungarian, Italian, Norwegian, Polish, Portuguese, Russian, Spanish, Swedish

Serial: MXX07706214D2/ENG

Mastering Code: 52256593/MXX0705630D2 CC 21
Mastering SID: IFPI LP73
Back Mould SID: IFPI 07K4
Front Mould SID: IPFI Q7N5

Barcode: 5 030930 065379

0320 : 20 20 20 20 20 20 20 20  20 20 20 20 20 32 30 30                200
0330 : 37 30 34 30 33 31 30 35  31 33 36 30 30 00 32 30   7040310513600.20
0340 : 30 37 30 34 30 33 31 30  35 31 33 36 30 30 00 30   07040310513600.0
0350 : 30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 00   000000000000000.
0360 : 30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30   0000000000000000
0370 : 00 01 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................

Size: 1823014912
CRC-32: 0f1ee318
MD5: e724f35ab1dfcd2a9548642b5924a1b5
SHA-1: f2b53166ca904cf6b177757f69c316ff7e8ca8d7


(3 replies, posted in Dumps)

Dump by einstein95. Some info is missing (edition, barcode, PVD), so moving this to the forum.

System: DVD-Video

Media: DVD-5

Title: The Making of... Spore

Category: Bonus Discs

Region: Europe

Language: English

Ring: IFBILB25    19080BONUS-DVD    (JH041A)

DVD Serial Number: D372CB9CAPPLEDSP
DVD Title (Alternative): THE_MAKING_OF_SPORE
DVD disk reports itself with Region mask 0x00400000. Regions: 1 2 3 4 5 6 8
Menu: English
Voices: English
Subtitles: None
Aspect ratio: 4:3
Frame rate: 29.97 fps
Video type: NTSC
Audio format: DVD LPCM 48kHz 1536kbps

Edition: Original
Size: 1963261952
CRC-32: ba8f3087
MD5: 1b07c390416e65b71c7625d813003404
SHA-1: d8c39e140811bb3f8d0108fdda82c3c8f0fa15a5

This fix dump DOES have bytes where limbo43's dump didn't?

So it contradicts earlier findings, where the bad dumps had data and the correct ones didnt.


(13 replies, posted in General discussion)

darksabre76 wrote:

I'm going to do some gravedigging here, so I apologize in advance. I recently came across the issue of trying to detect SafeDisc v3/4 without ProtectionId. There seem to be no public instructions out there on how these protections are actually found. If anyone here has even the slightest conceptual idea, I'd love to hear it. Thanks in advance!

AFAIK the only way is to scan the game .exe


(1 replies, posted in Dumps)


sorry but this really isn't the way to submit your dumps.. plz include DIC logs for all dumps, and preferably scans/pictures. And new dumps can be submitted here: http://redump.org/newdisc/

I noticed that the ringcodes are different..

Maybe the "Combo disc; works on Xbox 360" thing has something to do with it?
Are there any other cross-compatible discs like that in the db? Maybe worth double checking those too.
Hope limbo43 will be back soon, so we can get this resolved.


(9 replies, posted in Fixes & additions)

F1ReB4LL wrote:
reentrant wrote:

For some reason audio zero (checked the scm file) sectors were descrambled. That 75 sectors are just scrambled zeroes. Is it expected for DIC: May 18 2017 23:08:37 ?

Audio zeroes can't be scrambled or descrambled, these are zeroes.

If the Nexy's dump had 75 scrambled data sectors there, that should be examined. Maybe worth to dump the disc with cdtoimg_d8 and check that area.

The .scm file is the same thing as a cdtoimg_d8 dump? The problem was with the descrambling process.


(9 replies, posted in Fixes & additions)

IIRC Yellow Book specifies that for an audio to data transition, the data track pregap should start with 1 second of audio silence.
Dreamcast dumps where there's audio tracks followed by a data track in the high density area should have this too.
Scrambled audio data doesn't make any sense. The dreamcast dumps have zeroes too, so I fixed this.

@reentrant, maybe you could check for other PC dumps that might have this wrong.


(9 replies, posted in Fixes & additions)

I wonder what caused darksabre76's dump to be different? Do different DIC versions produce different dumps?


(7 replies, posted in General discussion)

iR0b0t wrote:

Would a "Credits" field fulfill your needs, guys? smile

I still think it has no place in a database.. it's not really relevant how the dumper obtained the disc. It would be better to make a wiki page or something to credit contributors.

The correct EXE date is 2006-11-09:

              Length of Directory Record: 60
        Extended Attribute Record Length: 0
                      Location of Extent: 279
                             Data Length: 3520792
                 Recording Date and Time: 2006-11-09 09:15:34 +09:00
                              File Flags: 0 (Visible, File, Disassociated, File has't record format, Owner/Group ID has't, Final Directory Record)
                          File Unit Size: 0
                     Interleave Gap Size: 0
                  Volume Sequence Number: 1
               Length of File Identifier: 13
                         File Identifier: SLES_545.60;1


(7 replies, posted in General discussion)

I removed these comments, because we need to be strict about who is the dumper and who gets credited.. some weeks ago, people were being credited as dumper in submissions, because they were the ones lending games to a dumper. This is not allowed, only the person who dumped the disc should be credited as dumper.

It's okay to thank people somewhere who are lending out discs, but let's not fill database fields with this info.

Blau wrote:

I have a few Gamecube games (all already on the db), but I don't have a Wii to dump them. However I have a compatible CD drive that works with Rawdump/Friidump. I already dumped all and every hash matches the database.

The problem is, as the wiki guide says, I can't get the BCA. So my question is, can I post the dumps even without the BCA?

Yes, as long as you include all the other relevant data (ringcodes etc.)


(1 replies, posted in Dumps)

thevoice wrote:

Menzoberranzan http://redump.org/disc/2882/

BARCODE : 5 018247 855227
SERIAL : CS090094
RINGCODE : CS090094 14 A1
EDITION : Original

All data matches with the database

DIC logs : https://www.sendspace.com/file/foncg8
Ringcode: https://www.sendspace.com/file/if3l8z

Region and cuesheet were wrong on the old dump wink

Didnt read all the posts, but when there's multiple versions released of a game, and one of them is undumped, the version can be added to the filename for the one that is dumped. Is that what you mean with New Super Mario Bros. Wii?

Even with the offset detection fixed, it will still produce potentially bad dumps with missing data because there is no overread into lead-out?

@sarami / others

It has come to my attention that some dumpers are using non-Plextor drives with DIC for their CD dumps.
The first issue that I see is the offset detection:
For this dump: http://forum.redump.org/topic/18020/add … 2002-demo/ DIC detects a write offset of -12.
But for this one: http://forum.redump.org/topic/18021/non … piel-demo/ it detects:

========== Offset (Drive offset referes to http://www.accuraterip.com) ==========
     Combined Offset(Byte) -24696000, (Samples) -6174000
    -   Drive Offset(Byte)     24, (Samples)     6
           CD Offset(Byte) -24696024, (Samples) -6174006
    Overread sector: -10500

So I wonder if the -12 offset is even correct?

Other risks of course include incorrectly descrambled / cut off data. As soon as a disc has audio tracks or mastering errors, the results can no longer be trusted.

It would probably be better to block CD dumping (or add warnings) on drives without D8 (at least by default, without a special parameter) and also add a check to the DICUI GUI to only allow dumping in D8 mode? If you don't add such checks, then people might think that they can just use any drive to dump, and if these dumps are added without checking, the database might soon be riddled with bad dumps.

Plz add some scans/pictures.