Well, probably. In my quest for weird and wacky multimedia samples I have amassed quite a collection of game titles. The number is well in excess of 400 right now. Not a hardcore collector by any stretch of the imagination. But it’s more than enough for any member of the opposite sex to write me off as an emotionally stunted, overgrown adolescent, despite the fact that I rarely actually play any of these games.

I catalog the games’ multimedia technology in my Multimedia Exploration Journal (and I presently have 70-80 games to process for the journal). If you care what all the games are, here is the master spreadsheet I maintain:

• mike-games.sxc (OpenOffice Calc format)
• mike-games.xls (same document exported to Microsoft Excel format)

Mostly, the spreadsheet is to help track which information still needs to go into MobyGames. I have not updated the spreadsheet in a little while so some of the red and yellow cells might be a little inaccurate w.r.t. the database.

Do you have any dusty old games stuffed in the closet? Do you have at least mild obsessive-compulsive tendencies? Check the MobyGames database and see if you have anything to contribute with those old games– box and media scans, game screenshots, reviews, the game itself if necessary– I have dozens of titles that still don’t exist in the database, expansive though it may be (27,478 games as of this post).

One of my original motivations which led to the creation of the MultimediaWiki was to expand on the knowledge enumerated at fourcc.org, heretofore the internet’s foremost authority on the curious multimedia concept known as the four-character code (FourCC). With the latest update of the MediaWiki software, I find that I am able to categorize FourCC redirect pages. What this means to the Wiki lay person is that I can use the Wiki to automatically maintain a list of all known video FourCCs, which I have done. I have done the same for audio FourCCs, though the list is not as extensive (mostly applies to QuickTime and Real codecs). I hope to give the same treatment to Microsoft 16-bit audio IDs soon.

So far, I have only catalogued the FourCCs and codecs that I can prove exist, either because we have samples, codecs, or both that correspond to the codec. The fourcc.org list contains dozens of FourCCs for which I can find no samples or codecs. It’s reasonable to believe that they existed, perhaps at the dawn of the consumer multimedia era. It also could be that certain FourCCs were formally registered with Microsoft by ambitious companies that were never able to release their multimedia programs that would have generated the corresponding data.

What to do about these? I don’t wish categorize them along with the provable FourCCs. I may create a different page or category for these strays until they can be claimed either by the discovery of actual media samples in the wild or by codecs (source or binary, coders or decoders) that can handle the data.

It turns out that FFmpeg has been accepted as one of Google’s Summer Of Code mentoring organizations. Here is FFmpeg’s page at the SoC site. The team is assembling possible project ideas over at the MultimediaWiki. This could be your one chance to actually make money in directly helping the open source community.

I have a plan, I really do. I am still working hard on Understanding VC-1. Just so that you, the reader and open source multimedia enthusiast understand correctly, this is not so that we can build a new implementation that mirrors the reference implementation 1:1. What I am doing right now is more or less the “phase 1″ of this particular documentation effort. Phase 2 is developing a more top-down specification in a similar spirit as my old VP3 format document. Phase 3 is to generate a development roadmap with specific tasks and milestones as well as a number of sample vectors for individual modules which should facilitate initial component validation as well as ease development of SIMD-optimized components.

So you see, phase 1 is where I essentially use the MultimediaWiki as a scratchpad. VC-1 is, like, really big and hard to get one’s head around. This process is helping me.

Part of my plan in all of this is that I am hoping to pawn off the actual writing of code on other people. I know there are people out there — even people reading this blog — who are interested in making some material contribution to open source multimedia. On Monday I learned of Google’s second annual Summer of Code initiative where, in a nutshell, college students can get paid to work on approved open source projects. Since the project as outlined above, with the roadmap and deliverables/milestones, seems ideal for this mentoring concept, I submitted FFmpeg as a project for consideration, albeit a few hours after the formal deadline for doing so. Since the SoC is quite popular, it’s likely that they have all the projects they need.

However, if a student is out there following this blog and interested in working on a very important piece of open source multimedia work, you will have the opportunity starting May 1 to submit an application to work on a project not listed with an official mentoring organization, per this SoC FAQ entry. It’s a long shot, but Google has sponsored more ambitious stuff.

