In short, this aims to maximize compression of a 7z archive when it contains sub-optimal archives (zip) inside it. The accepted disadvantage is that the integrity of the zip files is not fully guaranteed. Though the actual files inside will be untouched.
This would be an optional feature in 7-zip. When compressing files in 7-zip:
- The program will first check if any of these files are already compressed with a less effective compression (like zip). This will work only for supported compression formats.
- In case such files are found, the program will decompress them, save some metadata about this (including an integrity checksum), and compress them with its own 7-zip algorithm.
- When the archive is extracted later, the program will know which folders/files have originally been zipped, so it will first decompress them (from 7-zip), then compress them with the original algorith (zip).
Currently archiving multiple files with 7-zip does not produce best results when many of the files are already compressed with zip compression. For instance, in a test whith an ebook (that contains a lot of text) it produced the following results:
- 391 KB - zip (original)
- 1.32 MB - extracted files
- 382 KB - 7z of original zip
- 204 KB - 7z of extracted files
(As you can see there is an improvement of nearly 2x in this case.)
Obviosly we get much better results when compressing plain files, instead of their zipped version.
- Admittedly, this may result in different zip files byte-by-byte after the first cycle of compressing and decompressing. One of the reasons is that the original zip may have been compressed with a different algorithm than the one 7-zip uses in this process. However, this would not be a problem if the user does not need a 100% by-to-byte reproduction of the original zip files. Realistically speaking the contents are going to be the same byte-by-byte when we compare the fully extracted files before and after (disregarding the zipped form). Integrity could still be checked with a checksum on the extracted files instead of on the original zip.
- Another weak point of this algorithm is that it will be slower than just 7-zipping everything the regular way. However, I believe this is a reasonable price to pay for a dramatic improvement in the compression ratio.
- Due to the above reasons this feature would be off by default, and a short warning would be displayed when a user wants to turn it on. I believe the compression advantage outweighs the drawbacks in many use cases, where maximum compression is desired.
I was just thinking about scenario as well while doing some archiving.
And another idea, aside from Dimitrov's aforementioned idea, was also to set 7-Zip to just 'Store' compressed file types rather than attempt to compress them even further.
Not just achive files like .zip, .arj and others, but also .jpg, .gif, .png are also compressed, which could be incorporated into the 'Store' scope.