Kostya's Boring Codec World

You know, the greatest reverse engineer I know is Derek B. He’s managed to RE such codecs as Canopus HQX and Cineform HD in the most efficient manner ever—saying he’ll do it and patiently waiting until somebody else does it.

So here are some words about his favourite lossless audio codec. The most interesting thing about it is that it was actively developed in 2001-2006 and then it was suddenly resurrected in 2015. Also it’s one of few non-standard codecs (i.e. not made into standard) that has several articles written about it.

The codec actually consists of two different formats, seemingly an old one and a newer one (that looks like it supports all range of sample type). The former is notable for having signal reconstruction stage using floating point math (a thing you don’t see in codecs every day), the latter seems to employ various parameter reading and reconstruction methods. Coding is done using low precision range coder (large values are decoded using chunks of 8 or 12 bits). So nothing really interesting there.

P.S. I’m definitely not going to write a decoder for it. There are too many lossless audio codecs already, let all proprietary ones (in custom containers too) die in peace.

In the previous post I gave general overview of codec changes, now I’m going to look more deeply at the filter changes with time.

• 3950 — current mode with up to three layers of IIR filters
• 3930 — simpler filters: no third layer (there was no insane compression level back then) and the difference between predicted and actual value was not used.

For the older versions there are differences in the implementations of the filters for the different compression modes.

Fast compression:

• 3200 — order 2 adaptive prediction (i.e. previously decoded and adjustable prediction value are used in prediction)
• 0000 — almost the same but with different rules for adjustment factor updating

Normal compression:

• 3800 — two layers of filters: order 4 adaptive prediction and order 2 afterwards
• 3200 — the same structure, different rules for updating
• 0000 — three layers with orders 3, 2 and 1 and different updating rules

High compression:

• 3700 — first it tries first order adaptive prediction with the delay of 2-16 (i.e. the next to previous element is used for prediction) and normal mode decompression afterwards (different decoding for 3800 of course)
• 3600 — the same but delays are 2-13
• 3200 — the same but delays are 2-7
• 0000 — orders 5 and 4 and different updating rules

Extra high compression:

• 3830 — an IIR filter resembling the one used in the newer Monkey’s Audio versions
• 3800 — some filter parameters were half as much as in 3830 and there was no delay 2-8 filtering
• 3600 — delay filtering plus high filtering (which is delay filtering plus normal filtering, which can be expressed as a layer of filtering over fast filtering)
• 0000 — essentially the same but with different prefiltering

While preparing for working on old APE versions support I finally got courage to try and trace all changes for different versions. So here’s the list of internal versions and the changes they introduced:

• 0000 — the reference version for all prehistoric version. Before version 0000 it was fine, then it all got worse IMO.
• 3320 — changes in the filters
• 3600 — changes in the filters
• 3700 — changes in the filters
• 3800 — blocks per frame changed for extra high compression level; changes in the filters (yawn)
• 3810 — frame start at byte boundaries now
• 3820 — special codes extension (signalled by top bit of CRC set to one)
• 3830 — filter lengths and some implementation details changed
• 3840 — CRC calculation algorithm changed a bit
• 3870 — significant changes in residue coding
• 3890 — small changes in residue coding
• 3900 — residue coding format has changed seriously.
• 3910 — small change in the residue coding (more than 16 bit values can be coded now)
• 3930 — significantly changed format introduced (both filtering and coding scheme were changed)
• 3950 — filter format changed a bit (and insane compression mode is added somewhere after that), blocks per frame is changed too
• 3960 — some small and compatible change in the bitstream (consuming two last bytes or not)
• 3980 — file format is changed a bit; filtering process has changed a bit too.
• 3990 — the latest (known) format. Residue coding has changed.

Do you still wonder why I strongly dislike this format?

By the request of one guy (he has provided samples as well) I shall work on supporting old Monkey’s Audio versions (before 3.95).

Why? Because the latest official version of Monkey’s Audio has dropped support for those files, because I wanted to support such files since really long time (just didn’t have a good opportunity to do that) and because I definitely need a distraction from Go2Insanity codec (I shan’t blog about it anymore).

Well, let’s see what the old versions of the worst (known) designed lossless audio codec have to offer me.

Thanks to Peter Lemenkov who pointed me to this Monkey’s Audio decoder implementation. It has four strong points: GPL, C, small and clean. Oh, it also takes less memory too.

The only drawback is that old APE files are not supported (but nothing can play them on PPC anyway without x86 emulator) so I’m eager see APE support in MPlayer, Xine, VLC (or maybe it’s there already?). Preferably via libavcodec 😉

Why should I bother about Monkey’s Audio? Because many pirates good people offer classical music in this format (FLAC is quite rare and I’ve seen WavPack only once).

What I consider wrong in Monkey’s Audio design:

• No verson compatibility – each version alters decoding process
• Huge blocks – some megabytes is huge indeed (WavPack – 64k, FLAC – even less), hence inaccurate seeking and big memory requirements
• “Insane” profile – if it does not decode in realtime on my CPU that is unusable

What I consider wrong in MA implementation:

1. There is only one implementation (with two known ports)
2. It is not endian-safe (both generated WAV headers and < 3.92 decoding)
3. OO in that case means “Object-Obfuscated” (i.e. too many files where you can’t easily find required code)
4. Custom license

Maybe during GSoC somebody will write easily understandable portable decoder in Lavc that will allow playback of .APE in FFplay,MPlayer,VLC,Xine,etc. Otherwise I’ll have to do it myself.

There are currently 14 lossless audio codecs mentioned on MultiMedia Wiki page (look here for further links):

• Proprietary (Apple Lossless, Meridian Lossless Packing, Real Lossless, WMA Lossless)
• Closed source (LA, LPAC, LTAC, OptimFROG, RK Audio)
• Open source (Bonk, FLAC, MPEG-4 ALS, Monkey’s Audio, Shorten, TrueAudio, WavPack)

FFmpeg currently has decoders for Bonk, FLAC, Shorten, TrueAudio and Apple Lossless. So, there are at least MPEG-4 ALS, Monkey’s Audio and WavPack decoders can be added.

I will work on WavPack decoder and ALS (I hope standard will appear soon). What about Monkey’s Audio? Yes, it’s popular but it has following difficulties for implementation:

1. It has incredibly large  frame sizes (it may be more than one million samples) while competitors stick around 64k or less (hence the compression gain for MA). Current FFmpeg design cannot handle such frames.
2. Source code is a mess – for almost every action there are at least several if(ver >= …) or if(ver< ...). Format is too unstable for me.

Well, I still hope it will be implemented some day.