Breaking Eggs And Making Omelettes
A blog dealing with technical multimedia matters, binary reverse engineering, and the occasional video game hacking.
Les articles publiés sur le site
-
Game Music Appreciation
16 juillet 2012, par Multimedia Mike — Game HackingA little over a year ago, I was prototyping a method to leverage Google Chrome's Native Client technology in order to play old chiptunes (video game music) directly in a web browser. The last time I posted on the matter, I said that I might have something ready for public consumption by the time Google Chrome 21 rolled around. I thought I was being facetious but I wasn't too far off. Chrome 20 is the current release version as I write this.
Anyway, I did it: I created a chiptune music player in Native Client by leveraging existing C/C++ libraries such as Game Music Emu, Audio Overload SDK, and Vio2sf. Then I packaged up the player into into a Google Chrome extension and published it on the Chrome Web Store. Then I made a website cataloging as many chiptunes as I could find for 7 different systems:
http://gamemusic.multimedia.cx/
Check it out if you have any affinity for old game music or you want to hear how music was made using a limited range of bleeps and bloops. Thus far, the site catalogs NES, SNES, Game Boy, Nintendo DS, Genesis, Saturn, and Dreamcast songs. I'm hoping to add support and catalogs for many more systems, though, eventually bringing support in line with the Chipamp plugin for Winamp.
-
Winamp and the March of GUI
Ars Technica recently published a 15-year retrospective on the venerable Winamp multimedia player, prompting bouts of nostalgia and revelations of "Huh? That program is still around?" from many readers. I was among them.
I remember first using Winamp in 1997. I remember finding a few of these new files called MP3s online and being able to play the first 20 seconds using the official Fraunhofer Windows player-- full playback required the fully licensed version. Then I searched for another player and came up with Winamp. The first version I ever used was v1.05 in the summer of 1997. I remember checking the website often for updates and trying out every single one. I can't imagine doing that nowadays-- programs need to auto-update themselves (which Winamp probably does now; I can't recall the last time I used the program).
Video Underdog
The last time Winamp came up on my radar was early in 2003 when a new version came with support for a custom, proprietary multimedia audio/video format called Nullsoft Video (NSV). I remember the timeframe because the date is indicated in the earliest revision of my NSV spec document (back when I was maintaining such docs in a series of plaintext files). This was cobbled together from details I and others in the open source multimedia community sorted out from sample files. It was missing quite a few details, though.Then, Winamp founder Justin Frankel -- introduced through a colleague on the xine team -- emailed me his official NSV format and told me I was free to incorporate details into my document just as long as it wasn't obvious that I had the official spec. This put me in an obnoxious position of trying to incorporate details which would have been very difficult to reverse engineer without the official doc. I think I coped with the situation by never really getting around to updating my doc in any meaningful way. Then, one day, the official spec was released to the world anyway, and it is now mirrored here at multimedia.cx.
I don't think the format ever really caught on in any meaningful way, so not a big deal. (Anytime I say that about a format, I always learn it saw huge adoption is some small but vocal community.)
What's Wrong With This Picture?
What I really wanted to discuss in this post was the matter of graphical user interfaces and how they have changed in the last 15 years.
I still remember when I first downloaded Winamp v1.05 and tried it on my Windows machine at the time. Indignantly, the first thought I had was, "What makes this program think it's so special that it's allowed to violate the user interface conventions put forth by the rest of the desktop?" All of the Windows programs followed a standard set of user interface patterns and had a consistent look and feel... and then Winamp came along and felt it could violate all those conventions.I guess I let the program get away with it because it was either that or only play 20-second clips from the unregistered Fraunhofer player. Though incredibly sterile by comparison, the Fraunhofer player, it should be noted, followed Windows UI guidelines to the letter.
As the summer of 1997 progressed and more Winamp versions were released, eventually one came out (I think it was v1.6 or so) that supported skins. I was excited because there was a skin that made the program look like a proper Windows program-- at least if you used the default Windows color scheme, and had all of your fonts a certain type and size.
Skins were implemented by packaging together a set of BMP images to overlay on various UI elements. I immediately saw a number of shortcomings with this skinning approach. A big one was UI lock-in. Ironically, if you skin an app and wish to maintain backwards compatibility with the thousands of skins selflessly authored by your vibrant community (seriously, I couldn't believe how prolific these things were), then you were effectively locked into the primary UI. Forget about adding a new button anywhere.
Another big problem was resolution-independence. Basing your UI on static bitmaps doesn't scale well with various resolutions. Winamp had its normal mode and it also had double-sized mode.
Skins proliferated among many types of programs in the late 1990s. I always treasured this Suck.com (remember them? that's a whole other nostalgia trip) essay from April, 2000 entitled Skin Cancer. Still, Winamp was basically the standard, and the best, and I put away my righteous nerd rage and even dug through the vast troves of skins. I remember settling on Swankamp for a good part of 1998, probably due to the neo-swing revival at the time.
Then again, if Winamp irked me, imagine my reaction when I was first exposed to the Sonique Music Player in 1998:
The New UI Order
Upon reflection, I realize now that I had a really myopic view of what a computer GUI should be. I thought the GUIs were necessarily supposed to follow the WIMP (windows, icons, mouse, pointer) paradigm and couldn't conceive of anything different. For a long time, I couldn't envision a useful GUI on a small device (like a phone) because WIMP didn't fit well on such a small interface (even though I saw various ill-fated attempts to make it work). This thinking seriously crippled me when I was trying to craft a GUI for a custom console media player I was developing as a hobby many years ago.I'm looking around at what I have open on my Windows 7 desktop right now. Google Chrome browser, Apple iTunes, Adobe Photoshop Elements, and VMware Player are 4 programs which all seem to have their own skins. Maybe Winamp doesn't look so out of place these days.
-
Size Discrepany in the ‘du’ Command
22 juin 2012, par Multimedia Mike — GeneralI had a problem today while using the common Unix command 'du'. As a refresher, 'du' stands for disk usage and is a handy tool for understanding how much disk space is being occupied.
I think 'du' is probably doing the right thing. The problem might be that I'm getting strange (read: 1/2 the expected number) when running the tool against directories on vmhgfs, the VMware filesystem.
Science Project
On an Ubuntu Linux VMware session, my home directory is on the main file system, which is ext4. The directory /mnt/hgfs is reported by 'mount' to be of type vmhgfs and is shared with the host machine.Create a directory in the home directory and generate a 10 MiB file:
mkdir /home/melanson/dir dd if=/dev/urandom of=/home/melanson/dir/random-file bs=1048576 count=10
Create a directory on the shared drive and copy the same file:
mkdir /mnt/hgfs/vmshare/dir cp /home/melanson/dir/random-file /mnt/hgfs/vmshare/dir
Run 'du' on each directory using the -k and -h options:
du -k /home/melanson/dir /mnt/hgfs/vmshare/dir 10244 /home/melanson/dir 5120 /mnt/hgfs/vmshare/dir du -h /home/melanson/dir /mnt/hgfs/vmshare/dir 11M /home/melanson/directory 5.0M /mnt/hgfs/vmshare/directory
I noticed this discrepancy when I was trying to pack a set of files (akin to 'tar'-ing) living in a directory in the shared location. I was going mad trying to understand why the original directory was only 2 MB as reported by 'du' but the final packed file was 4 MB.
To be fair, the man page for 'du' succinctly states that the tool's purpose is merely to "estimate file space usage".
-
RAR Is Still A Contender
RAR (Roshal ARchive) is still a popular format in some corners of the internet. In fact, I procured a set of nearly 1500 RAR files that I want to use in a little project. But I didn't want my program to have to operate directly on the RAR files which meant that I would need to recompress them to another format. Surely, one of the usual lossless compressors commonplace with Linux these days would perform better. Probably not gzip. Maybe not bzip2 either. Perhaps xz, though?
Conclusion
At first, I concluded that xz beat RAR on every single file in the corpus. But then I studied the comparison again and realized it wasn't quite apples to apples. So I designed a new experiment.New conclusion: RAR still beats xz on every sample in this corpus (for the record, the data could be described as executable program data mixed with reduced quality PCM audio samples).
Methodology
My experiment involved first reprocessing the archive files into a new resource archive file format and only compressing that file (rather than a set of files) using gzip, bzip2, xz, and rar at the maximum compression settings.echo filesize,gzip,bzip2,xz,rar,filename > compressed-sizes.csv for f in `ls /path/to/files/*` do gzip -9 --stdout $f > out.gz bzip2 -9 --stdout $f > out.bz2 xz -9 --stdout --check=crc32 $f > out.xz rar a -m5 out.rar $f stat --printf "%s," $f out.gz out.bz2 out.rar out.xz >> compressed-sizes.csv echo $f >> compressed-sizes.csv rm -f out.gz out.bz2 out.xz out.rar done
Note that xz gets the option
'--check=crc32'since I'm using the XZ Embedded library which requires it. It really doesn't make a huge different in filesize.Experimental Results
The preceding command line generates compressed-sizes.csv which goes into a Google Spreadsheet (export as CSV).Here are the full results of the bake-off, graphed:
That's not especially useful. Here are the top 2 contenders compared directly:
Action
Obviously, I'm unmoved by the data. There is no way I'm leaving these files in their RAR form for this project, marginal space and bandwidth savings be darned. There are other trade-offs in play here. I know there is free source code available for decompressing RAR files but the license wouldn't mesh well with GPL source code libraries that form the core of the same project. Plus, the XZ Embedded code is already integrated and painstakingly debugged.During this little exercise, I learned of a little site called Maximum Compression which takes experiments like the foregoing to their logical conclusion by comparing over 200 compression programs on a standard data corpus. According to the site's summary page, there's a library called PAQ8PX which posts the best overall scores.
-
Releasing GME Players and Tools
I just can't stop living in the past. To that end, I've been playing around with the Game Music Emu (GME) library again. This is a software library that plays an impressive variety of special music files extracted from old video games.
I have just posted a series of GME tools and associated utilities up on Github.
Clone the repo and try them out. The repo includes a small test corpus since one of the most tedious parts about playing these files tends to be tracking them down in the first place.
Players
At first, I started with trying to write some simple command line audio output programs based on GME. GME has to be the simplest software library that it has ever been my pleasure to code against. All it took was a quick read through the gme.h header file and it was immediately obvious how to write a simple program.First, I wrote a command line tool that output audio through PulseAudio on Linux. Then I made a second program that used ALSA. Guess what I learned through this exercise? PulseAudio is actually far easier to program than ALSA.
I also created an SDL player, seen in my last post regarding how to write an oscilloscope. I think I have the A/V sync correct now. It's a little more fun to use than the command line tools. It also works on non-Linux platforms (tested at least on Mac OS X).
Utilities
I also wrote some utilities. I'm interested in exporting metadata from these rather opaque game music files in order to make them a bit more accessible. To that end, I wrote gme2json, a program that uses the GME library to fetch data from a game music file and then print it out in JSON format. This makes it trivial to extract the data from a large corpus of game music files and work with it in many higher level languages.Finally, I wrote a few utilities that repack certain ad-hoc community-supported game music archives into... well, an ad-hoc game music archive of my own device. Perhaps it's a bit NIH syndrome, but I don't think certain of these ad-hoc community formats were very well thought-out, or perhaps made sense a decade or more ago. I guess I'm trying to bring a bit of innovation to this archival process.
Endgame
I haven't given up on that SaltyGME idea (playing these game music files directly in a Google Chrome web browser via Google Chrome). All of this ancillary work is leading up to that goal.Silly? Perhaps. But I still think it would be really neat to be able to easily browse and play these songs, and make them accessible to a broader audience.
