#chemicalexperiments — Saumagen

June 15th, 2026

I think it’s time to talk about the würst aspect of German life.

It is a stereotype that Germans love sausages, and it seems this stereotype has some background after all. What’s more, as I learned from one fountain in Kandel, the nearby area of Rhineland Palatinate was known as the Cattle Belt—and you can guess what they made out of that cattle. One of those specialities is called Saumagen or “pig’s stomach”, a sausage made by filling the namesake with meat, diced potatoes, spices and boiling it (some people prefer to fry it afterwards anyway, making it to spiritually resemble haggis even more despite sheep not being involved at all).

Initially I learned about it when I bought various kinds of tinned sausage from Landau at the local supermarket (yes, it is common here to sell sausage tinned and even rural butcheries produce it), but in the recent years with the spread of vending machines in rural areas offering local goods I had a chance of trying more varieties of it (those machines work every day while almost everything is closed on Sundays—exactly when I have time to travel around). So I’ll describe what varieties of saumagen I’ve seen before mentioning other curious sausage-related things.

Weisenheim am Sand is the only place (so far) offering saumagen in slices (vacuum-packed) in addition to tins. It’s nice but it had a bit too much mustard seeds (or maybe it was marjoram) to my taste.

Kirchheimbolanden offers variety with the most ingredients: it’s the only one I’ve encountered that added carrots as well. Also it has the other variety of it like in St Martin.

Speaking on which, St Martin had the best saumagen to my taste. In addition to the regular version there’s another one with chestnuts instead of potatoes. Even the fact that they add a bit of beef to it does not spoil it at all. The funniest unrelated fact is that I bought it from the shop that was open on Good Friday (it is a rare occasion when something is open on public holiday, especially on public Catholic holiday in former part of Bavaria).

Maybe I’ve seen and tried it elsewhere but those variations didn’t leave an impression. Unlike the one variation that I’ve not tried and yet it left an impression: I’ve seen this exotic dish being advertised at some restaurant in Lorsch (which is a part of Hessen and lies on the other side of the Rhine).

There are other interesting mentions (with my health I should not eat meat much or often—so I don’t, and probably there are a lot of other things that I’ve never seen; but that’s for other people to talk about). For example, in Bavaria it is common to have a version of common dish made from liver (hence my test for maultaschen not being Swabish—otherwise there would be the ones made from liver in Bavaria like it happens with spätzle). Though they have Leberkäse, literally “liver-cheese”, which contains neither.

And in Württemberg I’ve encountered at least twice Bologna sausage with boiled eggs (it makes me think of Scotland for some reason once again).

For the traditional sausages I prefer käsekrainer which are available everywhere in varying thicknesses and lengths. The best ones I’ve ever tried came from Sasbachwalden (which is worth visiting for other reasons, it’s one of the most scenic places I’ve ever seen).

That’s the story with the sausages: you pull one link and another one comes after it. I started with one specific local variety of sausage, overcame a desire to talk about local vending machines that can sell e.g. ice cream instead (not something you’d expect to see in a random village), still ended mentioning some bits of geography and local customs as well as other food articles. More talented person could write a book about German history viewed through a sausage ring (and it would be a very entertaining read!), but all I can manage is this pathetic post.

P.S. And from a small biased review the most impressively decorated butcher shops I’ve seen were in Bad Kreuznach, Ingelheim am Rhein and Durbach (the one near Offenburg).

Posted in #chemicalexperiments | No Comments »

MOVing Puzzles

June 14th, 2026

Mostly because of the weather I have not been in mood to work on anything serious for weeks, but here is something rather interesting.

Apparently there are some CD-ROMs represented on discmaster titled “Moving Puzzle: …” that have some .mv files (inside media.pak archive) that supposedly give motion to those puzzles. And of course somebody had to look at the format.

Obviously the format was inspired by QuickTime as it has the header with all those chunks defining per-track data including e.g. sample-to-chunk mapping. There are two main differences though: the format is flat as first you have header size and header chunks following each other without any nesting (so when you encounter the second track header chunk the following chunks will belong to this new track); and the data is little-endian there, both numbers and tags (e.g. “ssiz” which is sample sizes chunk is written as “ziss” instead, same for e.g. codec IDs). Luckily I could ignore most of it as the data seems to be stored without gaps, so reading palette, then seeking to the first video chunk and reading individual samples(frames) from there works fine.

