In case it's helpful, I wrote a Ghidra SLEIGH processor spec for the MN102 processor (matsushita/panasonic) a while ago.  I'm not sure if anything recent/readily available still uses the MN102 though.


(6 replies, posted in General discussion)

I mainly try to try to have a light reflect where the code is, as that makes the code more visible.  I also have a magnifying glass I use.  It's still a bit annoying to work with.

I also had decent results scanning it with the scanner's lid open - this probably works better in a dark room at night; this image was during the day.  It probably also depends on the scanner - the scanner I used here produces black/grey when there's no background.  The text is also much more readable at higher DPIs.

Infinite Clouds wrote:

After all they do "Bard's Tale, The" and we do "The Bard's Tale".

Redump actually uses "Bard's Tale, The" in the datfile in the downloads section (I think this is an automatic conversion), but yeah, the No-Intro guide isn't actually that helpful here.

The wiki's useful links page links to the No-Intro Naming Convention, which is probably a good starting point.  (Note that the link on the wiki was broken until I fixed it just now.)

You should get dumper status when someone adds the dumps you posted to the database (but that can take a few days).

The wiki says that there's one missing Korean Wii disc: Revision 0 of Deca Sporta: Wiiro Jeulgineun Sports "10" Jongmok! / 데카스포르타 Wii로 즐기는 스포츠 "10"종목!.  You can determine a disc's revision by looking at the mastering code; in the case of that game, if it contains "RVL-RDXK-0A-0" it would be revision 0 while "RVL-RDXK-0A-1" would be revision 1.

To give my opinion, it's not useful to buy a disc that's already green for the express purpose of verifying it again, but if you already have it (or bought it for some other reason), there's no harm in submitting dump info for it.


(4 replies, posted in General discussion)

On any of the results pages (e.g. discs -> Sony Playstation), at the top it'll say "Displaying results 1 - 500 of 10449", so there are 10449 total discs in the collection.  Filtering to America ( gives 1966 (one of which appears to be canadian, and the rest USA)

From … dump-uses/ and it looks like there are other regions that aren't linked directly; for instance I gives Italy, and U gives USA.  (Oddly, I get 1964 US discs and 1 Canadian disc, which doesn't quite add up).  If you want to figure out the region code for something specific, you can right-click the flag and select "view image"; the URL will be something like and from that you can see that I is Italy.  (Or you can just guess at URLs; that's worked fairly well for me.)


(3 replies, posted in General discussion)

AnEvilKoala wrote:

DICUI prompts for information that goes into a !submissionInfo.txt, which I usually submit directly (sometimes I edit it afterwards to tweak language, version, or contents info).

Ah, I see. I have been using the command-line version since I am on Linux. That version doesn't prompt for that info, so I suspect I will have to do some things manually. I'll have to check later to see if I can use the GUI guide to see what else I might be missing on the command-line version.

Here's a sample from a CD (

Common Disc Info:
    Title: Unreal
    Foreign Title (Non-latin): 
    Disc Number / Letter: 
    Disc Title: 
    System: IBM PC Compatible
    Media Type: CD-ROM
    Category: Games
    Region: USA
    Languages: Klingon (CHANGE THIS)
    Disc Serial: 04-12527CD2

    Ringcode Information:
        Mastering Code (laser branded/etched): FUTURE MEDIA \ CA    FM 14171 (04-12527CD2/GT0001)
        Mastering SID Code: IFPI LG32
        Data-Side Mould SID Code: IFPI 3V19
        Label-Side Mould SID Code: 
        Additional Mould: 
        Toolstamp or Mastering Code (engraved/stamped): 
    Barcode: 7 42725 60369 1
    Error Count: 0
    Comments: [T:ISBN] 1-56893-420-3

Version and Editions:
    Edition/Release: Original

    Primary Volume Descriptor (PVD):

0320 : 20 20 20 20 20 20 20 20  20 20 20 20 20 31 39 39                199
0330 : 38 30 36 32 35 31 33 30  38 34 30 30 30 00 31 39   8062513084000.19
0340 : 39 38 30 36 32 35 31 33  30 38 34 30 30 30 00 32   98062513084000.2
0350 : 30 30 38 30 36 32 32 31  33 30 38 34 30 30 30 00   008062213084000.
0360 : 31 39 39 38 30 36 32 35  31 33 30 38 34 30 30 30   1998062513084000
0370 : 00 01 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................

Copy Protection:
    Copy Protection:

E:\ CD Check
E:\msvcrt.dll: CD Check
E:\DirectX5\dx5eng.exe: CD Check
E:\DirectX5\dx5frn.exe: CD Check
E:\DirectX5\dx5ger.exe: CD Check
E:\DirectX5\dx5itn.exe: CD Check
E:\DirectX5\dx5spa.exe: CD Check
E:\Heat\katalyst.exe: CD Check
E:\MPlayer\mplaynow.exe: CD Check
E:\Shared\MFC40.DLL: CD Check
E:\Shared\MSVBVM50.DLL: CD Check
E:\Shared\MSVCRT40.DLL: CD Check
E:\Shared\OLEAUT32.DLL: CD Check
E:\System\MSVCRT.DLL: CD Check
E:\WorldNet\iestuff\IE3240E\IE4SETUP.EXE: CD Check
E:\WorldNet\iestuff\IE3240E\MSVCRT40.DLL: CD Check

Tracks and Write Offsets:

<rom name="Unreal.bin" size="533435952" crc="f90745a5" md5="6ecaac5ca1e3ed590b4eb4b49390cfcc" sha1="94a09a8f33db49bd6298ecf1b969d3073324f93c" />


FILE "Unreal.bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00

    Write Offset: -22

I'm pretty sure the "Copy Protection" section is generated by DICUI and won't have an equivalent with the command-line.  Also note that I didn't bother testing languages, as I didn't want to try and install things (and they were already listed on the previous dump I was verifying).  The other fields are as explained in … _your_Dump (and … g_database)


(3 replies, posted in General discussion)

Here's my experience (which may not be the best practice):

1. For most of the things I've dumped, I only dumped them once, using DICUI and a Plexor PX-W4012TA (for CDs) or a TS-H352C (for Xbox 360) or the DVD drive in my laptop (for video DVDs).  However, if it seems like something's gone wrong, I'll usually dump it another time with the same drive.  For Wii or GameCube games, if it dumped successfully once, I don't bother with doing it a second time, except for unlicensed games by Datel where it can't detect errors during the dump process.  If you're verifying an existing dump, you probably don't need to dump with multiple drives.  (That said, I also haven't dumped anything with unusual copy protection, where things may be different.)

