Back in the nineties, Philips was days away from signing a licensing deal for a revolutionary video compression technology that compressed whole movies down to 8KB. The former Philips CTO was a strong believer. And then the inventor died and nothing ever came of it.
To be a fly on the wall during due diligence meetings between Philips engineers and management.
Video codec compression scams remained popular even in early 2000s. I worked for a very large public tech company. One of the top 10 in that era. And they fell hard for scammers from Las Vegas that promised revolutionary audio/video compression. We had to sign all sorts of NDA and couldn't look under the hood of what they delivered to us under penalty of breach of contract and all that stuff. I "accidentally" ended up looking under the hood and couldn't believe what I found. I reported the findings to my manager and told him to do what he wanted to with that information.
Long story short, the whole project got shut down and about 200 people working on project lost their jobs. Myself included. Luckily I quickly landed at a better place working on more meaningful things.
> I reported the findings to my manager [...] the whole project got shut down and about 200 people working on project lost their jobs. Myself included.
Good for you for reporting the threat. But I'm a little surprised that they let the messenger get killed along with all the other innocents.
I knew someone who whistleblew to C-suite, about misrepresentations they realized, on something that was then an existential threat to one of the top companies in its market. A series of layoffs and (IIUC) some M&A later, most of the employees were gone, but that one middle-aged engineer who warned C-suite (averting an even worse fate for the company) escaped all the layoffs, and was still there.
I’m sure that that one line manager who reported the fraud to the CEO was well rewarded. How he learned what he did? We’ll never know. Too bad his team had to be let go.
> But I'm a little surprised that they let the messenger get killed along with all the other innocents.
There was bad blood between the managers. My immediate manager bypassed his immediate manager and went above a few levels. Top management lost all confidence in the team and decided to can the project. We were all treated as peasants and told to find other jobs inside or outside the company.
> I "accidentally" ended up looking under the hood and couldn't believe what I found. I reported the findings to my manager and told him to do what he wanted to with that information.
What did you find? Low bitrates? Smaller resolutions? Enquiring minds want to know.
It was not a very sophisticated scam. The vendor had rebadged an opensource software I was very very familiar with. The only changes they had made were to rename things and fudge the reported stats.
It was not all that dissimilar from what Nikola Motors did when they pushed a non-working Hydrogen truck down a hill and filmed it and said look, the truck is working great. They too were caught. And eventually got an Italian company to produce a truck and put their name on it. And then eventually went bankrupt. But not before the officers, including the founder made bank on the entire scam. CEO was convicted of fraud. But he paid/donated $1m to Trump and was swiftly pardoned.
I mean, that would work. It's going to be the reason AI video compression works; people are okay with an AI model being 1GB but they wouldn't put up with libavcodec being 1GB.
It's a valid codec move to have 1GB in the codec but to be able to compress arbitrary video with it, or even just arbitrary video within a certain specialized domain. Having those requirements will affect all the cost/benefit decisions that get made when people decide whether to use it, but if it outperforms on other metrics it may be something that wins in some places.
I believe lumost is referring to the actual video being used for testing being embedded in the codec. That is not a valid move; it compresses just that one exact video arbitrarily small (honestly anything above zero bytes is just sandbagging, you can always map the empty file to your test video, for INFINITE COMPRESSIONS!!!1!) but nothing else.
>> people are okay with an AI model being 1GB but they wouldn't put up with libavcodec being 1GB.
If people are happy with the results of the libavcodec, you could rebrand it as "libavcodec-ai" and now you have a more effective codec that might be bigger, but is now palatable to users :-)
Between this and the other compression scams mentioned in the thread, is there any connection to the show Silicon Valley? I haven’t heard of this genre of scam before but it sounds a lot like the premise of pied piper!
I did DD on that for another group of investors and caused them to walk away. Interestingly, they too were scammers but of a completely different level.
I think the 'inventor' (loose use of the term, nothing really got invented) was a true believer, he basically thought that if only he could get his hands on some capital that he would be able to make it work. He simply did not have the background required to see that it could never work in the way that he proposed. Nicely faked demo though :)
I would do a write-up if I didn't think the case was more of a sad one than of someone trying to rip off investors, Jan Sloot just wasn't that kind of guy from my interaction with him. Maybe he did invent something: "Fake it before you make it".
I've occasionally been asked by an investor to do DD on some inventor's idea. Whenever it's an obvious scam I turn down the job. If I tell the truth and say it's a scam, the "inventor" will sue me. If I lie and say the technology has promise, the investor will sue me when he loses his investment.
>> I've occasionally been asked by an investor to do DD on some inventor's idea. Whenever it's an obvious scam I turn down the job. If I tell the truth and say it's a scam, the "inventor" will sue me. If I lie and say the technology has promise, the investor will sue me when he loses his investment.
Wouldnt the non-confrontational approach here be to agree with everyone on a benchmark, build up the benchmark, and showcase results?
Probably. The problem is that scammers are very clever with demos e.g. there's always a battery hidden inside the free energy device and they won't let you take it apart. One can work around such obstacles with very carefully designed tests, but then the scammer makes up some excuse not to agree to those conditions so you have to go back and forth and it becomes so expensive to do the DD exercise that the investor cancels the project.
Some people might be able to make this kind of business work but I don't have the patience or the political skills for it.
A key part here is that your advice to your customer is confidential. They simply should not release it unless it is under your letter of non-reliance. That said, yes, scammers are - by far - the most aggressive (they know they're scammers, after all, and you are between them and their goal, which is to get funded, not to provide a product or a service) but it is up to your customers to hold the line there. Weak customers may end up being intimidated, that can be an issue.
He's a windbag. I never understood how they could even think of making him head of Philips. And to this day he claims that Sloot's box worked. The group I worked for was a bunch of wealthy Dutch guys, several of whom ended up defrauding other investors. Great little world...
I came up with a similarly impressive compression scheme as a young teen, shortly after I started programming.
It was beautiful in its simplicity. Take 5 bytes, compute a 4-byte checksum, and just store the checksum. After all the chances of a checksum collision is miniscule.
When decompressing just iterate over all 5-byte values until you get the correct checksum.
The fantastic feature was of course that you could apply this recursively if you needed higher compression ratios.
Took me a good hour or so before I caught up with reality.
DOS International was a German magazine in the early nineties with excellent technical explanations and program listings. One of them was a super compressor that used your recursive technique. I didn't quite understand the details that were given in the description of the algorithm (I blamed my mediocre understanding of German), but it sounded legit.
So I spent a good hour to type in a page of impossible to follow C code with obscure numbers in lookup tables and all it did when I ran the program was to print out "April 1., April 1.".
I had another hairbrained idea once. Let's say you want to compress the number 5384615385. Find two numbers x and y so that x/y equals some number whose decimal part is 5384615385. In this case, that's 7/13. So the compressed output is just 7 and 13, which could be encoded very succinctly, thus saving lots of storage space; and decompression is just multiplying numbers.
Unfortunately, while the idea works for some input sequences, most numbers aren't rational, and most sequences would require numerators/denominators that would be larger than the input. So not practically feasible.
A variation on this would work, but alas we don't have the math tools as yet.
The idea (not mine) is that you can think of data as "very large numbers". So a 4096 bit number is just a big number.
Well, we have a short way to generate big numbers. x^y.
So given a big number (say 800 000 bits) we could generate a (Hopefully short) expression of the form a^b + (or minus) c^d + ... etc.
Unfortunately the "factorizing" (and indeed ecpansion) of a large number in this way can't (currently) be done quickly.
But in concept enormously large binary files could be compressed to tiny strings.
It would not work for arbitrary inputs. See the pigeonhole principal: you can’t represent all possible n-bit values with fewer than n bits, because otherwise you’d have at least one case where multiple input values map to the same output value. On decompression, which one do you go with?
And if that’s not convincing, then consider that any perfect compression scheme would be able to compress its own output even smaller, until you end up with a single bit output for any possible input.
So no, that wouldn’t work in general. Some specific values may compress well, but most others can’t. It’s not a matter of difficulty of finding the right answers, as much as you probably can’t do it.
To add to this, useful compression algorithms exploit patterns in the input data. A common pattern to target is repetition, since most files contain lots of repeated byte sequences.
The pattern that factorization targets are numbers that factor well. I doubt this is a pattern you’d find in any file worth compressing, it doesn’t have a clear relationship to file data.
Aside from the factorizing cost, I suspect decompression will also be prohibitively slow. Exponentiation, multiplication and addition such large range numbers could still end up prohibitively expensive.
In addition to the performance problems there's the basic fact that no such scheme can possibly work (as proven by the pigeonhole principle).
High compression rate schemes that actually work compress high likelihood inputs and expand low likelihood inputs by accounting for the characteristics that make inputs high likelihood--e.g., redundant highly patterned texts. Schemes that are agnostic about the input, like the one described here, are as likely to expand any given input as they are to compress it.
Once upon a time, I was strenuously recruited by a startup with similar, if not quite as extreme, codec promises. When I understood that my job would be rigging demos while trying to realize the non-software founder’s “algorithm”, I pretty much had to fake my own death to escape them. Shudder…
Perhaps you can help me; I can't find the original story of the following.
A similar scam was being demonstrated to transmit data wirelessly at a very high speed due to some fancy compression. The demo was between stations with a river in-between.
The investigators lifted the box and found an optical cable which was buried and went under the river.
If I hadn't seen something like this myself I would never believe it. In the late 90s I worked at a very large tech company, for the CTO. The company was considering investing in a startup that claimed to be able to transmit fiber-like data rates on high voltage transmission lines, somehow by using microwave. I was asked to comment on this. Within a few seconds I said it had to be a scam per Shannon, and at any rate said high voltage lines typically already have fiber on the ground wire at the top of the towers. The company went ahead with the investment.
I think I remember this, or a similar scam around the same time. What stood out to me is that one of the big six was hired to certify the legitimacy of the "black box", despite the obvious mathematical impossibility. I'm trying to find the firm ... Hm, according to Google AI it was Ernst and Young (I did a search for Ernst certifies compression technology 1990s). They apparently did two different "audits or demonstrations.
I was working at Andersen Consulting at the time, offshoot of Arthur Andersen. The Arthur Andersen that signed off on Enron (AC had before then become Accenture and separated from the audit partnership).
I chuckled to myself a few years later when the NBA draft lottery was signed off on/audited/witnessed by another Big6 firm. Yeah, give them enough money and they'll "audit" anything within some degree of plausible deniability.
So bizarre! It really shook my belief in Philips' competence at the time.
I mean, take a 100 minute movie, sliced into 1-second clips. 8kB is not even enough to store all possible orders you could put those clips in. I would hate to think so ill of any of my friends or colleagues to think that they could believe such an obvious fraud.
> I mean, take a 100 minute movie, sliced into 1-second clips. 8kB is not even enough to store all possible orders you could put those clips in.
Using a low hurdle to show it still failing is a good rhetorical technique, but you lowered your hurdle too far here. Yes technically specifying the order of 6000 segments takes more than 8KB. Because it takes 8.14KB. That's a rounding error. What could have been a useful argument is now a nitpick. And what if the movie was only 98 minutes, now it fits? What a mixed message.
It's a good reference point, but I'd replace "is not even enough" with "would only be enough".
Is it a sort of reversible pseudo-hashing function even possible? Or something like a seed in a deterministic procedural generator. You could store arbitrary data in a few bits. 8kb for all the redundancies and metadata even.
On a second thought, the compression alone would destroy information. NVM.
To be a fly on the wall during due diligence meetings between Philips engineers and management.
https://lowendbox.com/blog/the-man-who-was-paid-e113000-for-...