And it has its own two codecs, RLE and LZSS. RLE has two modes, both coded the same but inter mode storing the difference from the previous frame (not even XOR, simple subtraction by modulo). LZSS is not the usual flavour either. Unlike the most widespread scheme of “read 8/16/32-bit flags, treat the following bytes until next flags as either literals or packed 16-bit LZ offset+copy length combination” here it is a continuous bitstream with offset and length bits being signalled in the bitstream header and offset zero being used to skip decoded data (since you decode to the frame buffer, it leaves some bytes of it unchanged). Nothing groundbreaking but you most implementations hardly make any changes from the original LZSS.C and right now I can only think of JAM format which implemented LZSS with copying from the reference picture.

IMO this is an over-engineered system but that’s what makes it interesting to look at.

Posted in Game Video | No Comments »

AI-coholism

May 29th, 2026

With this matter, I hope I actually shan’t have more to write about. But this thought needed to be written out (only if to unload it from my head).

For some reason the current state of affairs around “AI” reminds me a lot of alcohol. Mind you, it’s a useful substance (as a solvent or a disinfectant), some people may even use it in recreational purposes or to deal with stress—but there are always some people abusing it, often for no good reason, and giving bad name to it all. Also there were countries whose budget was largely dependent on alcohol over-consumption but that’s less important here.

The situation with “AI” assistants looks entirely familiar: some people use it responsibly and even achieve useful results with it, but it’s usually other people (a loud but hopefully still minority) who abuse such tools to the point they get high with imaginary power and behave themselves as typical drunks: some boast how much they can consume (tokens or pints of beer), some vomit uncontrollably (you can see the results on GitHub—when it is still up of course), some suffer from neuro-toxic effects (and can’t move or code straight any longer without an external support), some lose all internal restraints (there’s little difference between alcoholics raising ruckus because their favourite liquor store is closed when they want to get a drink and AIcoholics trying to push slop to some project without caring what the change does and why the project in question doesn’t want to accept it). And occasionally you can see the entertaining stunts that would cause normal person a serious damage (like falling from a third floor or deleting a production database) but with a person in question not realising that at all.

Hopefully the situation with “AI” will mature and normalise so that the technology abusers will be shamed for their actions and become an exception instead of current “sport fans right after the match” vibe.

Posted in Useless Rants | 2 Comments »

We have FLI at home

May 29th, 2026

Recently I’ve released na_eofdec, a tool for decoding exotic and/or obscure formats. That release included F16 format support, but recently I’ve REd another one (PC Animate Plus / 3D WorkShop animation) and there’s yet another one waiting in the queue (Reflections animation). What unites them all is that they all employ simple compression schemes (mostly RLE-based) and (beside F16) they all have a 3D modelling program associated with them. And I’ve REd these formats by investigating the file format, they’re that simple.

F16 posed itself as “FLI but 16-bit” and it looks like its creators have failed to build an ecosystem out of it. I have encountered merely two demo samples at discmaster and nothing else. From technical point of view it’s either uncompressed intra frames or the rather familiar FLI delta compression scheme with its number of skip/run opcodes per line, just with small variations.

PC Animate Plus is more interesting as it has 4-, 8- and 16-bit content compressed, at least two format versions and several compression schemes. Plus it has some additional chunks for complex operations and even metadata telling e.g. which Voc file to play along. Intra frames are RLE-compressed, inter frames usually employ FLI delta compression (with small changes of course) but there’s another mode consisting of offsets and chunks of data to update. Another interesting thing is that it does not replace old pixels but XORs them with new data instead (maybe it comes from an alternative universe where 80×86 had REP XORMOVSB instruction).

And there’s Reflections animation. While I haven’t written a decoder for it yet, I can describe it already. I’m aware of three samples with rather uncommon 320×256 resolution and big-endian format. First frame is uncompressed, the rest seems to be simply “skip N 32-bit words, update M 32-bit words”. Writing a decoder for it should not be that hard… An update from the next day: it’s simple RLE with opcodes being skip/repeat/copy but the actual data is stored in 4-pixel columns format, so e.g. copying 8 pixel quads will result in 4×8 rectangle.

Individually the formats are nothing to write about but together they form a group of FLI clones that poses some interest. Now that I’m done with MVS it’s either extending QuickTime support in NihAV or REing obscure formats, hopefully it will give me more material for my writing.

Posted in Various Video Codecs | No Comments »

FFhistory: first slop

May 27th, 2026

