Check Compression Level In An Existing .rar File?

Hi all,

Just wondering if there's a way to check the compression of an already rared .rar file.

I'm trying to create a profile within WinRar and want to ensure it's doing exactly what I want it to do as far as compression (Store as opposed to the other compression levels). I don't want the files stored to be compressed in any way.

So, like I said, I know how to create a .rar without any compression, but I want to check that the files were stored after the .rar is made.

Thanks!

As far as I know the compression level is not stored anywhere within the file. If you ask WinRar for file information it will only report sizes and compression percentage. The only relevant info is the dictionary size, but the level "stored", "fast", "best", etc don't seems to be saves anywhere, so I think it's not possible to query it in an already created file.

However, if you just want to check if the rar is really uncompressed at all, it's possible to look at the compression level and the file sizes. If compression is at 100% and the total file size is equal to the compressed file sizes it means that the file was in fact "stored". For all other levels you can only guess, but the "no-compress" level is noticeable.

And do note that some file types don't compress much or not at all, see it with images, text files can compress quite a bit. Different programs tout they do better than others. The thing the no-compression would be good for is avoiding blocking of the actual file extension on the Internet.

I use no compression to store images. I was under the impression that once the file is compressed it "tosses" out bits of data...like a lossy .mp3 compared to a .flac.

And I figured once that compression is done the file is changed permanently.

And I figured once that compression is done the file is changed permanently.

No, decompressing should restore the original file, as it stood before the compressing. Compressing with WinZip, 7-Zip, ZPEG or others is only for storage, not for editing the file itself. If any bits are removed by the compression routine the decompression routine should restore them.

Saving images and their sizes is controlled by the format to be saved in, for example a .bmp converted to .jpg will result in a smaller file size and 'may' result is some loss of resolution, color layers, etc., which is fine for posting on the Internet or sending as attachments. For printing or archiving, the file type is important, want the best quality available which results in large file sizes with the camera's RAW format being quite large in comparison with other types, e.g. 20MB versus 3MB of a .jpg.

Unlike some other types of compression such as mp3, rar and zip are not lossy. A file compressed in this way is restored to the exact form it was before compression. This is critical for file types such as .exe where even a single bit wrong out of millions would likely render it useless.

As others have said, it's not the case with rar (or zip or 7z, for the matter), they all are effectively lossless like flac or png.

Multimedia compression algorithms are vastly different to those of WinRar. To begin with mp3 relies on an heavy assumption: that it always will be applied on audio data. It's a very important aspect of its operation. It's lossy not because it's just throws away random bits of data to make more effective compression, what it does is to analyze the audio stream and using the knowledge of the typical human earing characteristics it discards information in the frequency range where humans are less sensitive, so that only a musician is able to notice the difference. This characteristics is strongly influenced by the fact that the algorithm knows beforehand on what it will be working on, and makes assumptions and trade offs based on that data.

Png is also similar, it's optimized for photography and discards information that makes real-world images look almost the same while achieving an important size reduction. But the very same algorithm does disasters on screenshots, for example, with quite noticeable artifacts all over. This is the tradeoff when the assumptions aren't meet.

Rar files, or any other general purpose compression algorithm, does not have such privilege. It's designed to work on any piece of data, unknown beforehand so it can't make any guess on how the data will be used, or even what kind of data it is. Thus, the only safe move for it is to explicitly preserve each and every byte of the input in the final uncompressed output. This is the reason that it's often more inefficient for specific file types. For example, a rar'ed .bmp file will generally be bigger than converting it to png or jpg, for example. This is also the reason why rar is so ineffective with mp3 or mpg, because they've already been aggressively compressed by special-purpose algorithms before, and rar can barely find anything else to do.