Facebook Twitter LinkedIn Translate Favorites More Services
Blog Translate with Google  

My take on SDCS


  The Sloot Digital Coding System is not about compression
zondag 17 september 2006

As many, I was pretty intrigued by the Netwerk television documentary on the book “De broncode” (the source code) by Eric Smit, economic journalist. The book describes the incredible invention of an extreme compression method by which it would be possible to store an entire movie on a chipcard. The inventor, Jan Sloot, took the secret of his invention to the grave when he died in 1999. I usually recall this story at the end of a lecture on compression in my Digital Heritage course, and encourage students to go and watch the documentary. It always manages to leave some of them startled and just as intrigued as myself.

It’s easy to debunk the idea that it would be possible to compress a multi-gigabyte movie into the 512 Kb (512 thousand bytes) that a chip on a modern chipcard can store. The Dutch Wikipedia page on Jan Sloot contains a lengthy argument that this could simply never happen (an argument that, as I will counter-argue, misses the point of Sloot’s system).

So what is the Sloot Digital Coding System, if it isn’t plain compression? Roel Pieper has already given the answer, although it appears to have evaded the attention of most. Pieper is an influential Dutch IT-enterpreneur, and was involved in a very interesting but hazy way in Sloot’s invention (in the above photo, Pieper can be seen at the far left, next to Jan Sloot). On the rare occasion that he commented on the invention, Pieper was quoted in the Twente University weekly (translation by Pieter Spronck) as having said

"It is not about compression. Everyone is mistaken about that. The principle can be compared with a concept as Adobe-postscript, where sender and receiver know what kind of data recipes can be transferred, without the data itself actually being sent."

So it is not about compression, but rather about having some background knowledge, shared by the sender and the receiver, that the transferred message (the information on the chipcard) merely refers to. In Pieper’s example, the postscript document format and its successor PDF, this shared information concerns the fonts. If sender and receiver have the same fonts, documents transmitted between the two only need to contain letter codes; no font needs to be transmitted. Fonts can be bulky, so this saves considerable bandwidth.

Compression with shared resources

This is not compression, this is merely clever information transmission economics. Or, if you still want to call it compression, then call it compression with shared resources. An important trait of regular compression is that it is self-contained; a blob of information can be compressed by anyone and decompressed by anyone else, without needing any external resource but the decompression algorithm. If, however, the sender and the receiver share some background resource, which in strict compression terms would be considered cheating, it is possible to transmit very short coded messages that merely point to the shared resource.

The various and confusing accounts of Sloot’s invention-in-a-box mention that he indeed used some kind of resource, either stored on a hard drive or on some flash memory. This means we can reason with the realistic assumption of having not only a compressed media file and a decompression algorithm, but also some shared resource that the decompression algorithm can use while decompressing the media file.

Let’s work with the modest assumption of having 4 Gb on a flash memory that we will use for storing the magic resource on. Now suppose that you fill this 4 Gb with lots of tiny snippets of video and audio. One video snippet, for example, represents the red, green, or blue component of a video frame (one of 24 per second) of, say, 680x550 pixels. Storing one uncompressed video snippet, sampled at an 8-bit coding, will cost 680x550x8 = 3 Mb, roughly. But surely we want to, and indeed can, compress this; let’s say we do this, not with a video codec, but with good, clean, static compression (think JPEG), down to 5 Kb for one snippet. (Note that a CD-video only uses about 1.5 Kb per color per frame - but that is only possible by using frame-redundancy-sensitive codecs, which I am not assuming here.)

So on our 4 Gb flash memory we can store about 800 thousand snippets, each identifyable with a unique 24-bit number. This is now our repository, that sits in a tiny black box connected to our TV-set (some other components in the box being a few computer chips on a small mother board, a D/A convertor and some video connector).

Let’s now imagine going to a future video rental store and getting a chipcard with the movie “Steve Zissou’s Adventures in Space”. On this chipcard, the film’s 130 thousand frames (90 minutes x 60 seconds x 24 frames; one frame is 4 snippets for the red, blue, green, and audio components) are not stored as such, but indexed by 130 thousand (frames) x 4 (components) x 24-bit numbers, costing about 1.5 Mb. Oops - a chipcard can hold only 512 Kb. Here I will assume that it will be possible to compress (losslessly) the sequence of 1.5 million bytes to one-third of that. Or, we wait for chipcards that can hold 1.5 Mb. Bear with me please.

Now you say, hey, you have not compressed much here. Besides the 1.5 Mb chipcard, you need a good part of the 4 Gb of flash memory to store one movie; that’s only about a half of what a DVD-quality file costs. Essentially you have stored the entire movie on the flash card. In a rather cheating way, your player already contains the complete movie; with the chipcard, you have merely bought your ticket to unlock and watch it.

A business model and an explanation

