Compression Comparison Guide

[snn47]

Nice work, interesting read and you even found/tested a few formats I didn't know about.

However I do have to disagree with your conclusion.

I summed it up in

Which compression-program/-format for archiving which file(s)/-format http://ehome.compuserve.de/snn47/_GN...Bench_v0-1.pdf
and with input from others and a lively discussion at http://forums.overclockers.com.au/sh...threadid=89560

What time, how efficient is compression, can packed archives be repaired

You tested only various different file formats with medium sized files. not folders with various but relatvely small files .....

[snn47]

[quote="snn47"]Nice work, interesting read and you even found/tested a few formats I didn't know about.

However I do have to disagree with your conclusion, since it depends mainly on what you want to use a packer for.
What time, how efficient is compression for files/folders of what size format, can packed archives be repaired ...

You tested the packer for various single file-formats with an average medium sized file, but not folders with various but relatvely small files to large files .....

I summed my questions and my test-results up in
Which compression-program/-format for archiving which file-format FAQ/answers needed? with input from others and a lively discussion at http://forums.overclockers.com.au/sh...threadid=89560

[elh]

Adrian: which film did you use to test the DivX compression, at first the numbers that SBC gave seemed riddiculuosly high, but I gave it a try. As I expected I could not not reproduce the extraordinary compression ratios on divx files... I tried the same settings u've used as well as multitude of others, but none of them helped me to go past 97% compression ratio If anyone has ideas regarding this, tell me...

[Adrian Wong]

Hello snn47,

Evaluation of data compressors is very difficult. Especially since different compressors have different levels of compression available. That's why I chose to use only the maximum compression level. At least we will know what's the best compression we can see from each of them.

As for the test files, I prefer to use real-world files, instead of arbitrarily created "benchmark files". I did not specifically look for medium-sized files. I just chose as wide a range of filesizes as I could but we have to be realistic. Certain file formats like WAV will produce very large files. Of course, I could always use the beeps and burps WAV files cause they would be really small. But in real working environments, I doubt anyone would be working with lots of tiny WAV files. Again, the emphasis is on working files, not specially created benchmark files.


Hello elh,

I used two mini-clips created by Chai. I can send you the files if you wish to reproduce the test results. I assure you the results are accurate as far as the test files go. Just tell me how to send the files to you. They are two DIVX files weighing about 50MB in total.

But fret not because no matter what DIVX files we use, they are used for all the compressors so if a particular DIVX file is very compressible, the other data compressors should benefit too.

[Worf]

