SRF Extractor

As I now know enough about this to reliably decode most of the SRFs that are out there (no animations, but I will eventually work on that, I hope) – I’ve been working on a little tool that lets someone load a file, save out what’s relevant and play the sounds. I know there are a few tools out there, but I’m trying to make this one multiplatform through Java. Currently I have a proto build working on Windows that plays the PCM coded audio, but the finished version will play the compressed speech too, even if I have to decompress on the fly.

More on this as I get it together, but SWT isn’t exatcly something that lends itself to multiplatform, and I want to get this running on as many systems as I can, including OSX.

SRF Extractor

Caution: contains strong language

So, having started to play with the early build of the YDKJ SRF extractor and started to notice a few things. Firstly, the very first version of the YDKJ game engine attempts to make it harder to use the SRF sound content for certain files by changing the Apple codec id to YDKJ (for the record, it should be ima4, as these are Apple IMA ADPCM files). Not to difficult to work around. The other thing is that the question pack ‘upgrade’ actually censors part of the game. With the standard warning that all of the files in question, and the explanation of what occurs contains offensive material, you can make the comparison yourself at The Cutting Room Floor.

Many of the other titles have this easter egg in a clean form, but the code to trigger it is different for the foreign langauge editions, obviously.

Caution: contains strong language

Sound (and text) on, vision… nah.

So, a game that revolves almost entirely around speech and text needs to have a method to run this stuff quickly off the CD. Since Berkeley Systems were mainly Mac guys at the time, they seem to have gone down the route of just calling the System 7 sounds/Pascal strings to play them.

Sure enough, if you find an audio file in an srf (either under the name ‘snd ‘ or with an appropriate name tag for the engine script like ‘Mj19’, the offset and length just point to a perfectly standard SFIL. For the text, again it’s a perfect Pascal String with null termination.

This means that implementing an extractor for this format is largely straightforward, just a matter of converting the SFIL to something playable. The main issue remaining is the graphics file, a format developed seemingly by Twitter UI factotum Tom Wuttke ( I would wager that this is run length encoded, with maybe some pure LZS/Doublespace compression in there too to paint images to screen.

If anyone knows enough about Apple era graphics, I can probably get you a sample together to play with, there’s clearly two different encode methods depending on whether it’s an animation or a static image.

Sound (and text) on, vision… nah.


This is going to be a repository for my findings as I start to pull apart the original You Don’t Know Jack game engine (as first seen in 1995).

The games use a combination of audio and basic animation, but run on low spec PCs and the early Power Macs. All the data is stored in a special archive format (srf), which looks like it can embed the audio and video with a good compression rate.

So far, here’s what I know about the SRF setup (as posted to )

Format Specifications

char {4}   - Header (srf1)
uint32 {4}   - Archive Size

// for each file

uint32 {4}   – File Size (including these two 4-byte fields)
char {4}     – File Type/Extension (32 terminated)
byte {X}     – File Data

Essentially, each file has a header that points to all of the resources, which store the name, size and offset of the file in question, permitting separate streams to be recorded in the same file. It’s like a standard Mac resource file, but grouped by type, and shorn of attributes (since these are read only).

So far I’ve noticed three filetypes stores – a simple text string, a file format similar to the “snd ” or .sfil format for Macs, and something that looks vaguely like a quicktime RLE animation. As a Windows user, .sfil is hard to work with, so I’m currently looking into converters (I know the newer Quicktime for OSX no longer supports it). In my next post I’ll dig into more detail for these files.