Slashdot Mirror
Ask Slashdot: What Is Your View On Sloot Compression? (youtube.com)
An anonymous reader writes: A Dutch electronics engineer named Jan Sloot spent 20 years of his life trying to compress broadcast quality video down to kilobytes -- not megabytes or gigabytes (the link in this story contains an 11 minute mini-documentary on Sloot). His CODEC, finalized in the late 1990s, consisted of a massive 370Mb decoder engine that likely contained some kind of clever system for procedurally generating just about any video frame or audio sample desired -- fractals or other generative approaches may have been used by Sloot. The "instruction files" that told this decoder what kind of video frames, video motion and audio samples to generate were supposedly only kilobytes in size -- kind of like small MIDI files being able to generate hugely complex orchestral scores when they instruct a DAW software what to play. Jan Sloot died of a heart attack two days before he was due to sign a technology licensing deal with a major electronics company. The Sloot Video Compression system source code went missing after his death and was never recovered, prompting some to speculate that Jan Sloot was killed because his ultra-efficient video compression and transmission scheme threatened everyone profiting from storing, distributing and transmitting large amounts of digital video data. I found out about Sloot Compression only after watching some internet videos on "invention suppression." So the question is: is it technically possible that Sloot Compression, with its huge decoder file and tiny instruction files, actually worked? According to Reddit user PinGUY, the Sloot Digital Coding System may have been the inspiration for Pied Piper, a fictional data compression algorithm from HBO's Silicon Valley. Here's some more information about the Sloot Digital Coding System for those who are interested.
If it were just as easy to kill off someone to "solve" an issue like this then the bitcoin scaling debate would have been resolved a long time ago...
They killed him because you could feed a random input into his decoder and the movie that came out would be better than anything Hollywood can produce.
Sheesh, evil *and* a jerk. -- Jade
So, you want to replace every frame in a movie with a collection of images or snippets that correspond to each part of the frame, right? And you're going to store a dictionary of snippets, referenced by number, then say "this frame takes snippet 1234, 6543, and 9274". The problem is that the number of snippets you'd have to store is enormous, and that each snippet itself is going to be a ginormous number (like the bits of the string of bytes in that snippet).
See where this is going? You're basically establishing a mapping of small numbers to much larger numbers. Either that set of big numbers is tiny (in which case you can only represent a small number of frames in the output video and picture quality is awful) or it's huge, in which case the index numbers themselves become roughly as big as the numbers they're referring to, and oh yeah, good luck searching through that space bunches of times per frame.
The idea isn't inherently bad if you have a small number of states you want to represent. For instance, Zstandard lets you precompute a dictionary of common strings you want to shorten. Imagine if you trained it on HTML so that each tag or other common string just takes a few bits, then you can distribute that dictionary to the whole world so that you can save the bandwidth of transmitting it alongside the compressed data each and every time (like we do with Zip, Gzip, etc.). That's a nice thing! But the search space of "things you can display on a screen" is a hell of a lot bigger than "things you can sent in an HTTP header".
Dewey, what part of this looks like authorities should be involved?
Information theory stablishes what is really possible and that kind of compression is simply to much, even considering its lossy nature. Infomation entropy has very real limits no matter the encoder used in the data compression.
Jan Sloot had some ideas on how to compress things and despite hyping it up, he had gotten nowhere close to anything functional. With all the hype he generated, he had a deal lined up for the technology but he didn't have the goods. The stress of the impending revelation of his fraud caused him to suffer cardiac arrhythmia and he died. The source code was never found because it never existed.
Anons need not reply. Questions end with a question mark.
That really says a *lot* about the quality of today's movies.
Mimetics Inc. Twitter
The presumption isn't that it actually stored images but more likely that it contained numerous generators. It's entirely plausible is that similar to the way a neural net uses a combination of several algorithms to classify images, a similar approach could be taken to constructing them.
I'm not sitting through an 11 minute video to see if there are any examples of his compression - in particular the output compared to the input.
But the proof is in the pudding - what was the output quality like?
Specialist Mac support for creative pros, Melbourne
Sloots are gonna sloot!
What was that file format that was parts of sampled songs that were played back like a midi? It was "popular" in the late 90s I think. Maybe earlier. Pre MP3.
Sounded like a chopped up version of the original song. Much larger than midi but much smaller than wav.
Do not meddle in the affairs of sysadmins, for they are subtle, and quick to anger.
Myself, I've come up with a system that can compress a video file down to one byte. Unfortunately, it has some limitations. The size of the decoder is approximately the same size as the uncompressed video file, and it will only work on one specific file.
Damn, should I be afraid for my life now?
I believe it was a scam. He never really had that good compression. Either he got cold feet and offed himself before he had to deliver the product that would not work, or someone else found out and killed him in a a rage at being tricked.
While yes, there are a few scientific advancements that are remarkable, in fields like computer file compression that are:
1) Essential to an existing, highly profitable business
2) Mathematically interesting
3) Being heavily researched by multiple people.
then any advancements get duplicated in less than 10 years. Too much money, brains and corporate greed focused on this issue for us not to figure out it or something similar by ourselves.
This has not been duplicated, therefore it was fake.
excitingthingstodo.blogspot.com
Back in the day when Dr. Dobb's Journal and other computer magazines were a thing, one editorial writer was reflecting on how allowing multiple levels of an analog signal could encode more than one bit per symbol or cell or splotch or what have you. The idea was extended to a very hard, dimensionally accurate ruby rod upon which a very thin scribe line was made, and the writer mused that a very large number of bits of data could be encoded on that one physical object.
Since Claude Shannon's insights, Information Theory is also a thing. The number of bits goes linearly with the number of symbols or cells or optical splotches, but it only increases with the logarithm of the number of signal levels represented by those physical objects. A 16 bit unsigned integer can encode 2^16 or 65536 levels, 32 bit encodes about 4 Gig whereas a 64 bit unsigned integer encodes a number of levels exceeding most counts of objects in the known Universe -- think of tale of the king wanting to reward the inventor of the game of chess with anything he wanted, and the dude asked for 2^64 grains of wheat (one grain on the first chessboard square, two grains on the second, four grains on the third, and so on).
Turning this relationship around, scribing that ruby rod to the precision of, dunno, the Planck Length, gets you what, only a 100 bits of storage or something like that?
You are finding a related fallacy in this super video compression scheme?
I had a similar idea to develop an algorithm that would follow through and propagate successive frames of motion in a video, first analyzing it to create certain required textures and meshes, then applying it to various meshes that would be created by tracking the individual characters, objects, and sets in a video. I always believed it could work but it's a huge undertaking.
Twinstiq, game news
Sloot wasn't the only "Compression Tweak". This is someone who has compression "ideas" but can never get the product working. There was one in the US who wrote me for a long time in the 90's. One thing I remember is that he dropped hints about encoding data in the spaces in between bits. Of course this makes zero sense.
Bruce Perens.
Sloot was nothing more than another of a long line of scam artists (or delusional inventors) who claimed to have created a "magic" compression scheme. In his case, he said he could compress an entire movie down to 8 kilobytes.
Simple mathematics show why such schemes don't work. 8 kilobytes = 8192 bytes = 65536 bits. Assuming you have a two hour movie, then each second of the movie must be mapped into about one byte, which can have only 2^8 = 256 possible values to represent any conceivable second of video. It's mathematically impossible.
Engineers and mathematicians have been debunking these claims for decades, but they still occasionally pop up. I remember one scheme that got some press about 30 years ago. A guy claimed to have a compression program that could take any data file and compress it down to about 1 kilobyte. And it seemed to work, according to several people who tried it. As it turned out, the "compressed" file was nothing more an alias pointing to the original file, which was hidden from directory view by the program. When you "uncompressed" the file, the original file was unhidden. But it was a neat trick as long as you didn't try to copy the "compressed" file to another disk.
Sloot's program was "lost" because it never existed, just like the magic 300 mpg carburetors where the plans were "lost".
What you throw away, you cannot get back. Think of compression as a plastic bag filled with snow and maybe a little air at the top. Assume air represents '0' and water represents '1'. A snowflake can be said to be represented then by a sequential pattern of 0's and 1's. The more you squeeze the bag, the more air (0's) you throw away. Initially you're merely squeezing the air at the top out but as you continue to squeeze this bag, you start throwing away the 0's contained within the snowflakes themselves, in so doing the shape of the snowflakes becomes less and less defined. Squeeze all of the air out and you're left with water and absolutely no notion that the original defining shapes of the snowflakes.
Lossless compression in a sense only squeezes the air at the top out. Lossy compression continues on and erodes the actual pattern defining the snowflake. No matter how clever your algorithm is at deflating the bag, there are very real limits to how much you can squeeze before you stop being able to recognize the contents as the snow you once put into the bag. Procedural generation is a form lossy compression. Minecraft worlds are procedurally generated from small seed strings. These generated worlds are very impressive in their complexity and expansiveness. However, from those seed strings you have precious little control over what is generated. You cannot simply change the seed from "aaaaaa" to "aaabaa" and lower the height of a hill by 2 meters at coords 100,50 without very drastic changes propagated elsewhere throughout the entire world.
If someone killed Sloot it wasn't to suppress his invention, it was to save face for being conned by him.
Two of my imaginary friends reproduced once
The real trick is storing the data in two-dimensional bits, so that each bit can store many thousands of times as much data. /sarcasm
--- Most topics have many sides worth arguing, allow me to take one opposite you.
First of all, the guy who made the documentary didn't invent black bordered subtitles, and white on white is not easy to read.
Then, people who actually saw Sloot's invention talk about "movies" without any more details, like length or quality. Not much convincing. So, maybe Sloot invented a device that simply uses a kind of wifi?
Slashdot, fix the reply notifications... You won't get away with it...
Reminds me of KGB Archiver.
This level of compression translates to AI vision.
... interesting to say the least, as the hallucinated playback would heavily reuse "stage props", just as human brain does.
While retina and optic nerve run roughly at 8Mbits (retina already does a lot of pre-processing), visual cortex reduces this to 10kbit/s per eye and feeds it further into brain. Which is the same ballpark claimed by this kook.
It's obviously possible with *heavy* post processing to make very high representation of objects perceived. To replay, you need to hallucinate it back (akin to dreams). Problem is you need something as good as humans visual cortex, while modern ML vision is on the level of a fruit fly. Also, the fidelite would be
[1] Anderson, C.H. et al. (2005) Directed visual attention and the dynamic control of information flow. In Neurobiology of Attention (Itti, L. et al., eds),
[2] Norretranders, T. (1998) The User Illusion, Viking
None view.
I theorized that the Mandelbrot is capable of generating any string of data of any size given a high enough resolution, high enough iterations and enough time to process it. I haven't retested my theory on scale since 1998 (significant because of general availability of GPUs... if you count Voodoo2 as a GPU), but processing on a 486DX-50 with 16 megs of RAM and Linux allowed me to search for simple strings (kilobytes in size) within reasonable time.
:
What I found was that every 4KB sequence I randomly generated as part of a set was able to be located within the Mandelbrot set. Results generally were found in the nautilus or horse tail areas. I used several search methods.
1) Linear
2) Rectangular spiral clockwise (variable width, variable height)
3) Rectangular spiral counter-clockwise (variable width, variable height)
4) Zig-zag in 45 degree rotations and variable width and variable height)
5) Elliptical Spiral (clockwise and counter-clockwise, variable width, variable height)
I also experimented with added dimension which included iteration as a 3rd dimension when pattern searching allowing strings to extend across multiple iterations in cubical, spheroidical, etc... footprints. I had to abandon this effort due to computational complexity.
I also experimented with experimenting with adding bit layers as a 3rd dimension when searching, but this added even greater computational complexity than the previous method described above but certainly promised greater results.
The algorithms I used were exhaustive. So where a video motion vector search algorithm would abandon searching a given direction for performance reasons when the delta values in said direction were not yielding results, I searched every pattern type for every pixel for every parameter... etc...
Now, given my computational capacity and limitations of the time, the average seek time per 4KB string before finding a result was 1-2 weeks. All my code was heavily optimized to exploit memory as it was used on the architecture. Consider a combination of Michael Abrash style coding/optimizations with more specific knowledge of the specific CPU and memory it would run on. I also spent a great deal of money getting memory with 60ns response time (though I never measured better than 64ns on the scope). I also used a Micronics motherboard which at the time meant something as Intel had yet to enter the chipset market and as ECC memory was far too expensive... for pretty much anyone on that scale, and the memory controller was not yet part of the CPU, I needed a reliable and documented chipset to work with.
Ok, so here's the summary of all the results
1) It is worth investing greater effort in scientifically proving that absolutely any string can be found in the Mandelbrot Set given enough iterations, resolution, search creativity and of course CPU power.
2) It is believed (though through non-thorough experimentation, not mathematically proven) that any 4KB string can be found in the Mandelbrot Set
3) Once found, depending on the resolution and number of iterations provided as a coefficients for identifying the set, the data can be retrieved in a reasonable period of time (deterministic, though variable) on any device. The real computational cost was the search itself.
4) This method of compression has no value for video as the data sets are too large.
5) It is most common that longer string lengths searched for often requires higher resolutions and higher iteration counts to be found. This is common, not a rule. Depending on the search pattern, often strings with a more level histogram distribution could be found as bit patterns in lower resolutions and iterations.
6) The size of the strings found increased far more rapidly than the size of the coefficients required to represent the find. Meaning without employing additional methods such as entropy coding the
- resolution of the Mandelbrot image,
If you read the original stories in Dutch, the whole story becomes a lot clearer.
The system he had was enclosed in a box and you could initially see his "demo" of 4 movies in low quality. There were various claims on Sloot's part that it was only x size but nobody was allowed to look into or program the system. He was going around investors fishing for money to make it work at bigger resolutions for his lossless compression algorithm. When he croaked nobody found anything in regards source code or design documents.
It's also mathematically impossible to get the file compressions he got. At best it was a reference to a pre-programmed movie.
Custom electronics and digital signage for your business: www.evcircuits.com
But you need to download a 370 Mb CODEC for each one.
Have gnu, will travel.
There is a few hundred byte long URL to a movie and it can be "decompressed" to your hard drive in a matter of minutes, or hours.
I have a friend who invented an alternative to tracking time in place of the proposed time_t. Just 24 hours before he was to present it at a conference he was found murdered. I'll never forget the day it happened - January 1st, 1970.
There's already a way to compress a movie down to a few KB. You simply post it as a torrent and let other people store it on their computers. After it's been well-shared, you can simply delete it from your machine. Can't beat that level of compression. See, I've included Big Buck Bunny in this post:
magnet:?xt=urn:btih:88594AAACBDE40EF3E2510C47374EC0AA396C08E&dn=bbb_sunflower_1080p_30fps_normal.mp4&tr=udp%3a%2f%2ftracker.openbittorrent.com%3a80%2fannounce&tr=udp%3a%2f%2ftracker.publicbt.com%3a80%2fannounce&ws=http%3a%2f%2fdistribution.bbb3d.renderfarming.net%2fvideo%2fmp4%2fbbb_sunflower_1080p_30fps_normal.mp4
---
DRM is like antifreeze, to the MPAA/RIAA it's sweet, to the consumers it's poison.
When I insisted that the null set should be included the enumeration of subsets in answering a problem on an Information Theory homework, the professor was reminded that his colleague and author of our textbook once asked for "the null license plate" (i.e. a blank plate) for his personalized license plate but was turned down as I was about to be in my request for points back on the assignment.
Whereas there are certain plates you cannot have -- obscenities along with "1" or "A1" or similar license numbers reserved for high government officials or whatever the excuse -- the colleague insisted that a blank plate was not excluded by the rules.
DMV stood firm in rejecting this request, but if anyone, anyone at all in the State of California should have been permitted to have the blank license plate, don't you think they should have granted it to the author of a graduate-level textbook in Information Theory, especially with so many high-ranking academic institutions in math and engineering in that state?
My professor's take on why his colleague should have been granted the null plate is that it could have made it easier for the CHiPs seeing his colleague speeding down the Foothill Freeway, "Quick, get that car's license number! (partner to that officer rips off a blank sheet from a notepad) Here it is!"
1/ Never heard of it before thus no opinion - odd question to ask since so many will also have no opinion.
2/ If it is lost then it's technically irrelevant even if historically interesting.
This sounds like a cross between Guetzli, an AI-optimized jpeg encoder, and Brotli, a zlib encoder with a predefined library. And Google loves looking for ways to compress YouTube videos.
(T>t && O(n)--) == sqrt(666)
I have read the book "de broncode" some 10 (?) years ago. It read like a very exciting detective/mystery. The weird thing was that the book ends with lots of pictures and copies of documents that prove it's existence. In the end you really get the feeling that there was some foul play by some mayor company. It's not that difficult to make someone have a heart attack...
Offtopic maybe, but I had a guy with something like that bring it in to the University where I worked for independent testing. He was an artist with not a lot less technical skill than a mechanic, and paranoid as anything, but he couldn't hide what he'd done. The trick (on the perpetrator more than anyone else) is to tune the engine for maximum efficiency at idle - thus it uses very little fuel on a test bed with no load. Once you attempt to get it to do something useful it actually uses more fuel than if you hadn't messed around with it in the first place.
Those people "knew it was real" - they had seen it in action in a test, and in their minds there was only some tiny little glitch that was keeping it from working in practice. Anyone with an actual clue about engines that attempted to point out problems was apparently part of a conspiracy.
You're forgetting that it's 8kB ... plus the 370MB of data preloaded in the de/compression engine.
look. it doesn't MATTER if it's 370mb of data or if it is 1000 terabytes of data. given a random movie file it would have to be able to tell apart the same movie but lets say a 10 seconds of it is just blacked out in the other version or replaced with a random text(this is to take out possibility of having the whole movie already in the 1000 terabytes of data). you cannot index chunks with such a little data to go match there. IT CANNOT BE DONE. if it could be DONE THEN THIS WOULD REVOLUTIONIZE HARDDRIVES AND ALL DATA TRANSFER - not just videos.
besides 8000 bytes / 120 min is about 66 bytes per minute. thats like a byte per second.
so basically, at least the claims are an order of magnitude more ludicrous than is possible at all.
also a few years ago I ran into some startup guys who were claiming that (among other things) they had a new compression algorithm that could do 1gig to 100kb or some such... I tried to explain them the theoretical maximum they could attain is way worse what they were claiming (due to simple logic)... they never did anything with it or showed it of course - even if it would have been 1000000x more valuable than what their current company was doing. kind of lost faith in that then.
furthermore you could embed 50 megs of data easily visually on a normal vcd movie of 650 megs. what this is suggesting is that you could embed any random data of 100 megs into 8 kilobytes. it doesnt add up. it cannot add up.
world was created 5 seconds before this post as it is.
1. We use PDF's today which when compressed are relatively small.
2. We have a commercial entity called ScanSoft that also compresses PDFs
3. PDFs generated by ScanSoft are incredibly much smaller than any other PDFs
4. Scansoft PDFs use a compression algorithm called QMax
5. Nuance which now sells the Scansoft PDF products have access to the same technology
6. No other PDF technology in the marketplace has a compression algorithm that uses STANDARD decompression and unique COMPRESSION to achieve the ridiculous PDF sizes (try converting one of the PDFs and you will see)
Sloot didn't HAVE to have a good DECODER, but even a BETTER ENCODER would do. If you add a better DECODER as well, then things get really interesting and the compression factor suggested becomes visible as a possible end goal.
Find a person talking in front of a not moving background.
Try a resolution from the vcd or vhs years.
Take time to look at every frame in great detail. Keep working on the data in each frame for a much longer time.
Use a good cpu and gpu to really work the math per frame and each next frame, all frames.
Then have an artist correct each frame by hand for movement or areas that should have not moved.
Alter any code as needed.
Try again.
Code could be optimized for a set background and a talking presenter. Let good code, many gpu's and cpu's try again.
Have the artist look at every frame again.
Once some interesting results can be repeated try many different backgrounds. Some issue between the human moving and a different background might be more successful.
If the gpu's and cpu's need a day to work on a very short series of frames but produce a good result, keep trying.
Better cpu and gpu support can be added. A new idea about what code can do and what the artist suggests will take time.
Try every method and theory that can be found per frame and for every frame.
Also consider film, digital or other capture methods and how each frame is created.
A very different, emerging or old and unexpected way of working with each frame might be better for the math per frame.
Domestic spying is now "Benign Information Gathering"
I've compressed 27 years of 401K retirement fund down to something that fits comfortably into a coin purse with room left over for a couple fentanyls. I wish investing was as easy as ingesting.
The Russians have won. They have made the world a cesspool of distrust, greed, fear and hate.
no no no..
demoscene demos work because they work within the limits of the machines - the machine is part of the creation. it's limits dictate the creation. it's not for reproducing arbitrary input and that would lead to a logic loop.
you can agree that a video can have 140 characters? or 100x140 characters? basically the slooth claimed algorithm was so good that you could make a little logic play and include an infinite amount of hollywood movies(not just noise) in a chain of compressed links(any full lenght movie would have enough of sidechannel extra data visually in the video stream to include 2+ other compressed movies).
the claims were just too good. and it is strange anyone would have thought of giving him the money without running the idea through some mathematician or two which would have claimed bullshit on it.
like your scheme would work only if the movies were made for dwitter or some old pc or whatever. you can have pretty nice 64kbyte demos with music but that doesn't mean that you can reproduce any music video in 64kbytes, which was basically what slooth was claiming.
world was created 5 seconds before this post as it is.
I am actually not bragging, when I say I have put my penis into a bunch of women. I am actually a wee bit alarmed at the number. It's a lot. I was a man whore for a long time. Really, it's a lot.
I'm not sure if this makes me an authority, however. So, call this an anecdote...
Not one woman, with whom I have conferred, has ever used that nomenclature. Yoni is my favorite, if you're curious. I've even dated professionals who were involved in women's reproduction health. None have used that term. Not even farm girls, or chicks with horses, have used that terminology. They even are from diverse global locations., but none have.
It must be my lack of exposure...
"So long and thanks for all the fish."
Adam Clarks Adams Platform:
https://www.itwire.com/opinion...
http://www.smh.com.au/business...
Now you might think ok, this one was a scammer, but people vet those things, cant fool me twice, right?
http://v-net.tv/2015/10/09/unk...
5 years later VERY SAME "The company’s senior development team comprises: Adam Clarke" :)
Adam Clark, of Adam’s Platform Technology (2004) "transfer a 1.3 gigbyte video file to a 1.4 megabyte floppy disk." strikes again in another scam
Another one is Madison Priest's Zekko Corp: :D
http://www.bizjournals.com/sac...
http://jacksonville.com/tu-onl...
http://jacksonville.com/tu-onl...
Magic video compression turned out to be buried cable
Want more video compression scams? Check out V-Nova Perseus - they promise 3x smaller files than h.264, but somewhat independent tests show 20% bigger files at same quality :) and the real kicker is Perseus is really just reencapsulated h.264 video with resize filter on top :D multi million dollar scam, they even scored one Sat TV network contract.
Who logs in to gdm? Not I, said the duck.
According to the linked Wikipedia article on Jan Sloot, the guy he signed the deal with was named Roland "Roel" Pieper; so that's a point in favor of the Pied Piper theory.
by Cyphase ( 907627 )
if you don't care about quality.
Sloot's compression figures mean nothing unless we can evaluate how good the result is.
Which we can't, since is no such codec actually exists.
We didn't tell the artist his modification was BS because if we did he'd just call us part of the "conspiracy". We let him down gently and gave him enough hints that he eventually worked it out for himself.
Seriously kids - with the amount of competition in the automotive market back then do you really think a car company would sit on a magic system that would massively improve fuel economy - especially during the oil shock? GM would have given anything (apart from replacing dud management) to get their market share back from the Japanese manufacturers.
Back in the mid-90s, the "VP" of engineering (given that he supervised a team of two programmers the "VP" title was more than a little ridiculous -- of course I was the more "senior" of the two programmers, and my title was "Director of Engineering") of the startup I was working for told me he had a great idea for incredibly-efficient video compression, which would make full streaming video practical over dialup. When I asked for details, he told me the key was to find an optimal representation of the video stream, then send that. Since that statement was somewhere between blindingly obvious and utterly stupid, I pushed some more. His answer, delivered in hushed tones, after looking over his shoulder to check the empty room for spies, was:
"Here, do a thought experiment: Imagine a whole room full of transputers, all cranking away to find that one minimal representation of a frame of a movie. Now imagine a building full of them... can you imagine how optimalist the result would be?"
I laughed out loud, couldn't help it, which pissed him off so much that a few minutes later when the other programmer came in and greeted the "VP" with "Good morning, sunshine", he threw his very expensive headphones at him. He missed, so they shattered against the wall. Then the VP went running to one of the co-founders to complain about being disrespected by the staff. Nothing came of it.
That was far from the weirdest thing that happened at that place. My few months there ended abruptly one day when I arrived at work to find 20-foot flames shooting out of my office window. We're pretty sure that one of the co-founders torched the place to cover his theft of the ridiculously-expensive servers he'd purchased with the other co-founder's money, but nothing was ever proven.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
do you know why simply having vast amounts of more memory in a computer doesn't make zip algorithm much better? it just doesn't help. you can't just make the dictionary larger and larger and expect benefits from it with arbitrary data, pointing to that dictionary is going to start taking the same amount of bytes as you're getting out from there, because otherwise your pointer to the dictionary would point to multiple entries and that just doesn't work if you want to decompress.
same with the hash. it would be even expected that you would find a false match before the right one.
world was created 5 seconds before this post as it is.
No.
This is basically mathematically impossible. The problems is that even though fractals, random generators or any other formula that can produce every possible combination of output for some input, for example if you can find the value x for f(x) = y where y is the resulting file.In theory you only need to store x to generate the whole file. The problem is that you either end up with having to search through almost infinite space of numbers which means it takes the age of the universe to compress a single file or if you find the correct number x it is always larger than y making the whole thing useless.
What Sloot likely had was an algorithm that was specially designed for some limited input of files, which the algorithm could reproduce from very small input since most of the input was stored in the codec itself. This is usless because the algorithm can't handle general files.
Also any statement that says that the algorithm can always compress any input is false by definition. Because if that was true you could just re-compress the output until you end up with a single byte, which obviously wouldn't work unless there where only 256 distinct files in the whole world.
No? No opinion then, thank you.
That is not actually what the world wants. It is what you want. Most of the world most certainly does not want it.
Total, unmitigated bullshit.
I'll leave it to others to post the mathematical proof, but there is a limit to lossy compression and kilobyte output from gigabyte inputs isn't anywhere near the realm of possibility.
Why? Lossy compression is, at its core, the removal of redundant information, and its replacement with a smaller description of how to recreate what was removed. You can immediately see that your compression algorithm has to be able to efficiently (in fewer bits than what it took originally) describe what's been removed *so that it can be regenerated* (this is the tricky part).
Secondly, and very important, different inputs will have different amounts of redundant information. This affects their compressibilities. A totally random waveform can't be compressed, because every bit of information is important. So, saying that *any* film can be compressed to kilobytes is a red flag.
this seriously reminds me of http://www.theproduct.de/
a 64KB file that provided fully 3d rendered graphics and high quality music. this was obviously a static designed presentation so its easy to tune to that level, as well as being 3d graphics versus video frames.
i see it being possible, but more as a post-content encoding method, than an on-the-fly method.
Probable, MAYBE. Practical, prob needs high CPU/GPU acceleration to be able to encode on the fly, and possibly on decode too.
Probably the same shadowy cabal that did in Iron Butterfly drummer Philip Taylor Kramer
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
it's in the band.
I think I've seen this movie before.
"A plan fiendishly clever in its intricacies"- Homer Simpson
Yes it applies for lossy compression too.
With my 20TB decoder engine, i can compress movies down to 4 bytes! (ok, you may have to update the decoder engine once new movies come out, but hey...).
Years ago I became familiar with a company called eTreppid that was making some crazy claims about compression technology while securing investment. The "Trepp" part is Warren Trepp (https://lasvegassun.com/news/2006/nov/19/trepp-often-seems-to-be-in-the-wrong-place-at-the-/).
Anyway, see here for information about the compression:
http://endlesscompression.com/
Note that they reference Sloot and describe his methodology.
Do you have ESP?
If you have "video compression" that can procedureally generate any video, you can also generate any secret document from anywhere, ever. That makes some people nervous.
Of course, they miss the point that you also can generate a magnitude more garbage. The hard part is discerning wheat from the chaff. Given a sufficiently advanced AI, this becomes trivial. Yeah, you see what I did there.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
I mean, what if we move away from trying to reproduce individual pictures and their pixels and instead start transmitting the scene info? A TV show has a limited number of sets, what if the 3d model/texture info for most everything was transmitted in advance so that during playback all of that information is expressed in a few identifiers and their 3d transforms (ditto for the actors at some point too).
I think we will get a lot of research into that direction if VR catches up. Sending high-quality 360 degress videos is already a pain bandwidth-wise, allowing 3d + some/lot lateral head movement would make it even worse. With real time rendering, you get most of these things for free, at same time opening door to things like at least basic interactivity, nudity/gore censorship (which is not neccesarily bad thing as long as it is a receiver-side option), content customization (tailoring avatars to specific audience) etc.
I see you met my uncle's brother's friend. Too bad he was killed by some Saudi Princes after driving cross country in his Cadillac Fleetwood using only half a tank of gas.
Time to offend someone
Video and sound aside, I be astonished if you could compress just the text of the script of a full length film in 8k. Bottom line, impossible. Not even worth a more detailed analysis.
The idea here is to store a complete movie in a few kB.
If we are talking about an actual movie as made by a director, this is impossible. There is simply too much entropy. The 8 kB stated size is just sufficient to encode an already dense screenplay to the theoretical limit. You probably can't even keep the original dialogue intact at that point.
In theory, one could imagine an analyst AI able to turn a movie into such a script and forward it to a director AI which is able to recreate the movie. But it won't be the original movie but an interpretation of it. In the same way that a single play can change drastically depending on the performers.
What is possible however is to make a movie especially designed to fit in a few kB. In fact, if you look at some demoscene productions, this is exactly it. Some 64k or less intros could qualify as small movies.
Yes.
Listen to my music.
Snatch and another AC pointed out a similar word used in South Park. (I've only seen a few episodes.)
Not one woman, that I've ever known, has used that word. Snootch? I have heard "gooch." (Spelling?) Never snootch, however, and I've put my penis into a bunch of women.
"So long and thanks for all the fish."
Nice. Thanks for paying for my shoes.
"So long and thanks for all the fish."
What if Sloot found a way to rapidly Godelize and deGodelize huge files? Maybe he didn't realize that this would make encryption obsolete? I'm sure our guys (if not THEIR guys) would make all that go away.
'kilobytes' I'm assuming means less than a megabyte. Let's round up and say 8 million bits of information. At 24fps there are about 130,000 frames in a 90 minute movie. That means each frame is encoded in about 61 bits, less than 8 bytes, 0x0000000000000000 to 0x1FFFFFFFFFFFFFFF in hex. That's about 1.4 kilobits per second, 1/8th what you need for quite horrible sounding audio only compression. Someone isn't thinking straight...