While I observe the world with its “AI” evangelists suspiciously reminding of annoying religious missionaries (yes, I’m pretty sure I’ve heard the news from that newer part of widely circulated book that’s just under two millennia old, thank you very much) and the feats of token-wasting (name changed from “vibe-coding” to keep up with the times) like two FFmpeg rewrite attempts in Rust—probably just to spite the Nigel (name changed to protect the guilty) formerly responsible for FFaccount, since slop in any other language would be as smelly secure. Since I don’t use either of those three projects, I’d rather talk about the time when FFmpeg almost got its first organic slop.

People submitting sub-par patches are no news (as there were e.g. mediocre H.264 encoder rejected for not being good for anything really—x264 is a tough competition after all; or MS Video-1 encoder initially rejected for the same reason but later merged because it’s a feature), but this one is special because it had all signs of the modern “AI” slop while being produced organically more than a decade ago: doing something tangentially related to the original goal—check, being lots of incomprehensible code—check, a lot of effort wasted onto it—guess for yourselves.

This happened when a guy from a group Programmers Doing Awesome Things (name changed to protect the guilty) was taking part in Baidu Summer of Code (name changed to reflect company values) with his project being a support of a certain audio format. What we got instead was a large library doing something more generic; in theory it could be used to decode the audio format in question but I think nobody has found out how to do that. The reaction was more “uhm, thanks” and while that student was not failed (at least that’s what a quick search tell me), the library has never merged and probably it’s been completely lost in time by now. My memory is not as bad as it was back then (yes, it’s even worse) so I can’t remember if there were actual attempts to make something out of it afterwards or all hope was abandoned outright. At least it gave us all a distinct memory and a short-lived meme of “nicknamePDAT” being used by various developers for a while.

I often think about it when I see these new projects with whatever insane amount of tokens wasted on them. They seem to include everything and then some more. For example, one of them (name withheld since I believe they don’t deserve any advertising) supports a handful of formats and compensates that by adding a lot of features that (theoretically) would make it do anything—from game streaming to mastering IMF for broadcasting—with only GUI being missing. Another one (name withheld for the reason stated above) does not have those features but it compensates it by the plethora of formats being supported. So if you ever thought that FFmpeg definitely needs its own vector font rendering (for e.g. SVG and PDF support because of course they’re at least planned to be supported) or that it’s not usable without 3D scene rendering capabilities then this slop is definitely for you! Also it’s fun to watch how it undoes its own progress by trying to make “AI” developer to plagiarise less (so now it’s all based on the “AI”-generated specifications that nobody can see).

You know what could really improve those projects? Actually having a point. I know that the main goal there is to make money off it (and it even works for some FFmpeg developers, so it may work here), but in order to achieve that it needs to offer potential users a solution for their problems (again, like FFmpeg started with open-source implementation of decoding and encoding popular formats based on H.261-H.263 and grew up from there into something that most people use to decode or convert their multimedia content). And a pile of code that does everything and nothing at the same time is not it. Actually I encountered one of those project by searching a crate with libxvid bindings (and got only that thing in the search results, which doesn’t support even what my decoder does let alone the stuff I’d rather use libxvid for).

There was a joke about one hardware company (name not given since I forgot it) that its motto was “ready! shoot! aim!”. With modern tools people are so excited that they can shoot a lot, with minimum readying time, that they forgot about aiming entirely. So I’ll wait aside while the rest have fun shooting bystanders and themselves and keep doing what nobody else cares about.

Posted in FFhistory, Useless Rants | 4 Comments »

na_eofdec initial release

May 11th, 2026

Since I got lucky during weekend with some formats, I got enough of them to release na_eofdec. This is a tool similar to na_game_tool but oriented at generic exotic and obscure formats (or Amiga ones, put them into whatever category you like). So if you’re familiar with that one (why?!) you should have no troubles with the new one either (or at least it should be the same troubles).

The motivation behind it is about the same as with the other tool: decode whatever formats I find interesting enough to implement decoders for but not interesting enough to have them supported in the main NihAV base. Also it serves as a playground for various other things (like MOV muxer in this case, which served as the base for more versatile muxer in NihAV).

Anyway, it is released in hope (but no expectations and definitely no guarantees) that it will be useful for some purpose for others. The release is available at its own sub-page at nihav.org (and there’s a link to it in the appropriate section of this blog too).

Posted in NihAV | 2 Comments »

NihAV: QT support enhancements

May 8th, 2026

When I have enough inspiration, I improve NihAV. When I don’t (which is more common state to me), I RE codecs or write blog posts—so here’s one.

