I was poking at the data files of a really bad (is there any other kind?) interactive movie video game known simply by one letter: D. The Sega Saturn version of the game is comprised primarily of Sega FILM/CPK files, about which I wrote the book. The second most prolific file type bears the extension ‘.dg2′. Cursory examination of sample files revealed an apparently headerless format. Many of the video files are 288×144 in resolution. Multiplying that width by that height and then doubling it (as in, 2 bytes/pixel) yields 82944, which happens to be the size of a number of these DG2 files. Now, if only I had a tool that could take a suspected raw RGB file and convert it to a more standard image format.

Here’s the FFmpeg conversion recipe I used:

 ffmpeg -f rawvideo -pix_fmt rgb555 -s 288x144 -i raw_file -y output.png

So that covers the files that are suspected to be 288×144 in dimension. But what about other file sizes? My brute force approach was to try all possible dimensions that would yield a particular file size. The Python code for performing this operation is listed at the end of this post.

It’s interesting to view the progression as the script compresses to different sizes:

That ‘D’ is supposed to be red. So right away, we see that rgb555(le) is not the correct input format. Annoyingly, FFmpeg cannot handle rgb5[5|6]5be as a raw input format. But this little project worked well enough as a proof of concept.

If you want to toy around with these files (and I know you do), I have uploaded a selection at: http://multimedia.cx/dg2/.

Here is my quick Python script for converting one of these files to every acceptable resolution.

work-out-resolution.py:
Read the rest of this entry »

Thanks to Daniel Verkamp for contributing a Kega video (KGV1) decoder to FFmpeg. I was about to demand samples for testing until I looked up what Kega is — a Sega game console emulator — when I realized that it would be more fun to create my own (be advised that only the Windows version of Kega presently supports the AVI encoding option). Then I looked up the Wiki page and realized that there is, in fact, one sample on record at the archive. Well, I went ahead and made my own sample anyway. I used the mountainside attract-mode scene from the Genesis game Strider, one of my favorite sequences in any video game. It’s in the samples directory.

I am holding off on adding a FATE test; there’s still an endian issue (PPC configs disagree with x86 configs). I’m also a little puzzled as to why FFplay insists on playing the video as 320×240 even though the video is encoded as 640×480. For that matter, I’m also bewildered trying to understand why Kega renders video as 640×480 by default; that’s not a native resolution for any of its emulated consoles.

Today was the day: Kostya committed his Bink video decoder to FFmpeg. Here’s just one little screenshot:

Of course, this is just one Bink file out of the literal thousands of software titles that have incorporated Bink video (the above comes from Indiana Jones and the Emperor’s Tomb for Windows). For this reason, it’s entirely possible that the Bink video decoder (not to mention the Bink audio decoder and the Bink file format demuxer) might not cover all the cases out there. This is especially relevant considering intel I have received from a guy who has talked to the guy who invented Bink and described the development process. The upshot is that there could conceivably be a lot of custom Bink versions out there. That’s why Kostya hopes for a lot of testing with as many different Bink files that people can throw at this system. To that end, I started with my old Multimedia Exploration Journal and did a text search for every game that I recorded as using Bink.

Just think: The next time that YouTube and assorted other video uploading services update their video conversion backends, they can finally be flooded with Bink videos. (I know it seems silly, but I sometimes feel like my biggest contribution to open source multimedia has been to allow people to upload to YouTube video files that they found on their old Sega Saturn CD-ROMs).

As for FATE, is it plausible to get a basic decoding test staged at this point? I ran a simple sample through my RPC testing tool and learned that the video output is bit exact across platforms. Test staged.

(Aside: Thanks to Vitor Sessak, Valgrinder extraordinaire, for locating a memory bug in the Musepack v7 demuxer. Since I created and staged a v7 sample at the same time I staged a sample for the Musepack v8 demuxer, I have already activated a Musepack v7 demuxing test.)

