I guess this could be software but since i want to strictly talk about the physical size of files and now which is better, i would ask which compression scheme is better and why?
I guess this could be software but since i want to strictly talk about the physical size of files and now which is better, i would ask which compression scheme is better and why?
which can make files smaller?
is there one that gets corrupted easier?
.sitx is the smallest, and it preserves things like resource forks, HFS metadata, permissions, etc. It's best for casually sending files to Mac users.
.zip is much larger, but since it's bundled with Windows, it's the best one to use if you're sending files to PC users. It sucks for sending files to Mac users since it doesn't preserve any Mac metadata.
.dmg is a little better than .zip, but larger than .sitx. However, it is very easy to use and has many features that make it the best for software distribution.
bzip2: fast as zip, small as sit. . . plus it has error correction abilities. Only issue is that files have to be at least 100k or so is order for it to work well. (a batch of files larger than 100k should work fine)
I use bzip2 from the command line all the time, and Aladdin Expander can decompress them. I'm working on a heavily enhanced Cocoa version. (enhanced meaning that the algorithms I use fly on G4s)
when i have to compress things, i usually tar and gzip them. i have no idea how it compares, but it works fast enough for me. winzip and aladdin can both handle it. i usually use 'tar' on the cli though.
i just decided to do a comparison, on a 238k file. gzip'd its 107k, bzip'd its 106k; and tar'd plus gzip'd added negligibly, as did tar & bzip. so i guess bzip2 is smaller than gzip. i'll have to get used to piping tar into bzip2 now. maybe i should even cut that tar step...
I find .sitx to compress really fast...though decompression is awfully slow...
I don't know if you're serious here or not, but despite any benchmarks (I haven't seen em) it seems to work quite fast. Excedrin users should appreciate that.
Try compressing Bzip2 against Stuffit. Most of the use I have for it is image compression. (i.e. lots of big photoshop files that I copy onto CDs or MO Disks). It does a better job than sit. It really starts to do it's magic as files get large.
I don't know if you're serious here or not, but despite any benchmarks (I haven't seen em) it seems to work quite fast. Excedrin users should appreciate that.
Try compressing Bzip2 against Stuffit. Most of the use I have for it is image compression. (i.e. lots of big photoshop files that I copy onto CDs or MO Disks). It does a better job than sit. It really starts to do it's magic as files get large.
Actually, I retract my statement. I just did some tests. with a 50 MB file of /dev/random spew. Stuffit and bzip2 are about equally slow. What took 2 minutes to process in bzip2 and 2:20 in both stuffit formats took 17 seconds with gzip! 15 seconds with zip! 40 seconds with DropZip.
Actually, I retract my statement. I just did some tests. with a 50 MB file of /dev/random spew. Stuffit and bzip2 are about equally slow. What took 2 minutes to process in bzip2 and 2:20 in both stuffit formats took 17 seconds with gzip! 15 seconds with zip! 40 seconds with DropZip.
Lol, /dev/random = pure entropy...or tries to approximate it anyway. If you find a compression algorithm that can compress purely random code, you'd be God.
Just keep in mind never use anything but SIT for Mac specific files (installer, apps, etc)
If you compress those files in other format (Zip, TAR, GZIP) the resource fork will be lost. Once you decompress all you have will be bunch of "generic" file serving no purpose. SIT does store the resource fork data.
Other than that, you can use whatever compression you want.
I use Zip a lot because I can easily share file with other PC people. When compressing Mac specific self-executable files I use SIT
Comments
Originally posted by ast3r3x
I guess this could be software but since i want to strictly talk about the physical size of files and now which is better, i would ask which compression scheme is better and why?
which can make files smaller?
is there one that gets corrupted easier?
.sitx is the smallest, and it preserves things like resource forks, HFS metadata, permissions, etc. It's best for casually sending files to Mac users.
.zip is much larger, but since it's bundled with Windows, it's the best one to use if you're sending files to PC users. It sucks for sending files to Mac users since it doesn't preserve any Mac metadata.
.dmg is a little better than .zip, but larger than .sitx. However, it is very easy to use and has many features that make it the best for software distribution.
sit: slower, smaller files
bzip2: fast as zip, small as sit. . . plus it has error correction abilities. Only issue is that files have to be at least 100k or so is order for it to work well. (a batch of files larger than 100k should work fine)
I use bzip2 from the command line all the time, and Aladdin Expander can decompress them. I'm working on a heavily enhanced Cocoa version. (enhanced meaning that the algorithms I use fly on G4s)
I find .sitx to compress really fast...though decompression is awfully slow...
i just decided to do a comparison, on a 238k file. gzip'd its 107k, bzip'd its 106k; and tar'd plus gzip'd added negligibly, as did tar & bzip. so i guess bzip2 is smaller than gzip. i'll have to get used to piping tar into bzip2 now. maybe i should even cut that tar step...
Originally posted by Eugene
bzip2...fast? Our you out of your mind?
I find .sitx to compress really fast...though decompression is awfully slow...
I don't know if you're serious here or not, but despite any benchmarks (I haven't seen em) it seems to work quite fast. Excedrin users should appreciate that.
Try compressing Bzip2 against Stuffit. Most of the use I have for it is image compression. (i.e. lots of big photoshop files that I copy onto CDs or MO Disks). It does a better job than sit. It really starts to do it's magic as files get large.
Originally posted by Splinemodel
I don't know if you're serious here or not, but despite any benchmarks (I haven't seen em) it seems to work quite fast. Excedrin users should appreciate that.
Try compressing Bzip2 against Stuffit. Most of the use I have for it is image compression. (i.e. lots of big photoshop files that I copy onto CDs or MO Disks). It does a better job than sit. It really starts to do it's magic as files get large.
Actually, I retract my statement. I just did some tests. with a 50 MB file of /dev/random spew. Stuffit and bzip2 are about equally slow. What took 2 minutes to process in bzip2 and 2:20 in both stuffit formats took 17 seconds with gzip! 15 seconds with zip! 40 seconds with DropZip.
Originally posted by Eugene
Actually, I retract my statement. I just did some tests. with a 50 MB file of /dev/random spew. Stuffit and bzip2 are about equally slow. What took 2 minutes to process in bzip2 and 2:20 in both stuffit formats took 17 seconds with gzip! 15 seconds with zip! 40 seconds with DropZip.
but what were the sizes?
Originally posted by ast3r3x
but what were the sizes?
Lol, /dev/random = pure entropy...or tries to approximate it anyway. If you find a compression algorithm that can compress purely random code, you'd be God.
so if it look at a randomly generated lump of code couldn't it find something to do?
PS...i am god but for other reasons
Originally posted by ast3r3x
i thought compression was repetative or a pattern that can simply be stated in a lesser amount of code using an algorithm
so if it look at a randomly generated lump of code couldn't it find something to do?
PS...i am god but for other reasons
There will be patterns, but given a large enough sample, it won't be enough to combat the typical overhead.
In each case, zip, gz, bz2, sitx and sit, the compressed file ended up being between 100 and 300K larger.
If you compress those files in other format (Zip, TAR, GZIP) the resource fork will be lost. Once you decompress all you have will be bunch of "generic" file serving no purpose. SIT does store the resource fork data.
Other than that, you can use whatever compression you want.
I use Zip a lot because I can easily share file with other PC people. When compressing Mac specific self-executable files I use SIT