iRoms

[DaMadFiddler]

The idea came from a conversation I had with Quzar last summer.

Media management has matured significantly over the last few years; most people use an advanced database-centered program (such as iTunes, Songbird, WMP, etc.) for managing their music, and that program can act as a hub for importing, sorting, synchronizing, and exporting music. It's the root of many people's music collection these days.

So: why not do something similar with emulation? Create a Win/Mac/Linux database program that sorts and tags your games. It can launch games (either by acting as a frontend and launching an external program, or by internally running emulation modules through a plugin system...this was subject of some debate), it can help you create "playlists" for exporting custom collections of games from your library for copying to disc or memory card, and if compatible clients are written for other emulation-capable devices, it can synchronize and export games directly to your other gadgets.

Getting something like this up and running would probably require establishing a standardized protocol (akin to MTP), which would have to be incorporated into device builds of the client application. Or, for more limited devices that can handle some emulators but might choke on a large application like that, a framework could be established so that emu authors could easily integrate the transfer & cataloging protocol directly into their emulators.

I know there are plenty of frontends that catalog your games on the computer, and some emulators do it inherently. The root idea here is to establish a standardized database approach for building a sortable, tagged, exportable library of games that can be easily synced across different programs and platforms.

Any thoughts?

[Nico0020]

I have no means of knowing how to do such a thing, but I really do agree with the idea. I thought about why something similar did not exist before awhile back.

[Stryfe]

It probably would require a massive amount of work. First what roms naming standards would be accepted? Goodtools, No-Intro? Would bad dumps be fixed, or left alone until proper dumps can be made?

Header formats? NES example: iNES1A, iNES2, UNIF, XML...

I would think that this would be quite a project for one type of rom, let alone a building history of different systems.





-----------------------------------------------------------------------
BTW - What ever happened to the other people from over at Screamcast?

[Ex-Cyber]

I think it should be doable if kept simple. A management application might want to use a database engine like SQLite for various purposes, but I don't see why the interchange format would need to be more complex than ordinary ROM/disk image files coupled with a set of simplified CSV databases. Such a format would offer a lot of flexibility on the "player" end - resource-constrained devices (I'm thinking on the order of GBA and graphing calculators here; some of the smaller media players might be similar) could offer a basic feature set by parsing the CSV directly, while more capable ones could import it into their own database engines. The biggest challenges would probably be coming up with a set of standardized fields and designing a suitably flexible sync procedure. Can you get a little more detailed about the use cases that you're imagining? I think I get the basic idea, but as an everyday user I sort of missed the iTunes revolution.

[Ex-Cyber]

Realistically, I'm not sure that starting with Gamebase would save a lot of work, though examining its design would probably be a good idea.

[Specially Cork]

I really like the idea of being able to keep active playlists for exporting roms to other devices. Are there existing databases that can be used with all the additional info needed/wanted (developer, year of release, genre etc.)? It would be an awful lot of work if there isn't.