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.
Good morning,
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?
Thanks.
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 bytesFind package at: https://mega.nz/#!0aRDiAKQ!lrwtC64jnkk4d0ZKjcVGgLKPCcOqyUSyAQ62JJtQZOM[/QUOTE]
Here is the list of changes for Advanced Codec Pack engine
13-12-2016 09:56 vE4
zstd2 enc. progress reporting fix plzma4 progress fix plzma4 buffering changes21-12-2016 00:10 vE5
initial version of x64flt425-12-2016 06:39 vE6
x64flt4 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/x64flt325-01-2017 10:11 vE7
mpzapi filterpotential 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 vE7
lepton filter, same exewrap lib bugfix: “Data error” with mpzapi when extracting non-solid archive27-01-2017 07:48 vE7
lepton 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 extraction31-01-2017 07:44 vE7
packmp3 support10-02-2017 20:00 vE7
plzma MT bugfix12-02-2017 22:16 vE8
lepton fix to use two output streams; s0=fallback, s1=lepton lepton fix to use chunksize param for fallback; lepton:c=400M uses 400M inpbuf13-02-2017 08:47 vE8
bsc support added (as “bsc3”), with :c#M,:x0,3-6,:a1/2 as params13-02-2017 23:39 vE8
bsc3: added lc param - lc0-lc2 means cf/cp/ca, lc4 means -r; (lc6 = -ca -r)20-02-2017 12:19 vE8
plzma4: 32-bit outpos bugfix plzma4: loop_enc EOF check fix26-02-2017 19:51 vE8
bwt1/qlfc filters added27-02-2017 05:30 vE8
divsufsort.dll rebuilt with gcc28-02-2017 04:46 vE8
bwt1: chunksize bugfix bwt1/qlfc: disable chunksize alignment to 1M01-03-2017 22:26 vE8
added qlfc2:mt=#:c=# - qlfc with integrated MT wrapper03-03-2017 14:58 vE9
updated qlfc2/MTwrap added bwt2:mt=#:c=#08-03-2017 06:56 vE9
BUG: plzma4 decoder memory leak BUG: workaround for divsufsort’s inverse_bw_transform doing nothing for n=109-03-2017 09:31 vE9
BUG: 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 vE9
reflate update to ver 1l2 (bugfix)10-03-2017 13:41 vE9
BUG: ppmd_sh incorrectly parses memory size BUG: ppmd_sh UpdateModel bugfix13-03-2017 12:08 vE9
added coro_init() call to deltb::Init()14-03-2017 17:25 vE9
BUG: all x64flt filters got stuck on files shorter than 8 bytes15-03-2017 05:57 vE9
7z k_Scan_NumCodersStreams_in_Folder_MAX limit increased to 51217-03-2017 15:45 VE9
reflate speed optimization (23% faster on x64, 8% on x86)20-03-2017 03:30 vE9
BUG: lepton failed during encoding of some files; added exitcode check25-03-2017 04:32 vF0
switched default encryption to winaes30-03-2017 09:28 vF0
BUG: sometimes there’s not enough memory for winaes decrypting04-04-2017 19:15 vF0
added MTwrap-based MT zstd as zstd3 - seems incompatible with zstd2 for some reason06-04-2017 14:57 vF0
zstd3: update to 1.1.4 library06-04-2017 15:31 vF0
zstd3: fall back to zstd 1.1.0 - 1.1.4 is slower22-04-2017 17:42 vF1
plzma (plain single-threaded one) bwts,bwtsh,bwtsl,bwt1h,bwt1l,cdm,cdm224-04-2017 04:49 vF1
bwt2h,bwt2l mtwrap min_chunk workaround06-06-2017 02:57 vF1
BUG: bwt2,bwt blklen=2 incorrect handling mtwrap decoder buffer increased to 2*chunksize mtwrap/bufring anti-MT updates IC17->IC18 for x64 build08-06-2017 20:18 vF2
rep2 = rep1 + MTwrap // :c -> :d added PPMD codec from original 7z (vH)14-06-2017 13:07 vF2
BUG: zstd cQuit called instead of dQuit15-06-2017 13:27 vF2
BUG: mtwrap used memcpy on overlapped memory BUG: mtwrap had duplicate memcpys partial buffer flush at the end of BWT2 block updated version_info16-06-2017 09:33 vF2
!!! all mtwrap codecs lost compatibility (rep2,cdm2,zstd3,bwt2,bwt2l,bwt2h,qlfc2) !!!
17-06-2017 12:20 vF2
restored 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,zstd418-06-2017 23:00 vF2
BUG: 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 vF2
BUG: freezing/data error in zstd421-06-2017 16:01 vF2
BUG: data errors in bwt3 refactored mtwrap/loop_dec21-06-2017 22:54 VF3
archive cleanup modded packmp3 for mp3 compression25-06-2017 21:11 vF3
ppmd_sh2 added (dX can be used instead of mem=X) ppmd_sh reverted back into enc/dec template01-07-2017 13:02 vF3
alpha version of mp3det+packmp3b combo (x86 and x64 are incompatible)02-07-2017 21:14 vF3
packmp3b updated with mtwrap03-07-2017 06:41 vF3
BUG: 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.mp304-07-2017 18:14 vF4
source cleanup removed some experimental codecs etc06-07-2017 11:31 vF4
BUG: packmp3b formats created by 32-bit and 64-bit 7z.dll are different packmp3b compression slightly retuned towards 320kbit16-08-2017 22:53 vF5
reflate2 = reflate/mtwrap; eg. reflate2:x9:c10M27-08-2017 16:23 vF5
dropped packmp3,packmp3a codecs (and corresponding .exe) added lepton2 aka lepton-slow-best-ratio11-09-2017 07:10 vF5
added precomp as precomp:mt4:c64M12-09-2017 08:20 vF5
BUG: 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 handler13-09-2017 12:30 vF5
added jojpeg for jpeg compression (solid and with detection, but slow); s0=bin, s1=compressed14-09-2017 15:23 vF5
added packmp3c (2x slower than packmp3b, 1-2% better compression)15-09-2017 15:03 vF5
packmp3c bugfix (scfsi flags), a little worse compression19-09-2017 16:00 vF5
BUG: forgot coro_init for jojpeg19-09-2017 17:12 vF5
updated precomp to 0.4.620-09-2017 01:37 vF5
jojpeg switched to gcc dlls (35% faster)
0_1499762499381_9e61800d-3955-4326-b60c-ac07858f7139-image.png
° 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:
https://forums.powerarchiver.com/topic/5747/fast-ring-powerarchiver-2017-17-00-67-68-69
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.
Filter: Reflate
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.Advantages
Much 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.Examples:
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.
Tests
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
Optimized Strong, initial tests speed/compression
-
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.