Experimental Codecs - info, updates
-
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.
-
Like a lot the 2,5% together with the speed performance.
Where is 17.00.81 available? -
OK, I found 17.00.82, now testing…
http://dl.powerarchiver.com/2017/powarc170082.exe -
Just did a couple of quick tests, and is working quite well.
But noticed that “Use experimental codecs” is not permanent. I need to recheck it each type I use the Context menú -> Compress with Options. -
@nikkho said in Experimental Codecs - info, updates:
Just did a couple of quick tests, and is working quite well.
But noticed that “Use experimental codecs” is not permanent. I need to recheck it each type I use the Context menú -> Compress with Options.well, it is experimental… so better leave it unchecked by default.
As to .82, it is going to work even better in .83…
-
@spwolf I tried making a PA of a directory of MP3 files (two sub directories with 20 files in each).
The experimental codec failed spectacularly for me.
Firstly the PA file it made was over twice the size of the one without experimental codecs enabled. Secondly one of the files MP3 did not unpack correctly back to the original, it got it bit longer than it was originally! -
You are right @Brian-Gregory. I did the same test, compressing 3 MP3 files, with a total size of 15MB. Resulting PA archive was 27,7MB. Find details below @spwolf
Integrity check, reports that the generated PA archive is correct, and in fact I can extract it with no issues, but for some reason, it is not compressing at all.
Compression speed was quite reasonably as announced, but at the end, the progress reached 100%, and got stuck there for about 1 minute until the archive was created.
-
@Brian-Gregory @nikkho Reason .82 is not released publicly is because wrong mp3 codec version is used :). But I am glad you guys are testing anyway, it should be out properly soon.
-
Build 83 is much better. Size gets not increased anymore, and in fact, beats the ratios of 7z and RAR by about 5%. Also compression gets not stuck anymore at 100%.
-
@nikkho said in Experimental Codecs - info, updates:
Build 83 is much better. Size gets not increased anymore, and in fact, beats the ratios of 7z and RAR by about 5%. Also compression gets not stuck anymore at 100%.
what is calculated ratio when you manually check size of file and size of archive? It should be between 18% and 23%, as long as experimental codec is set. Otherwise, it means those mp3 files are not recognized as having mp3 data.
-
@nikkho @Brian-Gregory you can check with build .83, with experimental codec set and then if it is not 18-23% compression ratio, upload file and send it over to us via email (wetransfer?).
thanks!
-
It is 14% in my quick test. Better than WinRAR or 7z, but not yet 18%.
@spwolf said in Experimental Codecs - info, updates:
@nikkho said in Experimental Codecs - info, updates:
Build 83 is much better. Size gets not increased anymore, and in fact, beats the ratios of 7z and RAR by about 5%. Also compression gets not stuck anymore at 100%.
what is calculated ratio when you manually check size of file and size of archive? It should be between 18% and 23%, as long as experimental codec is set. Otherwise, it means those mp3 files are not recognized as having mp3 data.
-
- Original: 9.020.106 bytes
- 7-Zip: 8.758.585 bytes
- WinRAR: 8.750.307 bytes
- ZIP: 8.743.320 bytes
- PA 7.757.480 bytes
-
@nikkho said in Experimental Codecs - info, updates:
- Original: 9.020.106 bytes
- 7-Zip: 8.758.585 bytes
- WinRAR: 8.750.307 bytes
- ZIP: 8.743.320 bytes
- PA 7.757.480 bytes
can you compress both files individually and see whats c. ratio for each one of them? There might be a difference.
Also, WinZIP ZIPX is only one that has mp3 compression too, so that would be interesting to see.
Thanks!
-
can you compress both files individually and see whats c. ratio for each one of them? There might be a difference.
First one is 16%, second one is 10%. -
@nikkho can you send us that 10%, lets see what kind it is… optimizer is running currently on 320kbs sample.
-
Wetransfer seems to be down, so I have sent it to support@ConeXware.xxxx
MP3 is a VBR file, at about 128Kbps. -
@nikkho said in Experimental Codecs - info, updates:
Wetransfer seems to be down, so I have sent it to support@ConeXware.xxxx
MP3 is a VBR file, at about 128Kbps.Nikkho,
with some settings optimization, we can lower mt setting to mt1 in this case when it is small file, so it will be 13kb smaller result in next build, which would be 10kb less than packmp3 in winzip (in this build it is 3kb worse).
And then when our optimizer finishes, it should be another few kb better. But we are currently targeting 320kbs mp3’s for best results, because they seem the most popular right now, so those will show more compression ratio.
thanks for the file!
-
@nikkho also, interesting since here MT is actually not used due to small file size, speed wise:
PA 17.00.83 extreme: 1.28s
WinZip Zipx: 4.1sWe also have full mt support, so with more files, it would use all of the cores but since thats not happening here i would suspect that WinZip takes 2s to initialize packmp3.
Difference on 184 MB mp3 album (320kbs) is 25s (PA) vs 70s (WZ) on 8t cpu.
When you have more time, try with some other mp3 files and lets see how it does, including speed. Right now only commercial competition is WZ that uses packmp3. Rest of them do not do mp3 recompression.
-
@spwolf I will look for a 320Kpbs test set. It is strange, but most of my download music, is VBR, and not CBR.
