Sloot Digital Coding System

Question

" In the late 1990s, a Dutch electronics technician named Romke Jan Berhnard Sloot announced the development of the Sloot Digital Coding System, a revolutionary advance in data transmission that, he claimed, could reduce a feature-length movie down to a filesize of just 8KB. The decoding algorithm was 370MB, and apparently Sloot demonstrated this to Philips execs, dazzling them by playing 16 movies at the same time from a 64KB chip. After getting a bunch of investors, he mysteriously died on September 11, 1999"

it's possible or just a story

Answer 1

There are two views on the story of the Sloot Digital Coding System. They are incompatible: In one view it is impossible, in the other it is possible.

What is impossible?

To store every possible movie down to a file size of just 8KB. This boils down to the Pigeonhole principle.

A key of a limited length (whether it is a kilobyte or a terabyte) can only store a limited number of codes, and therefore can only distinguish a finite number of movies. However, the actual number of possible movies is infinite. For, suppose it were finite; in that case there would be a movie that is the longest. By just adding one extra image to the movie, I would have created a longer movie, which I didn't have before. Ergo, the number of possible movies is infinite. Ergo, any key of limited length cannot distinguish every possible movie.

The SDCS is only possible if keys are allowed to become infinite, or the data store is allowed to become infinite (if the data store already contains all movies ever made, a key consisting of a number can be used to select the movie you want to see -- however, in that case it is impossible to have keys for movies that have not been made yet at the time the data store was constructed). This would, of course, make the idea useless.

Pieter Spronck

What is possible?

To store or load a finite amount of feature-length movies on a device and be able to unlock them with a 8KB key.

Then it is not so about compression, but encoding / databases / data transmission. This is a change in distribution model: Why ship software/data at a later time over telephone or DVD, when you can pre-store it during fabrication, or pipe it all at once at intervals. This model is pretty close to how phones come with pre-loaded apps, or how some games allow you to unlock new game elements by entering a key.

The Sloot patents never claim feature-length movie -> 8KB data compression. They claim an 8x compression rate.

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. - Roel Pieper

In this view SDCS is a primitive form of DRM, that would reduce the band-with of getting access to a certain piece of pre-stored data to an 8KB key.

Imagine storing that month's popular movies by bringing your device to your local video store. Then when you want to see an available movie, you just call for your key, or buy a chipcard at the gas station. Now we have enough band-width for streaming Netflix, but back in the late 90s we were on dial-up and there was a billion dollar data transmission industry (DVD's, CD's, Video tapes, floppies, hard disks).

Was playing 16 movies at once possible?

This is unverified. Though many investors claim to have seen the demonstration. These people worked for respected companies like Philips, Oracle, Endemol, 'Kleiner, Perkins, Caufield and Byers'. I'd say it is not impossible, but await more verification.

Answer 2

A very interesting concept. Conceptually, the Sloot encoding premise seems to be that the "receiver" would have a heavy data rich (DRM-Like) program, capable of a large pre-programmed capabilities ready and able to execute complex programming tasks with minimal data instruction.

I am not a programmer, however, at present, current data transfer challenges exist where there seems to be more focus on the "transmission" of the of data (dense and voluminous), versus the capability of the receiving program/hardware. Whereas with Sloot, the emphasis is on the pre-loading of such data (with hardware/software that has much higher capabilities built-in). I hope I'm not saying the obvious here.

As an example, using sound files for simplicity, rather than sending a complex sound file containing say an Mp3 of Vivaldi – The Four Seasons, the coding just instructs the receiver the "musical notes" of the composition, where the system is pre-programmed to play the notes. Obviously there is more to it than that, however, the concept makes perfect sense. In other words rather than transmitting "Vivaldi" data rich signal, send simpler instructions to a "Vivaldi" trained receiver. Don't send the composer, send the instructions to a composer already there.

Yes, movies can contain billions of instructional data under the current system (and that of 1999), however, can beefing up the abilities, the pre-progammed functions, of the receiver achieve what Sloot had figured out?

Currently, the data stream seems to be carrying the load, where instead the receiver should be, as suggested by Sloot. So, does it make more sense to send the music composer by train to the concert hall across the country, or to send the music notes to another composer who is already there? This not to be confused with pre-loaded movies being "unlocked", rather that the movie player has infinite abilities that simple coding can instruct within an order of magnitude greater ability.

Just some random thoughts from a layman.