maxcompress.narod.ru

[squxe]

I made my own testset for archivers.
maxcompress.narod.ru

[JohanDeBock]

Showing some suggestion of the speed is a good idea. I also did it in my speed tables but I will have to redo the complete testing due to my new core 2 duo laptop.

I would suggest to make a much larger dataset and drop things like mp3 and jpg.
Also make multi-file datasets where solid compression schemes can show off their power, look at my Half-Life Mod test.
http://uclc.info/half-life_mod_compression_test.ht m

And please for the love of science drop Infima!!

[Bulat Ziganshin]

???? ????????, ??? ?????????? freearc ???? 7zip-??????. ????????, ????? ???????????? ???-?? ? ?????? -m7. ????? ????, ??? ????????? ???????? ???????? ?????? ?? ?????????? ?????, ??? ??? ???? ? ????????? ?????? ????? ??????????, ??????, txt - ?????? ?? ????? ????????

? ????????????? ? ?????? ???????? infim'?, ??????? ?????? ????? ??????????? ????????

[encode]

А я бы посоветовал сменить набор, на что-то более большое, скажем на какую-нибудь современную игру а-ля UT2004. А то таких сингл-файл тестов полным полно.

[JohanDeBock]

Can somebody translate

[encode]

I wonder why results of freearc is worser compared to the 7-zip. Probably, better use something like -m7. In addition, my program chooses algorithm by file extension, therefore if textual file will have a "txt" extension, compression will be higher.

I also suggest to kick out Infima from the test - its just a set of stolen software

[encode]

And I suggest to change the test set to something bigger. For example, to some modern game, like UT2004. Just too many single-file benchmarks.

[JohanDeBock]

Thanks

[encode]

[Black_Fox1]

I am surprised that Infima actually works, I never succeeded in even running it I also recommend testing WinRK 2.1.6, it's better than 3.0.3 for some files.
What do the orange-coloured cells mean? Second position?

[squxe]

What do the orange-coloured cells mean? Second position?

yes

[Bulat Ziganshin]

>For example, to some modern game, like UT2004

and i will prefer test that don't include MM data because they are rare imho in real life and apply our work in wrong direction. example is MFC test where RAR win +7% by MM algorithms

