Looking for a good media compression & archiving algorithm for an app I'm building. More specifically, I'm looking an algorithm I had used 10 years ago but had totally forgotten the name of. Description: It was a self-extracting archive (about 800MB) that spat out a folder of over 6GB (mainly media: movies & audio). Now, the media files themselves were already in compressed format (MP3, MP4, etc...) so I was really impressed. Only drawback (as expected) was that it took over 1 hour to decompress on an Intel dual core. Does this kind of performance ring any bells for anyone? I just need a name.
Ask HN: Looking for compression algorithm that took 6GB to 800MB. Anyone know?
1–10 of 17 posts
Re: Ask HN: Looking for compression algorithm that took 6GB to 800MB. Anyone know?
#2I wanted to add: The self-extractor had no interface -- it was all in the windows command prompt. A message in the prompt said something about "Media compressor" and below it was the percentage extracted.
Re: Ask HN: Looking for compression algorithm that took 6GB to 800MB. Anyone know?
#3Pied Piper?
Re: Ask HN: Looking for compression algorithm that took 6GB to 800MB. Anyone know?
#4Pied Piper?
[deleted]
Re: Ask HN: Looking for compression algorithm that took 6GB to 800MB. Anyone know?
#5We just to joke at NetApp that the Oil and Gas industry had the best compression algorithm, it could compress 100TB of seismic imaging data into a single bit {oil / no-oil } :-)
I created a theoretical compressor which I haven't yet been able to implement which uses the fact that every sequence of bits appears in pi somewhere, so my compressor would just return the digit offset and the length of data. I keep looking for a source for all the digits of pi though, have yet to find it.
Re: Ask HN: Looking for compression algorithm that took 6GB to 800MB. Anyone know?
#6Pied Piper?
inside out compression algorithm
Re: Ask HN: Looking for compression algorithm that took 6GB to 800MB. Anyone know?
#7I don't believe there is any known lossless algorithm which can achieve 7.5:1 compression on already-lossy-compressed media files.
If you want further lossy compression for existing media files, look at the newest algorithms supported by ffmpeg.
If you want generic lossless compression, you can do a bit better than the usual suspects (gzip et al), but only if you're willing to put up with very slow compression times.
If you have some other type of specific data (e.g. sparse files) then you could do something custom, but I guess this is unlikely to be your situation.
Re: Ask HN: Looking for compression algorithm that took 6GB to 800MB. Anyone know?
#8Call me a skeptic, but there is no way there was an algorithm available to humans 10 years ago that reversibly compressed 6GB of unique, already-compressed media files down to 800MB. The only way this could have happened is if there were shared files or shared segments between the files. For example, if a DVD had a bunch of audio tracks but some of the tracks were basically just direct copies of the others, then the compressor could recognise the similarity and capitalise thereon. For lossless compression of general data, 7-zip set on Ultra is probably the best available right now. On the other hand, algorithms such as FLAC or PNG work well for losslessly compressing uncompressed media.
Re: Ask HN: Looking for compression algorithm that took 6GB to 800MB. Anyone know?
#9You can look through the software here: http://www.maximumcompression.com/benchmarks/benchmarks.php
Or the software linked via here: http://prize.hutter1.net/
As other people say, what you're asking for probably isn't possible.
Re: Ask HN: Looking for compression algorithm that took 6GB to 800MB. Anyone know?
#10We just to joke at NetApp that the Oil and Gas industry had the best compression algorithm, it could compress 100TB of seismic imaging data into a single bit {oil / no-oil } :-) I created a theoretical compressor which I haven't yet been able to implement which uses the fact that every sequence of bits appears in pi somewhere, so my compressor would just return the digit offset and the length of data. I keep looking…
why not just create an online API for this? Sequences that are not yet "found" would go uncompressed, and as time goes by and internet speeds get faster and computing power gets cheaper, more sequences will be "found" for reference in that API and the algorithm will keep getting better.
Alternatively, you could release a program that comes with an already long sequence of the decimal section of PI and connects regularly to the internet to download more digits (you could even run the computation & API on a google compute / amazon ec2 instance to keep costs low)