Here’s a project for someone that likes text processing and searching puzzles: Find a simple, efficient method for comparing my list of DOS/Windows games (here’s the HTML list and here it is in CSV) against the big list of known Bink titles and find all the Bink games in my PC game collection. I have already harvested samples from: Alien vs. Predator Gold Edition, Disney’s Atlantis, Gabriel Knight 3, Gods & Generals, Halo 3 (Xbox 360), In Cold Blood, Indiana Jones and the Emperor’s Tomb, Monsters Inc. Wreck Room Arcade, Starlancer, Tony Hawk Pro Skater 2, Uru: Ages Beyond Myst.

First off, FFmpeg’s Interplay MVE decoder finally supports 16-bit video mode in addition to the original palette mode. I would post a pretty picture showcasing this (as I often do for new game-related formats) but Kostya has already done the honors.

I added some new FATE tests today based on systems that have recently appeared in FFmpeg:

• auravision
• auravision-v2
• cdgraphics
• interplay-mve-16bit
• lossless-als

I have been working (and occasionally playing) with my PlayStation 3 recently. I upgraded the 80 GB internal hard drive to a 1/2 TB one. Since I have the old 80 GB HD laying around, of course I have to plug it in and see if there’s anything familiar about the data. It’s a short exploration: As you might suspect, the HD is completely impenetrable. No partition table reported through Linux fdisk. No human-readable strings can be seen when running ‘strings’ over the raw HD sectors. Based on forum postings I have read where one PS3 HD can’t successfully be transplanted to another PS3 (and have all the data accessible; the HD could still be reformatted fresh to work in another PS3), I’m guessing that every sector is encrypted with a key derived at least partially from a unique ID embedded in each console. That’s all the effort I plan to put into this exercise. Next stop for this HD is my Eee PC 701 which is currently struggling to run Ubuntu Linux on a mere 4 GB SSD.

I downloaded a free movie trailer through the PlayStation store. When I inspected the information through the PS3′s XMB menu, the filetype was reported as “MNV”. A little Googling ties this format into the paid content format of the PS3 store. I’m not especially confident about this format since the trailer that I downloaded doesn’t even play correctly on the PS3. The video stutters back and forth, almost as though it’s swapping pairs of frames during playback: 1, 0, 3, 2, 5, 4, 7, 6, etc. The XMB allows me to “backup” this media. This option needs to be distinguished from “copy”, which is sometimes an option. “Copy” implies an unlocked version that can be copied onto removable media and used anywhere. “Backup” implies that it can be copied onto removable media but is still keyed to — and can only be used on — this console. I backed it up and was able to inspect the data on the USB drive. It turns out that the MNV file is still a stock MP4 but with custom DRM. When FFmpeg is aimed at this file, this is the result:

[h264 @ 0x1004000]AVC: nal size -2055117847
[h264 @ 0x1004000]no frame!
[...repeated many times...]
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x1002600]max_analyze_duration reached

Seems stream 0 codec frame rate differs from container frame rate:
 48000.00 (48000/1) -> 23.98 (24000/1001)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from
 '/Volumes/KINGSTON/PS3/EXPORT/VIDEOBKP/20091220-220733-00000001/20091220-220733-00000001.001':
  Metadata:
    major_brand     : MGSV
    minor_version   : 20842393
    compatible_brands: MGSVmp42isom
  Duration: 00:01:46.64, start: 0.000000, bitrate: 8651 kb/s
    Stream #0.0(und): Video: h264, 2205 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 48k tbc
    Stream #0.1(eng): Audio: aac, 48000 Hz, stereo, s16, 264 kb/s
    Stream #0.2(eng): Audio: aac, 48000 Hz, 5.1, s16, 395 kb/s
    Stream #0.3(und): Data: mp4s / 0x7334706D, 759552 kb/s
Video pixel format is unknown, stream cannot be decoded

I remember some patches flying around the FFmpeg-devel list recently which would allow the program to print warnings and bail out if it encountered a known DRM scheme. When I shove an Apple-encrypted file through FFmpeg, it doesn’t tell me anything special so I don’t think the patch is in yet. However, FFmpeg should probably detect this type of DRM file as well.

