[jsaxton86]

Cram makes an extraordinary claim: "Cram is a state-of-the-art media compressor that is able to significantly reduce (by more than 20%) the size of audio, video, and images losslessly without the need to re-encode or convert."

Decades of research have gone into media compression algorithms, and they claim to get a 20% improvement for free. I'm skeptical.

I don't run OSX, so I can't try out their binary, which they're distributing via email only. I challenge the Cram team to losslessly reduce the size of "The Simpsons Movie – 1080p Trailer" by 20%, available here: http://www.h264info.com/clips.html

[ceraes]

Hello jsaxton86, we love challenges! So we'll be starting here in a few moments and post the results when we're done. Also, I'm sorry to hear you can't try if for yourself, but we wanted to point out the compressor is readily available from our site, it's only the decompressor we've been asked to hold back at the request of an expert. We wanted to share our primary concern with you. Simply put: Piracy.

We hope to be accepted into ycombinator for our innovation. In, as you rightly pointed out, over coming 40 years of research to find answers that make us proud to say we're the first.

Piracy of digital media is not something we cannot condone as a company. We therefore have withheld our decompressor for that reason, and we'll still need people to test it which is why we've requested they ask via email. That way we can know, who has it and who does not. This helps us prevent our system from being used for questionable, if not illegal, means.

We understand your skepticism and we hope to prove it to you with our results of your test. We're very thankful their are people like you who will give us the chance to prove ourselves and we hope you'll follow us and keep us to our word, because that is what we believe makes innovators honest.

We'll have: Size of file to compress, size of "Crammed" file, file size ratio, time to compress, memory usage during compression, and machine model & config info posted for your trailer test soon!

[ceraes]

jsaxton86's Test Result's: Input File: Title: The Simpsons Movie - 1080p Trailer.mp4 Kind: MPEG-4 movie Size: 147,399,359 bytes (147.4 MB on disk) Video Dimensions: 1920 x 800 Codecs: H.264, AAC Duration: 02:17 Audio Channels: 6 Output Cram: Title: The Simpsons Movie - 1080p Trailer.mp4.cram Kind: Document Size: 113,620,340 bytes (113.6 MB on disk) Time to Cram File: Seconds: 3313.306152 (55 Minutes ~13.3 Seconds) Memory Usage: GB (Rounded): 24.67 GB Hardware Overview: Model Name: iMac Model Identifier: iMac11,1 Processor Name: Intel Core i7 Processor Speed: 2.8 GHz Number of Processors: 1 Total Number of Cores: 4 L2 Cache (per Core): 256 KB L3 Cache: 8 MB Memory: 16 GB Processor Interconnect Speed: 4.8 GT/s Boot ROM Version: IM111.0034.B02 SMC Version (system): 1.54f36

We're really proud to try our best on your test jsaxton86, and we know that test results from the person showing you something always come with a healthy pinch of salt. So we'll ask the community to give it a try, and back us up here. Scientific testing means repeatable parameters, so we urge others to take his test too. (--EDIT: Turns out this file is too big 50MB in the limit of Github push-- We're also making our Cram file available on github, check it out with the decompressor or in a Hex editor: https://github.com/Cramcore/Crams)

From these results you can clearly see areas we aren't happy with either. Time and memory, but this is just the beginning for us, we developed this system because 4 decades of research hadn't yielded these results. Then we sat down and threw out the book. With some notes on the research of Marcus Hutter (http://prize.hutter1.net/) and Matt Mahoney (http://mattmahoney.net/) plus the input of wonderful mentors and mathematical genius like Brad Feld (http://www.feld.com/) we started code for the Cram project over 3 years and research another 2 before that. We're very grateful for the opportunity we have now.

We encourage everyone to try if for themselves, request the decompressor and try it too. But let humanity never believe that innovation is impossible. In 1966, the idea of a flip open communicator was science fiction, today we have not only communicators in our pockets, but whole computers. At Cramtec we hope our work can help move humanity to the next set of great technologies.

[nextw33k]

The Cram time is what piqued my interest, I assume that the decompression is also not real time. Video formats are obviously designed with real time playback in mind and processing constraints. Could you give the time to decompress that file?

Not saying this is a bad thing in anyway. I believe you are right when you mention piracy. For a torrent swarm this format would be ideal in the same way that RAR was a decade or two ago.

I think the trend to a centralised streaming Internet is a bad one. A decentralised P2P one is much more in keeping with the initial ideals of the Internet. Download, decompress (for use) and share are a much more fitting if they respected copyright at the same time.

Best of luck.

[brandonsmits]

Time is interesting. There's certainly no way you could stream videos like this right now, but the mention of future multithreading and GPU support would help minimize the time. You could support "cramming" by blocks of bytes rather than a whole file and leave the beginning uncompressed so you could start a stream and decompress the rest of the file with some lead time for the viewer. Certainly, this is pushing the bounds of hardware as of right now, but in a few years that'd be irrelevant anyway. They also pretty clear about it being a beta, can't wait to see what it could do in future.

[jsaxton86]

Thanks for taking the time to run that test. It is an extremely impressive result if it truly is lossless. I'd love to be able to independently verify it, so if you ever get a Linux compressor/decompressor, feel free to get in touch with me (contact info is in my profile).

If you're looking for another challenge, HEVC content can be found here: http://www.elecard.com/en/download/videos.html

[ceraes]

Thanks for the test suggestion, we'll run some HEVC and share results here today or tomorrow. We do have plans for a C version in the future but we'll have to get that far this is why we hope to be accepted to the wonderful Ycombinator Accelerator this winter.

Thanks for all your time jsaxton86! We'd love to have more people visit this thread and get the chance to have some independent results shared here, if you have any friends with OS X or a Virtual Machine, we could use their support!