I am not the commercial type, but I can imagine an IT entrepreneur will like this scheme, and can distill a business plan out of it. But it takes more to interest an entrepreneur of the Roel Pieper level. Sloot’s player was reported to contain and play 16 movies simultaneously and smoothly on a 1999 PC, using a resource that, supposedly, in one of his demonstration boxes was not a hard drive or an optical disk like a CD, so its storage capacity might really have been of modest size, ruling out the straightforward storage of 16 complete movies compressed to CD-Video format.

So, Sloot’s miracle player was capable of very rapid retrieval of frames, and had very swift display routines, while at the same time his modest repository did compress movies beyond CD-Video compression rates.

My explanation is the following. Earlier, I assumed that Sloot’s method works with individual frames, not with the ubiquitous redundancy-based compression methods of the MPEG family, and I assumed that the red, green, and blue components of each frame could be compressed JPEG-style to 5 Kb. To store all frames of all 16 movies, a 4 Gb flash memory would only have 480 bytes of space for a snippet (a red, green, blue, or audio component of a frame), which does not seem enough.

I think that Sloot tried to reuse snippets wherever possible. For example, whenever one snippet is very similar to another snippet, possibly from another movie, one of the two can actually be dropped; the 24-bit code in the bit sequence encoding the dropped snippet can simply point to the snippet that is kept. The goal would be to find as many “prototypical snippets” as possible, like totally black (no red, green or blue) frames, or silent frames in the audio component, that could stand for all (almost) black and silent frames in all movies in the repository.

This is only a half-way explanation that does not solve the mystery of the smooth simultaneous rendering of 16 movies at the same time. What I assume is that the display of a single frame in the Sloot player, involving the decompression of four compressed component snippets, producing the entire frame as if it were a picture, is faster than the context-sensitive rendering of a frame in an MPEG movie. MPEG does not decompress a complete frame image, but builds it by applying changes to the previous frame. MPEG encoding allows high levels of compression, but the trade-off is that it is computationally rather costly. Sloot’s complete frame rendering method might just have worked at a rate that allowed the rendering of 16 (movies) x 24 = 384 frames per second simultaneously. In terms of the component snippets I have been assuming all along, the player would need to be able to retrieve 1536 snippets per second, which, with the proper tricks (hashing, memory mapping) should be doable in less than that; I can only imagine (in a wishful kind of way) that uncompressing them, putting them together, and displaying them, plus generating the audio, could be done in the remainder of each second.

In sum, thinking about the possibility of a static repository of (partly prototypical) audio and video snippets that would fit in a few Gigabytes in a really tiny video player, and would play movies coded on single chipcards that you insert in this player, I must say I can’t write off the idea of Jan Sloot entirely. Can you?

But if it were so easy, why is it not a product yet? If only Roel Pieper would answer that question.

(A note: I rewrote this blog on January 4, 2007, to reflect some afterthoughts.)




You're allmost there. Sloot just used an analog converter. The analog signal was created by a device that was parametrized by the data on the chipcard. The precise digital measuring of the output of the analog signal then generates the digital sequence. Digital compressors are extremely limited because computers use "integer" or "real" data to work with. Analog systems can contain millions (some unlimited) of times the quantity of information that digital systems contain.
Sloot was a tv-technician in the transition period from high-quality analog technology to the digitalisation. He made the link between the two.
His technique would or will ruin a whole industry, making "our" hich-tech IT based on digital processing completely obsolete.

For the one who does not understand the upper part: Consider a circle. The relation between diameter and circumference is the nubmer PI. Thats, 3.1415... and an inifinite numer of digits never recurring. Thats quite an amount of information in a simple analog thing.

There are other simple analog things that contain lots of information, even if you stay in the "rational number" range. Every movie, ever made on DVD and goïng to be made on DVD or every file on a computer in the world can be drawn by a single line on one sheet of paper: the slope (Y/X) as a finite row of digits can be the result of a digital measurement. Replace the sheet with a (virtual) tv-screen, and you have the SLOOT-compression, or something like. It's a digital to analog- and reverse thing. No more no less. Sloot himself spoke about the "end of the digital era"

Sunday, June 8, 2008 - 07:13 PM


Could the sender of this comment please contact me?

Thursday, August 7, 2008 - 09:10 PM



Dear Koen,

I don't understand your reasoning above. In my opinion the information content of the analog signal produced by entering the digital code on the chip card into the SLOOT device cannot be higher than the information content of the digital code on the chip card itself. Therefore, also the information content obtained by digitizing again the analog sigal cannot be higher than the information content of the digital code on the chip card itself. Thefore the process of turning digital information into analog information and back into digital information by whatever process cannot create extra information.

With regard to your example: in my opinion an analog picture of a circle does not contain information about pi to an infinite number of decimals. It only contains information about pi to a certain number of decimals and the number of decimals is defined by the resolution of the analog signal.

As a conclusion you may say that you can't create more information from less information.

Comments are very welcome.

Best regards,

Thursday, December 11, 2008 - 12:41 AM