Because I don’t have enough unfinished projects in my life, and because I have recently fallen in with a crowd of fanatical archivists, I started to ponder the possibility of systematically archiving all of the CD-based video games that I have collected. One day, some historian is going to want to study the proliferation of wedding simulators and licensed Barbie games. Then I noticed that I have an unused 2x750GB RAID brick (configured for redundancy, so 750 GB capacity), and that I haven’t had enough bad experiences with RAID technologies yet. Put the 2 together: why not try archiving a bunch of these games on said RAID brick?

So, that’s the pitch: archive a bunch of game discs onto this RAID brick. Assumption: a ‘disc’ is a string of 2048-byte sectors comprising a CD-ROM mode 1/form 1 data track, plus 1 or more redbook CD audio tracks if they exist. Some questions:

• What filesystem should the RAID brick be formatted in?
• Should the data tracks be compressed? If so, what format?
• Should the audio tracks be compressed (losslessly)? If so, what format?
• How should the information be organized on the disc?
• How should this process be automated?

Be advised that these are problems for which there is no “right” solution. There are many solutions and choosing one is all about evaluating trade-offs. Here are some solutions I am planning for:

• I have formatted the brick with Linux Ext3. At one point I had the brick formatted with FAT32 so it could easily be shared between many operating systems. Unfortunately, I had a bad experience with data integrity which marked either another strike against RAID tech in general, or perhaps a faulty FAT32 driver in either Linux or Mac OS X. Further, there’s the issue that I can’t abide Mac OS X’s insistence on pooping metadata files all over every filesystem it touches. I have that problem with my pocket USB drive. At least if it’s not in a Mac-native filesystem, I won’t have to worry about that.
• Compressing the data track should be performed using one of the usual suspects in Unix-land: gzip, bzip2, or lzma (at least, those are the ready-made solutions; I have a theory about better compression to be expounded upon in a later post). Which is best? Lzma is generally the champ in terms of size reduction. It’s useful to consider the time tradeoff. I was recently trying to compress some very large files for internet transfer and noticed that lzma took substantially longer than other options. But since this is for long term storage, it’s probably worth it to squeeze out the largest compression factor.
• For compressing the audio tracks, the 2 frontrunners are FLAC and Apple Lossless (ALAC). FLAC is obviously in consideration because it’s free and open source and all that. However, ALAC, while not necessarily free and open source in the most pure notion, is still free and open source enough for this purpose (FFmpeg has both a decoder and a competitive encoder). Archiving using ALAC also makes it possible to easily listen to the music using iTunes, my usual audio program. Thus, I’m leaning towards ALAC here.
• I need to come up with a directory structure for the master archive disc. I imagine something along the lines of “/game title” for single-disc games and “/game title/disc n” for multi-disc games. Each directory will have “track01.iso” and 0 or more “tracknn.m4a” files depending on the presence of audio tracks. That’s the general pattern, anyway.
• As for automating this, it will naturally be done with a Python script of my own creation. I wager I could actually make something that queries a disc directly (Python has ioctl libraries) and then read the raw data and audio tracks. That’s how I implemented the CD playback support in xine. This time, I suspect I’ll just be invoking cdparanoia and parsing the output to determine number of tracks and for subsequent ripping.

I am thinking that the automated Python script should maintain a centralized SQLite database at the root of the archive disc. This database should keep track of archived disc locations, the ripped tracks, and their before- and after-compression sizes. Further, it should store records of each file (with relative path) in the filesystem along with its timestamp and size. Also, the database needs to log information about errors encountered during the ripping process (i.e., store the stderr text from the data copy operation). Bonus points for running the Unix ‘file’ command against each file and also storing the output. This last bit of information would be useful for finding, e.g., all of the Smacker files in every game in the archive. There are still specialized game-related formats that the ‘file’ type database will not recognize. For this reason, it may also be useful to record the first, say, 32 bytes of a file in the central database as well for later identification. Maybe that’s overkill; I’m still tossing around ideas here.

Open questions:

