Kostya's Boring Codec World

So apparently there’s RIFF-inspired PAF format used in Bi-Fi racing game for DOS (essentially a promotional game for a local brand for sausage-in-a-roll snack).

It’s nothing to write a Multimedia Wiki article about but it’s somewhat interesting. Apparently it has one single CODE chunk that contains commands for updating frame—for all frames. It is pairs of (skip,copy) bytes that tell how many quads of bytes should be skipped on output or updated from the delta frames.

Delta frames are RLE-packed data in DLTA chunks, first 32 bits tell the unpacked data size, then it’s traditional RLE (top bit clear—copy data, top bit set—repeat next byte low seven bits times).

Apparently those files were intended to be used as an animated TV screen overlay on the jukebox background (maybe also for an intro but the CD-rip of the game didn’t have it). So on one hand it’s a mediocre format, on the other it’s somewhat interesting anyway.

Next I should explore the usage of a Duck codec on “iamaduck” console…

I keep looking at those, no significant progress yet but here’s what I have got so far:

• ClariSSA—I’ve managed to locate two routines in ssa.library that look like video decompression routines (one is more advanced version of the other SSA with over a hundred of opcodes, another one is a simple RLE) but I still don’t know how they relate to e.g. BEST or COST chunks inside IFF. Update: apparently it separates data like opcodes or plane values into those chunks, I’ll write in more details about it later;
• DeluxeVideo—haven’t looked at it that closely but it resembles more of an animation system (e.g. Macromedia Flash) than compressed video frames. Update: that’s because it is, the file essentially contains references to the actual sprites and backgrounds plus the commands and effects to apply on them;
• TheDirector Film—the player for the only known sample uses some LZ-based cruncher but I’m too lazy to spend time on reconstructing the unpacked executable (or mess with UAE let alone unpacking and powering on my expensive door-stopper with AmigaOS 4.1);
• Magic Lantern Diff—nothing much to say, looks doable. Update: it turned out to be RLE-based and I’m not sure but it might be coding data vertically like Zoetrope did;
• NTitler—this is essentially a binary script for the program, referring to external resources for everything and such. Not something particularly interesting or fun to look at.

And there you are. After I do what I can with these formats (though as you can see for two of them it’s “not worth looking further” resolution already) I’ll move to something non-Amiga entirely.

So I’m still looking at the list of unsupported video formats from dexvert in hope something curious comes by.

First, out of curiosity, I looked at the unsupported Delphine Software CIN files. Apparently they merely don’t have audio streams and contain garbage in an audio part of the header (plus they have 1-2 video frames). Ignoring the audio header makes them decode. Next.

Second, EA MAD file—apparently it comes from a game rip with audio and video files being dummied out so it’s easier to share. Nothing to look here in any sense. Next.

So, one of SSA formats (no, not that one SSA animation format for Amiga, another one). It turned out to be rather complicated RLE for bit-plane coding. I.e. frames are coded as several bit-planes with the codec commands essentially being something like “skip to this offset in the current bit-plane, then update following 16-bit values with these new values, then skip a bit more and update some more values then skip…”. There are different opcodes for run/copy of certain sizes (or ranges) plus some additional operations for repeating a pair of values (and I thought LinePack was rather unique at that).

I actually ended up hacking a some decoder. It does not seem to handle 8-bit palettes well and there are still some glitches here (just look at the letter ‘D’ in the following image) but in works in principle.

From technical point of view it was not that hard. Even if Ghidra failed to decompile decoder function properly (mostly because of the opcode jumptable) it was nothing hard, even if I don’t know M68k assembly, expressions like move.l (A0)+,(A1)+ are rather intuitive so I could figure out which piece of code, say, copied 18 bytes and which one replicated the same 16-bit value to those 18 bytes.

I’ll try to find something else to look next, there’s still half a dozen of potentially interesting formats in the list.

This is an old animation format on Acorn computers made by Ace Computing. It exists in several flavours.

There is bare Ace film that has barely any header (mostly just data size, title, some offsets) and chunks which start and end with the chunk size (so that you can seek backwards in the file). Then there’s chunked Ace film where all that data is wrapped into ACEF chunk with some other chunks following it (like RATE, FULL or PALE—the last one is for palette).

Presumably at offset 32 of raw data there is a compression method: 0, 1 or 2 (last one added in EuclidX). 0 means uncompressed data, 1 means LZW and 2 means unpacked data XORed with the previous frame.

Let’s take a closer look at method 1. It looks like a more or less conventional LZW. If the second byte of the stream is zero, the stream contains 16-bit little-endian LZW indices, otherwise it is variable-length LZW with initial index length being 9 bits (and value equal to 256) and growing up (the decoders don’t check upper limit but I suspect it should be around 16 bits). It also uses value 256 to signal the stream end and there are no other reserved values.

Apparently for convenience it decodes indices, stores them in the dictionary (it’s the property of LZW that each new index involves adding a new dictionary entry) and then decodes them backwards. After all, LZW dictionary entries are essentially stored in reverse so either you have to decode an entry, reverse and output it—or you can decode reverse string and output it at the end. This decoder chose the latter implementation (not that you can do it in any other way).

Unfortunately I’ve not managed to reconstruct data properly because of the implementation subtle details but I’m pretty sure anybody knowing how LZW works and willing to spend a bit of time fiddling with the format can come with a working decoder. As for me, it’s not interesting enough to spend more time on it. There are still several more ARMovie codecs to support and other formats to look at.

Considering the comment under my previous post, I had a better incentive to look at more formats. So here are two of them.

Since both are Amiga formats, here’s a summary picture:

First, Zoetrope Animation. The same ADF image containing BACKFLIP.rif has also the player sources (C + M68K assembly with comments). I have not studied them too closely but the main peculiarity of the format is that like its namesake it operates on image columns, employing simple RLE (and skip for inter frames). Also while it calls its format RIFF it has rather different structure (and may even pre-date more common RIFF by several years). And it seems to support different bitplane modes, as well as HAM.

Then, IFF VAXL. This is a conventional IFF with video properties inside VXHD chunk, PAD0 for padding, TMCD being always the same (is that a time between frames?), COLS containing something looking like some 12-bit palette entries, BMAP being of a constant size, SAMP probably containing PCM audio. But what about image data? Since it has a constant size fit for a 6-bit uncompressed image (and has 6 in the properties), I suspect it’s just Rohschinken uncompressed HAM (and trying to decode it as such results in a recognizable picture).

That was surprisingly easy but there are many more formats to look at.