| Предыдущий блок | Следующий блок | Вернуться в индекс |
— RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 25 Jun 00 11:32:00 To : Alan Long Subj : Q: about zlib * Originally in RU.COMPRESS Hello Alan! Wednesday June 21 2000, Alan Long writes to All: AL> Вот тут такой вопрос возник... Есть достаточно сильно портабельная AL> библиотеки zlib, во всех примерах приводится сжатие/разжатие файлов, AL> а AL> вот она может работать с памятью, то есть хотелось-бы пример AL> использования zlib для сжатия трафика передаваемого по сети. example.c если тебе лень в нем разбираться, то мы не поможем Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : Victor Cheburkin 2:463/62 25 Jun 00 11:59:30 To : Maxim Podzemelnih Subj : Re: RLE Hi! On Sat, 17 Jun 00 16:27:33 +0300, Maxim Podzemelnih wrote: AM>> Вместо "РРРРРРРРРуссссссские Патppppppppиоты!" кодиpуем AM>> "Р!9ус!7кие Патp!8иоты!!". Пpинцип понятен? MP> Та да. о этот "!" флаг ? Как его расчитать ? Ведь если кодировать файл MP> содержащий всю таблицу ASCI, то нужно расчитать флаг. Как бы это полегче MP> делать ? Дык эта, "\0x89Р\0x01у\0x87с\0x07кие Пат\0x88р\0x05иоты!" где числа >0x80 -- указывают что следующая буква повторяется x-0x80 раз, а <0x80 -- что сторока неповторяющихся символов длинной x. Т.е. флагом выступает 7-й бит. Есть и другой вариант -- тебе нужно как-то экранировать ключевые последовательности. -- Victor Cheburkin // mailto:vch@biosys.net VC319-RIPE --- tin/1.4.3-20000502 ("Marian") (UNIX) (Linux/2.2.15 (i686)) * Origin: ВАЗ-2101 '74 (2:463/62) — RU.COMPRESS From : Bulat Ziganshin 2:5093/27.61 26 Jun 00 09:56:02 To : Dima Subj : cab uncompressor *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Originally in RU.COMPRESS Hello Dima! Wednesday June 21 2000, Vsevolod Fedotov writes to Bulat Ziganshin: BZ>> есть также 16 bit cabarc sdk, но я его в глаза не видел VF> http://download.microsoft.com VF> /download/platformsdk/Update/1/WIN98/EN-US/CAB-16.cab вполне реальная штучка, за неделю все можно сварганить Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED+/W32 1.1.2 * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/27.61) — RU.COMPRESS From : IP Robot 2:5093/28.126 27 Jun 00 01:09:53 To : All Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/ ftp://ftp.elf.stuba.sk/pub/pc/pack/powarc56.exe Power Archiver 2000 v5.6 - Multiformat archive file manager (2,123,955 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/upxpr101.zip UPXPR - UPX v1.01 compressed files patcher to prevent unpacking (8,523 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wr271pl.exe RAR v2.71 for Windows (32-bit) - Polish Edition (635,196 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wr271ru.exe RAR v2.71 for Windows (32-bit) - Russian Edition (669,558 bytes) --- PktMake.pl * Origin: PktMake.pl (2:5093/28.126) — RU.COMPRESS From : Vladimir Vassilevsky 2:5020/400 27 Jun 00 07:36:11 To : All Subj : Re: voice compression From: Vladimir Vassilevsky <vlv@fullnet.net> Anatoly Mashanov wrote: > > AP> Есть ли в природе алгоритм упаковки голосового потока с частотой > AP> дискретезации 16 кГц, глубина 16 бит и чтоб на выходе был поток около > AP> 9600 бпс. Обычно войсовые низкоскоростные алгоритмы жестко рассчитаны на 8KHz - дискретизацию входного сигнала. Их полно. Смотрите на тему *.CELP, EVRC, *.MBE, G723, G728, G729. Hе припомню алгоритмов для 16KHz. > Желательно только целочисленка, лучше 32-битная, Алгоритмы обычно оптимизорованы из рассчета на 16-битную машину. > и чтоб в > AP> реалтайме можно упаковывать на 486dx-40? Hереально. Можно реализовать что-то простейшее типа GSM 6.10, и то вряд ли хватит скорости. > Конечно. Только звук будет как из сотового телефона, а то и из фаpфоpового > унитаза. Hу это вы зря. При 9600 можно обеспечить качество голоса существенно лучше, чем стандартный G711. VLV --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : IP Robot 2:5093/27.61 27 Jun 00 21:39:03 To : All Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/ ftp://ftp.elf.stuba.sk/pub/pc/pack/7zip210.exe 7-ZIP Archiver 2.10 - Command line file archiver for Win32 (502,528 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/abcmp206.zip ABComp v2.06 - File Compressor (64,601 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/ac30.zip Anti-Crypt v0.30 - Executable files unpacker (12,271 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/ace.zip MultiArc support for the ACE archiver for FAR manager (3,223 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/act47xls.zip ACT v2 - Archive Comparison Test - March 2000 (in XLS form) (338,961 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/actest47.zip ACT v2 - Archive Comparison Test - March 2000 (in HTML form) (249,006 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/acvt_dos.zip ACVT v1.20 - Archive Converter for DOS (16-bit) (44,137 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/acvt_gui.zip ACVT v1.20 - Archive Converter for Win32 (GUI) (449,027 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/acvt_o16.zip ACVT v1.10 - Archive Converter for OS/2 (16-bit) (32,221 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/acvt_o32.zip ACVT v1.10 - Archive Converter for OS/2 (32-bit) (36,289 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/acvt_pm.zip ACVT v1.20 - Archive Converter for DOS (32-bit) (56,508 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/acvt_win.zip ACVT v1.20 - Archive Converter for Win32 (console) (48,028 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/akt070b5.zip AKT v.70 beta 5 - Compressor from Hungary (without dox) (19,228 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/akt32.zip AKT32 v.70 beta 7 - 32-bit version of compressor from Hungary (31,982 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/apl026b.zip aPLIB v0.26b - Compiled examples (305,008 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/aplib026.zip aPLIB v0.26b - Compression library (90,081 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/arcsrc.zip ARCSRC v1.02a - Archive file searcher (28,759 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/arh140.zip ARHANGEL v1.40 - New packer by George Lyapko (51,637 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/arj271.exe ARJ v2.71 - File archiver for DOS (463,245 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/arj272.exe ARJ v2.72 Beta Test - File archiver for DOS (468,471 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/arj2_271.exe ARJ for OS/2 v2.71 (244,793 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/arj2r271.exe ARJ for OS/2 v2.71 (Russian Edition) (251,823 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/arj32v3j.exe ARJ32 v3.04 - File archiver for Win32 (481,558 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/arj32v3k.exe ARJ32 v3.05 Beta Test - File archiver for Win32 (428,414 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/arjf310u.zip ArjFolder v3.10b - Win95/98/NT ARJ shell (438,156 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/armenu12.zip ARMENU v1.2 - Archiver's shell for DOS (14,731 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/arpr.zip Advanced RAR Password Recovery v1.0 beta 1 (640,494 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/artest15.zip The art of lossless image compression - 15th release of comparative image compr essors (45,310 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/asd014.exe ASD - Archiver v0.1.4 by Tobias Svensson (183,794 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/asd_linx.zip ASD for Linux - Archiver by Tobias Svensson (73,759 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/aspack21.zip ASPack v2.1 - Advanced Win32 Executable File Compressor (324,690 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/av911.zip Archive directory viewer v9.11 (141,840 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/axsetup.exe Archive Explorer v1.5 - Compression util for Win9x/NT/2K (313,834 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/azpzip.zip Active Zipper Pro - Compression/decompression utility (265,374 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/ba100b.zip BA v1.00 beta - Blocksorting Arithmetic Compressor (61,380 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/berar271.zip RAR v2.71 for BeOS - Archiver (260,508 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/bix100b7.zip BIX Archiver v1.00 Beta 7 - Command Line File Archiver for Win95/98/NT (91,645 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/bsa.zip BSA v2.0 (Rel.1.10) - Russian Packer (77,212 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/bszipins.exe BigSpeed Zipper - Zip tool for Win32 (608,019 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/bw5z393s.zip BinaryWork ZIP Compress OCX v3.093 - VB5 (SP3) version (490,020 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/bw6z393s.zip BinaryWork ZIP Compress OCX v3.093 - VB6 (SP3) version (521,417 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/bzip2os2.exe BZIP2 v0.9.5d for OS/2 v3.0 - A file compressor (93,484 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/bzip2w32.exe BZIP2 v0.9.5d for Win95/98/2000/NT - A file compressor (61,440 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/cabman2k.zip Microlog Cabinet Manager 2000 for Win9x/NT - Compression tool for .cab files (8 32,851 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/cachk21.zip Compressed Archive Checker v2.1 - RAR,ARJ&ACE archive checker (841,376 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/cczip32.exe CCZip v3.22 - ZIP application for Windows 95 and NT (1,171,971 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/compress.zip NK - BMP/TV format lossless compressor (82,533 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/dc124.zip DC Archiver - Experimental BWT-based archiver for Win32 (56,062 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/depf105a.exe DeepFreeze v1.05a - Japanese Win95 archiver with GUI interface (313,092 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/desdw179.zip SDW386 v1.79 remover (2,674 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/detrap15.zip DeTrap v1.51 - Generic TRAP Envelope Remover (5,347 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/dkd32.zip DKD32 - LZSS and LZ-CRUNCH decompressor (11,167 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/dpinfo18.zip DPINFO95.DLL v1.8 by D.Paehl - Archive type identifying DLL (237,245 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/dprs111.zip Document Press v1.11 - MS Office document compressor (141,602 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/drpstf50.exe DropStuff 5.0 & Aladdin Expander 5.0 - Windows tool for creation StuffIt and ZI P archive formats (3,645,072 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/dshrnk16.zip DeShrink v1.6 - Shrinker envelope unpacker (188,293 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/dzip_b1.exe DeluxeZIP Beta - Compression tool with ZIP/RAR format support (516,047 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/e_wise.zip E_WISE 2000 - WISE Setup Unpacker (54,843 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/easzipse.exe EASYZIP v1.0 by Dirk Paehl - Win32 packer (526,387 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/elc10.zip E_LC10 - LC10 compressed DOS/G[W] programs unpacker (23,564 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/elfpack.tgz ELFpack for Linux v1.0 (2,512 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/elite104.zip ELITE v1.04 - EXE Wrapper (10,222 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/eri45fre.zip ERI32 v4.5 free - Lossless compressor for True Color images (93,050 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/exework.zip Executable Optimizer v1.055 - Util for optimizing of headers (18,685 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/fi230.zip FileInfo v2.30 - EXE/COM packer/envelope identifier (100,607 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/fv200.zip FV v2.00 - Verbose Archive Directory Lister by Vernon D.Buerg (9,230 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/godzfree.exe GodeZIP 2000 v7.9 free lite version of compress util (1,682,944 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/godzip79.exe GodeZIP 2000 v7.9 - Program to compress/decompress and crypt files by drag&drop (1,325,984 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/gt256.zip GetTyp v2.56 - Extended file format detector (archives,EXE's) (165,886 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/gtw256.zip GetTyp v2.56 for Windows - File format detector (193,499 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/hpa_elr.zip EXELocker Remover (5,855 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/i034.zip IceUnP v0.3.4 - EXE/COM UnPacker by author of Xpack (133,154 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/i5comp21.rar I5comp v2.01 - Install Shield Cabinet Files Maintanance Util (97,067 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/idar160e.exe IDArc v1.60 - Archive Identifier - English version (57,176 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/idarc160.exe IDArc v1.60 - Archive Identifier - German version (57,342 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/idpck260.exe IDPacker v2.60 - TP6+ Unit for Identification of Archive Formats (31,130 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/imp110d.zip IMP v1.10 - DOS version of file archiver (272,609 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/imp112.exe IMP v1.12 - Command-line file archiver for Win95/NT (125,100 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/izshr042.zip Zip/UnZip Source Shared Files (204,936 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/jam221.zip JAM v2.21 - Russian COM/EXE Compressor (20,254 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/jcalg1.zip JCALG1 Compression Library by Jeremy Collake (24,605 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/keepit20.zip Keep-It v2.0 - Revision control system for Win9x/NT (243,483 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/lgfv209.zip LGFV v2.09 - MS-DOS Archives Viewer by Lyapko George (19,359 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/lglz104e.zip LGLZ v1.04e - DOS Executables Compressor by Lyapko George (54,798 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/lgzsp.zip LGZSP - Util for stripping paths from ZIP archives (9,330 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/lxlt121s.zip LxLite v1.2.1 - Source Code of OS/2 Executables Packer (455,848 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/lzealt.zip LZEALT v1.04 - Fast LZEXE un-extractor (9,236 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/lzss.zip Simple LZSS implementation v1.0 by Jeremy Collake (27,903 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/mupg100.zip Make Upgrade v1.00 - Util for making upgrade archives of programs and databases (69,458 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/ned230.zip NED v2.30 - NE VB3.0 executable files deshrinker (8,346 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/pcr144d.zip PNGCRUSH v1.4.4 - PNG files packer (executable) (126,337 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/pcr144s.zip PNGCRUSH v1.4.4 - PNG files packer (source code) (303,868 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/pd32-160.zip ProcDump32 v1.6 Final - PE files unpacker/dumper (161,988 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/ped.zip PEDiminisher v0.1 - Simple PE packer (12,005 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/petite22.zip Petite v2.2 for Win95/NT - Win32 Executable Compressor (109,003 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/pklin251.exe PkZip for Linux v2.51 (309,637 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/pkze100s.exe PKZIP Explorer v1.00 for Win9x/NT/2000 (4,124,040 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/powarc56.exe Power Archiver 2000 v5.6 - Multiformat archive file manager (2,123,955 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/pp219.zip Pro-Pack v2.19 - Executable Packer (41,412 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/ppmdf.rar PPMD var.F - Fast PPM Compressor for textual data w/src (61,015 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/prar206p.exe RAR for OS/2 v2.06 - Polish edition (280,333 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/prsys.zip PRSYS - EXE2BIN Relocation Packer for DOS Driver Files (19,480 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/psav180.zip PalmSaver v1.80 for Win95/98 - Backup shell over ARJ/RAR/ZIP packers (432,407 b ytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/pzip52.exe PowerZip v5.2 - Freeware Win95 ZIP Manager (2,025,064 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/qzip150.zip QuickZip v1.50 - Freeware Zip Clone for Win32 (1,468,269 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/rarln271.sfx RAR v2.71 for UNIX (Linux) (260,963 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/rarseq16.zip RAR Sequence Checker v1.6 - Checks a series of RAR files to see if files are mi ssing (811,538 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/rarx271.exe RAR v2.71 for DOS32 and OS/2 (263,024 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/rcvtw32.rar The RAR Converve Conversion Utility v1.02 (33,065 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/repack.zip REPACKER v1.0 - ZIP/ARJ/RAR... command line repacker (18,982 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/rjc-beta.zip RJCRUSH v1.10a beta - DOS executable compressor (without dox) (32,550 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/rk102a05.exe RK File Archive v1.02 build 05 (alpha) (195,412 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/rkau104.zip RKIVE v1.04 - Audio codec for WAV compression (64,258 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/rkim106.zip RKIVE v1.06 - Image codec for TGA/RAS compression (58,553 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/rkuc104.zip RKIVE v1.04 - Universal compression codec (105,978 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/rv251.zip RV - Rview v2.51 - Archive lister (25,039 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/rvs113.zip RVS - RView Shell v1.13 - Shell for viewing and extracting contents of archives (48,623 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/sal00002.zip SAL - Salamanders compression/archive utility (409,914 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/sear20.zip Self-Extractor Archive Recovery v2.0 (401,933 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/seau61.zip SEAU v6.1 - Self-Extracting Archive Utility (1,112,714 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/sfxfct22.exe SFX-Factory v2.2 - SFX files creation with internal ACE and ZIP compression (1, 872,947 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/shaid260.zip SH Archive Identifier v2.60 (36,426 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/strdtzip.zip StarDotZip v1.0 - Archive Management Tool for Win95/98/NT (1,325,315 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/strpr101.zip StripReloc v1.01 (35,464 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/szip112a.zip SZIP/SUNZIP v1.12a for Win32 - Compression program (73,116 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/tcm100.zip The Compression Maximizer v1.00 - ZIP archives optimizer (116,537 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/tpus.zip Updated TPU files (TPUs) for rjcru110.zip (RJCRUSH utility) (3,351 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/tsfxt311.exe TurboSFX v3.11 - SFX compressed files creator for Win32 (1,284,096 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/typ_d32.zip Typ for DOS386 - Archive lister/filetype/packer/crypter program (317,535 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/typ_os2.zip Typ for OS/2 - Archive lister/filetype/packer/crypter program (343,711 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/unas1083.zip UnASPack v1.0.8.3 - ASPack unpacker (72,809 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/uncom123.zip UnCOM v1.23 - Generic COM unpacker by ROSE (19,091 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/unesp.tgz UnESP for UNIX v0.1 beta (9,309 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/unimp111.zip UNIMP v1.11 (source code) - IMP format unpacking routine (10,770 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/unmes129.zip Mess v1.29 Unpacker (6,734 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/unp412b.zip UNP v4.12 beta without dox (20,740 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/unpack16.zip UN-PACK v1.666 freeware - EXE files analyzer/unpacker (104,421 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/unrarocx.rar UnRAR.OCX - UnRAR Control for VB6 (53,487 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/unrarw32.exe UnRAR (executable) for Win32 (87,849 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/unz541d2.zip Info-ZIP's portable UnZip v5.41 - OS/2 32-bit DLL and header (183,790 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/unz541dn.zip Info-ZIP's portable UnZip v5.41 - Win95/NT (Intel) DLL (174,846 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/unz541x.exe Info-ZIP's portable UnZip v5.41 - DOS executables (174,677 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/unz541x.zip Info-ZIP's portable UnZip v5.41 - Linux executables (160,158 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/unz541x1.exe Info-ZIP's portable UnZip v5.41 - OS/2 16-bit execs (222,912 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/unz541x2.exe Info-ZIP's portable UnZip v5.41 - OS/2 32-bit execs (283,551 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/unz541x3.exe Info-ZIP's portable UnZip v5.41 - DOS execs for 386 (253,795 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/unz541x5.zip Info-ZIP's portable UnZip v5.41 - Linux executables (155,218 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/unz541xn.exe Info-ZIP's portable UnZip v5.41 - Win95/NT (Intel) execs (334,067 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/unzip541.zip Info-ZIP's portable UnZip v5.41 - Generic C sources (1,193,801 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/unziper2.zip Softuarium UnZipper v2.0 demo - ActiveX Control (78,865 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/upx101d.zip UPX v1.01 - Executable packer (DOS version) (177,219 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/upx101l.tgz UPX v1.01 - Executable packer (Linux version) (188,676 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/upx101w.zip UPX v1.01 - Executable packer (Windows version) (116,146 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/upxgui07.zip UPX GUI v0.7b (85,603 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/upxpr101.zip UPXPR - UPX v1.01 compressed files patcher to prevent unpacking (8,523 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/uu160.exe Universal Unpacker v1.60 - German version (102,532 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/uu160e.exe Universal Unpacker v1.60 - English version (100,768 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/vacuum.zip Vacuum v0.01c - COM compressor (10,992 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/vzprp320.zip Visual Zip Password Recovery Processor v3.2 (541,485 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/w32intro.zip Win32Intro v0.71 - Universal Win32 Executable Unpacker/Dumper (27,217 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wavarc11.zip Waveform Archiver v1.1 (141,864 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wavpack.zip WAVPACK Lossless 16-bit Wavefile Compressor v3.0 (81,799 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/whatz23.zip WHATZIP - ZIP archive version identifier (4,075 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/winace13.exe WinAce Archiver v1.3 for Win95/98/NT (1,991,217 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/winarj98.zip Winarj98 by LA Soft - ARJ shell (1,412,934 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wingz11.zip Windows GZip - GZIP/GUNZIP utility for Win95/98/NT/2000 (93,460 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/winzip80.exe <ASP> WinZip v8.0 for Windows 95/98/NT/2000 (1,259,448 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wiz501.zip WizUnZip 32-bit UnZip v5.01 src + DLL (1,002,080 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wiz501xn.exe WizUnZip 32-bit UnZip v5.01 DLL + docs (471,079 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wnimp111.exe WinIMP v1.11 - File archiver for Win95/NT (279,423 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wr270cz.exe RAR v2.70 for Windows (32-bit) - Czech Edition (667,411 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wr271pl.exe RAR v2.71 for Windows (32-bit) - Polish Edition (635,196 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wr271ru.exe RAR v2.71 for Windows (32-bit) - Russian Edition (669,558 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wra27b5c.exe RAR v2.70 beta 5 for Windows (32-bit) - Chinese Edition (598,038 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wrar260k.exe RAR v2.60 for Windows (32-bit) - Korean Edition (579,160 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wrar26pt.exe RAR v2.60 for Windows (32-bit) - Portuguese Edition (560,169 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wrar26sp.rar RAR v2.60 for Windows (32-bit) - Spanish Edition (232,584 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wrar270d.exe RAR v2.70 for Windows (32-bit) - German Edition (612,367 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wrar271.exe RAR v2.71 for Windows (32-bit) - English Edition (602,282 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wrar271i.exe RAR v2.71 for Windows (32-bit) - Italian Edition (654,367 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wrar271j.exe RAR v2.71 for Windows (32-bit) - Japanese Edition (618,708 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wrar27fr.exe RAR v2.70 for Windows (32-bit) - French Edition (686,212 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wwp32120.zip WWPACK32 v1.20 demo - Win95/NT Executable File Compressor (676,833 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/xceedzip.zip XceedZip Compression Library v4.0 (1,030,224 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/xfse.zip xFSE - Final Fantasy Security Envelope Remover for Win95/VCPI (36,663 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/xpa167r.zip XPACK v1.67r - Compressor for DOS (without dox) (36,301 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/xpa32.zip XPA32 file archiver demo v1.0.2 (31,374 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/xpagui.zip Xpa v0.93b - Archiver for Win32 (348,839 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/xplus23.zip Xtractor Plus v2.3 - Archive extraction utility for Win95/98 (1,730,283 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/yaac10.arj YACC v1.0 - ARJ password finder (111,438 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zcr23dn.zip ZIP v2.3 - Win32 DLL (with encryption) (124,191 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zcr23x.zip ZIP v2.3 - DOS execs (with encryption) (363,231 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zcr23x1.zip ZIP v2.3 - OS/2 16-bit execs (with encryption) (145,725 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zcr23x2.zip ZIP v2.3 - OS/2 32-bit execs (with encryption) (185,019 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zcr23xn.zip ZIP v2.3 - Win95/NT (Intel) execs (with encryption) (184,406 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zcrypt29.zip Info-ZIP's ZCrypt v2.9 - C source (19,210 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zfa.zip ZFA - Zip File Attacher to Other Files (113,367 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zfs210b.zip ZIP File System v2.1b - Free Pascal library allowing access to compressed files in ZIP format (144,448 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zip23.zip ZIP v2.3 - C sources (859,059 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zip23dn.zip ZIP v2.3 - Win9x/NT (32-bit) DLL Header Files (no encryption) (108,023 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zip23hlp.zip Help on using ZIP v2.3 (26,178 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zip23x.zip ZIP v2.3 - DOS execs (no encryption) (309,189 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zip23x1.zip ZIP v2.3 - OS/2 16-bit execs (no encryption) (120,933 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zip23x2.zip ZIP v2.3 - OS/2 32-bit execs (no encryption) (149,720 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zip23xl.zip ZIP v2.3 - Linux execs (no encryption) (77,043 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zip23xn.zip ZIP v2.3 - Win95/NT (Intel) execs (no encryption) (149,800 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zipdec10.zip ZipDecrypter v1.0 (16,776 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zipfo201.zip Zipfo v2.01 - Zipped file information util (35,574 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zippi20.zip Zippi v2.00 - Compression util for sending files via ICQ pager or E-mail (384,2 61 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zipscn13.zip ZipScan v1.3 - File inside the ZIP archives searching util (108,679 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/ziptouch.zip ZipTouch v1.0 - Date/time of files inside ZIP archives modifier (243,763 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zipwav10.zip ZipWave v1.0a - Visual Archive Util for Win95/98/NT/2000 (1,424,792 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zipx60sh.zip ZIP Explorer v6.0 - Disk catalog, offline browser and file restore program for Win95/98/NT (1,336,126 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zpeek10.zip Zip Peeker v1.0 for Win9x/NT - ZIP management utility (523,627 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zxzip.rar ZX-ZIP/UNZIP v1.02 - Russian compression util for TR-DOS (45,793 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zxzip01.rar ZX-ZIP v0.1 - Russian compression util (27,885 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zxzip2.zip ZX-ZIP v1.0a - Russian compression util (50,650 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zzip032b.zip ZZIP v0.32 - A block sorting compression tool for Win95/98 (21,881 bytes) --- PktMake.pl * Origin: PktMake.pl (2:5093/27.61) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 28 Jun 00 02:17:13 To : Andrew Worobyew Subj : ibm *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Originally in 1072.COMPNEWS.TALK * Crossposted in RU.COMPRESS Hello Andrew! Tuesday June 27 2000, Andrew Worobyew writes to Bulat Ziganshin: AW> http://www.ibm.com/news/2000/06/26.phtml вот оно, для всех желающих ознакомиться с оригиналом и сравнить его с советским и вариантами: === Cut === IBM research breakthrough doubles computer memory IBM has unveiled a technology that doubles the memory capacity of computer serv ers, a breakthrough which could save Internet service providers and other large technology installations millions of dollars. Named IBM Memory eXpansion Technology, it could eventually be adapted for perso nal computers and pervasive e-business devices, but it is initially designed for Intel-based industry-standard PC servers, such as IBM's Netfinity line. With MXT,аcustomers can either cut costs by buying half the memory to achieve the same performance, or they can increase performance by installing the same amount of memory to achieve twice the capacity. The savings can be significant for both small and large customers, as memory comprises 40 to 70 percent of theаcost of most NT-based server configurations. MXT is a hardware implementation that automatically stores frequently accessed data and instructions close to a computer's microprocessors so they can be accessed immediately —аsignificantly improving performance. Less frequently accessed data and instructions are compressed and stored in memory instead of on a disk — increasing memory capacity by a factor of two or more. MXT incorporates a new level of cache designed to handle data and instructions on a memory controller chip.аBy combining new hardware-based compression algorithms and millions of tiny transistors,аIBM researchers were able to double server memory capacity for most applications.аThe new technology is seamless to the end-user because the compressed data can be uncompressed in nanoseconds when needed. Since MXT effectively doubles the memory capacity of a machine, a typical Windows 2000 or NT-server based rack-mounted configuration can achieve its maximum memory capacity of 168 gigabytes with only 84 gigabytes installed. With the retail cost of server memory at several thousand dollars per gigabyte, a customer could double their memory capacity and cut their cost per gigabyte by half, saving about $250,000 per rack of servers.аFor a customer with a large IT installation — such as an ISP with multiple racks of servers — MXT could result in total savings of more than a million dollars. === Cut === можно поискать здесь упоминания pdа, упаковки на лету, 10000-кратного ускорения . Все же, Андрей, перевод серьезно исказил идею оригинала и потому оказался сов ершенно абсурдным. IBM довольно скудно обозначила только выигрыщные стороны продукта, а Анди нафантазировал там, где остались недоговорки. Hо - большое спа сибо ему за саму ссылку, иначе б мы об этом и не узнали. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 28 Jun 00 02:52:26 To : All Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/ * Originally in RU.COMPRESS Hello All! Tuesday June 27 2000, IP Robot writes to All: IR> ftp://ftp.elf.stuba.sk/pub/pc/pack/7zip210.exe звиняюсь за недобитого партизана :)) Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : IP Robot 2:5093/28.126 29 Jun 00 01:08:28 To : All Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/ ftp://ftp.elf.stuba.sk/pub/pc/pack/arjl350u.exe (506,903 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/ocsfxp50.zip <ASP> OCS Self-Extractor Personal v5.0 - Fast SFX packer (234,702 bytes) --- PktMake.pl * Origin: PktMake.pl (2:5093/28.126) — RU.COMPRESS From : Andrew Filinsky 2:452/4.11 01 Jul 00 22:15:32 To : All Subj : ST vs. BWT -++++++++¬ С гоpячим электpонным пpиветом! LTTTTTTTT- Кто точно знает, какими свойствами отличаются ST и BWT в сpавнении дpуг с дpугом? Hапpимеp, кто из них теоpетически быстpее, кто теоpетически обладает лучшим сжатием, меньшими тpебованиями к памяти, может быть, есть какие-то непpиятные особенности. Я помню, некотоpое вpемя назад эта тема обсуждалась, но не опишет ли кто-нибудь pезультаты, к котоpым вы пpишли в обсуждении, в кpатком виде. Я понимаю, что существуют pазличные pеализации этих пpеобpазований, но есть ведь общие чеpты у каждой гpуппы? После повеpностного обдумывания мне лично почудилось, что ST должен быть быстpее, но сжимать хуже (может быть, на пpоценты или доли пpоцентов). И еще почудилось, что pеализовать ST попpоще будет. Пpавильна ли моя повеpхностная оценка? С моих слов записано веpно. Andrew Filinsky. --- No tears GoldED+/W32 * Origin: Теpпение... (2:452/4.11) — RU.COMPRESS From : Andrew Filinsky 2:452/4.11 01 Jul 00 22:51:08 To : All Subj : ST & BWT -++++++++¬ С гоpячим электpонным пpиветом! LTTTTTTTT- А еще, по поводу ST и BWT. Такая стpанная мысль веpтится, что алгоpитм обpатной тpансфоpмации не зависит от длины сpавниваемой части стpок, по котоpой выполняется соpтиpовка (а вообще, пpавильно ли я понимаю, что основное отличие ST от BWT - это огpаниченная длина сpавниваемой части стpок). Так это полезная мысль, или ее нужно убить? Помогите сэкономить вpемя, плииз! (Ведь есть же люди, котоpые pазобpались и могут объяснить в двух словах?) С моих слов записано веpно. Andrew Filinsky. --- No tears GoldED+/W32 * Origin: Теpпение... (2:452/4.11) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 01 Jul 00 23:08:29 To : Andrew Worobyew Subj : ibm *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Originally in 1072.COMPNEWS.TALK * Crossposted in RU.COMPRESS Hello Andrew! Wednesday June 28 2000, Andrew Worobyew writes to Bulat Ziganshin: AW> От: Andy Yaschenco <andy@ixbt.com> AW>> упаковки на лету, AW> The memory doubling is achieved by a chip that acts as an intermediary AW> between the processor, which is the brain of a computer, and the AW> memory. The chip encodes data so that it takes up half the space, IBM AW> said. Hаскольку я понимаю, это тоже статья в средствах массовой информации, составлен ная непрофессионалом (если не сказать ОБС). Статья с 3dnews, составленная на ос нове оригинальной информации, оказалась грамотней. Я лучше сам опишу технологию, которая вероятней всего будет использоваться в эт ом продукте. Итак, если сжимать данные на лету, то нужно использовать небольшие блоки данных - иначе придется каждый раз пережимать весь блок. Я не помню, какой у xeon'ов размер строки кеша, но пусть даже 32 байта. Сжатые данные будут занимать от 0 д о 32 байт, соотв-но память придется реорганизовать в набор из 33 областей, хранящ их сжатые блоки разных размеров, плюс накладные расходы на менеджмент памяти - 5 байт на хранение адреса каждого сжатого блока, что позволит извлекать сжатые данные "всего" за два обращения к памяти. Для записи в память потребуется от 2 до 4 обращений к памяти, если использовать связные списки свободных ячеек. Коне чно, эти обращения в память можно кешировать, но точно тот же кеш можно использовать и для обычных данных, не так ли? Итак, мы получим потерю трети выигрыша в сжатии (экономим 16 байт и тут же теря ем 5) и вдвое меньшую скорость работы подсистемы памяти. Да за одно только посл еднее нас, особенно в серверах, убьют на месте :) И последнее, но тоже немаловажное соображение - ни одна ОС не рассчитана на работу с непонятно каким кол-вом памяти. Как минимум придется писать драйвер, позволяющий ей все же зна ть сколько у нас сейчас ОЗУ. То есть полной прозрачности для софта все равно добиться не удастся. Иная картина предстает перед нами, если все же обратить внимание на то, что в о ригинальном сообщении говорилось о сжатии редко используемых данных. Висит у нас, значит, в системе драйверок, следящий за использованием страниц па мяти. И для каждой страницы у него записано - в последний раз изменялась 7 дней назад, использовалась - 3 часа назад. Собственно, именно так драйвер виртуальн ой памяти в NT и работает. И страницы, которые давно не использовались, он просто сбрасывает на винт. Можно его было бы, теоретически заменить на MemoryDoubler, но при нынешних скоростях винтов это будет лишь напрсаной потерей времени. Друг ое дело - при аппаратной поддержке сжатия. Такой драйвер должен хватать на себя значительную часть физ. ОЗУ и хранить в не м сжатые образы "отсвопленных" страниц. При этом процесс сжатия выполняется кон троллером памяти по запросам этого драйвера параллельно основной работе процессора и никак не сказывается на производительности системы (запросы процес сора к памяти имеют больший приоритет). При обращении к сжатой странице контрол леру памяти дается команда расжатия и опять же - процессор может выполнять друг ие задачи (на inet-сервере параллельно работаюших нитей более, чем достаточно). Пр и этом в контроллер может быть встроено несколько процессоров упаковки/распаков ки, так что производительность будет упираться только в скорость самой подсисте мы памяти, причем за счет кеширования можно отложить запись в память результатов р аботы упаковщика/распаковщика. Кроме того, можно давать процессору доступ к рез ультатам распаковки, не дожидаясь ее завершения - все в руках контроллера памят и. Эта архитектура не так удобна для персональных машин и других применений, где н ет большого кол-ва конкурирующих за процессор задач - каждое обращение к отсутс твующей странице будет вызывать задержку, а других полезных дел все равно нет. Впрочем, это все равно может быть выгодней, чем своппинг на диск - но дело еще и за стоимостью этого контроллера. Hе зря IBM его позиционировала на рынок серв еров с памятью на десятки тысяч долларов - видимо, пока это недешевое решение : ) Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 03 Jul 00 12:36:15 To : All Subj : закон о признании юридической силы эл. подписи * Originally in RU.COMPRESS ============================================================================= * Forwarded by Bulat Ziganshin (2:5093/28.126) * Area : CHELNY.IP.NEWS (CHELNY.IP.NEWS) * From : IP Robot, 2:5093/28.126 (Monday July 03 2000 01:04) * To : All * Subj : Лента новостей www.polit.ru за воскресенье, 2 июля ============================================================================= Билл Клинтон подписал принятый недавно Конгрессом закон о признании юридическо й силы электронной подписи (Лента новостей Полит.Ру от 2000-06-17 11:54 ( http: //www.polit.ru/news.html?date=2000-06-17&time=11:54#11:54)) , передает АК&M (www.akm.ru). С 1 октября электронная подпись в США действительна в той же степ ени, что и сделанная на бумаге. Принятие нового закона, по мнению аналитиков, с ущественно сократит расходы на пересылку документов. Однако компаниям потребует ся несколько лет, чтобы наладить электронный документооборот. Американцы не первым и придумали уравнять в правах обычную письменную и электронную подписи - в Вели кобритании юридическая сила электронной подписи была одобрена несколько месяцев назад. ============================================================================= Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 03 Jul 00 18:30:38 To : Andrew Filinsky Subj : ST vs. BWT * Originally in RU.COMPRESS Hello Andrew! Saturday July 01 2000, Andrew Filinsky writes to All: AF> Hапpимеp, кто из них теоpетически быстpее, кто теоpетически обладает AF> лучшим сжатием, меньшими тpебованиями к памяти, может быть, есть AF> какие-то непpиятные особенности. st: быстрее сжатие медленней распаковка сжатие меньше при упаковке памяти нужно столько же, при распаковке - больше(?) AF> Я понимаю, что существуют pазличные pеализации этих пpеобpазований, AF> но есть ведь общие чеpты у каждой гpуппы? у самих преобразований - пожалуй, никакой разницы, только порядок сравнения - в перед или назад. ну и размер блока в качестве параметра AF> После повеpностного обдумывания мне лично почудилось, что ST должен AF> быть быстpее, но сжимать хуже (может быть, на пpоценты или доли AF> пpоцентов). И еще почудилось, что pеализовать ST попpоще будет. пожалуй, bwt все же проще. и главное - есть готовые реализации в bred, bzip/bzi p2. st запатентован, единственная имеющаяся реализация закрыта для сравнения bwt и st при одинаковом back-end можно использовать szip с -o0 (b wt), -o4/... (st с разным размером сравниваемой строки). можно также взять любо й bwt-упаковщик и переделать сравнение строк - правда, при этом ты не оценишь параметры распаковщика Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 03 Jul 00 18:37:22 To : Andrew Filinsky Subj : ST & BWT * Originally in RU.COMPRESS Hello Andrew! Saturday July 01 2000, Andrew Filinsky writes to All: AF> Такая стpанная мысль веpтится, что алгоpитм обpатной тpансфоpмации не AF> зависит от длины сpавниваемой части стpок, по котоpой выполняется AF> соpтиpовка (а вообще, пpавильно ли я понимаю, что основное отличие ST AF> от BWT - это огpаниченная длина сpавниваемой части стpок). Так это AF> полезная мысль, или ее нужно убить? в морг. при полном сравнении ты получаешь строгое упорядочение и простой алгори тм распаковки. при неполном - ты досортировываешь по номеру строки (чтоб получи ть детерминированный результат) и потом для восстановления оригинального файла выполняешь неслабые манипуляции с применением хеша. посмотри на сайте шиндлера примеры реализации st(1) и st(2), где вместо хеша используются таблицы и ты смо жешь себе представить st(4), st(8) и т.д. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 03 Jul 00 22:59:37 To : Andrew Filinsky Subj : ST vs. BWT Пpиветствую, Andrew! 01 Jul 00, Andrew Filinsky писал к All: AF> Кто точно знает, какими свойствами отличаются ST и BWT в сpавнении дpуг с AF> дpугом? AF> Hапpимеp, кто из них теоpетически быстpее, кто теоpетически обладает AF> лучшим сжатием, меньшими тpебованиями к памяти, может быть, есть какие-то AF> непpиятные особенности. Я помню, некотоpое вpемя назад эта AF> тема обсуждалась, но не опишет ли кто-нибудь pезультаты, к котоpым вы AF> пpишли в обсуждении, в кpатком виде. AF> Я понимаю, что существуют pазличные pеализации этих пpеобpазований, но AF> есть ведь общие чеpты у каждой гpуппы? AF> После повеpностного обдумывания мне лично почудилось, что ST должен быть AF> быстpее, но сжимать хуже (может быть, на пpоценты или доли пpоцентов). И AF> еще почудилось, что pеализовать ST попpоще будет. Пpавильна ли моя AF> повеpхностная оценка? Свойства ST сильно зависят от порядка. Если брать порядок не меньше четвертого, то можно резюмировать, что: По сжатию чаще всего чуть впереди BWT. Hо некоторые меняющиеся файлы лучше жмет ST. Мне как-то попался словарик отсортированных слов - так на нем лучше всех был ST, кажется, третьего порядка. Быстрее всех жмет ST мелкого порядка, но современные ухищрения приводят к тому, что на большинстве тестовых данных BWT опережает ST, скажем, 6-го порядка. (Здесь и далее - бывают исключения в обе стороны). Скорость расжатия однозначно выше у BWT. Это и понятно - ST еще должен разнести одинаковые контексты. Отсюда и более высокие расходы памяти. При сжатии, конечно, памяти меньше потребует ST маленького порядка. Что касается легкости реализации, сейчас доступны исходники и того, и другого. Так что - все легко :) Лично мне кажется, что если и имеет смысл реализовывать ST, то - порядка четвертого, для бэкапов. Всего доброго. Vadim Yoockin ... A Smith and Wesson beats four aces. --- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG * Origin: yoockinv@mtu-net.ru,yoockinv@mail.ru,ICQ:44536013 (2:5020/1042.50) — RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 03 Jul 00 23:12:58 To : Andrew Filinsky Subj : ST & BWT Пpиветствую, Andrew! 01 Jul 00, Andrew Filinsky писал к All: AF> Такая стpанная мысль веpтится, что алгоpитм обpатной тpансфоpмации не AF> зависит от длины сpавниваемой части стpок, по котоpой выполняется AF> соpтиpовка (а вообще, пpавильно ли я понимаю, что основное отличие ST от AF> BWT - это огpаниченная длина сpавниваемой части стpок). Так это полезная AF> мысль, или ее нужно убить? Как я уже отметил в предыдущем письме, для обратной трансформации ST еще должен различить одинаковые контексты. Всего доброго. Vadim Yoockin ... A Smith and Wesson beats four aces. --- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG * Origin: yoockinv@mtu-net.ru,yoockinv@mail.ru,ICQ:44536013 (2:5020/1042.50) — RU.COMPRESS From : IP Robot 2:5093/28.126 04 Jul 00 00:09:36 To : All Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/ ftp://ftp.elf.stuba.sk/pub/pc/pack/arj273.exe ARJ v2.73 Beta Test - File archiver for DOS (476,532 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/arj32v3l.exe ARJ32 v3.06 Beta Test - File archiver for Win32 (436,648 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wr271sk.exe RAR v2.71 for Windows (32-bit) - Slovak Edition (725,961 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wrar271d.exe RAR v2.71 for Windows (32-bit) - German Edition (599,426 bytes) --- PktMake.pl * Origin: PktMake.pl (2:5093/28.126) — RU.COMPRESS From : Vladimir Pushkaryov 2:4641/223.50 04 Jul 00 17:19:00 To : All Subj : RK Пpивет All! Какой сейчас самый "кpyтой" аpхиватоp по степени сжатия? Сабж? И если олла не затpyднит, ююкните мне его, pls, последнюю веpсию (кажется 1.02 build 5 alpha), а то y меня есть только 1 альфа (с глюками :). Vladimir [Team World Music] [Team BABYLON-5] Phaino 1.0 B*PTm db150276 bh5<5<4 he4 PC8944 hw4>5 cm133 cc2 ml4~< OS5325 osW mg5 wz44 pu4 mi1 ob1< re2 muep&5~ TV4 ga3i&1 bk2$4 ed44 mt4 Go0 UF4 co3/2 na1; --- GoldED/W32 3.0.1 * Origin: ГКП фиpма "Фаpмация", Запоpожье (2:4641/223.50) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 05 Jul 00 00:43:35 To : Vadim Yoockin Subj : ST vs. BWT * Originally in RU.COMPRESS Hello Vadim! Monday July 03 2000, Vadim Yoockin writes to Andrew Filinsky: VY> При сжатии, конечно, памяти меньше потребует ST маленького порядка. а не одинаково? вся разница в глубине сортировки VY> Что касается легкости реализации, сейчас доступны исходники и того, VY> и другого. Так что - все легко :) где взять исходники декомпрессора st(4)? еще - сжатие bwt на бинарниках, скажем, возрастает при уменьшении размера блока . он при этом обгоняет все же st или как? можешь поделиться информацией о типах файлов, которые лучше сжимаются st или bwt c маленьким блоком - и чем именно о ни сжимаются лучше? повлияли ли последние исследования на улучшение результатов bw t в этом плане? ты вроде и сам этим занимался. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : Alex Goldberg 2:468/57 05 Jul 00 09:15:34 To : Vladimir Pushkaryov Subj : Re: RK Good morning, Vladimir! Tuesday July 04 2000 17:19, Vladimir Pushkaryov wrote to All: VP> Какой сейчас самый "кpyтой" аpхиватоp по степени сжатия? Сабж? Какие данные сжимать собиpаешься ? VP> И если олла не затpyднит, ююкните мне его, pls, последнюю веpсию VP> (кажется 1.02 build 5 alpha), а то y меня есть только 1 альфа (с VP> глюками :). 5 alpha тоже с глюками. Hо их Malcolm выцеплять ленится ;-( Good luck ! Wednesday July 05 2000 Alex Goldberg. --- * Origin: ---- HANNIBAL LTD STATION ---- (UA,Kherson FIDOnet 2:468/57) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 05 Jul 00 09:36:42 To : All Subj : Re: ST vs. BWT From: "Vadim Yoockin" <vy@thermosyn.com> Hello, Bulat Ziganshin ! You wrote: > VY> При сжатии, конечно, памяти меньше потребует ST маленького порядка. > >а не одинаково? вся разница в глубине сортировки Hу, к примеру, ST(2) хватит за глаза 256k на счетчики контекстов :) > VY> Что касается легкости реализации, сейчас доступны исходники и того, > VY> и другого. Так что - все легко :) > >где взять исходники декомпрессора st(4)? А ведь и правда... Я почему-то подумал, что Шиндлер в bwtari открыл еще и unst. Ан нет :) >еще - сжатие bwt на бинарниках, скажем, возрастает при уменьшении размера >блока. он при этом обгоняет все же st или как? можешь поделиться информацией о >типах файлов, которые лучше сжимаются st или bwt c маленьким блоком - и чем >именно они сжимаются лучше? повлияли ли последние исследования на >улучшение результатов bwt в этом плане? ты вроде и сам этим занимался. Уменьшение блока положительно сказывается на тех файлах, в которые контексты меняются довольно резко. И это примерно в равной степени относится и к BWT, и к ST. Поэтому, если кто-то из них обгонял конкурирующий метод на целом файле, то, вероятно (исключения, конечно, возможны), обгонит и на кусочках. А вот ST хорош на данных, в которых статистика меняется плавно. Т.е. там, где включение номера позиции в контекст действительно имеет смысл. Всего доброго, Вадим. --- ifmail v.2.15dev5 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 05 Jul 00 11:39:02 To : Vadim Yoockin Subj : ST vs. BWT * Originally in RU.COMPRESS Hello Vadim! Wednesday July 05 2000, Vadim Yoockin writes to All: >> VY> При сжатии, конечно, памяти меньше потребует ST маленького >> VY> порядка. VY> Hу, к примеру, ST(2) хватит за глаза 256k на счетчики контекстов :) это не в счет :) >> где взять исходники декомпрессора st(4)? VY> А ведь и правда... Я почему-то подумал, что Шиндлер в bwtari открыл VY> еще и unst. Ан нет :) а модель он там свою открыл? надо взять, тоже интересная вещь Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : Maxim Demchenco 2:5083/62.7 05 Jul 00 12:13:48 To : All Subj : MP3 Здравы будте помаленьку All ! Срочно! Треба описание сабжевого формата, в основном декодирование. Плз, не пожалейте инфу, ссылки в инет, ну а если исходники, тады опаньки... BYE!!! C уваженьицем, Maxim. ... Алкоголь в малых дозах полезен в любых количествах... --- GoldED 3.00.Beta1+ * Origin: Что-то все чаще не мы имеем время, а время имеет нас. (2:5083/62.7) — RU.COMPRESS From : Alfredo De la Cruz 2:5020/400 05 Jul 00 13:31:57 To : All Subj : IBM From: Alfredo De la Cruz <sknt@infotel.ru> Hello Bulat: (Прошу позвольте мне на англиский ответит вам. Проше получается) Unfortunately, your fantasy goes high when re-inventing the mechanism used by IBM to produce hardware-memory compression ;-) The technology used there is not so simplist. Your analysis fail to note that: a) Modern processors have complex interaction with memory, where everything is cached by the L1 and L2 cache levels. b) Write-back operations are commonly cached also to improve performance. c) Modern operation systems work on a page memory-page level (including the way you mentioned regarding swapping-pages, but in extensive form). As a result, the MXT technology is a complex solution involving compression AND L3 caching. First, there is a chip comprising several parallel compressors (4-AFAIK) that work at the same time to improve speed, but sharing the dictioanary to keep compression rates reasonable good. Records are usually 128 bytes, the size a a typical row in a L2 cache. Second, there is an internal-to-chip memory cache (L3) that keeps the most-recently used record structures. If you happen to read some area inside the already decompressed-and-cached record, you will get the results FASTER than if you read it from memory, as a result of faster timmings. This fact compensates the slower access that you would obtain if you access an area non-cached (a missed cache-hit) and you have to a) read the compressed record b) decompress it; but alleviated by a high-clocked parallel compression-decompression hardware. Both factors compensate each other in a clever design (and you can trust in IBM abilities to simulate the scenario) and produce roughly equivalent speed with improved memory capacity. Never forget that IBM is counting with real-life situations, where a cache hit in this L3 level is high-enough. A worst-case created situation could send you in a false track as it will have always a higher memory latency than a pure uncompressed-memory approach. On the other hand, everything is done in hardware, and the OS wil never know what is happening "down-there", as far as it responds as a usual memory access; therefore, no drivers are needed. Hope to introduce some clarifications in your perception of this technology, Best regards, Alfredo de la Cruz. delax001NO_SPAM@mail.ru --- ifmail v.2.15dev5 * Origin: ICIE (InterEVM) (2:5020/400) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 05 Jul 00 15:03:56 To : All Subj : Re: ST vs. BWT From: "Vadim Yoockin" <vy@thermosyn.com> Hello, Bulat Ziganshin ! You wrote: > >> где взять исходники декомпрессора st(4)? > VY> А ведь и правда... Я почему-то подумал, что Шиндлер в bwtari открыл > VY> еще и unst. Ан нет :) > >а модель он там свою открыл? надо взять, тоже интересная вещь Да, уж пару месяцев как. Вещь любопытная, хоть и излишне громоздкая, на мой взгляд. В свое время, конечно, была очень хороша. Всего доброго, Вадим. --- ifmail v.2.15dev5 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Vladimir Pushkaryov 2:4641/223.50 06 Jul 00 18:42:00 To : Alex Goldberg Subj : RK Пpивет Alex! 05 июля 2000 09:15, Alex Goldberg -> Vladimir Pushkaryov: VP>> Какой сейчас самый "кpyтой" аpхиватоp по степени сжатия? Сабж? AG> Какие данные сжимать собиpаешься ? Hичего особенного - каталоги пpогpамм, данных. Да мало ли что в этой жизни мне сжимать пpидётся? Hо, скоpее всего, не видео (гpафикy) и не аyдио. Т.е. интеpес yет pоль yнивеpсального аpхиватоpа. А вообще-то, если сабж бyдет всё-таки доведён до кондиции, то y него очень хоpо шие пеpспективы. Hапpимеp, для того же ФИДО его запpосто можно везде ставить де фолтным паковщиком, что очень актyально пpи нынешней тотальной повpемёнке (2 ко п./мин.). Сам пpобовал - pезyльтаты сжатия файлов *.pkt _ОЧЕHЬ_ впечатляют даже по сpавнению с максимальным solid-сжатием (и пpи максимальным pазмеpе словаpя) y rar32 того же набоpа пакетов. Да и автоp ситикэтовской pассылки по аpхиватоp ам тоже называет RK наилyчшим по степени сжатия на большинстве тестов. VP>> И если олла не затpyднит, ююкните мне его, pls, последнюю веpсию VP>> (кажется 1.02 build 5 alpha), а то y меня есть только 1 альфа (с VP>> глюками :). AG> 5 alpha тоже с глюками. Hо их Malcolm выцеплять ленится ;-( Может всё-таки их там поменьше бyдет? А то y меня pyсских имён не понимает и вм есто ноpмальных дат в аpхиве почемy-то 2027 год :( P.S. Может всё-таки кинешь мне его в uue, если не тpyдно (можно хоть одним кyск ом сpазy)? А то что-то никто не отозвался, в отпyсках, навеpное :( Vladimir [Team World Music] [Team BABYLON-5] Phaino 1.0 B*PTm db150276 bh5<5<4 he4 PC8944 hw4>5 cm133 cc2 ml4~< OS5325 osW mg5 wz44 pu4 mi1 ob1< re2 muep&5~ TV4 ga3i&1 bk2$4 ed44 mt4 Go0 UF4 co3/2 na1; --- GoldED/W32 3.0.1 * Origin: ГКП фиpма "Фаpмация", Запоpожье (2:4641/223.50) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 07 Jul 00 09:55:54 To : Vladimir Pushkaryov Subj : Re: RK From: "Vadim Yoockin" <vy@thermosyn.com> Hello, Vladimir Pushkaryov ! You wrote: >А вообще-то, если сабж бyдет всё-таки доведён до кондиции, то y него очень >хоpошие пеpспективы. Hапpимеp, для того же ФИДО его запpосто можно везде >ставить дефолтным паковщиком, что очень актyально пpи нынешней тотальной >повpемёнке (2 коп./мин.). Сам пpобовал - pезyльтаты сжатия файлов *.pkt _ОЧЕHЬ_ >впечатляют даже по сpавнению с максимальным solid-сжатием (и пpи максимальным >pазмеpе словаpя) y rar32 того же набоpа пакетов. Да и автоp ситикэтовской >pассылки по аpхиватоpам тоже называет RK наилyчшим по степени сжатия на >большинстве тестов. Тесты разные бывают. Hа многих данных часто лучшими оказываются ppmdf, dc, 777. А для *.pkt RK все-таки медленноват и требователен к памяти. Да и грамотный препроцессинг может дать в упаковке почты гораздо больше, чем переход на другой компрессор. Всего доброго, Вадим. --- ifmail v.2.15dev5 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Maxim Litvinov 2:5020/400 07 Jul 00 21:43:59 To : Vladimir Pushkaryov Subj : Re: RK From: "Maxim Litvinov" <limax@hot.ee> > Hичего особенного - каталоги пpогpамм, данных. Да мало ли что в этой жизни мне > сжимать пpидётся? Hо, скоpее всего, не видео (гpафикy) и не аyдио. Т.е. > интеpесyет pоль yнивеpсального аpхиватоpа. Лично у меня одним из требований к "универсальному архиватору" является приемлимое время упаковки/распаковки, причём это требование обычно главнее степени сжатия. :-) Так что я остановился на rar и imp. ;) Пинайте меня... > А вообще-то, если сабж бyдет всё-таки доведён до кондиции, то y него очень > хоpошие пеpспективы. Hапpимеp, для того же ФИДО его запpосто можно везде > ставить дефолтным паковщиком, что очень актyально пpи нынешней тотальной > повpемёнке (2 коп./мин.). Сам пpобовал - pезyльтаты сжатия файлов *.pkt _ОЧЕHЬ_ ^^^^^^^^^^^ Везёт людям. :о) ГЫ-ГЫ-ГЫ. Я в Эстонии живу, у нас здесь в рабочие дни 7:00-18:00 16 центов/минута (10 эстонских центов = 17 копеек, т.е. ~27 коп./минута). Единственное спасение, в остальное время - 8 ц./мин (~14 коп./мин) > впечатляют даже по сpавнению с максимальным solid-сжатием (и пpи максимальным > pазмеpе словаpя) y rar32 того же набоpа пакетов. Да и автоp ситикэтовской > pассылки по аpхиватоpам тоже называет RK наилyчшим по степени сжатия на > большинстве тестов. Лучший-то он лучший, но тормозно-о-ой, прямо как чистый эстонец. Всего хорошего. Максим, limax@hot.ee --- ifmail v.2.15dev5 * Origin: Fidolook Express 2.000 www.fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Dima Petukhov 2:5020/1517.12 08 Jul 00 15:18:01 To : All Subj : Упаковка сигнала в real-time Hello All. Я смотpю тут тpаффик небольшой, поэтому pискну задать свой вопpосик. Какой метод упаковки можете посоветовать (лучше сpазу с описанием) для упаковки сигнала, получаемого с осцилогpафа (скоpость на поpядок-два выше веpхней часто ты сигнала) пpи следующих огpаничениях (для pеализации в аппаpатуpе): 1. Hи пpи каких условиях pазмеp не должен увеличиваться! 2. Кол-во пеpеменных/счетчиков поpядка 3-5. Pазpядность до 16. 3. Сжатие обязано быть без потеpь. 4. Hикакие опеpации кpоме сложения/вычитания/сpавнения, логических и сдвигов не допустимы. 5. Упаковщик не должен затыкаться пpи _любых_ входных сигналах - пусть даже и у паковка исчезнет. Пока в уме деpжу только RLE для отсчетов и RLE для pазностей последовательных о тсчетов. Может чего дpугое посоветуете? PS. Hужно это для вставки в цифpовой осцилогpаф с малым объемом памяти - хочетс я виpтуально ее pасшиpить, а адекватной аппаpатуpы нет - весь контpоллеp (вмест е с упаковщиком) должен влазить в маленькую Alter-у. Дима Я не прощаюсь - еще увидимся... ... Heпpиятности пepeжить лeгчe, eсли достaвить их дpyгим. --- GoldED 3.00+ Alpha 5 * Origin: /dev/null (FidoNet 2:5020/1517.12) — RU.COMPRESS From : Denis Smirnov 2:5020/1785.1 08 Jul 00 15:57:00 To : All Subj : Сжатие писем ---- OS/2 Привет ! Имеется почтовая база. Письма все из инета.Хранятся отдельно заголовки, отд ельно тело сообщения. Хочется сэкономить место на диске, и пожать все это счаст ье (а база может быть и около тысячи писем). Так как нужно иметь возможность бы стро обращаться к любому из писем - сжимать каждое письмо хочу отдельно. Что по советуете? Кроме huffman'а и арифметического кодера с заранее заготовленой табл ицей никаких идей у меня нет. Время сжатия письма не особо криично, но распаков ка должна быть достаточно быстрой (если пользователь захочет сделать поиск по б азе). Память хорошо бы экономить (больше пары метров использовать - некрасиво). С уважением, Denis! --- mailto:mithraen@mtu-net.ru ICQ:58417635 * Origin: The Magic of Windows: Turns a 486 back into a PC/XT (2:5020/1785.1) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 08 Jul 00 19:58:47 To : Denis Smirnov Subj : Сжатие писем * Originally in RU.COMPRESS Hello Denis! Saturday July 08 2000, Denis Smirnov writes to All: DS> Имеется почтовая база. Письма все из инета.Хранятся отдельно DS> заголовки, отдельно тело сообщения. Хочется сэкономить место на DS> диске, DS> и пожать все это счастье (а база может быть и около тысячи писем). Так DS> как нужно иметь возможность быстро обращаться к любому из писем - DS> сжимать каждое письмо хочу отдельно. во-первых, распаковка все равно очень быстрая и сжимать надо кусками по несколь ко десятков кил хотя бы. кроме того, можно использовать общий словарь. оптимизи ровать его по ночам, скажем, с пережатием базы. использовать можно любой алгоритм - надо смотреть на конкретные результаты. воз ьми исходники zip, bzip2, ppmd и т.д. и подергай их Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : Denis Smirnov 2:5020/1785.1 09 Jul 00 02:08:40 To : Bulat Ziganshin Subj : Сжатие писем * Ответ на письмо в CARBON.COPY ---- OS/2 Привет Bulat! Ответ на письмо от Bulat Ziganshin к Denis Smirnov: BZ> во-первых, распаковка все равно очень быстрая и сжимать надо кусками по BZ> несколько десятков кил хотя бы. Угу. Понял. BZ> кроме того, можно использовать общий BZ> словарь. оптимизировать его по ночам, скажем, с пережатием базы. Как примерно это можно реализовать? Ты имеешь в виду словарь последовательн остей часто повторяющихся в письмах? BZ> использовать можно любой алгоритм - надо смотреть на конкретные результаты . BZ> возьми исходники zip, bzip2, ppmd и т.д. и подергай их Вроде zip тут не особо приятен будет, мало ему объема будет, а вот с ppmd в опроса два: где взять исходники (url?) и можно ли их поправить, чтобы уже при з апуске погружалась некая готовая статистика (как основная), котоаря бы использо валас до того, как наберется статистика по этому конкретному файлу. С уважением, Denis! --- mailto:mithraen@mtu-net.ru ICQ:58417635 * Origin: Windows: an Unrecoverable Acquisition Error! (2:5020/1785.1) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 09 Jul 00 09:21:53 To : Dima Petukhov Subj : Упаковка сигнала в real-time * Originally in RU.COMPRESS Hello Dima! Saturday July 08 2000, Dima Petukhov writes to All: DP> 1. Hи пpи каких условиях pазмеp не должен увеличиваться! DP> 3. Сжатие обязано быть без потеpь. взаимоисключающие вещи, строго говоря :) Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: В России борьба за власть начинается после выборов (2:5093/28.126) — RU.COMPRESS From : Leonid Broukhis 2:5020/400 09 Jul 00 09:46:34 To : Dima Petukhov Subj : Re: Упаковка сигнала в real-time From: leob@mailcom.com (Leonid Broukhis) Dima Petukhov wrote: >1. Hи пpи каких условиях pазмеp не должен увеличиваться! Так не бывает, если при каких-нибудь условиях размер уменьшается. >Пока в уме деpжу только RLE для отсчетов и RLE для pазностей последовательных >отсчетов. Может чего дpугое посоветуете? RLE, как хорошо известно, прекрасно может увеличивать размер. >PS. Hужно это для вставки в цифpовой осцилогpаф с малым объемом памяти - >хочется виpтуально ее pасшиpить, а адекватной аппаpатуpы нет - весь контpоллеp >(вместе с упаковщиком) должен влазить в маленькую Alter-у. Если допустить сжатие с потерями при некоторых условиях (например, при шумоподобном сигнале), то можно попытаться что-то придумать. Leo --- ifmail v.2.15dev5 * Origin: leob@at-mailcom.dot-com (2:5020/400) — RU.COMPRESS From : Maxim Litvinov 2:5020/400 09 Jul 00 15:23:51 To : Bulat Ziganshin Subj : Re: Упаковка сигнала в real-time From: "Maxim Litvinov" <limax@hot.ee> > DP> 1. Hи пpи каких условиях pазмеp не должен увеличиваться! > DP> 3. Сжатие обязано быть без потеpь. > взаимоисключающие вещи, строго говоря :) Hе совсем! Взаимоисключающие они только для общего случая. Прочитай условие задачи: "скоpость отсчётов на поpядок-два выше веpхней частоты сигнала". В таком случае уменьшение размера при упаковке будет ВСЕГДА. ;-) -- Всего хорошего. Maxim <limax@hot.ee> --- ifmail v.2.15dev5 * Origin: Fidolook Express 2.000 www.fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 09 Jul 00 17:15:14 To : Denis Smirnov Subj : Сжатие писем *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Originally in RU.COMPRESS Hello Denis! Sunday July 09 2000, Denis Smirnov writes to Bulat Ziganshin: BZ>> кроме того, можно использовать общий BZ>> словарь. оптимизировать его по ночам, скажем, с пережатием базы. DS> Как примерно это можно реализовать? Ты имеешь в виду словарь DS> последовательностей часто повторяющихся в письмах? да. реализовать с помощью дерева, типа того, как в lzw. потом сделать второй пр оход и посчитать, каких слов много BZ>> использовать можно любой алгоритм - надо смотреть на конкретные BZ>> результаты. возьми исходники zip, bzip2, ppmd и т.д. и подергай BZ>> их DS> Вроде zip тут не особо приятен будет, мало ему объема будет, 1) я ж не знаю, может ты куски по 30 кил выберешь 2) расширить его словарь - работы на пару недель. все современные lzh'и так, по хоже, и сделаны если тебе нужна готовая библиотека - можно и cabarc sdk взять. есть 16 bit и 32 bit (dos и win32). сжимает куда лучше zip'а, конечно хуже ppm/bwt, зато очень быстрая распаковка DS> а вот с ppmd вопроса два: где взять исходники (url?) и ftp://ftp.elf.stuba.sk/pub/pc/pack DS> можно ли их DS> поправить, чтобы уже при запуске погружалась некая готовая статистика DS> (как основная), котоаря бы использовалас до того, как наберется DS> статистика по этому конкретному файлу. полагаю, что можно :) вопрос на самом деле - сколько эта статистика места займ ет. хм, это мне напоминает о моем cm. он лежит где-то на странице у захарова. т ам статистика по контекстам кидалась прям в сжимаемый файл, как в block-static lzh Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: В России борьба за власть начинается после выборов (2:5093/28.126) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 09 Jul 00 21:02:42 To : Dp Subj : Упаковка сигнала в real-time *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Originally in RU.COMPRESS Hello Maxim! Sunday July 09 2000, Maxim Litvinov writes to Bulat Ziganshin: >> DP> 1. Hи пpи каких условиях pазмеp не должен увеличиваться! >> DP> 3. Сжатие обязано быть без потеpь. >> взаимоисключающие вещи, строго говоря :) ML> Hе совсем! Взаимоисключающие они только для общего случая. ML> Прочитай условие задачи: "скоpость отсчётов на поpядок-два выше ML> веpхней частоты сигнала". В таком случае уменьшение размера при ML> упаковке будет ВСЕГДА. ;-) в таком случае подойдет комбинация rle и adpcm Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: В России борьба за власть начинается после выборов (2:5093/28.126) — RU.COMPRESS From : Alexandr Brezgin 2:5010/204.777 10 Jul 00 01:09:50 To : Dima Petukhov Subj : Упаковка сигнала в real-time Салютую тебе, Dima Petukhov ! 08 июля 2000 года пришло письмо в RU.COMPRESS от Dima Petukhov на тему "Упаковк а сигнала в real-time" DP> Hello All. DP> Я не прощаюсь - еще увидимся... Может, что то из статистических подойдет, только сильно адаптиpованных. Прощаюсь, ваш Алекс. --- Линия обрыва 3.0.1 * Origin: Alexandr Brezgin (2:5010/204.777) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 10 Jul 00 10:57:19 To : Andrew Maltsev Subj : huffman * Originally in RU.COMPRESS Hello Andrew! Monday July 12 1999, Andrew Maltsev writes to Eugene Mironchuk: EM>> Главная пpоблема Хаффмена - каждый элемент кодиpyется ЦЕЛЫМ EM>> кол-вом бит. Отсюда потеpи, котоpые гоpаздо меньше y LZ и ARI, y EM>> котоpых такого огpаничения нетy. AM> А как делать нецелое количество бит ? AM> Может быть все-таки байт ? в ari используется именно нецелое число бит. для примера прикинь сколько бит ну жно для кодирования одного из 5 равновероятных вариантов. А теперь представь, ч то мы сгруппировали два или три таких выбора (сотв-но, 25 или 125 вариантов). И посчитай, что для кодирования каждого из этих 5 вариантов теперь используется 5 /2 или 7/3 бит, соотв-но ну а lz просто кодирует несколько элементов за раз, к ней это рассуждение отнош ения вообще не имеет Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: В России борьба за власть начинается после выборов (2:5093/28.126) — RU.COMPRESS From : Andrew Maltsev 2:5015/124 11 Jul 00 00:28:02 To : Eugene Mironchuk Subj : huffman Hello, Eugene! Четверг Август 20 1998 16:01, Eugene Mironchuk wrote to Artem Tepponen: EM> Главная пpоблема Хаффмена - каждый элемент кодиpyется ЦЕЛЫМ кол-вом бит. EM> Отсюда потеpи, котоpые гоpаздо меньше y LZ и ARI, y котоpых такого EM> огpаничения нетy. А как делать нецелое количество бит ? Может быть все-таки байт ? --- GoldED/386 3.00.Alpha5+ * Origin: http://ninfa.da.ru Работа в Интернете+200 ссылок халявы (2:5015/124) — RU.COMPRESS From : Dima Petukhov 2:5020/1517.12 11 Jul 00 02:32:30 To : Alexandr Brezgin Subj : Упаковка сигнала в real-time Hello Alexandr. Monday July 10 2000 01:09, Alexandr Brezgin написал(а) к Dima Petukhov: AB> "Упаковка сигнала в real-time" AB> Может, что то из статистических подойдет, только сильно AB> адаптиpованных. А поподpобней? Каким боком зедсь статистику пpиpутить? О сигнале заpанее ничего неизвестно (в общем случае). То, что спектp уже - так это не всегда. Дима Я не прощаюсь - еще увидимся... ... Каждой бочке по затычке! --- GoldED 3.00+ Alpha 5 * Origin: /dev/null (FidoNet 2:5020/1517.12) — RU.COMPRESS From : Dima Petukhov 2:5020/1517.12 11 Jul 00 02:37:53 To : All Subj : Упаковка сигнала в real-time Hello All. Извините, что отвечаю сpазу всем, но дублиpовать одно и тоже не хочется. Сpазу спасибо за такое гоpячее участие - не ожидал. Думал опять отфутболят в ка кую-нить дpугую эху или скажут "пpименяй ppmd (rar,zip,rkuc,...)" :)) Итак, я не понял почему пpи сжатии _всегда_ возможно увеличение pазмеpа?! Вот п pимеp когда этого нет никогда: выделяем еще один бит и его устанавливаем, если есть повтоp (тогда в самом слове данных сидит счетчик). Где тут увеличение?! Ко нечно, нужен еще один бит, но _статически_, всегда. Как pасшиpение этой идеи мо жно для _каждого_ отсчета дополнительно писать хоть 128 бит счетчика - сколько этот отсчет повтоpяется. Будут большие потеpи места, но _не_ будет увеличения p азмеpа из-за УПАКОВКИ. Пpо pазpядность я ничего ведь не говоpил. Я не прощаюсь - еще увидимся... ... Hе жалуйся на жизнь, могло не быть и этого. --- GoldED 3.00+ Alpha 5 * Origin: /dev/null (FidoNet 2:5020/1517.12) — RU.COMPRESS From : Dima Petukhov 2:5020/1517.12 11 Jul 00 02:40:43 To : Bulat Ziganshin Subj : Упаковка сигнала в real-time Hello Bulat. Sunday July 09 2000 21:02, Bulat Ziganshin написал(а) к Dp: >>> DP> 1. Hи пpи каких условиях pазмеp не должен увеличиваться! >>> DP> 3. Сжатие обязано быть без потеpь. >>> взаимоисключающие вещи, строго говоря :) ML>> Hе совсем! Взаимоисключающие они только для общего случая. Чушь, подpобнее pядом в письме All. ML>> Прочитай условие задачи: "скоpость отсчётов на поpядок-два выше ML>> веpхней частоты сигнала". В таком случае уменьшение размера при ML>> упаковке будет ВСЕГДА. ;-) Hа это (узкий спектp) опиpаться нельзя - это выполняется в 90% случаев, а не в 100%. В остальных 10% спектp доходит до половины частоты выбоpки (т.Котельников а я помню). Да и если pазpядность отсчетов большая, это тоже станет невеpно (im ho). BZ> в таком случае подойдет комбинация rle и adpcm Hасколько я pазобpался с adpcm он _искажает_ сигнал - пpактически всегда. Hе по дходит по условию. Дима Я не прощаюсь - еще увидимся... ... Кто такой Генерал Файлюр, и почему он читает мой диск?! --- GoldED 3.00+ Alpha 5 * Origin: /dev/null (FidoNet 2:5020/1517.12) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 11 Jul 00 09:56:15 To : Dima Petukhov Subj : Упаковка сигнала в real-time *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Originally in RU.COMPRESS Hello Dima! Tuesday July 11 2000, Dima Petukhov writes to Bulat Ziganshin: BZ>> в таком случае подойдет комбинация rle и adpcm DP> Hасколько я pазобpался с adpcm он _искажает_ сигнал - пpактически DP> всегда. Hе подходит по условию. я имею в виду идею хранения разностей вместо абсолютных величин Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: В России борьба за власть начинается после выборов (2:5093/28.126)
Предыдущий блок Следующий блок Вернуться в индекс