As always, your explanation is excellent!

I’d like to add another proposal/benefit: the possibility for the user to flag an incorrect ROM or media association, as well as flag a missing ROM association. After these flags are reviewed, they could be incorporated into the database.

Let me try to give an example. Imagine that you imported a ROM set, and one of those ROMs was incorrectly identified by the database. Also, imagine that a game had an incorrect image fetched from EmuMovies. The user could notify LaunchBox, and after a review, this information could be updated in LaunchBox. In the case of the ROM, if this entry had already been registered as a predefined association (for example, from a No-Intro or TOSEC set, or through an MD5 association), this association could be removed. Similarly, for media, if it was also a predefined association, it could be removed in case of an error.

The same applies when a user finds an association that wasn’t predefined. This association could be automatically sent to LaunchBox for review, and once confirmed as correct, it could be added to the database.

I believe that for a more accurate media association system, a database with extra descriptions of the media would be necessary — a table containing: the source path of the media, the origin of the media (EmuMovies, LaunchBox database, name of the community pack, etc.), a hash of the media, a table of associations between this media and games (since one piece of media could be associated with more than one game), and a table to identify duplicate media (e.g., identical videos that only differ in quality).

I hope the explanation was clear. I'm available to provide more information if needed.

Thank you! Best regards,

Hello, AstroBob!

I’ve been thinking about new applications with a new database and had a few ideas. Before listing them, I’ll share a bit of the experience that led me to think about a more complete database.

A few years ago, I started developing an external tool for LaunchBox to create my own engine to: associate ROMs with the LaunchBox database, assign a probability of correctness to the association, manage the association and prioritize between the main and additional applications, find associated media for each ROM, choose the "best" media for certain categories (e.g., 3D Box), delete duplicate media, copy all necessary files, and automatically generate the platform’s XML. Incredibly, my engine turned out to be more accurate than LaunchBox's own engine.

When importing platforms with thousands of games, my engine is relatively slow and impractical for all users. However, once the process is complete, it doesn’t need to be run again. That made me think: if something similar were built directly into the LaunchBox database, everyone could benefit from faster and more accurate associations. In my engine, I used data sources like No-Intro, TOSEC, and MAME.

Later on, I came across IGDB’s database structure and thought it was fantastic! I tried to replicate it myself, but the complexity and lack of time made the idea unfeasible.

That said, here are some ideas for implementation and usage (some are repeats, others are new):

Implementation:

Essentially, the database could be divided into parts:

1. A structure similar to IGDB for the games.

2. APIs from databases like No-Intro, TOSEC, Redump, and MAME.

3. Tables to store media paths and their metadata (LaunchBox DB, EmuMovies, community packs).

4. Tables for emulator information.

5. Predefined associations between No-Intro, TOSEC, Redump, MAME, and the games.

6. Predefined associations between media and games (noting that a single media file might serve multiple games and categories).

   Of course, there’s much more to consider, but this should be enough to illustrate the concept.

How to use it:

1. When importing ROMs—let’s say for SNES—LaunchBox could scan the MD5 of each file and search the databases. If a match and predefined association are found, the ROM is automatically linked to the game (and, consequently, the media). If there are additional apps, the main one is predefined in the database (though users could override this if needed). For unidentified MD5s, LaunchBox attempts a search and suggests an association (which is added to the DB, but marked as uncertain). After import, LaunchBox could ask users if they want to review the associations and evaluate them as correct or incorrect. Once a certain number of users confirm a match, it becomes reliable. The same process could apply to media—users could mark associations as correct or incorrect via the game edit screen. If a media association is marked wrong, the media’s unique hash is sent to the DB and flagged. After a number of reports, that media is no longer used in future imports.

2. If LaunchBox can’t identify a match, users could propose one, which is added to the database. Once enough confirmations are received, it becomes valid. On top of that, I believe IGDB’s API can be used freely for non-commercial purposes. If each user has their own API key, LaunchBox could connect using the user’s key and pull data to add to the LaunchBox database—making it more complete over time.

3. When viewing media for a game, a user might find one particular 3D Box image much more appealing than others. They could have the option to set it as the default not only for that game but for the entire platform. LaunchBox could then use the media’s hash to trace its source (e.g., a specific community pack) and apply other media from the same source as the default.

4. A registered media database could help better detect duplicates. For example, LaunchBox doesn’t currently identify duplicate videos with different resolutions. When a user spots identical media, they could report it, and the database would track this equivalence. After enough confirmations, LaunchBox would consider both versions the same and offer only one to the user’s library.

5. Using a unique ROM identifier (like MD5) allows users to report ROM performance with a specific emulator and settings. This opens the door for game-specific discussions, letting users contribute the best ways to run a particular ROM. For instance, I was never able to run dual-cartridge Sufami Turbo games via RetroArch command line—only through MAME. I could share this directly through LaunchBox, logging it in the database and giving other users a way to see what’s being discussed about their platform. In other words, it’s like having a fully integrated forum system tied to both the database and LaunchBox itself. Other examples include N64DD and Sega CD 32X games. For N64DD, some games only work in RetroArch, others only in Ares. For Sega CD 32X, it’s the same story. I could share how I got things working and see what others recommend. Even more ambitious—imagine a way to record the community-recommended emulator settings for each obscure ROM. When importing a platform, LaunchBox could ask if the user wants to use recommended settings for each game. That would be a dream come true!

That’s it! I hope I was clear and not too long-winded. I’d also like to use this explanation as an example for the “Extra Information for Media Files” topic.

Best regards,