View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003298 | Plugins | Arclite | public | 2016-09-11 05:44 | 2017-01-10 13:58 |
Reporter | HermanSemm | Assigned To | 2useven10 | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Platform | x86 | OS | Windows | OS Version | 10 |
Summary | 0003298: Difference 7z archive size result between compression level ultra - normal - max | ||||
Description | Hi Far team.. I might be experienced bug when working with Far 30 build 4774 when add/creating archive, as below: 1.The archive.7z size result in win10 x86: ultra > normal > max 2.The archive.7z size result in win7 x86: normal > ultra = max Note: > means size Bigger than, = means size Equal to I think it's also depends on various kind of processor and windows with x86 or x64, also RAMS. But you should fix this problem anyway. I hope you could fix this problem soon and please reply to herman.semm@gmail.com... Best Regards, Herman Semm | ||||
Tags | No tags attached. | ||||
|
Hi Herman, 1. The Project and Category you selected are incorrect. The correct values are: Project=Plugins, Category=Arclite. (Only administrators can repair that). 2. There is no need to manually send replies to your email, it is done automatically. |
|
what is number of cpu cores on win10/win7 system? |
|
also you can check 7z.exe results with same parameters. if far3/arclite sizes == 7z sizes -- you should ask 7z author about that. |
|
According to Report ID=0003330 (Closed) Here I send you sample of .7z archives created by Far & 7-Zip File Manager in "Please Extract This File 1st.7z", please see differences of sizes result carefully that: "Far 3 Arclite: Ultra .7z size is always bigger than Maximum and Normal / same result even when compressing bigger sizes of other kind of files" All compressed with same settings using 7z version 16.04 in Solid archive with: -Compression Level= Ultra, Maximum and Normal -Compression Method= LZMA2 -Command line switch for Far 1.75 7z Multiarc= -mx=9 -ms=4g (LZMA2 Solid Ultra), -mx=7 -ms=4g (LZMA2 Solid Maximum) and -mx=5 -ms=4g (LZMA2 Solid Normal) 1.On Windows 10 x86 with Core 2 duo 2.00GHz (Same result on Windows 10 x64 with Quad Core 3.00GHz), files are: -Far 1.75 (build 2634) Ultra: F1W10C2u.7z Maximum: F1W10C2m.7z Normal: F1W10C2n.7z -Far 2.0 (build 1807) with 7z.dll version 16.04 Ultra: F2W10C2u.7z Maximum: F2W10C2m.7z Normal: F2W10C2n.7z -Far 3.0 (build 4826) Ultra: F3W10C2u.7z Maximum: F3W10C2m.7z Normal: F3W10C2n.7z -7-Zip File Manager Version 16.04 Ultra: 7fmW10C2u.7z Maximum: 7fmW10C2m.7z Normal: 7fmW10C2n.7z 2.On Windows 7 x86 with Pentium 4 1.8GHz, files are: -Far 1.75 (build 2634), same result as 7-Zip File Manager Version 16.04 Ultra: F1W7P4u.7z Maximum: F1W7P4m.7z Normal: F1W7P4n.7z -Far 3.0 (build 4826), same result as Far 2.0 (build 1807) with 7z.dll version 16.04 Ultra: F3W7P4u.7z Maximum: F3W7P4m.7z Normal: F3W7P4n.7z I hope you would see this problem more clear and could fix this soon (I hope you could also fix the Far 2 Arclite).. Regards, Herman Semm |
|
|
|
Ok, I can confirm that with that particular data (actually, ncmain.exe is enough to reproduce it) "ultra" produces bigger file than "maximum" and this doesn't happen with 7-zip file manager using the same 7z.dll. We will investigate this. Please, do not create any more duplicate issues. |
|
Size arclite-max 7z-max arclite-ultra 7z-ultra NC.EXE 2912 1944 1944 2009 2000 NCMAIN.EXE 212416 96087 96087 96712 96048corrected... |
|
NCMAIN is probably arclite problem. |
|
.7z results on my Windows 10 x86 with Core 2 Duo and on my Windows 10 x64 with Quad Core are=Size arclite-max 7z-max arclite-ultra 7z-ultra NC.EXE 2912 1944 1944 2009 2000 NCMAIN.EXE 212416 96087 96087 96712 96048 I've been experienced that there're no problem when comparing Arclite vs. 7z at compression level Maximum and Normal etc. the size always equal. The Problem only happens at compression level Ultra as above. Please do more compressing test with your other bigger size of file(s) then you'll see the problem more clearly.. Note: Sorry for adding and deleting notes until 3 times, because after Add Note the data being squeezed as above.. |
|
You are right. NC.exe -- 2009/2000. The problem is cleared enough. But the reason unfortunately is not so evident. |
|
Just focus to Arclite, the main problem is in Arclite, because when compressing anyfile(s) at compression level Ultra it always produce bigger archive size than level Maximum or Normal. If the problem still there means it useless there's Level Ultra in Arclite. You're the developer, so I'm sure you'll find the way to fix it. This problem happened since Far Manager 2 Arclite, please fix it either... |
|
build 244 |
Date Modified | Username | Field | Change |
---|---|---|---|
2016-09-11 05:44 | HermanSemm | New Issue | |
2016-09-11 06:43 | shmuel | Note Added: 0014754 | |
2016-09-11 07:54 | 2useven10 | Category | Command Line/Execute => _Common |
2016-09-11 07:54 | 2useven10 | Project | Known Error => Plugins |
2016-09-11 07:55 | 2useven10 | Category | _Common => Arclite |
2016-09-11 07:56 | 2useven10 | Note Added: 0014755 | |
2016-09-11 07:57 | 2useven10 | Note Edited: 0014755 | |
2016-09-11 08:29 | 2useven10 | Note Added: 0014757 | |
2016-09-21 09:46 | shmuel | Relationship added | has duplicate 0003308 |
2016-10-17 12:13 | 2useven10 | Status | new => closed |
2016-10-17 12:13 | 2useven10 | Assigned To | => 2useven10 |
2016-10-17 12:13 | 2useven10 | Resolution | open => no change required |
2016-10-17 14:14 | 2useven10 | Relationship added | parent of 0003330 |
2016-10-18 05:01 | DrKnS | Assigned To | 2useven10 => |
2016-10-18 05:01 | DrKnS | Status | closed => new |
2016-10-18 05:02 | DrKnS | Relationship added | parent of 0003331 |
2016-10-18 05:27 | HermanSemm | Note Added: 0014928 | |
2016-10-18 05:29 | HermanSemm | File Added: Please Extract This File 1st.7z | |
2016-10-18 05:32 | DrKnS | Note Added: 0014929 | |
2016-10-18 11:30 | 2useven10 | Note Added: 0014930 | |
2016-10-18 11:30 | 2useven10 | Note Edited: 0014930 | |
2016-10-18 11:32 | 2useven10 | Note Edited: 0014930 | |
2016-10-18 11:34 | 2useven10 | Note Added: 0014931 | |
2016-10-19 02:44 | HermanSemm | Note Added: 0014935 | |
2016-10-19 02:49 | HermanSemm | Note Edited: 0014935 | |
2016-10-19 03:11 | HermanSemm | Note Edited: 0014935 | |
2016-10-19 05:48 | 2useven10 | Note Edited: 0014930 | |
2016-10-19 05:49 | 2useven10 | Note Edited: 0014930 | |
2016-10-19 05:49 | 2useven10 | Note Edited: 0014930 | |
2016-10-19 05:52 | 2useven10 | Note Edited: 0014935 | |
2016-10-19 06:04 | 2useven10 | Note Added: 0014938 | |
2016-10-19 07:29 | DrKnS | Priority | immediate => normal |
2016-10-19 07:29 | DrKnS | Severity | feature => minor |
2016-10-19 07:29 | DrKnS | Resolution | no change required => open |
2016-10-20 01:07 | HermanSemm | Note Added: 0014940 | |
2016-12-27 17:36 | 2useven10 | Assigned To | => 2useven10 |
2016-12-27 17:36 | 2useven10 | Status | new => assigned |
2016-12-27 17:45 | 2useven10 | Note Added: 0015107 | |
2016-12-27 17:45 | 2useven10 | Status | assigned => feedback |
2017-01-10 13:58 | 2useven10 | Status | feedback => closed |
2017-01-10 13:58 | 2useven10 | Resolution | open => fixed |