First of all, I’ve started adding non-raw encoders for some common QT formats. It’s not that there are no open-source encoders for them, but I do them mostly to find out how it is done and maybe learn something new in the process. For instance, RLE encoding combines skips, runs and pixel copies; this rises the question of optimal encoding as sometimes it may be cheaper to encode a whole area as new pixels instead of a mix of copy+skip+copy. So I’ve implemented a greedy approach (i.e. code longest skip or run and fall back to encoding raw if those two fail) as well as slow but optimal one. It’s a variation of trellis coding: just calculate encoding cost with each mode (skip/run/raw) to all next possible positions and if it’s lower than the existing one, use that mode; at the end simply trace back the decisions that gave least cost at the end and encode them in right order.

Then I also added RPZA encoder. This is essentially the first texture codec before GPUs with the need for texture compression, its main compression mode is encoding 4×4 block with four colours where two colours are linearly interpolated from two explicitly transmitted colours. There is no apparent way on how to do it fast, so I ended up with an extremely simplified scheme: first I calculate the maximum difference between components and pick the one with the largest difference (or code block as single-colour if it’s small enough) to decide what values to pick, then I calculate explicit colours from an average of input pixels close to minimum and maximum ends of that range. I also have a refinement step by running vector quantisation loop to adjust the ends but it’s rarely needed in practice.

There are still more encoders to implement (SMC, SVQ1, IMA ADPCM and MACE) but none of them is interesting beside SVQ1, so probably I’ll write about it when/if I ever get to implementing an encoder for it (it does not matter if The Multimedia Mike has done that over fifteen years ago—NIH is there in the project name for a reason).

Now, surprisingly enough I’ve improved decoding support as well. The original QuickTime had SIVQ codec which is a straightforward 256-entry codebook for 2×2 RGB24 tiles followed by codebook indices. I had read its binary specification some time ago and recently I was able to locate (probably the only existing) sample for it, which is a good reason to write a decoder for it. It was well-spent five minutes of my time. Maybe in the future I’ll also do something about Pixar codecs (Ghidra works better with raw m68k version of the decoder than with 16-bit Windows 3.x version of the same).

And finally I’ve improved the support for multi-descriptor MOV files. I mentioned it some time ago and I got bitten by it again recently. For example, alice_lo_m.mov from samples.mplayerhq.hu got just first frame decoded for me and many QuickTime 1.5 sample videos (with its developers) gave an error on the last frame. For the former it’s because first frame is JPEG and the rest of them are SVQ1, while the latter samples are coded with Cinepak but the last frame may be a special one encoded with RPZA. And there was another file fully encoded with RPZA—but with the majority of it being 160×120 while last dozen of frames or so were 320×240. So I finally got annoyed enough to implement multiple streams per track so at least the frames get marshalled to the correct decoder, even if it leads to the partial streams being rather unusable. Maybe one day I’ll write a tool which will walk through MOV and render all tracks in correct sequence (taking edit lists into account), scaling and adjusting playback rate as needed, producing a raw MOV file that can be played without special hacks; or maybe I don’t hate myself that much.

That’s it for now, don’t expect anything soon (MVS description may appear but who’s waiting for that?).

Posted in NihAV, Various Video Codecs | No Comments »

Quickly about AC2

May 2nd, 2026

I’ve finally had a look at this codec and it’s not particularly remarkable (and I did it mostly because it beats documenting minute details of MVS).

Anyway, there’s nothing much interesting about it. Like its successor, it employs parametric bit allocation to read bits from the input block. The main difference is that there are only two channels allowed and there’s single block per channel too. More curious thing is there are two revisions of this codec, with revision A having simpler bit allocation while revision B has additional tables (dependent on sample rate of course) to adjust how many bits per band will be eventually read. Also unlike successor there are no tricks to allocate fractional amount of bits per band, it’s always an integer amount of bits.

From coding side it seems to be more or less straightforward MDCT with the only interesting trick is splitting frame data into sums and differences (not channels but the subsequent samples in frequency domain) and coding them in such separate matter.

Overall, it’s a simple perceptual codec (and a half, considering revision B) that worked not that bad. And considering the claims given here, I suppose it was essentially equivalent to MPEG I Layer II. At least it’s more interesting than a bit of audio coding bolted to the (patented of course) DRC and named AC4.

Posted in Audio | No Comments »

NihAV: palettisation

April 30th, 2026

