So I set out to create a website that allows people to easily listen to video game music directly through their web browser. I succeeded in that goal. However, I must admit that the project has limited appeal since the web player is delivered via Chrome’s Native Client technology, somewhat limiting its audience. I’m not certain if anyone really expects NaCl to take off in any serious way, but I still have a few other projects in mind.
I recently realized that, as a side effect of this project, I accidentally created something of significant value to fans of old video games and associated music– a searchable database of chiptune music and metadata. To my knowledge, no one else has endeavored to create such a thing. I figured that I might as well make the database easily accessible with an API and see where it leads.
To that end, I created 2 API entry points. First, there is the search API located at http://gamemusic.multimedia.cx/api/search/. This can be exercised by ending the URL with a URL-encoded search string, e.g.: http://gamemusic.multimedia.cx/api/search/super+mario. This returns JSON data containing an array of results in decreasing order of relevance. Each result has a game title, database ID, media URL, system type, and an SHA-1 hash. This is the same API that the site’s own search page uses.
The database ID can be plugged into http://gamemusic.multimedia.cx/api/metadata/ to retrieve the song’s metadata in JSON format. E.g., the ID for Super Mario Bros. 3 on the NES is 161: http://gamemusic.multimedia.cx/api/metadata/161.
I recently read an article about sins against true RESTful API principles which led me to believe I’m almost certainly doing this web API stuff wrong. I don’t think it’s a huge deal, though, since I don’t think anyone actually listens to chiptunes any more. But if there are offline chiptune music players that are still in service and actively maintained, perhaps the authors would like to implement this API. It would require some type of HTTP networking library, a JSON parser, the embedded XZ decoder, and some new code to parse through my .gamemusic and .psfarchive formats.
This database could be a significant value-add to chiptune playback software, and could help people experience classic game music much more easily.
Do as it’s done in the modern world – reimplement everything in JS, starting with chip emulators (so no NaCl is needed at all).
If people can do it for H.264/VP8 decoders why can’t you do it for something simpler?
@Kostya: I’m not sure if you’re being facetious or not.
I’ve considered (however briefly) JS ports for the audio backends. I suspect that it’s plausible for some of the lower-spec systems supported (NES, Game Boy). I have my doubts on some of the later systems– Nintendo DS tunes in SaltyGME tend to occupy around 15-20% of one thread of a rather powerful Core i7; Dreamcast tunes typically take 35-40%. I shudder to think what the visualization plot would amount to on top of that, were I to port this all to JS.
(At this point, JavaScript advocates usually shout something about “web workers!” and then scurry off.)
Then there’s the matter of audio output via JS which is far from standardized.
Regarding audio standards: mozilla has officially confirmed to support google’s web audio proposal [1]. They are working on it already as part of WebRTC, so it’s probably coming sometime in the next few months.
You could also try to compile your player via emscripten to JS and see what performance you get out of it this way.
[1] http://robert.ocallahan.org/2012/09/web-audio-in-firefox.html
Audio Overload guy here. DSF barely works on an 800 MHz Cortex-A9 at 22 kHz with a lot of “getting out and pushing” (AOSDK is used in Modizer for iOS and DroidSound for Android, so I’m quite familiar with the performance characteristics). A JS conversion would likely be brutal. Modern JS JITs are very good, but there are limits.
PS: big fan of gamemusic.multimedia.cx itself! I use Chrome pretty much everywhere now (Firefox has been too crashy lately) so the NaCl requirement doesn’t bother me.
What are the chances of getting some API endpoints that provide a list of available systems, and games for each system so a client player could provide system/game browsing like the web site currently does? I’m looking at writing a player app for iOS that can support local files or playback from the GMA site and figured some extra endpoints might be more efficient than scraping the site pages and then correlating that with endpoint results to get the actual music files.
@Shinohara: I’ve been thinking about the API from the perspective of a client app and I realized that being able to retrieve complete lists would be pretty useful. I’ll be working on that.
Thanks for your interest.