-
Hello!
I know I have been asking for this feature some time ago, but as nothing has changed let me ask again:
The ZIPX-format offers an algorithm, that compresses JPEG-files by about 20-30%. Please add compression (packing) support for this in ZIPX-archives to Powerarchiver. Extraction of JPEGs packed into ZIPX by this algorithm is already supported by Powerarchiver for a long time, so it should not be difficult? Or is it a licensing problem?
Thanks! -
I love this, only there is one problem. The UAC elevation feature does not extend to Mount Image option in the add-on software PA provided. It is most annoying whenever I am on highest UAC settings and I mount an ISO, every time I open and create a virtual drive UAC appears. I also do not want to completely disable UAC.
Is adding UAC elevation for mount image feature possible?
-
The now defunct Bulkzip had Nanozip (nz) as an option this would be great to have for compatibility with my .nz files, so I don’t have to install Bulkzip separately.
-
Hi.
I noticed that when I want to run the Virtual Drive for the first time inside the PowerArchiver Burner it prompts to download it form the internet.
I was wondering, would it be OK to include this utility straight into the offline installer to be able to set it up locally?
Thank you!
-
How about recognising a few more (or all) of the file formats that are basically renamed zip files and treating them is if they are zip files.
For instance Android .apk files are just renamed .zip files.
Libreoffice/Openoffice ODF documents are all, as far as I am aware, just renamed .zip files. (.odt, .ott, .ods, .ots, .odp, .otp, .odb, .odf etc.) -
-
-
Hi,
I’d like to suggest, that the correct archive type is (always) selected, when adding files by drag & drop to an archive.
This is already happening if the archive has the correct extension. For example, if I’m adding files to test.zip, zip will be selected. If I’m adding files to test.7z, 7z will be selected as format in “Add dialog”.
But this won’t be working, if the archive has not the “right” extension.
So XPI files (Firefox addons) for example are ZIP files. PowerArchiver opens them without any problems, but if I try to add file by drag & drop, PowerArchiver won’t auto select “ZIP”, but use the last selected archive format, while PowerArchiver already knows, that I’m trying to add files to a ZIP. -
Would it be possible at all in some future version perhaps, to have a “find file” function?
Reason I ask is that I was looking for a certain file I knew existed in an archive, but I had to unzip it then use another tool to find the file. It would have saved that extra step if that function existed in PA itself. -
Hi.
Is there a way to enable the user to encrypt the files inside a ZIPX archive that has already been created?
This could save time for large archives that the user may need to encrypt at a later stage or that he/she has forgotten to enable encryption before creating the archive,
Thank you!
-
Hi.
I would like to see a new feature implemented: a ‘Fast Extract’ Mode.
Currently PowerArchiver extracts files to a temporary directory and then moves them to the target directory chosen by the user. At least via drag and drop.
This can be both time consuming and needs free space on the system drive for large files.
Is there a way to directly extract files to the target directory with PowerArchiver?
And if not, can a feature like this be considered for future updates?Thanks very much!
-
Hello.
I believe it would be useful to implement Serpent-256 encryption for PAE/PAE2 formats, even though PowerArchiver offers strong encryption ciphers already.
(deleted part advertising other software - admin)
Do you think this will be a useful addition?
Thank you for the consideration!
-
Hello!
I think it would be a great option to make the portable version of PowerArchiver compatible with PortableApps (i.e. adding the necessary files and folders to integrate it smoothly into their structure).
I own various other commercial programmes which -when installed in portable mode- offer to make the becessary changes without needing an extra installer or the official PortableApps repos.
Thanks for opinions or perhaps even a realization of this.
A.Borque -
Presently, PowerArchiver 2019 (any build) cannot rename PBS filenames by single clicking on such entry or right-click menu has no “Rename” feature!
Hmm, even pressing F2 on selected entry does nothing :(
-
Please add support for ownCloud / Nextcloud, thanks.
-
-
-
Hi,
I had a look at the command line switches, but there are no switches to change the startup mode.
At the moment, PowerArchiver opens in the last used mode.
Opening PowerArchiver from Start Menu or Desktop: Start in Explorer Mode Opening PowerArchiver by double clicking an archive: Start PowerArchiver in Archive Mode
I’d like to have command line switches to influence the startup mode.
Basically, the aim is:
Support for Google Zopfli and Brotli compression
-
I would like to see at least Zopfli-Support, which is a DEFLATE-compatible open compression algorithm which is slow but has better compression.
Reference implementations are available and details can be found here:
https://github.com/google/zopfli
https://en.wikipedia.org/wiki/ZopfliBrotli is NOT deflate-compatible but has even better ratios (beating LZMA2) and is intended to replace gzip on the web for data transfers.
http://google-opensource.blogspot.de/2015/09/introducing-brotli-new-compression.html
https://github.com/google/brotli/
http://www.gstatic.com/b/brotlidocs/brotli-2015-09-22.pdfCheers!
-
Thanks Manuel!
are there any test results comparing speed with kzip or 7zip deflate?
-
There’s a comparision table for the “Canterbury corpus” in http://www.gstatic.com/b/brotlidocs/brotli-2015-09-22.pdf at Page 4 and the following pages with “real world” data.
-
There’s a comparision table for the “Canterbury corpus” in http://www.gstatic.com/b/brotlidocs/brotli-2015-09-22.pdf at Page 4 and the following pages with “real world” data.
hm, first test shows zoplfi being 70x slower to compress than deflate for 0.2% better compression ratio… this is likely because focus of their deflate is strong er compression for png images.
However in archiver, this would be very impractical since you can use 7z format for instance to achieve much better compression at much faster speed. For instance they show 7z at ultra setting being 20x faster than zoplfi while getting much better compression.
Similar implementations of stronger but much slower deflate existed before (kzip), and are used for various png re-compress tools.
-
Fair point. Zopfli is already in use for PNG re-compression.
Since it it deflate-compatible no further support is needed on PA side I understand.But if some sort of “real” format of Brotli gets adopted at least decompression support for that could be implemented (like PA already supports some more exotic formats).
Thanks for your considerations so far :)
-
Fair point. Zopfli is already in use for PNG re-compression.
Since it it deflate-compatible no further support is needed on PA side I understand.But if some sort of “real” format of Brotli gets adopted at least decompression support for that could be implemented (like PA already supports some more exotic formats).
Thanks for your considerations so far :)
if they add it for 7z or zip, we will use it of course, but again, this seems to be made for web page compression where speed of extract is important… test shows LZMA being 8x faster at ultra than Brotli with LZMA being tested at low window sizes, which means comparing it to classic LZMA window sizes, it would get much better results.
For them though, most important part is again speed of decompression, which is only where it is likely good.
So I dont think you will see this implemented in real archivers, unless someone makes modifications that make it much better.
Now on the other side, zpaq…
-
@H4ndy interesting… since .pa is coming, we just tested brotli vs zstandard:
43426928 0.921s: bro.exe --verbose --force --input enwik8 --output 1 --window 27 --quality 0 42456665 1.139s: bro.exe --verbose --force --input enwik8 --output 1 --window 27 --quality 1 36950376 2.371s: bro.exe --verbose --force --input enwik8 --output 1 --window 27 --quality 2 36685096 2.839s: bro.exe --verbose --force --input enwik8 --output 1 --window 27 --quality 3 35623532 4.446s: bro.exe --verbose --force --input enwik8 --output 1 --window 27 --quality 4 33409515 8.269s: bro.exe --verbose --force --input enwik8 --output 1 --window 27 --quality 5 32447946 11.654s: bro.exe --verbose --force --input enwik8 --output 1 --window 27 --quality 6 31059249 21.435s: bro.exe --verbose --force --input enwik8 --output 1 --window 27 --quality 7 30327408 35.272s: bro.exe --verbose --force --input enwik8 --output 1 --window 27 --quality 8 29686256 61.574s: bro.exe --verbose --force --input enwik8 --output 1 --window 27 --quality 9 40859654 0.905s: zstd.exe c enwik8 0 1 52 1 27 37647556 1.124s: zstd.exe c enwik8 0 1 52 2 27 35643321 1.358s: zstd.exe c enwik8 0 1 52 3 27 34878618 1.544s: zstd.exe c enwik8 0 1 52 4 27 34801006 2.246s: zstd.exe c enwik8 0 1 52 5 27 33269248 3.042s: zstd.exe c enwik8 0 1 52 6 27 32588280 3.931s: zstd.exe c enwik8 0 1 52 7 27 31796598 5.460s: zstd.exe c enwik8 0 1 52 8 27 31293605 7.363s: zstd.exe c enwik8 0 1 52 9 27 27259613 62.759s: zstd.exe c enwik8 0 1 52 19 27 29686256 61.574s: bro.exe --verbose --force --input enwik8 --output 1 --window 27 --quality 9 27259613 62.759s: zstd.exe c enwik8 0 1 52 19 27 29686256 61.808s: bro.exe --verbose --force --input enwik8 --output 1 --window 25 --quality 9 27287874 62.463s: zstd.exe c enwik8 0 1 52 19 25
so at same speed it has lower compression in testing by @eugene , and in my testing with same compression, it is 2x slower… so it seems like inferior to zstandard.
-
@spwolf Yeah it really is only for high-demand resources where you want to squeeze the smallest possible size out of it and you do not care that it takes half an hour to compress it in the first place. It’s bandwidth optimization.
-
@H4ndy I know that’s the official line, i hope it works for them :).
-
@spwolf Probably once you start serving some resources a few million times a day :D
Anyway, thanks for still checking it out :) -
@H4ndy yeah… pretty much everything was tried… same goes for apple’s port of zstd. Not efficient for archiver at all.