While I’ve added palettisation support for NihAV about six years ago, it was limited to per-frame palette generation back then. Since I had only two encoders supporting paletted input and both were accepting palette changes, it worked fine. It’s only when I decided to implement MOV muxer I really got a need for palettisation using global palette, so I’ve started experimenting with that.

First and foremost, design. While frame palettisation is a part of NAScale that handles video frame conversion from and to various formats, this palettisation mode is bolted to nihav-encoder. It is actually implemented in two parts: initial pass that decodes input and generates palette at the end, and actual frame palettisation (which can actually work just fine without that pass if you tell it to use some pre-defined palette). I actually started with the second part and added palette generation later (for tests using default QuickTime palette was enough). Then I went even further and extended palette generation to support segmented mode (i.e. palette may change but not for every frame, I made the limit configurable but it should be at least 10 frames—storing palette for each frame before processing is too much).

This mode is a bit fragile since palettes are calculated for the decoded frames and not for processed frames. And for palette segments it’s even worse since it tells the number of frames for which the palette is valid, so framerate conversion will make it a mess. But the alternative leads to madness libavfilter and that’s hard pass for me. I see filters more as a drug that makes multimedia projects shift attention to them, making it more and more about e.g. filter negotiation and complex graphs support and less about playing actual media; consequently, making everything a filter is a sure sign the project is on its way to becoming obsolete (yes, I don’t hold neither DirectShow nor gstreamer in high regard).

Anyway, after overall design description it’s time to talk about implementation details. Palette generation for video differs from palette generation for single image by the sheer amount of data it needs to take into account. So while I have “let’s waste memory and have a table of 64-bit counters for each possible colour” my first mode was putting colours into smaller buckets (bucket index is calculated from the top bits of components) and join similar colours (e.g. differing just by two low bits in each component) when the number of entries gets too high. It is slower and not as accurate but it consumes less memory and performing vector quantisation on hundreds of thousands of entries is much faster than on millions. So it may have its uses.

Then palette segments generation. I don’t do anything fancy and simply calculate coarse colour histogram to decide when to start a new segment. For cut-off criterion I selected the ratio between correlated histograms and auto-correlated new frame histogram. If they’re of about the same magnitude then I can add this frame to a group, update group histogram and continue, otherwise I generate palette for the just finished segment and start a new one. It’s naïve but it seems to work reasonably well.

Palettisation itself consists of finding an appropriate palette entry for the input colour (I’m aware of dithering but haven’t bothered with it yet). I use the same three methods as back then: brute force search, local search and k-d tree search. The latter is faster than the rest but gives horrible quality so I don’t know if I should improve it or throw away. Local search (especially with a small cache for last 32 results) is a nice trade-off between the rest. And brute force search is implemented by filling a small 16MB table which maps each input colour to the palette index; it is slow to generate but it works extremely fast with global palette and reasonably large video (i.e. more than those sixteen million pixels). For segmented palettes it’s better to use local search though.

That’s it. I realise that I’m the only user of such feature but it gave me something to play with and brought some joy implementing it. After all, who else can claim he converted movieCD into animated GIF without using any 16- or even 32-bit code?

Posted in NihAV | 2 Comments »

Quickly about Factor 5 VID 1

April 24th, 2026

Yes, calculating that results in VID5 but in reality it’s MPEG-4 part 2 (minus some parts). Paul has asked me to look at it some time ago, so I did (which is much better than implementing a decoder for it).

As I said already, this is essentially MPEG-4 part 2 with some insane parts being cut off (but not enough to turn it back into ITU H.263): there’s no support for special texture shapes, interlacing or even quarterpel motion compensation. There are still B- and S-frames to complicate things though. Bitstream format is cut down as well to remove most of the nonsense (or omgFFeatures if you have that view), so there are just frames containing basic header (or slightly less basic with GMC and S-frames) plus macroblock data. Macroblock data is almost identical to the expected format—they even still have sync pattern handling in MCBPC despite there being no need for that.

So on the one hard writing decoder for it is not that hard, as you can simply hack an existing decoder for that, and hard enough at the same time (because you either need to hack an existing decoder or implement it yourself and that ISO standard is not easy to comprehend and personally I decided not to touch S-frames at all and if the need arises I’m actually considering making a wrapper for xvidcore instead).

Meanwhile I still have MVS to document and lots of encoders to write to make use of my new palettiser (because so far I have just three codecs that can encode paletted formats—two of them are for AVI, one is GIF, and none are for MOV). So hopefully I’ll have something more interesting to write about next time.

Posted in Game Video | No Comments »

« Older Entries