(although my english is terrible, some readers prefer to read it instead of seeing russian text. btw, http://babel.altavista.com/translate.dyn gives the following translation for my first post:

it astonishes me, which results freearc worse than 7zip-ovskix. is probable, it is better to use something in the region of -.m". furthermore, my program selects the algorithm of compression on the expansion of file, so that if it is file it yuudet expansion, let us say in text, txt - compression from this will win and I am joined to svoyetu to throw out infim'u, which it is simple the collection of the stolen programs

can anyone understand this?

[JohanDeBock]

and i will prefer test that dont include MM data because they are rare imho in real life and apply our work in wrong direction.

They are all but rare and they are generally much bigger that the binary and text stuff.
They are mostly embedded in other files and that makes the simple extension checking useless. Checkout UHARC for a good generic MM data compressor.

[Bulat Ziganshin]

you mean that games is the most popular data to compress?

the question is not how to develop such algorithm, but whether it is useful for many users. in which files MM data compressible by uharc may be embedded? i'm all ears

[LovePimple]

can anyone understand this?

My Russion is not very good, but that translation is worse!

[JohanDeBock]

you mean that games is the most popular data to compress?

No, I mean that the amount of non compressed multimedia data is not to be underestimated.
And games are a fine example, but also in applications.

the question is not how to develop such algorithm, but whether it is useful for many users. in which files MM data compressible by uharc may be embedded? im all ears

You should ask Uwe Herklotz

[Bulat Ziganshin]

why you ask for MM compression if you even don't know why *you* need it?

[squxe]

it astonishes me, which results freearc worse than 7zip

I use files with extensions.
May be because freearc doesnt use ultra mode for lzma?

[Bulat Ziganshin]

try -m7. afaik, freearc's settings even more agressive than 7zip's ones. the only position when i should lose is exe/dll compression

although, try -m7x too

[JohanDeBock]

why you ask for MM compression if you even dont know why *you* need it?

Ah sorry I thought you asked how to develop it

wav, bmp embedded in exe, textures of games, general resource files of games, ISOs, TARs, ...

[encode]

Don't spread the dark energy, Bulat!

[Bulat Ziganshin]

encdode, ? ??? ????? ????? ??? ?????? ? ?? ?? ????? ??????? ??????, ??? ??? ????? ????????? ?????? ? ?????????? ??????. ??? ??? ??? ?????????? ????? - ???????? ????????. ???? ???????? ?????????? ?????? ?????? ???????? - ?? ????? ?? ??? ? ???????. ????-?? ???? ??????? ? ????, ??? ???? ??????? - ??? ???? ?????????? ?????? ? ???????????? ?? ??? ?????????????? ?????? ? ???????????? ???????????. ? ????? ??????????? ????????? ???? ????????? ?? ????????????? - ? ?????? ? ? ??????????? ?????

>Ah sorry I thought you asked how to develop it

i asked both questions - why you think that you need it and how to add it. if you will point me to *easy* way to add MM to freearc, i will do it, despite i consider it as almost useless. if you will convince me that it is widespread, i will work harder in order to implement it

>wav, bmp embedded in exe, textures of games, general resource files of games, ISO's, TAR's, ...

well, i belive that games may contain uncompressed sound data. but, besides it - why you think that exe/iso/tar files usually contains uncompressed multimedia information? can you try to compress some exe/iso/tar files with and without MM filters and check your assumption?

[encode]

Да, на самом-то деле это так Булат. Многие слишком привязаны к бенчмаркам а ля максимум компрешн - которые иногда врут.

Edit:
ММ сжатие - это просто рекламный трюк

[JohanDeBock]

well, i belive that games may contain uncompressed sound data. but, besides it - why you think that exe/iso/tar files usually contains uncompressed multimedia information? can you try to compress some exe/iso/tar files with and without MM filters and check your assumption?

4,323,069 tst-mm+.uha
4,606,815 tst-mm-.uha
12,975,616 mplayer.exe

[Uwe Herklotz]

4,323,069 tst-mm+.uha
4,606,815 tst-mm-.uha
12,975,616 mplayer.exe

However, this doesnt actually mean that there is real multimedia information present (i.e. something like image, audio, video data). For generic approach so-called multimedia filters should not assume any specific file types (e.g. wav or bmp) but deal with specific data structures. UHARC checks if data could be compressed better with applying delta-filters on 1/2/3/4-byte sequences. This could be embedded media resources, for executables this covers relocation tables or similar structures as well.

[Bulat Ziganshin]

unlike uharc, rar allows to disable selectively audio, rgb and delta (table) compression using -mca-, -mcc- and -mcd- switches, respectively. Johan, can you recheck using these switches?

btw, delta compression was our (me and Dima Bortoq) invention it is among my nearest goals for freearc, too. in my own tests, it imrove EXE/DLL compression at about 3.5% (and i made this test on hundreds megabytes installed in my Program Files)

ps: i just conducted the same test again. results are:
91,547,693 bytes - rar a a -r *.exe *.dll
91,868,694 bytes - rar a a -r *.exe *.dll -mcc- -mca-
93,898,427 bytes - rar a a -r *.exe *.dll -mcc- -mca- -mcd-
94,632,687 bytes - rar a a -r *.exe *.dll -mcc- -mca- -mcd- -mct-
95,706,290 bytes - rar a a -r *.exe *.dll -mcc- -mca- -mcd- -md2048

(823 files of total 317.111.637 bytes)

The last 2 results are rather interesting. Both use ~32 mb of memory for compression (unlike previous tests that use ~64 mb). 4th command uses whole 32 mb for lzh compression with 4 mb dictionary, while 5th command uses half of this memory for lzh:2mb and half - for ppmd compression. you can see that first strategy is much better for executable files

"Best practical compressors" shows on this test the following results:
7z │ 76,748,667
arc│ 77,285,882
arc│ 78,550,626 without REP preprocessor
uha│ 80,104,513

It's interesting to note that REP preprocessor used in FreeArc, significanltly reduces amount of work for LZMA algorithm:
317.111.637 => 235.045.360 bytes. Ratio 74.1%

Speed improvement was about 10%

[JohanDeBock]

However, this doesnt actually mean that there is real multimedia information present

I know but Bulat Ziganshin asked for examples where there was a clear difference between with and without multimedia filters in exe, so I gave one.

[Bulat Ziganshin]

it is the question of terminology you use uharc's one, while i use (more concrete) rar's one. i can and will work on filter that implements delta compression

[JohanDeBock]

4,751,176 rar-3.70b4-m5-mdg-mct--mcc-.rar
4,751,176 rar-3.70b4-m5-mdg-mct-.rar
4,806,312 rar-3.70b4-m5-mdg-mct--mca-.rar
4,913,541 rar-3.70b4-m5-mdg-mct--mcd-.rar

-mct- is just to disable ppmd.

[Bulat Ziganshin]

my tests shows the same. delta filter - it makes the real difference