I bought Powerarchiver Toolbox because I find the .pa format brilliant!
The problem with this format is that only Powerarchiver can open it, so it won’t be as famous as the .rar or .7z!
In my opinion it is okay to have the exclusive of the creation of the format, but not of the extraction, otherwise it will never be used by anyone because few people have Powerarchiver!
I hope that one day the other extractors will be able to extract the .pa format, I will be able to create archives and send them to whoever I want!
Hi, I have such a problem. 03.09.2020 I bought this program, I received the registration data that I entered into the application (copy and paste), the application restarted and again reported that it is not registered. I tried it several times, online and offline, I logged in to the web account, I sent the activation email again, I entered its data, but I still can’t register it. So I wrote to support and on September 3, 2020, three hours later, they sent me a screenshot that they managed to activate the program. I thought I might have something to do with windows, so I reinstalled. But that didn’t solve the problem. It cannot be activated in either version 19.00.59 or version 20.00.53. When I wrote them that I still can’t do it, I even sent it to them both in screenshots and in the video, even after reinstallation, and I even attached a dxdiag file to them, so they don’t even answer me anymore and I don’t know what to do with it :-(
It’s been a week since it was shipped.
Any suggestions please?
It was raised poor PA compression ratio:Uncompressed: 21,657,900,590 bytes 7-Zip (your package): 2,662,732,158 bytes PowerArchiver 17.00.90 (Optimize Strong): 3,398,179,937 bytes
Find package at: https://mega.nz/#!0aRDiAKQ!lrwtC64jnkk4d0ZKjcVGgLKPCcOqyUSyAQ62JJtQZOM[/QUOTE]
Here is the list of changes for Advanced Codec Pack engine
13-12-2016 09:56 vE4zstd2 enc. progress reporting fix plzma4 progress fix plzma4 buffering changes
21-12-2016 00:10 vE5initial version of x64flt4
25-12-2016 06:39 vE6x64flt4 update single compressed stream instead of 3 rc speed opt compression improvement rc flush after 256k bytes without any addr output x64comp filter, for addr stream compression with bcj2/x64flt3
25-01-2017 10:11 vE7mpzapi filter
potential support for external executables as .pa filters
potential support for executables that don’t work with stdin/stdout (via winapi hooks)
26-01-2017 13:18 vE7lepton filter, same exewrap lib bugfix: “Data error” with mpzapi when extracting non-solid archive
27-01-2017 07:48 vE7lepton fallback: files are now stored if lepton quits without writing anything bugfix: lepton inputs that can’t be correctly restored are now reported during compression, not decompression bugfix: remove mpzapi.exe crashes during extraction
31-01-2017 07:44 vE7packmp3 support
10-02-2017 20:00 vE7plzma MT bugfix
12-02-2017 22:16 vE8lepton fix to use two output streams; s0=fallback, s1=lepton lepton fix to use chunksize param for fallback; lepton:c=400M uses 400M inpbuf
13-02-2017 08:47 vE8bsc support added (as “bsc3”), with :c#M,:x0,3-6,:a1/2 as params
13-02-2017 23:39 vE8bsc3: added lc param - lc0-lc2 means cf/cp/ca, lc4 means -r; (lc6 = -ca -r)
20-02-2017 12:19 vE8plzma4: 32-bit outpos bugfix plzma4: loop_enc EOF check fix
26-02-2017 19:51 vE8bwt1/qlfc filters added
27-02-2017 05:30 vE8divsufsort.dll rebuilt with gcc
28-02-2017 04:46 vE8bwt1: chunksize bugfix bwt1/qlfc: disable chunksize alignment to 1M
01-03-2017 22:26 vE8added qlfc2:mt=#:c=# - qlfc with integrated MT wrapper
03-03-2017 14:58 vE9updated qlfc2/MTwrap added bwt2:mt=#:c=#
08-03-2017 06:56 vE9BUG: plzma4 decoder memory leak BUG: workaround for divsufsort’s inverse_bw_transform doing nothing for n=1
09-03-2017 09:31 vE9BUG: 7z function CHandler::IsFolderEncrypted is buggy (outdated) update bwt1 to 5N version (was 6N) x64flt3: remove zero padding at the end (left from debug)
10-03-2017 07:52 vE9reflate update to ver 1l2 (bugfix)
10-03-2017 13:41 vE9BUG: ppmd_sh incorrectly parses memory size BUG: ppmd_sh UpdateModel bugfix
13-03-2017 12:08 vE9added coro_init() call to deltb::Init()
14-03-2017 17:25 vE9BUG: all x64flt filters got stuck on files shorter than 8 bytes
15-03-2017 05:57 vE97z k_Scan_NumCodersStreams_in_Folder_MAX limit increased to 512
17-03-2017 15:45 VE9reflate speed optimization (23% faster on x64, 8% on x86)
20-03-2017 03:30 vE9BUG: lepton failed during encoding of some files; added exitcode check
25-03-2017 04:32 vF0switched default encryption to winaes
30-03-2017 09:28 vF0BUG: sometimes there’s not enough memory for winaes decrypting
04-04-2017 19:15 vF0added MTwrap-based MT zstd as zstd3 - seems incompatible with zstd2 for some reason
06-04-2017 14:57 vF0zstd3: update to 1.1.4 library
06-04-2017 15:31 vF0zstd3: fall back to zstd 1.1.0 - 1.1.4 is slower
22-04-2017 17:42 vF1plzma (plain single-threaded one) bwts,bwtsh,bwtsl,bwt1h,bwt1l,cdm,cdm2
24-04-2017 04:49 vF1bwt2h,bwt2l mtwrap min_chunk workaround
06-06-2017 02:57 vF1BUG: bwt2,bwt blklen=2 incorrect handling mtwrap decoder buffer increased to 2*chunksize mtwrap/bufring anti-MT updates IC17->IC18 for x64 build
08-06-2017 20:18 vF2rep2 = rep1 + MTwrap // :c -> :d added PPMD codec from original 7z (vH)
14-06-2017 13:07 vF2BUG: zstd cQuit called instead of dQuit
15-06-2017 13:27 vF2BUG: mtwrap used memcpy on overlapped memory BUG: mtwrap had duplicate memcpys partial buffer flush at the end of BWT2 block updated version_info
16-06-2017 09:33 vF2
!!! all mtwrap codecs lost compatibility (rep2,cdm2,zstd3,bwt2,bwt2l,bwt2h,qlfc2) !!!
17-06-2017 12:20 vF2restored vF0-compatible zstd3,bwt2,qlfc2; test scripts included BUG: freezing bug is finally solved by adding dynamic buffering to MTwrap decoder mtwrap decoder input buffer reduced from 2C to 1C following codecs use MTwrap_v3: BWT3,BWT3H,BWT3L,QLFC3,cdm2,rep2,zstd4
18-06-2017 23:00 vF2BUG: another mtwrap freezing bug - mtwrap didn’t notice when thread with empty input quits without outputting anything 32-bit variable was used for thread EOF flags, so max mt32 was supported; updated to 64.
19-06-2017 20:09 vF2BUG: freezing/data error in zstd4
21-06-2017 16:01 vF2BUG: data errors in bwt3 refactored mtwrap/loop_dec
21-06-2017 22:54 VF3archive cleanup modded packmp3 for mp3 compression
25-06-2017 21:11 vF3ppmd_sh2 added (dX can be used instead of mem=X) ppmd_sh reverted back into enc/dec template
01-07-2017 13:02 vF3alpha version of mp3det+packmp3b combo (x86 and x64 are incompatible)
02-07-2017 21:14 vF3packmp3b updated with mtwrap
03-07-2017 06:41 vF3BUG: x86 version of packmp3b crashes on decoding (problem with IC and floats; /fp:strict fixed it) BUG: memory leak in packmp3b BUG: crash on decoding of test4a.mp3
04-07-2017 18:14 vF4source cleanup removed some experimental codecs etc
06-07-2017 11:31 vF4BUG: packmp3b formats created by 32-bit and 64-bit 7z.dll are different packmp3b compression slightly retuned towards 320kbit
16-08-2017 22:53 vF5reflate2 = reflate/mtwrap; eg. reflate2:x9:c10M
27-08-2017 16:23 vF5dropped packmp3,packmp3a codecs (and corresponding .exe) added lepton2 aka lepton-slow-best-ratio
11-09-2017 07:10 vF5added precomp as precomp:mt4:c64M
12-09-2017 08:20 vF5BUG: fixed precomp to not use same tempfile names in all instances disabled console input in precomp on file overwrite enabled ZIP/PNG/PDF/GZIP parsing in precomp updated precomp handler
13-09-2017 12:30 vF5added jojpeg for jpeg compression (solid and with detection, but slow); s0=bin, s1=compressed
14-09-2017 15:23 vF5added packmp3c (2x slower than packmp3b, 1-2% better compression)
15-09-2017 15:03 vF5packmp3c bugfix (scfsi flags), a little worse compression
19-09-2017 16:00 vF5BUG: forgot coro_init for jojpeg
19-09-2017 17:12 vF5updated precomp to 0.4.6
20-09-2017 01:37 vF5jojpeg switched to gcc dlls (35% faster)
Hello. I would like to know if there is some way to open .pa files on mobile devices such as the ones using android. I wanted to use it on my samsung phone but i could not find an app or something that would let me to open those files. Do somebody knows how to open them or could it be that there is a powerarchiver ver for mobile?. Thanks in advance.
° at job status 100% the .zip closed almost instantly, pa needs a lot of extra time to finish the job…
° in speed, the classic zip is still the best choice
° PA experimental is incredible in compression but it is in the actual stage a time consumer…
° other users reported this too : PA interfaces are slower to open now.
In explorer shell it takes time too, before the ‘settings’ window opens ?
This is a thread about Experimental Codecs used with PowerArchiver when Experimental Codecs check is used.
Currently used Experimental Codecs (from PA 17.00.81) :mp3det filter + Packmp3b codec = mp3 codec, currently around 2.5% better compression than WinZip ZIPX and 3x faster speed on 8t cpus.
*** Please note, experimental codecs are for testing purposes only and will be used only when experimental checkbox is checked. Quite likely there will be no backwards compatibility with finished versions of codecs, so please use it only for testing.
thread for delta/plzma4:a0 settings discussion, moved from:
since on version specific thread it will be pushed back on thread list quite fast.
Do you plan to release unpacking library, so 3rd party software can extract PA format as well? It would be great and certainly would expand the format.
this format compresses word files better than rar zip and 7zip thanks powerarchiver
Hello @Alpha-Tester . Lets test a bit Optimized Strong methods and see what works and what can be improved. Relationship between codec and filter paramters as well as number of threads is complicated ones, and while we have tried to automate it in the best possible way, improvements are still possible.
@skypx has a nice cpu for testing 16t performance for instance. It would be interesting to see whats maximized performance for Optimized Strong Maximum and Ultra options because they use different entropy models (a0 lzma, a1 or lzmarec) which provide different performance - lzmarec is much stronger but also slower to extract where our parallel decode helps.
Debug mode can help to log all of this.
What is it?
Reflate is advanced deflate recompression filter designed to improve compression of files with deflate streams. Obvious examples are pdf, docx, xlsx, swf, png but deflate streams can be found in many other files, usually in form of png images.
Where to use it?Optimized Strong mode - PowerArchiver will compress all pdf, docx/xslx, pngs, swf, etc, files with Reflate filter automatically. PLZMA4 codec - You can enable reflate filter.
AdvantagesMuch better compression of PDF. DOCX and other files with deflate streams. Between 30%-50% on average (vs 5% for regular archivers). PDFs that are mostly big pictures wont be compressed well (especially if it is jpegs), but it will still be substantially better than regular codecs. Disadvantage: Slower speed.
FY17_Proposed_Budget_Vol_1.pdf (Austin Texas Budget 2016/2017) - 20,157 kb
PowerArchiver (Extreme): 9,994 kb
WinRar (best): 18,356 kb
7zip (Ultra) : 18,336 kb
WinZip (Zipx/Lzma) : 18,411 kb
oig-work-plan-2016.pdf (Office of Inspector General plan 2016) - 4,165 kb
PowerArchiver (Extreme): 1,346 kb
WinRar (best): 3,790 kb
7zip (Ultra) : 3,791 kb
WinZip (Zipx/Lzma) : 3,784 kb
Analysis: Good case scenario. Images are likely pngs, and a lot of text that can be compressed great.
(This article is work in progress)
What is fma-rep?
Deduplication filter based on anchor hashing. Technically LZ77, but has no entropy coding, and only longer matches have a chance to be replaced with a reference.
It has much lower memory requirements than lzma, so can be used to compensate lzma’s smaller window/dictionary size.
Examples: Official ISOs from Microsoft for Windows 10 Pro and Office 2016:
Due to large file sizes, and the fact that fma-rep takes a lot less memory than plzma4, it is very useful for large software installation DVDs that have a lot of compressed data already. Best idea is to use large window of fma-rep1 and fast codec, to achieve good compression and yet very fast speed.
AMD FX8320 with 16GB RAM and SSD
Office 2016 Pro ISO - 1,985,392 kB
.pa (Zstandard2, x64flt, bcj2, fma-rep1) 36s encode, 37s decode - 1,551,741 kB
.rar (Normal) 128s encode, 13s decode, 1,892,471 kB
Windows 10 Pro ISO
.pa (Zstandard2, x64flt, bcj2, fma-rep1) 87s encode, 77s decode - 3,577,849 kB
.rar (Normal) 314s encode, 27s decode - 3,838,188 kB
Sharepoint Server 2013
.rar (Normal) 369s encode, 15s decode - 2,269,782 kB
.zip (WZ 21 Normal) - 47s encode, 13s decode - 2,305, 755 kB
.pa (Zstandard2, x64flt, bcj2, fma-rep1) - 61s encode, 41s decode - 1,955,468 kB
settings for wav/sf2 files (from 17.00.68)
thread for delta/plzma4:a0 settings discussion, moved from:
since on version specific thread it will be pushed back on thread list quite fast.
@spwolf compression of sounds is much more than delta on .wav. Wav can have different bit depths and number of channels which affect delta number - delta:1 is good for 8-bit mono, delta:2 is good for 8-bit stereo, delta:4 is good for 16-bit stereo…
Sound modules (.dmf, .it, .med, .mod, .mptm, .okt, .rns, .s3m, .umx, .xm) and soundfonts (.sf2): most of them support 8-bit mono and stereo, some also contain 16-bit mono and stereo. If you are using 7z delta filter for files like this, I would recommend delta:2 + LZMA for all sound modules except .s3m which are compressed better using delta:1 + LZMA.
delta:3 + PPMd:mem256m:o3 would help on all non-compressed images in 24-bit such as .PPM, .PNM and also .PAM; with LZMA2 instead of PPMd delta:3 would help on all camera raw in Mamiya .mef format while delta:4 would help on all camera raw in Leaf .mos format and on uncompressed Sony .arw.
Soundfonts are compressed best by closed-source sfArk (nothing practical comes close atm), but libbsc -b1024rcf -m0 -H28 is good here. A parser with Monkeys Audio would be superior to both.
@spwolf worth to mention are also those audio formats: .xi (instruments), in some rare cases there are .au and .aif/.aiff, .voc and .snd
@Stephan we have optimized switches for 16 bit stereo. We assume that is the most commonly used format, hence the delta:4 and lp2, pb2. With higher chunk size and dictionary in next version, it is not only faster than ppmd_sh but also compresses better on our “real” life samples. That goes the same for sf2 files (also tested au but did not work there).
For bmp, our results were too varied and we could not pick a single setting to use on our samples. So that will have to wait for detector to be built first.
MA is a lock, likely for the next release, but we will still need fast settings with delta for faster modes, so detector for wavs will also be beneficial in the future.
Can you send me those sound modules files for testing, if we can replicate results on larger amount of samples, we would also include it for next release.
Thanks a lot for the feedback!
.70 adds larger dictionary and chunk sizes in stronger options for wav mode, also added sf2 to that mode.