1. How do I rip a data track that is not the first track of an optical disc? My standard method is to use the Unix command ‘dd if=/dev/disc of=file.iso’ but that only works if the first track contains data. I have encountered at least one disc on which the data track isn’t first. Come to think of it, I guess this is standard for “enhanced” audio CDs and this particular demo disc might have fallen into that category.
2. How do I mount an ISO filesystem for browsing without needing root permissions? Since I want to put as much brainpower into this automated script as possible and I don’t want to run the script as root, it will be necessary to at least be able to get a listing of the directory structure, and preferable to mount the filesystem and run ‘file’ against each one. There is the option of mounting via the loopback device (maybe loosening the permissions of the loopback device will help). FUSE seems like an option, in theory, but the last time I checked, there were no ISO-9660 drivers for FUSE.

Archiving a bunch of old games seems so simple. Leave it to me to make it complicated.

I’ve been on a gaming kick lately. I found a game in my collection called Roketz; the full DOS game can be downloaded from the publisher. The game has 2 files bearing the extension VQM that appear to be FMV files. Wiki and samples.

Roketz comes from a company called Bluemoon. According to their website, they’re also responsible for building the technological foundations for 2 well-known pieces of software: Kazaa and Skype. I’ve never used either, personally, but I understand that Skype uses a custom vocoder called SILK. Maybe Roketz and VQM is where the team got their start in codec technology?

I have never really figured out what role Reddit plays in the grand scheme of things. But someone over there has taken an interest in figuring out the Treasure Master code system, something on which I have previously hypothesized.

+

It’s a determined bunch and I’m impressed with the headway they seem to be making. I never had time to get to the bottom of this. I’m eagerly watching to see if they can crack this ancient and useless puzzle.

I played an old DOS game a few months ago by the title of Klondike Moon. I really didn’t comprehend it at all. The gameplay dealt with outerspace mining while the storyline was something about paying off your debt with the proceeds of your labor while also actively thwarting your opponents from making good on theirs. That struck me as odd– it wasn’t about stealing what they had, it was merely a scorched earth matter to ensure that they couldn’t prosper.

But taking a second look at it recently, I noticed that the CD-ROM has a VIDEOS/ subdirectory. Clearly, this directory holds the FMV for the game. Each FMV is actually spread across 3 files: A .VID file (I’m presuming this is the video data), a .SFX file (looks to be raw, unsigned, 8-bit PCM), and a small .SEQ file (I suspect this ties all the data together). There are 23 .SEQ files which are either 26, 37, 103, 114, 158, 312, or 1280 bytes large. These numbers all happen to be divisible by 11 if 15 is first subtracted away which leads me to believe that each contains a 15-byte header followed by a series of 11-byte records.

Meanwhile, the .VID files clearly begin with 768-byte palette. I don’t think that the frames are uncompressed, paletted images, or else the frames are not a common width.

I’m trying to remember a formula — I seem to recall something from the discrete math branch of mathematics — for doing remainder math, something involving an operator that looks like an equal sign but with 3 bars instead of the customary 2. It turns out that the concept I am searching for is modular arithmetic. I was hoping that this could lead me to a formula that would show me possible frame dimensions given the size of the files, but I’m too tired to figure it out right now. You’re welcome to study the files and their sizes, though.

MultimediaWiki page and samples, as is customary.

Do you have any idea who killed Jennifer Shefield?
How well did you know Jennifer Shefield?
What can you tell me about Jennifer Shefield?

Call me cold, but I just can’t bring myself to care about the above questions more than I care about what multimedia format is being used in an old Amiga shareware game simply entitled Murder, the demo of which can be downloaded in 11 .lha files from Aminet. LHA… does that ever take me back to the BBS days. That and ARJ.

Back to the format, though, it’s definitely not related to Sega’s FILM format (one of my all-time favorite formats). I think this may just be a series of Amiga IFF files with a header on them. This is because I see markers such as “8SVX”.

The files also contain curious advice about playback. Apart from a string that specifically stipulates “Motorola 68000 family”, there’s also this tidbit in the header: “Amiga Hint LIST subtype FILM requires that all CAT chunks are exactly the same size, start at long word boundaries (pad with filler chunks) and come one after the other right to the end of the LIST. Write to agmsmith at 71330.3173@CompuServe.com for more info.” I would email that address for the sake of due diligence but — darn — bad timing! CompuServe finally died just last week. The files were apparently made by a piece of software named AGMSMakeFilm which also seems to be available at the Aminet.

MultimediaWiki page and samples, naturally.