[Jansar]

I have a folder on my computer which contains a bunch of .ace files (.ace, .c00, .c01, etc) and I was wondering which program can be used to un-ACE it. Does un-RAR X work?

[yukon]

WinACE. their website has a brand new OS X program to do it, unace probably.

second step, reprimand the sender/creator, introduce them to either; Fist, or tar and gzip (.tar.gz). this goes for RAR archives too, use bzip2

[CharlesS]

I thought StuffIt Expander was supposed to be able to decode those?

[yukon]

the new Stuffit 8 seems to want to decompress RAR files (even has an icon for them), I haven't given it the chance though, used to try and die half way in v.7. ACE and RAR are propreetary formats, previously at least never compatible with anything other than the programs made by the company owning the format. I believe there's still no way to make a RAR or ACE file on the Macintosh (discounting windows emulation).

I often have trouble with RAR and ACE files, they apparently (it's propretary, I can't know) leave no redundancy at all, making for easier corruption....or it's just a crap format that causes corruption in about 20% of the files I get in said formats.

[bradoesch]

StuffIt (v. 8) has decoded a few RARs for me.

[iOliverC]

I use UnRarX. Don't know if it works with ACE files.

[Moonray]

Rar and Ace are different and not compatible to each other.

You can get the original OS X versions of unrar (free) and rar (not free) from http://www.rarlab.com/. Both are command line versions but there exists a number of GUI wrappers.

For .ace archives I found recently iUnacer. I didn't have a chance to try it yet though. However the original at http://www.winace.com/ will be the way to go.

-

[RevEvs]

All you need to get is UnRar X and there is also unAce X. Both much better than Stuff It.

let me go find the links...

unrar X : http://unrarx.sourceforge.net/

and

unace X : http://unacex.sourceforge.net/

they should surfice

revs

[yukon]

I actually had trouble decoding archives with the open source unrar. I'd suggest using the "official" unrar program to decode RAR files (then zip or tar gzip them), at least until the OSS one improves.

RAR and ACE are different, but have similar aims. They are both propretary, both made more difficult by the owning companies, and offer compression better than gzip and zip. Again, if you're doing the encoding, use zip quickly as it's in OS X.3, use gzip for fast easy compression, or bzip2 for strong compression (bzip3 for maximum), and only compress once (redundant compression ADDS to the file size).

Just one of my pet peeves. getting a zip file from a exe from a zip from an ace from a 82 part rar file.

[Moonray]

Originally posted by yukon:
RAR and ACE are different, but have similar aims. They are both propretary, both made more difficult by the owning companies, and offer compression better than gzip and zip.

Any proof for that?

-

[yukon]

What can I say, TRY IT. there's a tradeoff of CPU usage and ability to compress. ZIP and GZIP are general purpose compression algorithms. RAR and ACE took advantage of this, to offer better compression rates, spreading their standards. If you check their websites, they will extoll the virtues of their amazing slightly better compression, and indeed they will get you smaller archives on average. But, there are better open formats that do the job, as mentioned before, GZIP and BZIP2 (BZIP3 in development, very strong compression).

It's general knowledge, I'm looking and I don't see many "benchmarks", but then it's your question and I hear google.com has an interesting feature :). You can try testing though, and despite each format possibly having advantages and disadvantages for different types of data (text, binaries, whatever), ACE, RAR, and BZIP2 will "win" for file size. For fun, try clocking them, and try clocking BZIP2 with the highest compression level (-9 switch or something), might get a few kilobytes down ;-)

[[APi]TheMan]

I use UnaceX and command line unrar. This day in age is there really a need to preserve clock cycles or a few kilobytes? Eh. I think .ace and .rar are a pain in the butt, I'd rather see stuff .tar.gz'd.

Some communities use RAR segments (.rar, .r01, .r02, etc), which is cool with me, but otherwise I think tar is the easiest to use as it's been around since T-Rex was cruisin' the streets.

[Moonray]

Originally posted by yukon:
... It's general knowledge ...

Shouldn't I have heard of it if it's general knowledge?

However, I tried. Compressed a 50 MB folder with about 20 MB text files, 20 MB JPGs, and "Address book" which is about 10 MB:

Code:
        time (s)  size (MB)
rar     48.9      29.5
zip     10.4      30.9
gzip    10.8      29.6
bzip2   41.9      26.6

The rar results are not that impressive to me. It's even questionable if the 10% less size of bzip2 is always worth waiting 4 times as long, but that depends on the use (-9 is already the default).

Oh well.

-

[yukon]

Heh, general knowledge, yeah you should have ;-). I suppose it could be general UNIX and Windows knowledge, but we also have "fast" and "maximum" compression settings in dropstuff, and sitx using it's doubleplusmaximum whatever (which takes forever to decompress, geez). Competing compression died out pretty fast on the Macintosh unfortunatly.

JPEG is already highly compressed, you won't get much of anything out of that (same with video, notice I said "uncompressed video" earlier) but a few kilobytes. Text will compress easily, human language is pretty redundant. Often, strong compression would be used on large files, like CD size. Saving 10% more on a 1.2gb archive means quite a lot of additional savings in storage and distribution time. Of course, diminishing returns, very fast compression will get you maximum savings per time necessary.

I was actually surprised how well bzip2 fared against RAR, I expected it to be better but not both faster and creating smaller archives. The difference between ZIP and TGZ, could be partly attributed to the tarring (it helps), but it wouldn't be all the difference unless you used 1k jpegs or something ;-). Overall, a good show for OSS, bad show for Windows utilities, and some confusion as to why Apple didn't use HFSTar with gzip for their Panther BOMArchiveHelper/In-Finder-Zip-Compression.

[Moonray]

For the sake of fairness... gzip and bzip2 were each including tar. Most JPGs were around 200 to 350 kB, most text files from 0.5 up to 1 MB.

Compressing only the text files made rar look a bit better for the compression (not the speed), doing only the pictures let rar create the biggest file but all were only a bit under the sum of the size of the JPG files as expected.

I wonder how it could be general UNIX knowledge if rar isn't a popular format there and how it would be Windows knowledge given that most windows users don't know about gzip.

I think Apple decided for zip because everyone knows and has it (however they ran out of ideas when they were to find a good name for BOMArchiveHelper).

-

[yukon]

I've been told that WinRAR 3 and above, along with WinACE (possibly 2.2 only) have new compression algorithms. Testing that, yeah, RAR3.2 is getting quite a lot better compression that bzip2, at least when it's set to maximum compression and solid archives (similar to tar functionality), not sure about how much longer it takes. Unfortunate, bzip2 is free, it would be nice to see it winning. There was a page for bzip3 up, now I can't find a mention of it anywhere on google, apparently it was an experiment of some sort.

Sorry to bring up an old thread, but this was the only place I could remember explaining compression.