Stuffit is actually a *MacOS* based compression utility - it has several advantages over the other Mac-based compression utilities out there. Namely, it was excellent at putting all the data in the data fork, so no special BinHex or MacBinary conversion was needed (helpful to preserve other metadata, but not necessary). I know there was a Windows version of it, but always discounted it as its 'native' environment was a Mac (for the same reason most Windows users don't try tar-gzip or tar-bzip2).

[snn47]

Hello Adrian,

thank you for your reply.

I agree with the use of real-world files, however the one we might choose might favor one algorythmn more then others, unless it's very complex.

For my Graphic tests I scanned a LH-Boarding Slip into Tif-Format, and converted this into all other formats.

All files used should be availble if someone wants to redo/verify results, which would require at least one CD and might pose a problem for WAV-files due to copyright, but it would allow to make tests compareable.

I have to disagree with just using a single large file.

The main use of single files compression is when I want to compress a large file onto a disk/CD and avoid having to split it. Here it's important to know what is the best compression format/setting for the task.

However if you want to archive folder/volumne containing many different file formats e.g. like internet downloads (html, gif, jpeg..) then it's the efficiency for small files of the various formats and the overall effeiency that counts.

I opt normally for efficiency rather then short compression time, since on may Laptop and slower drives the compression time is often compensated by slower drives access.


As for reference files maybee there is a way to multiply fragments of a picture, video into larger resolutions, sizes for archieving the referenc data.

But this would require the willingness of more then one site to generate a unique applicable test source.

[Adrian Wong]

Hello snn47,

Actually, the files I used were not specifically created for the tests. All of them were either obtained online from public domain sources or were taken from our own PCs (our work files). As such, they should accurately reflect real-world files.

Also, I don't mind anyone making use of our test files as some kind of standard. I can write a CD of the entire test compilation for whoever's interested. All the files in the compilation are either public domain or belong to us so there's no copyright issue.

As for favouring one algorithm over another, well, I frankly have no idea what to say to that. To do that, I will have to do quite a bit of research to see how I can tweak the files to favour one compressor over another. Unfortunately, I really do not have the time for such hanky-panky. Hehe...

Frankly, irrespective of the results, I'm still keeping to my favourite data archiver. I only did this comparison out of interest. Just to see how well they all perform. There's really more to data compressors than just the performance. But for those who are interested to see how well they perform, well, that's what the comparison is for.

Again, if you wish to verify the results, I would be happy to let you download our files. We have nothing to hide.

Hmm... it's not really useful to create multiple small files. That would just be skewing the results in favour of certain compressors. Some files are inherently small while others are, by nature, very large. For example, GIF and HTML files tend to be small (less than 500kb) while DIVX movies are large (more than 20MB).

IMHO, it's best to use working files because they will accurately reflect the situations you will encounter in the real world. Even if some files are large, that's okay. What we want to know is - if compressor X is better than compressor Y in the comparison, it must be better than compressor Y when I actually compress the same files. There's really no point (inaccurate even) to specifically break down large files to smaller sizes.

[peaz]

Just thought that I should share this experience i had with compressors...

I use to do lots of Flash, and once, I had to submit a few versions of a particular Flash file for approval. The only difference between the files are a few text changes, all the graphic elements remains the same. So, this set of files should be very compressible in my opinion. Single file, maybe not, but the whole set... YES!

Well, I tried compressing them with WinZip 8 and WinRAR 2.5 (it was quite a while ago)

The result was sort of expected. WinZip treats each file as a distinct file and compresses them seperately also! As the files was not very compressible(already compressed in nature) the whole zip file was quite huge.

However, with WinRAR, the result was interesting. I used the highest possible settings, with the multimedia option checked. WinRAR manages to see that all the files are almost the same and therefore, the first file was compressed as much as it could, then it 'seems' to store the other files difference only!

As such, the total compressed RAR file size was only a little bit larger than a single filesize of that set of files!!!

Interesting!

[elh]

Originally Posted by Adrian Wong

Hello elh,

I used two mini-clips created by Chai. I can send you the files if you wish to reproduce the test results. I assure you the results are accurate as far as the test files go. Just tell me how to send the files to you. They are two DIVX files weighing about 50MB in total.

But fret not because no matter what DIVX files we use, they are used for all the compressors so if a particular DIVX file is very compressible, the other data compressors should benefit too.

First of all, thanks for the response ans sorry as I was kind of offline for a week or so..
Anyway, have you actually tried compressing "commercial" divx? Just a casual 700MB film? I tried every setting on several films, but as I said before - it's no breakthrough, am I right? I see no other application of SBC, winrar has far more developed interface etc. So the only use of SBC could be packing ~1GB divx's on a single CD, at least for me.
Anyway, I asked you the question, because I might be wrong, maybe there is some basic error. I typed the following:
sbc c -m3 [-b1 / b63] -hn archive film.avi
This should give the best comprresion ratio, right? I'd love to download the files from you, but unfortunately I'm still on the dial-up, so I'd rather not

Regards,

Elh

[Chai]

We can't use 'commercial' DIVX for obvious copyright issues, so we have to use our 'home videos' to do the testing, just in case we might need to distribute the testing files.

But the problem is, I was not able to use the maximum compression when compressing the videos when compressing in Adobe Premier. So the videos can still be compressed a little more.

The 'commercial' DIVXs use maximum compressiong with VBR, and to optimize the file size and quality, they have to go thru a few more passes, instead of just one in Adobe Premier.

So that's the reason why the 'commercial' DIVXs are not as compressible as the test DIVX files we used during testing. You can't compare your video's compression ratio with our test file.