Archive for March, 2013


Saturday, March 23rd, 2013


I think this should be in every first aid kit.

On some screen codecs

Tuesday, March 5th, 2013

Recently my attention was drawn to two screen codecs. So I’ve looked a bit closer at them (I’m not going to implement them — at least now, simian audio codec is waiting) and here are the most interesting bits to me.

Dxtory codec. I don’t know if it uses prediction or not but the coding is extremely simple: read unary code (1-8 bits), if the code is 8 (escape) then read byte for a new value, otherwise retrieve value from LRU list and of course move/put the new value to the beginning of that list.
The organisation into slices and decoding for different colourspaces is trivial.

Mirillis FIC Video. This one has more complexity: it operates on 8×8 blocks. Block is coded in the following way: if the flag is present then the block is skipped, otherwise read 7 bits for the number of coefficients to decode and the coefficients (signed exp-Golomb coded). Zigzag scan, IDCT, output.


A new record

Monday, March 4th, 2013

I thought that there’s no codec more horrible than Go2Despair and was proved wrong again. Here’s the even worse pair: Dxtory codec and its standalone companion PackBit.

DxtoryCodec.dll is 8.2MB which rivals Go2C++Hell because it’s standalone decoder without any additional code. PackBitCodec.dll is even more elegant. Of the total size of 672256 bytes more than 357000 bytes are occupied by the code of one function (that’s 3-6 times more than the ordinary zlib-based codec complete DLL file). Truly some people should not be allowed to program.

More about Monkey’s Audio filter changes

Sunday, March 3rd, 2013

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