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-...
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.
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.
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.
What did you find? Low bitrates? Smaller resolutions? Enquiring minds want to know.
It was just an MPEG wrapper.
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 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.
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 :-)
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".
There's no upside to a job doing DD on a scam.
Wouldnt the non-confrontational approach here be to agree with everyone on a benchmark, build up the benchmark, and showcase results?
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.
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.
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.".
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.
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.
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.
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.
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.
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.
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.
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.
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".
On a second thought, the compression alone would destroy information. NVM.
they still have the domain lol broadcast.com