Or maybe you just meant I could include links to the miss lists for the user to check?

Just blast out the miss lists

GC
Asia - http://wiki.redump.org/index.php?title= … ia_Missing
PAL - http://wiki.redump.org/index.php?title= … AL_Missing
USA - http://wiki.redump.org/index.php?title= … SA_Missing

Wii
Asia - http://wiki.redump.org/index.php?title= … ia_Missing
PAL - http://wiki.redump.org/index.php?title= … AL_Missing
USA - http://wiki.redump.org/index.php?title= … SA_Missing

Feel free to unsticky this thread now, since there isn't much left to discuss.

For integrating this into Dolphin, would you prefer that we ship a copy of the dat file with every release of Dolphin, or would you prefer that Dolphin downloads the dat file from redump.org on behalf of the user? The former would place less of a load on the server, but the latter would enable people to get the hashes for new dumps without having to update Dolphin. (There aren't all that many undumped discs now, though... At least if you don't count demos and all the Korean Wii games.) If I do the latter, I'll make it download only if the user is trying to verify a disc (and with local caching), so the server isn't going to be getting a request for every person who uses Dolphin or anything like that.

Also, if we ship a copy of the dat file with Dolphin, is it fine to ship the Wii dat file too even though it's not publicly available on redump.org?

supported options = serial and/or version

separated by comma, order does not matter.

This can be scraped easily and provided in bulk.

There is A LOT of good parseable information in nintendo disc headers that could be useful:

GameCube: https://www.gc-forever.com/yagcd/chap13.html#sec13.1
Wii: https://wiibrew.org/wiki/Wii_Disc

I believe Jos would only need the highlighted text portion in a new field in the GC/Wii dats:

Apparently we don't store the version of gamecube and wii discs anymore. I am kind of "delaying" the deletion task for that matter because i don't know yet if we still need it or not.

The version is being stored, just in a different format. Old 1.01 is equivalent to new Rev 1, old 1.02 is equivalent to new Rev 2, and so on. (But it seems like 1.00 is being replaced with just nothing? Not sure why, but it's not a problem for me, since I can simply treat an empty field as meaning Rev 0.) I'll just need to add an exception for Korean GameCube games with the country code E, since it seems like they now start counting the revision from 0 rather than 48.

Serial + revision would be enough.

EDIT: Actually, a small correction: Due to the exception with Korean GameCube games mentioned above, I would also need information about whether games are Korean or not. But this information is already present in the current datfile if you check whether the game name has (Korea) at the end, so it shouldn't be a problem. It would have been convenient if those revisions still were being counted from 48, though.

@JosJuice
Whould the serial tag still be enough for the integration purpose?

JosJuice wrote:

is there a possibility of Redump releasing dat files with additional fields (serial, version)

If you want to have it, I can make it happen.

That would be very nice. For Dolphin's purposes, the serial and version are the only things that really are needed (in addition to the hashes, of course). The disc number would also be convenient to have, but it can be determined based on the serial.

I don't think there's anything we can do with those unlicensed discs other than checking whether the hash is in the database or not. A lot of those discs even share the name that is displayed in the GC IPL, so there really isn't anything good to go on other than hashes.

is there a possibility of Redump releasing dat files with additional fields (serial, version)

If you want to have it, I can make it happen.

What will you do about discs which don't have a serial or version, though?
http://redump.org/discs/system/gc/sort/serial/?page=1

Though, I can imagine there are also drawbacks to a Redump API. It would probably increase the server load (imagine all thousands of Dolphin users querying the API), especially when more rom managers/emulators/launchers will use it. And it would increase the 'risk' of someone scraping Redump and 'stealing' the data. Though, it's of course a point of discussion whether the data is really a property of Redump

Or, maybe not an online API, but an 'offline' one that generates a json/xml file for offline use. Where a user would select which data (maybe even from a limited selection, e.g. only hashes, titles, editions and serials) he/she wants and then Redump generates a file. It would at the very least be much less of a strain on the server.