2. I don't know anything about this.

3. I've never edited the dat file.  DICUI prompts for information that goes into a !submissionInfo.txt, which I usually submit directly (sometimes I edit it afterwards to tweak language, version, or contents info).  I upload all of the files (other than img/iso/bin/scm) though.  I think the metadata in the dat file is to match the format seen in datfiles from and doesn't matter for the individual ones.

I think part of the issue is that cleanrip 2.0.0-datel2 ignores all errors; I wonder if it would be possible to check the error and only ignore it if it's a 030200 (No Seek Complete) while still stopping for other errors.  I'm not sure if such a check would affect dump times or not.  (I guess a log of all unreadable sectors and the corresponding errors would be useful too; Cleanrip 2.1.1's skips file is close to that and probably could be used as a starting point.)

It does sound like your dump is correct; once the 2.0.0-datel2 dump finishes go ahead with submitting it.  I've also purchased this same title and should be able to verify it in a week or so.

Datel titles usually have their main code starting at 0x50000000.  If that area is completely blank, your dump is probably bad.  Cleanrip 2.1.1 doesn't know what to do with most datel titles and will have everything after 0x01F00000 zero'd out without trying to read it, while 2.0.0-datel2 will attempt to read it, ignoring any errors for the unreadable sectors and filling those sectors with 0x55.  If everything is still 0x55, that's a bad sign.  Also if there are 0x55-filled sectors in the middle of code that otherwise looks fine, that's probably a bad sign.

Check if the game starts properly on console; if it's unable to read it normally when you launch it, then there's no hope of cleanrip doing the right thing unfortunately.  Otherwise, you can try testing your dumps with dolphin; Datel being Datel the games don't launch unless you've got the GC bios and have DSP LLE enabled though.  If you get error messages other than FIFO overruns, and if it doesn't start, your dump probably still isn't correct.

Even if you eventually get something that matches what's in the database, verification dumps are always useful (especially for discs as volatile as these).

It's also worth noting that the numbers in the ringcode can be the same for multiple discs; Advance Game Port and both Cheat Construction Kit videos (PAL and NTSC) are 04070501 (see images), though they have different text.  To my understanding, the numbers are a date (in the form of year month day 01); the Cube magazine discs help establish this.


(2 replies, posted in General discussion)

To my understanding, subchannel data doesn't have a complete checksum and can't be error-corrected in all cases, but it isn't directly entered into the database either so having some errors doesn't matter.  I.e. it's fine to submit even with some errors in the subchannel data, since the subchannel data isn't part of the final database entry.

I'd like a wiki account (with this same username), mainly to update info about GC/Wii games (in particular unlicensed ones).


(3,488 replies, posted in General discussion)

sarami wrote:

Try to use the latest test version before reports bug.

Looks like both issues have been fixed!  Sorry about that; I assumed that since there weren't any more commits in the GitHub repo, there hadn't been any further changes, and didn't think to look for the test version.  (I was still unable to complete a dump of DVD 1, but that's expected due to the scratches on the disc, but it at least started).


(3,488 replies, posted in General discussion)

I've found a problem with dumping some DVD-Video discs using DIC.  Well, really, 2 problems.

First, starting with DIC 20200203, all of the Cube DVDs fail to dump, with the error being "nLBA 262, Directory Record is invalid".  DIC 20200204 is also affected, while 20191116, 20191223, and 20200120 are not.  This immediately stops dumping right at the start, with a 0-byte image file.

Secondly, DIC 20191223 and 20200120 produce an error with Cube DVD 01.  Unfortunately, my disc is rather scratched and it was hard to get a full dump, so I can't do too much testing and most dump attempts are polluted with other errors later on, but I did get a clean dump with 20200120 (which is the one I submitted there).  The specific error appears at the start and is this:

LBA[702695, 0xab8e7]: [F:ReadDVDForFileSystem][L:855]
    Opcode: 0xa8
    ScsiStatus: 0x02 = CHECK_CONDITION
    SenseData Key-Asc-Ascq: 03-11-05 = MEDIUM_ERROR - L-EC UNCORRECTABLE ERROR

Dumping continues after the error, and (in that one lucky dump) I didn't get any other errors, including when it read that same area for actually writing.  (That area is all zeros, though).

These are all 8 cm DVDs, so perhaps that has something to do with it?  Unfortunately I don't have any regular full-size DVDs to compare with.

The first is probably a bigger issue since it completely prevents dumping these discs with current versions of DIC, but I am curious why the second one happens too.