Pasha_ZZZ
Спасибо.
Для установки игр - однозначно быстрые методы.
Спасибо.
Для установки игр - однозначно быстрые методы.
» Архиваторы. Сравнение сжатия
Shuld
17:44 27-01-2011
Цитата:
... и архивирование супер-пупер методом сжатия (который обычно используют нестандартные архиваторы) тоже...
Цитата:
Вот именно. Поэтому вполне можно обойтись стандартным архиватором, меньше (и быстрее) будет и проблем при распаковке на другом компе.
17:44 27-01-2011
Цитата:
В таких случаях простое пофайловое копирование может занять более часа!
... и архивирование супер-пупер методом сжатия (который обычно используют нестандартные архиваторы) тоже...
Цитата:
Правда, степень сжатия при этом не является самым главным
Вот именно. Поэтому вполне можно обойтись стандартным архиватором, меньше (и быстрее) будет и проблем при распаковке на другом компе.
Я тоже на флэш мелкие файлы так же пееношу, пакую в tar, и без сжатия либо с минимальным zip,rar,7zip. tar быстро работает (но не жмет а пакует), а с минимальным сжатием zip вроде как быстрее
есть вордовский документ весом 125 кб, подскажите существует ли программа способная сжать его до 50 кб ?
DJMC
Обычные средства(WinRAR, 7-zip, Zip) до какого размера сжимают?
Обычные средства(WinRAR, 7-zip, Zip) до какого размера сжимают?
DJMC
В ЛС пришлёте файлик?
В ЛС пришлёте файлик?
Engaged Clown
Цитата:
до 120 кб.
V2driver
Цитата:
уже решил проблему, в тексте было 6 страниц, и там была одна схема, я взял вырезал ее, получился текст 21 кб. потом взял этот рисунок и сохранил как bmp 16 цветов, получилось 25 кб. так что я уложился в 50 кб. вопрос снят.
Цитата:
Обычные средства(WinRAR, 7-zip, Zip) до какого размера сжимают?
до 120 кб.
V2driver
Цитата:
В ЛС пришлёте файлик?
уже решил проблему, в тексте было 6 страниц, и там была одна схема, я взял вырезал ее, получился текст 21 кб. потом взял этот рисунок и сохранил как bmp 16 цветов, получилось 25 кб. так что я уложился в 50 кб. вопрос снят.
DJMC, если это DOCX, то сжимать бесполезно, ибо они уже сжатые алгоритмом зип
Тест методов сжатия сверхплотных архиваторов PAQ8
Архиваторы PAQ8 имеют несколько методов сжатия: от 0 до 8. Причем метод 0 – это отсутствие сжатия.
Участники теста: WinRAR 3.93, 7z 9.20, FreeArc 0.67а (17 ноября 2010), PAQ8pf, PAQ8px_v69 (sse2), fp8 и WinRK 3.1.2.
Принята следующая цветовая маркировка:
- синий цвет – fp8
- красный цвет – PAQ8pf
- зеленый цвет – PAQ8px_v69 (sse2),
- крестик - WinRK 3.1.2.
Каждый маркер обозначает один результат теста. Слева вверху – быстрые режимы, справа внизу – максимальные режимы. Маркер, который находится одновременно левее и ниже – лучше того, который находится правее и выше.
Требования к памяти в зависимости от режима сжатия архиваторов PAQ8:
1 – 35 МБ
2 – 48 МБ
3 – 59 МБ
4 – 133 МБ
5 – 233 МБ (по умолчанию)
6 – 435 МБ
7 – 837 МБ
8 – 1643 МБ.
На основании одного теста не следует делать глобальных выводов, но некоторые интересные наблюдения обнаруживаются:
- У архиваторов fp8 и PAQ8pf изменение режима меняет скорость и степень сжатия незначительно. Режим 8 не имеет явного преимущества по сравнению с режимом по умолчанию - 5.
- Архиватор PAQ8px_v69 в режимах 1-3 может работать как быстрая версия PAQ8pf, в 10 раз быстерее режимов 4-8! Но такое бывает только на некоторых типах данных.
- Архиватор WinRK 3.1.2 выглядит лидером. Смущает только настоятельная рекомендация Булата Зиганшина не использовать его из-за ошибок в работе. Правда Булат не уточняет, к какой версии WinRK это относится.
- Архиватор fp8 смотрится предпочтительней своих коллег из серии PAQ8. И, похоже, ошибок в его работе нет.
Архиваторы PAQ8 имеют несколько методов сжатия: от 0 до 8. Причем метод 0 – это отсутствие сжатия.
Участники теста: WinRAR 3.93, 7z 9.20, FreeArc 0.67а (17 ноября 2010), PAQ8pf, PAQ8px_v69 (sse2), fp8 и WinRK 3.1.2.
Принята следующая цветовая маркировка:
- синий цвет – fp8
- красный цвет – PAQ8pf
- зеленый цвет – PAQ8px_v69 (sse2),
- крестик - WinRK 3.1.2.
Каждый маркер обозначает один результат теста. Слева вверху – быстрые режимы, справа внизу – максимальные режимы. Маркер, который находится одновременно левее и ниже – лучше того, который находится правее и выше.
Требования к памяти в зависимости от режима сжатия архиваторов PAQ8:
1 – 35 МБ
2 – 48 МБ
3 – 59 МБ
4 – 133 МБ
5 – 233 МБ (по умолчанию)
6 – 435 МБ
7 – 837 МБ
8 – 1643 МБ.
На основании одного теста не следует делать глобальных выводов, но некоторые интересные наблюдения обнаруживаются:
- У архиваторов fp8 и PAQ8pf изменение режима меняет скорость и степень сжатия незначительно. Режим 8 не имеет явного преимущества по сравнению с режимом по умолчанию - 5.
- Архиватор PAQ8px_v69 в режимах 1-3 может работать как быстрая версия PAQ8pf, в 10 раз быстерее режимов 4-8! Но такое бывает только на некоторых типах данных.
- Архиватор WinRK 3.1.2 выглядит лидером. Смущает только настоятельная рекомендация Булата Зиганшина не использовать его из-за ошибок в работе. Правда Булат не уточняет, к какой версии WinRK это относится.
- Архиватор fp8 смотрится предпочтительней своих коллег из серии PAQ8. И, похоже, ошибок в его работе нет.
Unknown CSA archive found to Academic Mobimouse Plus (Released: 2006) Eng/Hun - Hun/Eng Dictionary Translator Application Trial Version
This CSA Archive unknown compression method (modified inflate/deflate compression???) used from ENG/HUN dictionary-files (extremelly compressed!!)
Download CSA archive + extractor: CSA Archive and Extractor
Mirrors: CSA Archive and Extractor
7z Archive Password: EH-AKA1
Archive Content:
csa_extract.exe (CSA archive extractor)
eh-aka1.csa (CSA archive)
Extraction commands:
csa_extract.exe eh-aka1.csa
http://kepfeltoltes.hu/110606/csa_unpack_www.kepfeltoltes.hu_.jpg
Extracted files:
eh-aka1.cri
eh-aka1.dic
eh-aka1.ecx
eh-aka1.ini
eh-aka1.lic
eh-aka1.xsl
eh-aka1_1.hdw
eh-aka1_1.idx
eh-aka1_1.ixw
eh-aka1_2.hdw
eh-aka1_2.idx
eh-aka1_2.ixw
Unpacked this 12 files, 46.7MB
Official Academic Mobimouse Plus 2006 Trial Download:
Eng/HUn - Hun/Eng Version: Download Page
Press click to "mbmpaka2e.zip" filename to download
Ger/Hun - Hun/Ger Version: Download Page
Press click to "mbmpaka2d.zip" filename to download
Unzip, run installers, please wait from initialization progress.
Open %TEMP% folder, search "Akademiai... Angol.msi" file, open msi file, using to 7-Zip, found this 4 *.csa archive to msi packages.
Screens: http://kepfeltoltes.hu/110606/csa_archives_this_msi_packages_www.kepfeltoltes.hu_.jpg
Compression Test:
Source File (Akademic MobiMouse Plus 2006), extractorfile original name: CSUnzipG.exe Size: 156 kB
Archive name: eh-aka1.csa
Size: 19753kB = 19.29MB (20226761 byte
Extraction Time: 79 sec
Extraxted this 12 files, Total Size: 48968824 byte = 47821kB = 46.70MB
Ratio: 41.30538%
WinRAR 3.62
Best, Solid Archive
RAR Archive Size: 28131kB = 27.47MB
Ratio: 58.826%
Decompression Time: 3 sec
WinUHA 2.0 RC1
PPMD (Text-Optimized), Dictionary size: 16MB, Buffersize: 1024kB
UHA Archive Size: 26291kB = 25.67Mb
Ratio: 54.978%
Decompression Time: 205 sec
7-Zip 4.57
7z, LZMA, Ultra, 32MB, 64, Solid
7Z Archive Size: 26056kB = 25.45MB
Ratio: 54.487%
Decompression Time: 7 sec
7-Zip 9.13 Console
7z, command: 7z.exe a -r0 -uz1 -mmt2 -ssw -mx9 -m0=lzma:fb255:lp0:pb0:lc8:d25
7Z Archive Size: 25990kB = 25.38MB
Ratio: 54.349%
Decompression Time: 7 sec
TugZip 3.5.0.0
SQX
Best, Dictionary size: 4096kB
SQX Archive Size: 27658kB = 27.01MB
Ratio: 57.837%
Decompression Time: ~3.5 sec
LZX
CAB Archive Size: 27852kB = 27.2MB
Ratio: 58.242%
NanoZip 0.07 alpha
nz_cm, using 372MB memory (Compression Time: 254 sec)
NZ Archive Size: 23565kB = 23.013MB
Test time (full extraction): 239 sec
Ratio: 49.278%
nz_cm, using 276MB memory (Compression Time: 250 sec)
NZ Archive Size: 23640kB = 23.086MB
Test time (full extraction): 236 sec
Ratio: 49.434%
nz_optimum2, using 300MB memory (Compression Time: 248 sec)
NZ Archive Size: 25026kB = 24.44MB
Ratio: 52.33%
Test time (full extraction): 58 sec
nz_optimum1, using 284MB memory (Compression Time: 110 sec)
NZ Archive Size: 25885kB = 25.28MB
Ratio: 54.13%
Test time (full extraction): 21 sec
NanoZip 0.08 alpha
nz_cm, using 353MB memory (Compression Time: 292 sec)
NZ Archive Size: 23606kB = 23.053MB
Test time (full extraction): 259 sec
Ratio: 49.363%
nz_optimum2, using 328MB memory (Compression Time: 239 sec)
NZ Archive Size: 24972kB = 24.39MB
Ratio: 52.22%
Test time (full extraction): 58 sec
nz_optimum1, using 312MB memory (Compression Time: 133 sec)
NZ Archive Size: 25841kB = 25.24MB
Ratio: 54.04%
Test time (full extraction): 27 sec
FreeArc 0.60 RC
mx, using 384MB memory (Compression Time: 74 sec)
ARC Archive Size: 26164kB = 25.55MB
Ratio: 54.71%
RZM 0.07h
c, (EH-AKA1.zip file, size: 48970046 byte, store compressed) using 258MB memory (Compression Time: 154 sec)
RZM Archive Size: 25424kB = 24.83MB
Ratio: 53.16%
Extraction time: 27 sec
CCMx 1.26b
4, (EH-AKA1.tar file, size: 48977408 byte, store compressed) Allocated 276MiB memory (Compression Time: 114 sec)
CCMx Archive Size: 25998.88kB = 25.39MB
Ratio: 54.36%
Extraction time: 115 sec
CCMx 1.30c
4, (EH-AKA1.tar file, size: 48977408 byte, store compressed) Allocated 274MiB memory (Compression Time: 99 sec)
CCMx Archive Size: 26000.23kB = 25.39MB
Ratio: 54.36%
Extraction time: 99 sec
SBC 0.970
c -m3 -b63 -af, mem: 226.1 MB
(EH-AKA1.tar file, size: 48977408 byte, store compressed)
SBC Archive Size: 29908.7kB = 29.207MB
Ratio: 62.532%
UDA 0.301
e, Memory needed: 180MB
(EH-AKA1.tar file, size: 48977408 byte, store compressed)
UDA Archive Size: 23409kB = 22.86MB (Compression Time: ~37 min!!)
Ratio: 48.9428%
WinUDA 0.291 Classic
Mode-3 (Require 194MB memory), Recurse subdirectories
UDA Archive Size: 25302kB = 24.71MB (Compression Time: 1659 sec!!)
Ratio: 52.9103%
Please compression test other archivers (WinRK, PAQ8, KGB...).
Sorry this english translated languages.
Update1:
Waaaaah, Link: http://encode.ru/threads/1296-CSA-archiver?p=25313&viewfull=1#post25313
Thanks for the tips Shelwien (precomp)
Original CSA Archive Size: 19.29MB
Extracted Files Total Size: 46.7MB
Recompress using precomp+archivers CSA archive!!!
CSA --> Precomp --> PCF --> 7z/arc/nz/others archivers.
C:\Documents and Settings\...\EH-AKA1>precomp038 -slow eh-aka1.csa
Precomp v0.3.8 - ALPHA version - USE FOR TESTING ONLY
Free for non-commercial use - Copyright 2006-2008 by Christian Schneider
Input file: eh-aka1.csa
Output file: eh-aka1.pcf
Using PACKJPG.DLL for JPG recompression.
--> packJPG DLL v2.4WIP4 (11/06/2008) by Matthias Stirner <--
More about PackJPG here: http://www.elektronik.htw-aalen.de/packjpg
100.0% - New size: 86313067 instead of 20226761
Done.
Time: 46187 ms
Recompressed streams: 1/1
zLib streams (slow mode): 1/1
You can speed up Precomp for THIS FILE with these parameters:
-c9 -m8
Fast mode does exactly the same for this file, only faster.
20226761 --> 86313067 byte !! (84290.1kB = 82.31MB !!), This 12 unpacked files total size 46.7MB, Precompressed PCF files 82.31MB !!
(PCF file 82,31MB --> Precomp --> New PCF file 83.0857MB):
C:\Documents and Settings\...\Desktop>precomp038.exe -slow eh-aka1.pcf
Precomp v0.3.8 - ALPHA version - USE FOR TESTING ONLY
Free for non-commercial use - Copyright 2006-2008 by Christian Schneider
Input file: eh-aka1.pcf
Output file: eh-aka1_pcf.pcf
Using PACKJPG.DLL for JPG recompression.
--> packJPG DLL v2.4WIP4 (11/06/2008) by Matthias Stirner <--
More about PackJPG here: http://www.elektronik.htw-aalen.de/packjpg
100.0% - New size: 87121709 instead of 86313067
Done.
Time: 30391 ms
Recompressed streams: 3/7
GZip streams: 1/1
zLib streams (slow mode): 2/6
You can speed up Precomp for THIS FILE with these parameters:
-c6 -m8
Fast mode does exactly the same for this file, only faster.
Extracted 12 files to ZIP file to precomp:
C:\Documents and Settings\...\EH-AKA1>precomp038 -slow eh-aka1.zip
Precomp v0.3.8 - ALPHA version - USE FOR TESTING ONLY
Free for non-commercial use - Copyright 2006-2008 by Christian Schneider
Input file: eh-aka1.zip
Output file: eh-aka1.pcf
Using PACKJPG.DLL for JPG recompression.
--> packJPG DLL v2.4WIP4 (11/06/2008) by Matthias Stirner <--
More about PackJPG here: http://www.elektronik.htw-aalen.de/packjpg
100.0% - New size: 49778688 instead of 48970046
Done.
Time: 146344 ms
Recompressed streams: 3/47
GZip streams: 1/1
zLib streams (slow mode): 2/46
You can speed up Precomp for THIS FILE with these parameters:
-c6 -m8
Fast mode does exactly the same for this file, only faster.
This precompressed zipped file 48970046 --> 49778688 = 47.42MB not 82.31MB!
Compress (precompressed CSA archive file) PCF file (82.31MB file):
7-Zip 9.13 beta GUI
z, LZMA, Ultra, 32MB, 273, Solid
7Z Archive Size: 14216385 byte !! = 13883.19kB = 13.56MB
Nanozip 0.08 alpha
Commands: nz8 a -cc -m320m tmp.nz eh-aka1.pcf
NanoZip 0.08 alpha/Win32 (C) 2008-2010 Sami Runsas www.nanozip.net
Intel(R) Celeron(R) CPU 2.93GHz|8 MHz|#1|336/511 MB
*** THIS IS AN EARLY ALPHA VERSION OF NANOZIP *** USE ONLY FOR TESTING ***
Archive: tmp.nz
Compressor: nz_cm [355 MB], threads: 1.
Warning: only 336 MB free!
Compressed 86 313 067 into 10 078 177 in 7m 39.45s, 183 KB/s
IO-in: 0.56s, 146 MB/s. IO-out: 0.04s, 214 MB/s
9.611298MB!!!!
UDA 0.301
e, Memory needed: 180MB
C:\Documents and Settings\...\EH-AKA1>uda.exe e eh-aka1.pcf tmp.uda
UDA 0.301 -- Experimental Console Version -- Base on PAQ8I -- 19 Dec 2006
Author: dwing -- dwing@163.com -- http://wex.cn/dwing http://dwing.51.net
eh-aka1.pcf => tmp.uda
100.0% Finished!
9490431/86313067 in 3342.16 sec, 0.8796 bpb, 11.0% at 25.8 KB/s
9490431 byte = 9268 kB = 9.0507MB!!
Other CSA Archives Precompression Test:
eh_web1.csa: 358518 byte
he_aka1.csa: 18885003 byte
he_web1.csa: 434259 byte
C:\Documents and Settings\...\EH-AKA1>precomp038.exe -slow eh_web1.csa
Precomp v0.3.8 - ALPHA version - USE FOR TESTING ONLY
Free for non-commercial use - Copyright 2006-2008 by Christian Schneider
Input file: eh_web1.csa
Output file: eh_web1.pcf
Using PACKJPG.DLL for JPG recompression.
--> packJPG DLL v2.4WIP4 (11/06/2008) by Matthias Stirner <--
More about PackJPG here: http://www.elektronik.htw-aalen.de/packjpg
100.0% - New size: 358545 instead of 358518
Done.
Time: 828 ms
Recompressed streams: 0/0
None of the given compression and memory levels could be used.
There will be no gain compressing the output file.
C:\Documents and Settings\...\EH-AKA1>precomp038.exe -slow he_aka1.csa
Precomp v0.3.8 - ALPHA version - USE FOR TESTING ONLY
Free for non-commercial use - Copyright 2006-2008 by Christian Schneider
Input file: he_aka1.csa
Output file: he_aka1.pcf
Using PACKJPG.DLL for JPG recompression.
--> packJPG DLL v2.4WIP4 (11/06/2008) by Matthias Stirner <--
More about PackJPG here: http://www.elektronik.htw-aalen.de/packjpg
100.0% - New size: 18885030 instead of 18885003
Done.
Time: 46656 ms
Recompressed streams: 0/4
zLib streams (slow mode): 0/4
None of the given compression and memory levels could be used.
There will be no gain compressing the output file.
C:\Documents and Settings\...\EH-AKA1>precomp038.exe -slow he_web1.csa
Precomp v0.3.8 - ALPHA version - USE FOR TESTING ONLY
Free for non-commercial use - Copyright 2006-2008 by Christian Schneider
Input file: he_web1.csa
Output file: he_web1.pcf
Using PACKJPG.DLL for JPG recompression.
--> packJPG DLL v2.4WIP4 (11/06/2008) by Matthias Stirner <--
More about PackJPG here: http://www.elektronik.htw-aalen.de/packjpg
100.0% - New size: 434286 instead of 434259
Done.
Time: 985 ms
Recompressed streams: 0/0
None of the given compression and memory levels could be used.
There will be no gain compressing the output file.
Hmm, eh-aka1.csa file size bigger then precompressing this file used precomp, Other 3 CSA archive file size not bigger this precompressed used precomp.
Please decompiling this csa_extract.exe file and compliling new file-compress tools.
This CSA Archive unknown compression method (modified inflate/deflate compression???) used from ENG/HUN dictionary-files (extremelly compressed!!)
Download CSA archive + extractor: CSA Archive and Extractor
Mirrors: CSA Archive and Extractor
7z Archive Password: EH-AKA1
Archive Content:
csa_extract.exe (CSA archive extractor)
eh-aka1.csa (CSA archive)
Extraction commands:
csa_extract.exe eh-aka1.csa
http://kepfeltoltes.hu/110606/csa_unpack_www.kepfeltoltes.hu_.jpg
Extracted files:
eh-aka1.cri
eh-aka1.dic
eh-aka1.ecx
eh-aka1.ini
eh-aka1.lic
eh-aka1.xsl
eh-aka1_1.hdw
eh-aka1_1.idx
eh-aka1_1.ixw
eh-aka1_2.hdw
eh-aka1_2.idx
eh-aka1_2.ixw
Unpacked this 12 files, 46.7MB
Official Academic Mobimouse Plus 2006 Trial Download:
Eng/HUn - Hun/Eng Version: Download Page
Press click to "mbmpaka2e.zip" filename to download
Ger/Hun - Hun/Ger Version: Download Page
Press click to "mbmpaka2d.zip" filename to download
Unzip, run installers, please wait from initialization progress.
Open %TEMP% folder, search "Akademiai... Angol.msi" file, open msi file, using to 7-Zip, found this 4 *.csa archive to msi packages.
Screens: http://kepfeltoltes.hu/110606/csa_archives_this_msi_packages_www.kepfeltoltes.hu_.jpg
Compression Test:
Source File (Akademic MobiMouse Plus 2006), extractorfile original name: CSUnzipG.exe Size: 156 kB
Archive name: eh-aka1.csa
Size: 19753kB = 19.29MB (20226761 byte
Extraction Time: 79 sec
Extraxted this 12 files, Total Size: 48968824 byte = 47821kB = 46.70MB
Ratio: 41.30538%
WinRAR 3.62
Best, Solid Archive
RAR Archive Size: 28131kB = 27.47MB
Ratio: 58.826%
Decompression Time: 3 sec
WinUHA 2.0 RC1
PPMD (Text-Optimized), Dictionary size: 16MB, Buffersize: 1024kB
UHA Archive Size: 26291kB = 25.67Mb
Ratio: 54.978%
Decompression Time: 205 sec
7-Zip 4.57
7z, LZMA, Ultra, 32MB, 64, Solid
7Z Archive Size: 26056kB = 25.45MB
Ratio: 54.487%
Decompression Time: 7 sec
7-Zip 9.13 Console
7z, command: 7z.exe a -r0 -uz1 -mmt2 -ssw -mx9 -m0=lzma:fb255:lp0:pb0:lc8:d25
7Z Archive Size: 25990kB = 25.38MB
Ratio: 54.349%
Decompression Time: 7 sec
TugZip 3.5.0.0
SQX
Best, Dictionary size: 4096kB
SQX Archive Size: 27658kB = 27.01MB
Ratio: 57.837%
Decompression Time: ~3.5 sec
LZX
CAB Archive Size: 27852kB = 27.2MB
Ratio: 58.242%
NanoZip 0.07 alpha
nz_cm, using 372MB memory (Compression Time: 254 sec)
NZ Archive Size: 23565kB = 23.013MB
Test time (full extraction): 239 sec
Ratio: 49.278%
nz_cm, using 276MB memory (Compression Time: 250 sec)
NZ Archive Size: 23640kB = 23.086MB
Test time (full extraction): 236 sec
Ratio: 49.434%
nz_optimum2, using 300MB memory (Compression Time: 248 sec)
NZ Archive Size: 25026kB = 24.44MB
Ratio: 52.33%
Test time (full extraction): 58 sec
nz_optimum1, using 284MB memory (Compression Time: 110 sec)
NZ Archive Size: 25885kB = 25.28MB
Ratio: 54.13%
Test time (full extraction): 21 sec
NanoZip 0.08 alpha
nz_cm, using 353MB memory (Compression Time: 292 sec)
NZ Archive Size: 23606kB = 23.053MB
Test time (full extraction): 259 sec
Ratio: 49.363%
nz_optimum2, using 328MB memory (Compression Time: 239 sec)
NZ Archive Size: 24972kB = 24.39MB
Ratio: 52.22%
Test time (full extraction): 58 sec
nz_optimum1, using 312MB memory (Compression Time: 133 sec)
NZ Archive Size: 25841kB = 25.24MB
Ratio: 54.04%
Test time (full extraction): 27 sec
FreeArc 0.60 RC
mx, using 384MB memory (Compression Time: 74 sec)
ARC Archive Size: 26164kB = 25.55MB
Ratio: 54.71%
RZM 0.07h
c, (EH-AKA1.zip file, size: 48970046 byte, store compressed) using 258MB memory (Compression Time: 154 sec)
RZM Archive Size: 25424kB = 24.83MB
Ratio: 53.16%
Extraction time: 27 sec
CCMx 1.26b
4, (EH-AKA1.tar file, size: 48977408 byte, store compressed) Allocated 276MiB memory (Compression Time: 114 sec)
CCMx Archive Size: 25998.88kB = 25.39MB
Ratio: 54.36%
Extraction time: 115 sec
CCMx 1.30c
4, (EH-AKA1.tar file, size: 48977408 byte, store compressed) Allocated 274MiB memory (Compression Time: 99 sec)
CCMx Archive Size: 26000.23kB = 25.39MB
Ratio: 54.36%
Extraction time: 99 sec
SBC 0.970
c -m3 -b63 -af, mem: 226.1 MB
(EH-AKA1.tar file, size: 48977408 byte, store compressed)
SBC Archive Size: 29908.7kB = 29.207MB
Ratio: 62.532%
UDA 0.301
e, Memory needed: 180MB
(EH-AKA1.tar file, size: 48977408 byte, store compressed)
UDA Archive Size: 23409kB = 22.86MB (Compression Time: ~37 min!!)
Ratio: 48.9428%
WinUDA 0.291 Classic
Mode-3 (Require 194MB memory), Recurse subdirectories
UDA Archive Size: 25302kB = 24.71MB (Compression Time: 1659 sec!!)
Ratio: 52.9103%
Please compression test other archivers (WinRK, PAQ8, KGB...).
Sorry this english translated languages.
Update1:
Waaaaah, Link: http://encode.ru/threads/1296-CSA-archiver?p=25313&viewfull=1#post25313
Thanks for the tips Shelwien (precomp)
Original CSA Archive Size: 19.29MB
Extracted Files Total Size: 46.7MB
Recompress using precomp+archivers CSA archive!!!
CSA --> Precomp --> PCF --> 7z/arc/nz/others archivers.
C:\Documents and Settings\...\EH-AKA1>precomp038 -slow eh-aka1.csa
Precomp v0.3.8 - ALPHA version - USE FOR TESTING ONLY
Free for non-commercial use - Copyright 2006-2008 by Christian Schneider
Input file: eh-aka1.csa
Output file: eh-aka1.pcf
Using PACKJPG.DLL for JPG recompression.
--> packJPG DLL v2.4WIP4 (11/06/2008) by Matthias Stirner <--
More about PackJPG here: http://www.elektronik.htw-aalen.de/packjpg
100.0% - New size: 86313067 instead of 20226761
Done.
Time: 46187 ms
Recompressed streams: 1/1
zLib streams (slow mode): 1/1
You can speed up Precomp for THIS FILE with these parameters:
-c9 -m8
Fast mode does exactly the same for this file, only faster.
20226761 --> 86313067 byte !! (84290.1kB = 82.31MB !!), This 12 unpacked files total size 46.7MB, Precompressed PCF files 82.31MB !!
(PCF file 82,31MB --> Precomp --> New PCF file 83.0857MB):
C:\Documents and Settings\...\Desktop>precomp038.exe -slow eh-aka1.pcf
Precomp v0.3.8 - ALPHA version - USE FOR TESTING ONLY
Free for non-commercial use - Copyright 2006-2008 by Christian Schneider
Input file: eh-aka1.pcf
Output file: eh-aka1_pcf.pcf
Using PACKJPG.DLL for JPG recompression.
--> packJPG DLL v2.4WIP4 (11/06/2008) by Matthias Stirner <--
More about PackJPG here: http://www.elektronik.htw-aalen.de/packjpg
100.0% - New size: 87121709 instead of 86313067
Done.
Time: 30391 ms
Recompressed streams: 3/7
GZip streams: 1/1
zLib streams (slow mode): 2/6
You can speed up Precomp for THIS FILE with these parameters:
-c6 -m8
Fast mode does exactly the same for this file, only faster.
Extracted 12 files to ZIP file to precomp:
C:\Documents and Settings\...\EH-AKA1>precomp038 -slow eh-aka1.zip
Precomp v0.3.8 - ALPHA version - USE FOR TESTING ONLY
Free for non-commercial use - Copyright 2006-2008 by Christian Schneider
Input file: eh-aka1.zip
Output file: eh-aka1.pcf
Using PACKJPG.DLL for JPG recompression.
--> packJPG DLL v2.4WIP4 (11/06/2008) by Matthias Stirner <--
More about PackJPG here: http://www.elektronik.htw-aalen.de/packjpg
100.0% - New size: 49778688 instead of 48970046
Done.
Time: 146344 ms
Recompressed streams: 3/47
GZip streams: 1/1
zLib streams (slow mode): 2/46
You can speed up Precomp for THIS FILE with these parameters:
-c6 -m8
Fast mode does exactly the same for this file, only faster.
This precompressed zipped file 48970046 --> 49778688 = 47.42MB not 82.31MB!
Compress (precompressed CSA archive file) PCF file (82.31MB file):
7-Zip 9.13 beta GUI
z, LZMA, Ultra, 32MB, 273, Solid
7Z Archive Size: 14216385 byte !! = 13883.19kB = 13.56MB
Nanozip 0.08 alpha
Commands: nz8 a -cc -m320m tmp.nz eh-aka1.pcf
NanoZip 0.08 alpha/Win32 (C) 2008-2010 Sami Runsas www.nanozip.net
Intel(R) Celeron(R) CPU 2.93GHz|8 MHz|#1|336/511 MB
*** THIS IS AN EARLY ALPHA VERSION OF NANOZIP *** USE ONLY FOR TESTING ***
Archive: tmp.nz
Compressor: nz_cm [355 MB], threads: 1.
Warning: only 336 MB free!
Compressed 86 313 067 into 10 078 177 in 7m 39.45s, 183 KB/s
IO-in: 0.56s, 146 MB/s. IO-out: 0.04s, 214 MB/s
9.611298MB!!!!
UDA 0.301
e, Memory needed: 180MB
C:\Documents and Settings\...\EH-AKA1>uda.exe e eh-aka1.pcf tmp.uda
UDA 0.301 -- Experimental Console Version -- Base on PAQ8I -- 19 Dec 2006
Author: dwing -- dwing@163.com -- http://wex.cn/dwing http://dwing.51.net
eh-aka1.pcf => tmp.uda
100.0% Finished!
9490431/86313067 in 3342.16 sec, 0.8796 bpb, 11.0% at 25.8 KB/s
9490431 byte = 9268 kB = 9.0507MB!!
Other CSA Archives Precompression Test:
eh_web1.csa: 358518 byte
he_aka1.csa: 18885003 byte
he_web1.csa: 434259 byte
C:\Documents and Settings\...\EH-AKA1>precomp038.exe -slow eh_web1.csa
Precomp v0.3.8 - ALPHA version - USE FOR TESTING ONLY
Free for non-commercial use - Copyright 2006-2008 by Christian Schneider
Input file: eh_web1.csa
Output file: eh_web1.pcf
Using PACKJPG.DLL for JPG recompression.
--> packJPG DLL v2.4WIP4 (11/06/2008) by Matthias Stirner <--
More about PackJPG here: http://www.elektronik.htw-aalen.de/packjpg
100.0% - New size: 358545 instead of 358518
Done.
Time: 828 ms
Recompressed streams: 0/0
None of the given compression and memory levels could be used.
There will be no gain compressing the output file.
C:\Documents and Settings\...\EH-AKA1>precomp038.exe -slow he_aka1.csa
Precomp v0.3.8 - ALPHA version - USE FOR TESTING ONLY
Free for non-commercial use - Copyright 2006-2008 by Christian Schneider
Input file: he_aka1.csa
Output file: he_aka1.pcf
Using PACKJPG.DLL for JPG recompression.
--> packJPG DLL v2.4WIP4 (11/06/2008) by Matthias Stirner <--
More about PackJPG here: http://www.elektronik.htw-aalen.de/packjpg
100.0% - New size: 18885030 instead of 18885003
Done.
Time: 46656 ms
Recompressed streams: 0/4
zLib streams (slow mode): 0/4
None of the given compression and memory levels could be used.
There will be no gain compressing the output file.
C:\Documents and Settings\...\EH-AKA1>precomp038.exe -slow he_web1.csa
Precomp v0.3.8 - ALPHA version - USE FOR TESTING ONLY
Free for non-commercial use - Copyright 2006-2008 by Christian Schneider
Input file: he_web1.csa
Output file: he_web1.pcf
Using PACKJPG.DLL for JPG recompression.
--> packJPG DLL v2.4WIP4 (11/06/2008) by Matthias Stirner <--
More about PackJPG here: http://www.elektronik.htw-aalen.de/packjpg
100.0% - New size: 434286 instead of 434259
Done.
Time: 985 ms
Recompressed streams: 0/0
None of the given compression and memory levels could be used.
There will be no gain compressing the output file.
Hmm, eh-aka1.csa file size bigger then precompressing this file used precomp, Other 3 CSA archive file size not bigger this precompressed used precomp.
Please decompiling this csa_extract.exe file and compliling new file-compress tools.
Тест архиваторов на январь 2012 года
Сравнение архиваторов по параметрам время сжатия и степень сжатия в своих «родных» форматах.
Участники теста: WinRAR 4.10b5 (15 дек 2011), 7z 9.22b (18.04.2011), FreeArc 0.67 (25 декабря 2011) и fp8 (2010-05-02). Про последний архиватор можно прочитать здесь:
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=740#2
Тест одиночных файлов
Одно из применений архиватора – сжать одиночный файл для отправки по электронной почте.
Время работы всех современных архиваторов при этом настолько мало (секунда или меньше), что разумно использовать самый максимальный режим. При этом важен размер файла, а временем практически можно пренебречь. Вот где становится важен параметр времени – это при сжатии больших объемов информации, но об этом отдельный тест.
1 Файл 7z.dll из комплекта 7zip v9.22b размером 941 568 байт.
2 Файл doc размером 19 655 байт.
Архиваторы WinRAR 4.10b5, 7z 9.22b, FreeArc 0.67 работали в максимальных режимах, а fp8 – по умолчанию (режим 5 из 0...8 возможных).
Процессор i3-530 (2 ядерный, 4 поточный), Win7 32-разрядная, ОЗУ 4 ГБ
Архиватор Размер архива 1 Размер архива 2
Сравнение архиваторов по параметрам время сжатия и степень сжатия в своих «родных» форматах.
Участники теста: WinRAR 4.10b5 (15 дек 2011), 7z 9.22b (18.04.2011), FreeArc 0.67 (25 декабря 2011) и fp8 (2010-05-02). Про последний архиватор можно прочитать здесь:
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=740#2
Тест одиночных файлов
Одно из применений архиватора – сжать одиночный файл для отправки по электронной почте.
Время работы всех современных архиваторов при этом настолько мало (секунда или меньше), что разумно использовать самый максимальный режим. При этом важен размер файла, а временем практически можно пренебречь. Вот где становится важен параметр времени – это при сжатии больших объемов информации, но об этом отдельный тест.
1 Файл 7z.dll из комплекта 7zip v9.22b размером 941 568 байт.
2 Файл doc размером 19 655 байт.
Архиваторы WinRAR 4.10b5, 7z 9.22b, FreeArc 0.67 работали в максимальных режимах, а fp8 – по умолчанию (режим 5 из 0...8 возможных).
Процессор i3-530 (2 ядерный, 4 поточный), Win7 32-разрядная, ОЗУ 4 ГБ
Архиватор Размер архива 1 Размер архива 2
И вот так бывает!
Сравнительное тестирование архиваторов на февраль 2012 года
Участники теста: WinRAR 4.10 (16 января 2012), 7z 9.22b (18.04.2011), FreeArc 0.67 (25 декабря 2011).
Совсем недавно я проводил аналогичное тестирование (чуть выше).
За прошедший месяц вышел релиз WinRAR 4.10. Но главное не в этом. В прошлом тестировании я писал о возможности самому составлять методы сжатия из готовых алгоритмов, которое возможно в FreeArc-е, и приводил 2 варианта быстрого сжатия больших объемов информации. Вот в этом направлении и появилась интересная информация.
Я «написал» линейку методов от самого быстрого –m81 до самого плотного –m89, в качестве альтернативы стандартным методам, встроенным в FreeArc изначально. На маленьких объемах информации эти методы могут быть как хуже, так и лучше стандартных. А вот на больших объемах они в моих экспериментах как правило лучше стандартных. Под большими объемами буду подразумевать размер данных примерно от 500 МБ и выше.
Итак, результаты одного из тестов:
Однако, намного нагляднее график с осями «время» и «размер архива»:
График приведен в логарифмическом масштабе по оси времени, поскольку для FreeArc-а диапазон скоростей работы отличается в 30 раз, что плохо передается в линейном масштабе. Зеленый цвет принят для стандартных методов FreeArc, серый цвет – для экспериментальных –m81…-m89.
Начнем с WinRAR-а. Из теста в тест методы «обычный, хороший и максимальный (непрерывные)» дают практически идентичный результат. С точки зрения «время сжатия – размер архива» аутсайдер данного теста.
7z – результаты несколько лучше, чем у WinRAR-а.
FreeArc – явный лидер данного теста. Просто поражает, что при использовании метода –m81, за несколько секунд сжимает лучше чем 7z в режиме «ультра» за несколько минут! Но не стоит забывать, что это относится к данному тесту, на других данных картина будет другая. Также эти методы, скорее всего, уступят любому архиватору при сжатии одиночных файлов. Увы, идеала на все случаи жизни не бывает!
Методы –m81 и-m82 не совпадают с теми что были в предыдущем тесте: «старый» -m82 теперь переименован в –m84, а «старый» -m81 как таковой не сохранился, но примерно соответствует новому –m82.
Все методы –m81…-m89 требуют много памяти (2 ГБ и более) и проверены на компьютерах с процессорами i3-530 (2 ядерный, 4 поточный) и двухядерным E6750 (2.66GHz). На 8-ми ядерных процессорах не проверялись.
Для того, чтобы использовать методы –m81…-m89 необходимо скачать файл arc.ini, запакованный в архив (8КБ): Скачать arc2012-01-30.zip с WebFile.RU и записать его поверх стандартного arc.ini, который должен находиться в том же каталоге, что и Arc.exe (под Windows).
Следует иметь ввиду, что самые быстрые методы (–m81) настолько быстры, что на многих компьютерах, из-за «ограниченного» быстродействия винчестеров (!) время сжатия первых двух методов будет примерно совпадать. Я сталкивался с компьютером, где время сжатия у первых трех методов совпадало! Это означает лишь, что дело «упирается» в быстродействие винчестера! Эта ситуация совершенно незнакома большинству пользователей архиваторов. Сам начал понимать это только недавно. Могу добавить еще, что автор архиватора FreeArc уже выпустил новую пробную версию (в январе 2012) в которой метод –m81 стал заметно быстрее, и обогнал по скорости существующий сейчас –m1.
С другой стороны, самые плотные методы у FreeArc и 7z «упираются» в ограничения памяти 32-разрядной операционной системы. Ограничивается размер словаря и количество одновременно выполняемых потоков. Здесь улучшений можно ожидать на 64-разрядных версиях.
Исходя из этих ограничений, наиболее востребованы, вероятно, будут методы –m83…-m87.
Добавление от 2 декабря 2012 года:
Указанный выше файл arc.ini использовать только с архиватором FreeArc версий до 2011 года включительно.
Для версий 2012 года использовать файл arc.ini от теста за декабрь 2012 года:
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=780#19
Сравнительное тестирование архиваторов на февраль 2012 года
Участники теста: WinRAR 4.10 (16 января 2012), 7z 9.22b (18.04.2011), FreeArc 0.67 (25 декабря 2011).
Совсем недавно я проводил аналогичное тестирование (чуть выше).
За прошедший месяц вышел релиз WinRAR 4.10. Но главное не в этом. В прошлом тестировании я писал о возможности самому составлять методы сжатия из готовых алгоритмов, которое возможно в FreeArc-е, и приводил 2 варианта быстрого сжатия больших объемов информации. Вот в этом направлении и появилась интересная информация.
Я «написал» линейку методов от самого быстрого –m81 до самого плотного –m89, в качестве альтернативы стандартным методам, встроенным в FreeArc изначально. На маленьких объемах информации эти методы могут быть как хуже, так и лучше стандартных. А вот на больших объемах они в моих экспериментах как правило лучше стандартных. Под большими объемами буду подразумевать размер данных примерно от 500 МБ и выше.
Итак, результаты одного из тестов:
Однако, намного нагляднее график с осями «время» и «размер архива»:
График приведен в логарифмическом масштабе по оси времени, поскольку для FreeArc-а диапазон скоростей работы отличается в 30 раз, что плохо передается в линейном масштабе. Зеленый цвет принят для стандартных методов FreeArc, серый цвет – для экспериментальных –m81…-m89.
Начнем с WinRAR-а. Из теста в тест методы «обычный, хороший и максимальный (непрерывные)» дают практически идентичный результат. С точки зрения «время сжатия – размер архива» аутсайдер данного теста.
7z – результаты несколько лучше, чем у WinRAR-а.
FreeArc – явный лидер данного теста. Просто поражает, что при использовании метода –m81, за несколько секунд сжимает лучше чем 7z в режиме «ультра» за несколько минут! Но не стоит забывать, что это относится к данному тесту, на других данных картина будет другая. Также эти методы, скорее всего, уступят любому архиватору при сжатии одиночных файлов. Увы, идеала на все случаи жизни не бывает!
Методы –m81 и-m82 не совпадают с теми что были в предыдущем тесте: «старый» -m82 теперь переименован в –m84, а «старый» -m81 как таковой не сохранился, но примерно соответствует новому –m82.
Все методы –m81…-m89 требуют много памяти (2 ГБ и более) и проверены на компьютерах с процессорами i3-530 (2 ядерный, 4 поточный) и двухядерным E6750 (2.66GHz). На 8-ми ядерных процессорах не проверялись.
Для того, чтобы использовать методы –m81…-m89 необходимо скачать файл arc.ini, запакованный в архив (8КБ): Скачать arc2012-01-30.zip с WebFile.RU и записать его поверх стандартного arc.ini, который должен находиться в том же каталоге, что и Arc.exe (под Windows).
Следует иметь ввиду, что самые быстрые методы (–m81) настолько быстры, что на многих компьютерах, из-за «ограниченного» быстродействия винчестеров (!) время сжатия первых двух методов будет примерно совпадать. Я сталкивался с компьютером, где время сжатия у первых трех методов совпадало! Это означает лишь, что дело «упирается» в быстродействие винчестера! Эта ситуация совершенно незнакома большинству пользователей архиваторов. Сам начал понимать это только недавно. Могу добавить еще, что автор архиватора FreeArc уже выпустил новую пробную версию (в январе 2012) в которой метод –m81 стал заметно быстрее, и обогнал по скорости существующий сейчас –m1.
С другой стороны, самые плотные методы у FreeArc и 7z «упираются» в ограничения памяти 32-разрядной операционной системы. Ограничивается размер словаря и количество одновременно выполняемых потоков. Здесь улучшений можно ожидать на 64-разрядных версиях.
Исходя из этих ограничений, наиболее востребованы, вероятно, будут методы –m83…-m87.
Добавление от 2 декабря 2012 года:
Указанный выше файл arc.ini использовать только с архиватором FreeArc версий до 2011 года включительно.
Для версий 2012 года использовать файл arc.ini от теста за декабрь 2012 года:
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=780#19
А как задействавать –m81 ?
Заменил arc.ini в меню -81 не появляется ...
Написал в ручную -m81 сохранил как профиль супербыстрое.
Сейчас жму на Phenom II X4 3.2ГГц (Разлоченный Athlon X3) ХР32 4Гб (3,25) папку ~100000 файлов 5000 папок
там и фото и офисные документы и видео на фотик и пара программ.
Папка 28,9Гб
скорость 13-16МБ/с
Время 31 минута нагрузка на проц ~6-7%
Даже не знаю радоваться или нет ...
пробую жать скоростным методом RAR и 7zip и зип.
Добавлено:
на выходе 16,7Гб
Заменил arc.ini в меню -81 не появляется ...
Написал в ручную -m81 сохранил как профиль супербыстрое.
Сейчас жму на Phenom II X4 3.2ГГц (Разлоченный Athlon X3) ХР32 4Гб (3,25) папку ~100000 файлов 5000 папок
там и фото и офисные документы и видео на фотик и пара программ.
Папка 28,9Гб
скорость 13-16МБ/с
Время 31 минута нагрузка на проц ~6-7%
Даже не знаю радоваться или нет ...
пробую жать скоростным методом RAR и 7zip и зип.
Добавлено:
на выходе 16,7Гб
При сжатии на вкладке "основное" надо в строке "сжатие" набрать -m81.
После того, как один раз наберете, эта строка "запомнится".
Маленькая нагрузка на проц - означает, что сжатие "ограничивается" скоростью винчестера. Можно попробовать -m82, вероятно, скорость хуже не будет.
А что получилось с RAR-ом и 7z?
После того, как один раз наберете, эта строка "запомнится".
Маленькая нагрузка на проц - означает, что сжатие "ограничивается" скоростью винчестера. Можно попробовать -m82, вероятно, скорость хуже не будет.
А что получилось с RAR-ом и 7z?
у меня Athlon II X3 3,2 ГГц (разлоченный)
в Винде определился как Phenom II X4 B50 3.2ГГц + 2+2Гб памяти
папка 650 мб
в папке :
128мб xls
66 мб DOC
168 мб jpg
61мб bmp
97 мб rar
258 мб остальное *SCRATCH*
FreeArc Max 264мб 4:10 Fast 329мб 0:07 noPack 650мб 0:05
WinRAR Max 439мб 2:56 Fast 457мб 1:14 noPack 650Мб 0:18
Hao(7z) Max 431мб 3:51 Fast 453Мб 0:70 noPack 650мб 0:05
RAR(zip) Max 466мб 1:29 Fast 471Мб 0:39 noPack 650мб 0:16
Hao(zip) Max 464мб 0:24 Fast 471Мб 0:18 noPack 650мб 0:18
qpress.exe -rv 511мб 0-15 консольная утилита
папку 28,9 Гб -m81 сжал за 31:10 16,7 Гб (в папке в принципе всяко разное но по идее состав аналогчиной той что выше на 650мб, папка на 650мб это подпапка в папке на 28,9 Гб )
WinRar (скоростной, дефолтные настройки) сжал за 1:06:30 до 21,4Гб
Я в шоке
Проверю на SSD диске и отпишусь (на том же железе)
той же папки тех же архиваторов.
Может добавлю оригинальный 7Zip
Папка 200 мб ТОЛЬКО doc*/xls* 1881 файл
FreeArc 27.2мб 2 сек -m81
FreeArc 16.4мб 55 сек Ультра (требует 2 гб ОЗУ для распаковки): -mx -ld1600m распаковка 12 сек
FreeArc(zip) 61,8 МБ 6 сек Максимальное: -mx9
FreeArc(zip) 62,8 МБ 2 сек Максимальное: -m81
FreeArc(7zip) 16,1 МБ 1:03 сек Ультра: -mx9
FreeArc(7zip) 27,6 МБ 0:19 сек Быстрое: -mx3
WinRar 61,9 МБ скоростной 9сек
WinRar 53,6 МБ максимальный 46 сек распаковка 16 сек
WinRar(zip) 67,2 МБ скоростной 6сек
WinRar(zip) 61,7 МБ максимальный 46 сек
HaoZip(7zip) 54,0 МБ скоростной 19сек
HaoZip(7zip) 48,0 МБ максимальный 1:10сек
HaoZip(zip) 67,3 МБ скоростной 2 сек
HaoZip(zip) 61,7 МБ максимальный 7сек
Текстовую информацию FreeArc -m81 жмет крайне быстро ...
в Винде определился как Phenom II X4 B50 3.2ГГц + 2+2Гб памяти
папка 650 мб
в папке :
128мб xls
66 мб DOC
168 мб jpg
61мб bmp
97 мб rar
258 мб остальное *SCRATCH*
FreeArc Max 264мб 4:10 Fast 329мб 0:07 noPack 650мб 0:05
WinRAR Max 439мб 2:56 Fast 457мб 1:14 noPack 650Мб 0:18
Hao(7z) Max 431мб 3:51 Fast 453Мб 0:70 noPack 650мб 0:05
RAR(zip) Max 466мб 1:29 Fast 471Мб 0:39 noPack 650мб 0:16
Hao(zip) Max 464мб 0:24 Fast 471Мб 0:18 noPack 650мб 0:18
qpress.exe -rv 511мб 0-15 консольная утилита
папку 28,9 Гб -m81 сжал за 31:10 16,7 Гб (в папке в принципе всяко разное но по идее состав аналогчиной той что выше на 650мб, папка на 650мб это подпапка в папке на 28,9 Гб )
WinRar (скоростной, дефолтные настройки) сжал за 1:06:30 до 21,4Гб
Я в шоке
Проверю на SSD диске и отпишусь (на том же железе)
той же папки тех же архиваторов.
Может добавлю оригинальный 7Zip
Папка 200 мб ТОЛЬКО doc*/xls* 1881 файл
FreeArc 27.2мб 2 сек -m81
FreeArc 16.4мб 55 сек Ультра (требует 2 гб ОЗУ для распаковки): -mx -ld1600m распаковка 12 сек
FreeArc(zip) 61,8 МБ 6 сек Максимальное: -mx9
FreeArc(zip) 62,8 МБ 2 сек Максимальное: -m81
FreeArc(7zip) 16,1 МБ 1:03 сек Ультра: -mx9
FreeArc(7zip) 27,6 МБ 0:19 сек Быстрое: -mx3
WinRar 61,9 МБ скоростной 9сек
WinRar 53,6 МБ максимальный 46 сек распаковка 16 сек
WinRar(zip) 67,2 МБ скоростной 6сек
WinRar(zip) 61,7 МБ максимальный 46 сек
HaoZip(7zip) 54,0 МБ скоростной 19сек
HaoZip(7zip) 48,0 МБ максимальный 1:10сек
HaoZip(zip) 67,3 МБ скоростной 2 сек
HaoZip(zip) 61,7 МБ максимальный 7сек
Текстовую информацию FreeArc -m81 жмет крайне быстро ...
ты в курсе сколько -m81 требует памяти для распаковки?
freearc 0.67 в zip тоже умеет сжимать. попробуй - тоже будешь шокирован
freearc 0.67 в zip тоже умеет сжимать. попробуй - тоже будешь шокирован
ну когда даже в буке 4гб памяти то это не так и страшно!
vitektm
Цитата:
Попробуйте для интереса просто скопировать эту папку на том же диске (если есть место). Сколько займет времени? Думаю, порядка 30 мин или больше.
Цитата:
папку 28,9 Гб -m81 сжал за 31:10 16,7 Гб
Попробуйте для интереса просто скопировать эту папку на том же диске (если есть место). Сколько займет времени? Думаю, порядка 30 мин или больше.
Папка чуток разбухла 32Гб стала.
Время копирования на тот же раздел заняло 50 минут
Архивировал раньше тоже на тот же диск.
Время копирования на тот же раздел заняло 50 минут
Архивировал раньше тоже на тот же диск.
Ну вот, просто копирование - 50 мин, а FreeArc сжал за 31 мин!
Цитата:
Ну вотЭто значит что уперлось в жесткий диск и сжатие может быть еще быстрее чем 31 минута ?
Быстрее - вряд ли.
Ерунда какая-то с последним FreeArc:
1. В GUI настройки при смене верхних пресетов вверху галочки внизу не меняются.
2. Нигде не слова о том что надо packjpg.exe положить в папку freearc/bin (нужен подход как в megui с автообновлением компонентов)
3. Подаю на вход чистого packjpg 1.jpg, на выходе - получаю 80%. Запускаю с тем же файлом freearc с -m5p (или -m9p), packjpg пишет в консоле что вроде как работает, но на выходе архив 101%. WTF ?
4. freearc.ini данный здесь не до конца совместим с последней версией freearc, в частности те же -m5p не работают (а в -m81 jpg preprocess вроде как нет).
5. Почему бы не включить эти m81-m87 в официальную версию, в том числе сделать их доступными и через GUI ?
1. В GUI настройки при смене верхних пресетов вверху галочки внизу не меняются.
2. Нигде не слова о том что надо packjpg.exe положить в папку freearc/bin (нужен подход как в megui с автообновлением компонентов)
3. Подаю на вход чистого packjpg 1.jpg, на выходе - получаю 80%. Запускаю с тем же файлом freearc с -m5p (или -m9p), packjpg пишет в консоле что вроде как работает, но на выходе архив 101%. WTF ?
4. freearc.ini данный здесь не до конца совместим с последней версией freearc, в частности те же -m5p не работают (а в -m81 jpg preprocess вроде как нет).
5. Почему бы не включить эти m81-m87 в официальную версию, в том числе сделать их доступными и через GUI ?
Тест архиваторов на июль 2012 года. Сжатие одиночных файлов.
Участники теста: WinRAR 4.20 (14 июня 2012), 7z 9.22b (18.04.2011), FreeArc 0.67 (5 февраля 2012) и сверхплотные из серии PAQ8.
1. Цель тестирования.
Идея тестирования появилась, когда обнаружил, что «несжимаемые» популярными архиваторами данные (.jpg) могут быть заметно сжаты сверхплотными архиваторами. Поэтому решил посмотреть, насколько большая будет разница, и, кроме того, разобраться, как различаются между собой по времени/степени сжатия различные версии PAQ8.
2. Описание архиваторов.
Все архиваторы, кроме WinRAR, бесплатны.
Версия WinRAR 4.20 по скорости работы превосходит 4.11 в два и более раз. В предыдущем тесте для папки размером 757 717 055 байт в режиме макс, непрерывный:
v4.11 – 504 750 080 за 218 с,
v4.20 - 505 264 040 за 93 с.
Загрузка процессора стала 60…70 %, что больше, но все равно отстает от конкурентов. Есть еще резервы!
В линейке PAQ8 в 2012 году появились новые версии fp8_v3 (=fast paq8) и paq8pxd_v4.
Архиваторы PAQ8 любопытны благодаря своим свойствам: бесплатны, являются победителями различных тестов на сжатие, корректно работают с русскими буквами в названиях папок и файлов, очень легко можно использовать в Windows по технологии drag and drop / тащи и бросай (Перетаскиваем выбранный файл (папку) на программу PAQ8 (fp8) – и все!). Обратная сторона медали - работают очень медленно! Большое количество версий PAQ8 доступно для скачивания здесь: http://dhost.info/paq8/. Если какой-либо версии на этой странице нет, я буду давать дополнительную ссылку.
3. Описание сжимаемых файлов
.jpg – 1 580 276 байт
.pdf – 1 214 802 байта
SqueezeChart2012.xlsx – 947 808 байт, таблица с сайта http://www.squeezechart.com/index.html с результатами тестирования архиваторов на дату 2012 Jun 18.
.doc – 1 440 768
7z.dll – 914 432 (от v9.20)
.mht – 1 497 180
4. Описание компьютера
Процессор i3-530 (2 ядерный, 4 поточный), Win7 32-разрядная, ОЗУ 4 ГБ
5. Описание теста
Для популярных архиваторов WinRAR, 7z и FreeArc время сжатия менее секунды. Выбор нужных пунктов в меню занимает больше времени! И в данном тестировании упор не на это. Поэтому для них время не измерялось и в таблице не приводится.
Для архиваторов PAQ8 использовалась (во всех случаях) технология drag and drop. Время записывалось то, которое показывал сам архиватор.
Две последние колонки таблицы показывают сумму размеров созданных архивов и суммарное время, потраченное на сжатие.
Архиваторы располагались в таблице, по возможности, в порядке увеличения суммарного времени, за некоторыми отступлениями, которые показались мне уместны.
Для архиваторов PAQ8 достаточно часто существует несколько вариантов компиляции/под разные процессоры (с одинаковым сжатием), я старался брать наиболее быстрый для моего компьютера, и указывал это в скобках, после версии архиватора. Наиболее быстрые – от M4ST3R(SS2) http://encode.ru/threads/395-Alternative-paq8px-builds, http://encode.ru/threads/544-Alternative-paq8pxpre-builds.
Необходимо обратить внимание на ряд результатов с красным полем. Дело в том, что во всех архиваторах PAQ8 с октября 2007 по 12 мая 2009 года (paq8o7…paq8o10t…paq8p…paq8px_v1…paq8p3x2_v3) была ошибка детектирования JPEG файлов. Проявлялась она только на некоторых файлах. Здесь можно скачать фотографию, что я использовал при тестировании Скачать 100_3951.JPG с WebFile.RU. (Другие фото, сделанные с этого же фотоаппарата, в это же время, детектировались и сжимались нормально.) После 12 мая 2009 года (paq8p3x_v20… paq8q2_v3) архиваторы лишены (?) этого недостатка http://encode.ru/threads/342-paq8px/page5 (здесь можно скачать paq8p3x_v20.zip).
Увидеть, задействован ли алгоритм JPEG, можно в окне программы. Например, paq8o8pre:
Однако, видимо, какие-то неточности в детектировании JPEG файлов были и остались во всех версиях. У меня есть фото, которое ни одна версия, включая последние, не распознает (!):
Скачать CIMG1186.JPG с WebFile.RU
Опять-таки, другие фото сделанные этим фотоаппаратом примерно в то же время, распознаются нормально.
6. Анализ результатов по группам
Таблица разделена на несколько групп по времени сжатия, группы разделены горизонтальной линией.
А) Популярные архиваторы WinRAR 4.20 (14 июня 2012), 7z 9.22b (18.04.2011), FreeArc 0.67 (5 февраля 2012)
Каждый хотя бы раз показал лучший результат по сжатию в своей группе. Разница внутри группы по суммарному размеру архивов около 3%. Отрыв от следующей группы – более 15%. Хотя нельзя не отметить факта, что при сжатии файла .doc популярные архиваторы смогли обогнать некоторые версии быстрых paq8.
Б) Быстрые PAQ8
Несомненный прогресс в лице fp8_v3 – очень удачная версия. Время работы (внутри группы) незначительно больше, размеры архивов заметно уменьшились. По сжатию изображений показывает чуть ли не лучший результат среди всех архиваторов. Скачать можно здесь: http://encode.ru/threads/613-FP8-(-Fast-PAQ8)
Надо отметить, что разные версии fp8 имеют несовместимые архивы.
В) PAQ8F
Видно, что результаты по сжатию в этой серии отличаются только сжатием изображений. Наилучшее сжатие изображений у версии paq8fthis4. Зато наиболее быстрое (в 2,5 раза быстрее, чем fp8) у версии paq8fthis_fast. Обе эти версии находятся в одном архиве paq8fthis4.zip.
Отдельно скажу про основную версию – paq8f. Я знаю 3 реализации: быстрая - paq-8f (http://cs.fit.edu/~mmahoney/compression/paq.html), «просто» paq8f, и версия в архиваторе peazip. Степень сжатия одинакова, а время сжатия, на примере файла .doc: paq-8f – 46,57 с, paq8f – 49.41 с, paq8f (peazip 3.6) – 63.82 с.
Если оценивать по суммарному размеру архивов, то paq8f сжимает хуже, чем fp8_v3, а paq8fthis4 – не намного лучше. Зато время сжатия близко к следующей группе. В общем, на сегодняшний день, серия paq8f – не самая удачная.
(Хотя у меня был случай, когда .doc был сжат paq8f лучше, чем paq8o/paq8px/paq8pxd. При этом еще и быстрее).
Г) paq8p3x_v20
Удачная версия по соотношению время сжатия/ размер архива. Скачать можно здесь: http://encode.ru/threads/342-paq8px/page5.
Похожа на нее, и чуть быстрее версия paq8q2_v3(sse_intel). Но иногда при сжатии файлов .mht размер архива больше, чем у paq8f. Такого недостатка у paq8p3x_v20 не заметил.
Д) paq8o
Основные отличия – в сжатии изображений. А начиная с версии paq8o7 и до самой последней paq8o10t – иногда ошибка в детектировании JPEG файлов. Изменения происходили вслед за аналогичными изменениями paq8f. Некоторые версии показывают одинаковые результаты по степени сжатия, отличаясь временем сжатия.
Самая первая версия paq8o была создана на основе paq8n и создавала архивы с расширением .paq8n, затем это было исправлено и новая версия получила название paq8o2. Время сжатия файла 7z.dll: paq8o2\paq8osse – 73.93 с, paq8o2\paq8o – 85,11 с, paq8o (peazip 3.6) – 107.61 с. Опять, как и в случае paq8f, peazip тормозит!
Младшие версии paq8o по суммарному размеру архивов хуже предыдущей группы, а старшие – только чуть лучше, при большем времени сжатия. Не самые удачные показатели.
Е) paq8px_v69/paq8pxd_v4
paq8px_v69_M4ST3R(SSE2) – удачная версия по соотношению время сжатия/ размер архива.
paq8pxd_v4 – примерно такие же показатели по размеру архива, кроме файлов .mht, которые сжимаются очень сильно. У меня был случай когда подобный файл был сжат заметно лучше, чем всеми другими архиваторами (paq8), включая paq8kx_v7.
Ж) paq8kx_v4/…/paq8kx_v7
Сюда же можно отнести paq8px_v68p3, эти все версии предложены одним автором. Обеспечивают самое максимальное сжатие во многих тестах. Время работы самое большое.
http://encode.ru/threads/296-PAQ8K/page2
Добавлю также, что ни один из архиваторов этой группы не захотел работать на компьютере с двухядерным процессором E6750 (2.66GHz), WinXP 32-разрядная, ОЗУ 2 ГБ. (Все архиваторы других групп работали нормально).
З) Архиваторы с precomp
Я выделил эти две версии, paq8o8pre и paq8pxpre, в отдельную группу.
При сжатии .pdf и .xlsx они показали значительное преимущество.
Версия paq8o8pre является лучшей по сжатию среди всех архиваторов (не только paq), по тестам SqueezeChart. Однако там не была протестирована версия paq8pxpre, вероятно, она бы стала новым победителем.
7. Заключительные замечания
Нельзя объять необъятное, и эти тесты не исключения. Например, в этих тестах не было архивов .zip, на которых архиваторы с precomp показывают интересные результаты, не было музыкальных форматов. Да и вообще, на других данных результаты могут получиться другими.
Тем не менее, общая картина, как мне кажется, получилась.
Более полные данные (включены версии paq8q2_v3/ paq8kx_v6 и другие, график время/размер архива, но без подписей) есть в файле .xls:
Скачать Сравнение PAQ8.rar с WebFile.RU
Участники теста: WinRAR 4.20 (14 июня 2012), 7z 9.22b (18.04.2011), FreeArc 0.67 (5 февраля 2012) и сверхплотные из серии PAQ8.
1. Цель тестирования.
Идея тестирования появилась, когда обнаружил, что «несжимаемые» популярными архиваторами данные (.jpg) могут быть заметно сжаты сверхплотными архиваторами. Поэтому решил посмотреть, насколько большая будет разница, и, кроме того, разобраться, как различаются между собой по времени/степени сжатия различные версии PAQ8.
2. Описание архиваторов.
Все архиваторы, кроме WinRAR, бесплатны.
Версия WinRAR 4.20 по скорости работы превосходит 4.11 в два и более раз. В предыдущем тесте для папки размером 757 717 055 байт в режиме макс, непрерывный:
v4.11 – 504 750 080 за 218 с,
v4.20 - 505 264 040 за 93 с.
Загрузка процессора стала 60…70 %, что больше, но все равно отстает от конкурентов. Есть еще резервы!
В линейке PAQ8 в 2012 году появились новые версии fp8_v3 (=fast paq8) и paq8pxd_v4.
Архиваторы PAQ8 любопытны благодаря своим свойствам: бесплатны, являются победителями различных тестов на сжатие, корректно работают с русскими буквами в названиях папок и файлов, очень легко можно использовать в Windows по технологии drag and drop / тащи и бросай (Перетаскиваем выбранный файл (папку) на программу PAQ8 (fp8) – и все!). Обратная сторона медали - работают очень медленно! Большое количество версий PAQ8 доступно для скачивания здесь: http://dhost.info/paq8/. Если какой-либо версии на этой странице нет, я буду давать дополнительную ссылку.
3. Описание сжимаемых файлов
.jpg – 1 580 276 байт
.pdf – 1 214 802 байта
SqueezeChart2012.xlsx – 947 808 байт, таблица с сайта http://www.squeezechart.com/index.html с результатами тестирования архиваторов на дату 2012 Jun 18.
.doc – 1 440 768
7z.dll – 914 432 (от v9.20)
.mht – 1 497 180
4. Описание компьютера
Процессор i3-530 (2 ядерный, 4 поточный), Win7 32-разрядная, ОЗУ 4 ГБ
5. Описание теста
Для популярных архиваторов WinRAR, 7z и FreeArc время сжатия менее секунды. Выбор нужных пунктов в меню занимает больше времени! И в данном тестировании упор не на это. Поэтому для них время не измерялось и в таблице не приводится.
Для архиваторов PAQ8 использовалась (во всех случаях) технология drag and drop. Время записывалось то, которое показывал сам архиватор.
Две последние колонки таблицы показывают сумму размеров созданных архивов и суммарное время, потраченное на сжатие.
Архиваторы располагались в таблице, по возможности, в порядке увеличения суммарного времени, за некоторыми отступлениями, которые показались мне уместны.
Для архиваторов PAQ8 достаточно часто существует несколько вариантов компиляции/под разные процессоры (с одинаковым сжатием), я старался брать наиболее быстрый для моего компьютера, и указывал это в скобках, после версии архиватора. Наиболее быстрые – от M4ST3R(SS2) http://encode.ru/threads/395-Alternative-paq8px-builds, http://encode.ru/threads/544-Alternative-paq8pxpre-builds.
Необходимо обратить внимание на ряд результатов с красным полем. Дело в том, что во всех архиваторах PAQ8 с октября 2007 по 12 мая 2009 года (paq8o7…paq8o10t…paq8p…paq8px_v1…paq8p3x2_v3) была ошибка детектирования JPEG файлов. Проявлялась она только на некоторых файлах. Здесь можно скачать фотографию, что я использовал при тестировании Скачать 100_3951.JPG с WebFile.RU. (Другие фото, сделанные с этого же фотоаппарата, в это же время, детектировались и сжимались нормально.) После 12 мая 2009 года (paq8p3x_v20… paq8q2_v3) архиваторы лишены (?) этого недостатка http://encode.ru/threads/342-paq8px/page5 (здесь можно скачать paq8p3x_v20.zip).
Увидеть, задействован ли алгоритм JPEG, можно в окне программы. Например, paq8o8pre:
Однако, видимо, какие-то неточности в детектировании JPEG файлов были и остались во всех версиях. У меня есть фото, которое ни одна версия, включая последние, не распознает (!):
Скачать CIMG1186.JPG с WebFile.RU
Опять-таки, другие фото сделанные этим фотоаппаратом примерно в то же время, распознаются нормально.
6. Анализ результатов по группам
Таблица разделена на несколько групп по времени сжатия, группы разделены горизонтальной линией.
А) Популярные архиваторы WinRAR 4.20 (14 июня 2012), 7z 9.22b (18.04.2011), FreeArc 0.67 (5 февраля 2012)
Каждый хотя бы раз показал лучший результат по сжатию в своей группе. Разница внутри группы по суммарному размеру архивов около 3%. Отрыв от следующей группы – более 15%. Хотя нельзя не отметить факта, что при сжатии файла .doc популярные архиваторы смогли обогнать некоторые версии быстрых paq8.
Б) Быстрые PAQ8
Несомненный прогресс в лице fp8_v3 – очень удачная версия. Время работы (внутри группы) незначительно больше, размеры архивов заметно уменьшились. По сжатию изображений показывает чуть ли не лучший результат среди всех архиваторов. Скачать можно здесь: http://encode.ru/threads/613-FP8-(-Fast-PAQ8)
Надо отметить, что разные версии fp8 имеют несовместимые архивы.
В) PAQ8F
Видно, что результаты по сжатию в этой серии отличаются только сжатием изображений. Наилучшее сжатие изображений у версии paq8fthis4. Зато наиболее быстрое (в 2,5 раза быстрее, чем fp8) у версии paq8fthis_fast. Обе эти версии находятся в одном архиве paq8fthis4.zip.
Отдельно скажу про основную версию – paq8f. Я знаю 3 реализации: быстрая - paq-8f (http://cs.fit.edu/~mmahoney/compression/paq.html), «просто» paq8f, и версия в архиваторе peazip. Степень сжатия одинакова, а время сжатия, на примере файла .doc: paq-8f – 46,57 с, paq8f – 49.41 с, paq8f (peazip 3.6) – 63.82 с.
Если оценивать по суммарному размеру архивов, то paq8f сжимает хуже, чем fp8_v3, а paq8fthis4 – не намного лучше. Зато время сжатия близко к следующей группе. В общем, на сегодняшний день, серия paq8f – не самая удачная.
(Хотя у меня был случай, когда .doc был сжат paq8f лучше, чем paq8o/paq8px/paq8pxd. При этом еще и быстрее).
Г) paq8p3x_v20
Удачная версия по соотношению время сжатия/ размер архива. Скачать можно здесь: http://encode.ru/threads/342-paq8px/page5.
Похожа на нее, и чуть быстрее версия paq8q2_v3(sse_intel). Но иногда при сжатии файлов .mht размер архива больше, чем у paq8f. Такого недостатка у paq8p3x_v20 не заметил.
Д) paq8o
Основные отличия – в сжатии изображений. А начиная с версии paq8o7 и до самой последней paq8o10t – иногда ошибка в детектировании JPEG файлов. Изменения происходили вслед за аналогичными изменениями paq8f. Некоторые версии показывают одинаковые результаты по степени сжатия, отличаясь временем сжатия.
Самая первая версия paq8o была создана на основе paq8n и создавала архивы с расширением .paq8n, затем это было исправлено и новая версия получила название paq8o2. Время сжатия файла 7z.dll: paq8o2\paq8osse – 73.93 с, paq8o2\paq8o – 85,11 с, paq8o (peazip 3.6) – 107.61 с. Опять, как и в случае paq8f, peazip тормозит!
Младшие версии paq8o по суммарному размеру архивов хуже предыдущей группы, а старшие – только чуть лучше, при большем времени сжатия. Не самые удачные показатели.
Е) paq8px_v69/paq8pxd_v4
paq8px_v69_M4ST3R(SSE2) – удачная версия по соотношению время сжатия/ размер архива.
paq8pxd_v4 – примерно такие же показатели по размеру архива, кроме файлов .mht, которые сжимаются очень сильно. У меня был случай когда подобный файл был сжат заметно лучше, чем всеми другими архиваторами (paq8), включая paq8kx_v7.
Ж) paq8kx_v4/…/paq8kx_v7
Сюда же можно отнести paq8px_v68p3, эти все версии предложены одним автором. Обеспечивают самое максимальное сжатие во многих тестах. Время работы самое большое.
http://encode.ru/threads/296-PAQ8K/page2
Добавлю также, что ни один из архиваторов этой группы не захотел работать на компьютере с двухядерным процессором E6750 (2.66GHz), WinXP 32-разрядная, ОЗУ 2 ГБ. (Все архиваторы других групп работали нормально).
З) Архиваторы с precomp
Я выделил эти две версии, paq8o8pre и paq8pxpre, в отдельную группу.
При сжатии .pdf и .xlsx они показали значительное преимущество.
Версия paq8o8pre является лучшей по сжатию среди всех архиваторов (не только paq), по тестам SqueezeChart. Однако там не была протестирована версия paq8pxpre, вероятно, она бы стала новым победителем.
7. Заключительные замечания
Нельзя объять необъятное, и эти тесты не исключения. Например, в этих тестах не было архивов .zip, на которых архиваторы с precomp показывают интересные результаты, не было музыкальных форматов. Да и вообще, на других данных результаты могут получиться другими.
Тем не менее, общая картина, как мне кажется, получилась.
Более полные данные (включены версии paq8q2_v3/ paq8kx_v6 и другие, график время/размер архива, но без подписей) есть в файле .xls:
Скачать Сравнение PAQ8.rar с WebFile.RU
А почему взяли 7z старенький?
И FreeArc тоже.
Пока еще не устанавливал более свежие...
(Разницы особой не жду. А вообще на все времени не хватает. Поставить новые версии и протестировать давно руки не доходят. Здесь же меня интересовали больше paq8)
Пока еще не устанавливал более свежие...
(Разницы особой не жду. А вообще на все времени не хватает. Поставить новые версии и протестировать давно руки не доходят. Здесь же меня интересовали больше paq8)
Shuld
Я вот недели через 2 поставлю ОЗУ 8 гигов вместо 4 как сейчас и сравню сжатие.
Я вот недели через 2 поставлю ОЗУ 8 гигов вместо 4 как сейчас и сравню сжатие.
Страницы: 12345678910111213141516171819202122232425262728293031
Предыдущая тема: canopus pro coder
Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.