A big task? You bet. But if you follow this blog you’re probably at least minimally qualified to tackle the project.

I just want to briefly recognize MySQL for its resilience and robustness. Even in the event that a table gets corrupted, as happened today with the tables driving the MultimediaWiki, ‘CHECK TABLE’ and ‘REPAIR TABLE’ can diagnose and fix the problem and have your MySQL-backed application up and running in short order. Of course, I also have an automated script backing up the database tables off-site, every night, just for good measure.

I just want any current or future contributors to be secure in the knowledge that the data is safe.

While raiding Wikipedia for scant pieces of multimedia information they might have that are not yet in the MultimediaWiki, I learned of 2 new lossless video codecs– Lagarith and MSU Lossless Video. I’ve heard people grumble about how lossless video codecs just don’t perform. I know of one grumbler in particular — you know who you are — who claims that FLAC actually outperforms the nominal special-purpose lossless video codec. I am expecting a full report from you on how these new codecs stack up. The MSU technology is proprietary but I have started to document the GPL’d Lagarith codec in the Wiki. The author contributed a write-up of the surface details. I am trying to plod through the control flow. It’s a bit slow-going though since many of the crucial functions are written in MMX-optimized ASM.

In other Wiki news, I finally found a logo:

It is the same one seen on Wikipedia’s multimedia entry and apparently comes from a set of KDE icons made here. I like it.

I was searching for some comprehensive registry of FourCCs when I happened upon Sustainability of Digital Formats: Planning for Library of Congress Collections. They host an interesting, and recently updated, survey of all manner of multimedia formats including containers, video codecs, audio codecs, and text formats.

Also, I eventually found the Microsoft’s official list of registered AVI video FourCCs (and 16-bit audio codec identifiers): The IANA hosts it: http://www.iana.org/assignments/wave-avi-codec-registry. There is some very interesting stuff in there. Did you know that Dolby had an AC2 codec? And that their listed address is spelled incorrectly? (I know since their office is about 2 blocks away from where I work.)

Aurel Jacobs would like to share his FMV laptop with the group: http://gnuage.free.fr/t70r/. Apparently, it’s a real brand of laptop from Fujitsu.

People keep asking me which format I think will win the HD war, as if I’m some kind of authority on the matter. My answer: I don’t really care. I’m just interested in sitting ringside and observing the action like a drunken boxing fan.

vs.

Seriously, from my perspective, it has never mattered which format I actually like. The mission of a multimedia hacker is to understand and support as many diverse formats as various factions can possibly develop.

Here’s something from my personal archives that is of practial use to almost no one– a gallery of ROM images: http://multimedia.cx/nesgallery/. Technically, they are the printed circuit boards (PCBs) inside the actual NES cartridges. Much of the real estate inside a regulation NES cartridge went unused. I scanned these back when I used to be unusually interested in the technical workings of the classic 8-bit Nintendo Entertainment System and was maintaining a Linux-based NES emulator. Perhaps the most interesting speciman of the set is the PCB for the unlicensed game Bee-52 from Codemasters:

All PCBs for official, licensed games contain at least 3 chips: The PRG ROM (program), the CHR ROM (character/graphic data), and the CIC lockout chip (located next to PRG and CHR ROMs). The NES console had a piece of circuitry that interfaced with the CIC chip and the upshot is that the console refused to run a game cartridge if the CIC chip was not present. Nintendo held a patent on the CIC chip and was, for the most part, able to control which games could be manufactured for the console. Assorted ambitious game houses went the unlicensed route and developed various techniques to circumvent the CIC mechanism. That is what all those hacks on the Bee-52 PCB represent, in lieu of a CIC chip. Notice the switch on the PCB. That’s because when Nintendo rolled out a redesigned top-loading NES console, one of the cost reduction measures was to remove the console-side lockout circuitry. All licensed games continued to play. But it broke the vast majority of unlicensed titles. The switch allows the user to enable or disable the lockout-defeating measures.

Other interesting artifacts to note on the various PCBs are the stock TTL chips or custom mapper chips that games used to break through various limitations of the NES hardware, as well as shiny round batteries which indicate that the user is able to save their game in some RAM area also present on the PCB.