FreeArc

[vi6hd8]

Maybe -- is unnecessary?

check previous post, its option error without "--"

anyone tried "+RTC -K64M" ? maybe its a problem with my OS

[m^2]

Hey Bulat, I have a feature suggestion.
It's something for distant future, but I'd like to know what do you think about it.

Incremental backups. FreeArc takes as parameters an archive and a set of files and creates a new archive with new / changed files and a reference to the previous archive for the rest.
Something like DAR.

[osmanturan]

Hey! It was planned for BIT!

[m^2]

Hey! It was planned for BIT!

[IsName]

Strange. +RTS option works (if "--" doesn't occur before) with 23 June version, but doesn't with current(16 Jan '09). So probably Bulat compiled that new version in another way.

[Bulat Ziganshin]

yes, i fixed handling unicode filenames in cmdline, but it leads to broken +RTS handling

vi6hd8, try to add -mcd- switch. i have found that delta filter sometimes crashes in arc

btw, anyone who have reported broken compression in arc - please yell again. i even have some data you have snet, but don't remember what yoy have reported. i was busy last 6 monts, now it's time to fix these


>Incremental backups...

saved to my huge to-do list

[Bulat Ziganshin]

updated http://www.haskell.org/bz/arc1.arc

• fixed bug in Delta filter (leading to crashes)
• -m3 - improved compression by 1% on binary files

[vi6hd8]

"-mcd-" didnt help

I checked 23 June version, increased stack size using "+RTS -K16M" and file was successfully compressed and tested without any errors

edit:
new version (with fixed delta) also gives this error

[Bulat Ziganshin]

updated http://www.haskell.org/bz/arc1.arc

• added Compressed/Total compressed to progress dialog

If you support some FreeArc translation, please look for "??" in your language file and translate it



>I checked 23 June version, increased stack size using "+RTS -K16M" and file was successfully compressed and tested without any errors

this means that without +RTS switch, Jun23 version was also crashed??

[vi6hd8]

this means that without +RTS switch, Jun23 version was also crashed??

yes, without it its giving error

[Vacon]

Hello everyone,

thank you Bulat!

If you support some FreeArc translation, please look for "??" in your language file and translate it

Done
But what does:

0253 Total compressed=Gesamt-Kompression <- gives you a clue where it is
=Всего сжатых <= THIS IS MEANT

mean...?

Best regards!

[Bulat Ziganshin]

just run any compression command with new freearc

on the left it shows current archive size, on the right - estimated final archive size

[Bulat Ziganshin]

vi6hd8, finally i just tried myself to compress huge file and got the same problem. thank you for report and sorry that i don't tried it myself

[Vacon]

Hello everyone,

thank you Bulat for your kind answer. Next time I will try to be even more clear (though I thought my arrows were a good attempt...)
Line 0253 has english text and two question-marks:

0253 Total compressed=Gesamt-Kompression

which were translated by me into german.
So far, so good.
Right underneath there is a "crippeld" line, starting with "=" and some russian (?) text:

=Всего сжатых

I believe / think / suppose this is by accident. But I don't know. So I'm asking here, because it's possibly:
-> left over from original language file (russian) and needless
or
-> english string is missing, meaning some feature of FreeArc will either be shown in russian or not shown at all.
Please enlight me / us.

Best regards!

[Bulat Ziganshin]

yes, it is "total compressed" in russian. small mistake

thank you for translation, i will update it in a moment

[Vacon]

Hello everyone,

thank you again, Bulat!

small mistake

I can think of things that are worse
Since I had no russian in school, I had to ask people who are more competent than I.
So from now on let's concentrate on more important things!

Best regards!

[Bulat Ziganshin]

updated http://www.haskell.org/bz/arc1.arc

• fixed "+RTS -Ksize" bug on some huge files

[nanoflooder]

http://anonym.to/?http://nanoflooder...taller-cmd.sfx
A stub that launches "setup.cmd" instead of "setup.exe" after the extraction. Might be useful for those who make unattended distributions

[Black_Fox]

I had no russian in school

Fear not, to have a basic overview what the thing may mean there's Google translator

[Vacon]

Hello everyone,

Fear not, to have a basic overview what the thing may mean there's Google translator

That's why I like this forum -> at any time someone helps one out
When will Google have a site where one can find out if something is written really intensionally?

Best regards!

[pat357]

check previous post, its option error without "--"

anyone tried "+RTC -K64M" ? maybe its a problem with my OS

i the same problem once...

see : http://encode.ru/forum/showpost.php?...&postcount=368

and solved it : http://encode.ru/forum/showpost.php?...&postcount=372

The clue was to set an extra environment variable like :

set GHCRTS=-K20000k

[pat357]

updated
http://www.haskell.org/bz/arc1.arc

Thanks for the update !

>I checked 23 June version, increased stack size using "+RTS -K16M" and file was successfully compressed and tested without any errors

this means that without +RTS switch, Jun23 version was also crashed??

Yes it also crashed...
I guess it has something to do with the length of the parameters given to ARC.
See my other post about it :

set GHCRTS=-K20000k

I reported this error before with the 28-10-09 version :
http://encode.ru/forum/showpost.php?...&postcount=368
http://encode.ru/forum/showpost.php?...&postcount=372

I'll test this new version and let you know.

--edit--
Results from testing this version with same parameters on the same file :

G:\test\gentoo\Gentoo 64-bit.vmwarevm>arc a  mexe+rep:1300mb+tempfile+rep:1300mb+tempfile+rep:1300mb+tempfile+7zx:0 -lc1600mb -ld1600mb gentoo_tar gentoo.tar
FreeArc 0.50 alpha (Jan 20 2009) started: 0.00 secs
Compressing 1 file of 4.519.589.888 bytes: 0.01 secs
  Using exe+rep:1300mb+tempfile+rep:1300mb+tempfile+rep:1300mb+tempfile+7zx:0
  Memory for compression 1556mb, decompression
  Compressing Gentoo.tar                                                 99.9%
Compressing 1924863692 bytes with 7za a -mx0 -mmt=3 $$arcpackedfile$$.7z $$arcdatafile$$.tmp
 99.9%
7-Zip (A) 4.63  Copyright (c) 1999-2008 Igor Pavlov  2008-12-31
Scanning

Creating archive $$arcpackedfile$$.7z

Compressing  $$arcdatafile$$.tmp

Everything is Ok
 99.9%
  Solid block compression results (223.332 seconds)
    exe: 4.519.589.888 bytes in 10.858 seconds
 99.9%    rep:1300mb: 2.239.734.974 bytes in 74.818 seconds
    tempfile: 2.239.734.974 bytes in 3.416 seconds
    rep:1300mb: 1.946.846.587 bytes in 40.716 seconds
    tempfile: 1.946.846.587 bytes in 1.794 seconds
    rep:1300mb: 1.924.863.692 bytes in 38.610 seconds
    tempfile: 1.924.863.692 bytes in 1.357 seconds
    7zx:0: 1.924.863.827 bytes in 51.762 seconds

  Writing directory: 391.99 secs
  Found 1 directory names: 392.02 secs
  Directory written: 392.0
Compressed 1 file, 4.519.589.888 => 1.924.863.827 bytes. Ratio 42.5%
Compression time: cpu 249.26 secs, real 392.09 secs. Speed 11.527 kB/s
G:\test\gentoo\Gentoo 64-bit.vmwarevm>

Seems OK to me !!

[Bulat Ziganshin]

>I guess it has something to do with the length of the parameters given to ARC.

no, the problem was progress indicator internals which showed itself on huge files compressed using rep

>I reported this error before

yes, i recalled that there were some errreports, but don't recalled where exactly i seen these (unfortunately, search on forum doesn't work)

btw, if you reported any (de)compression problems with freearc - please say it again. now i'm looking for all these bugs

[Bulat Ziganshin]

updated http://www.haskell.org/bz/arc1.arc

• reporting when data cannot be decrypted:

>Arc.exe t b.arc -p2 -p-
FreeArc 0.50 alpha (Jan 21 2009)
Testing archive: b.arc
Testing 2 files, 121 bytes. Processed 0%
ERROR: Bad password for compile.cmd in archive b.arc

[Bulat Ziganshin]

updated http://www.haskell.org/bz/arc1.arc
fixed two severe bugs:

• program was terminated when trying to detect filetype of locked file (such as pagefile.swp)
• "divide by zero" error when calculating "Total compressed" for GUI progress indicator
• also now "Compressed/Total compressed" line displayed only for compression commands

[Bulat Ziganshin]

Documentation mentions -ep0 switch, while FreeArc doesn't accept it

i don't remember who asked it, but now i checked this problem: it was a bug in docs, this switch is just -ep actually. btw, one can find this info in rar.txt - i maintain a high level of compatibility with rar

[nanoflooder]

http://anonym.to/?http://nanoflooder...taller-cmd.sfx
A stub that launches "setup.cmd" instead of "setup.exe" after the extraction. Might be useful for those who make unattended distributions

updated http://www.haskell.org/bz/arc1.arc
fixed two severe bugs

Updated
http://anonym.to/?http://nanoflooder...taller-cmd.sfx

[Bulat Ziganshin]

FreeArc (and it's companion libraries) sources are now available via SVN:

https://freearc.svn.sourceforge.net/svnroot/freearc

you can even ask me about write access

[Beppi]

Wow! Fantastic!
Only now I discovered this forum, with the mighty author of the fantastic arc!!! :-)

First of all, thanks very much for arc, a wonderful, fast and well made program! I use it really very much.

Second of all, recently I really was astonished by a compression argument I came through.

I had to compress a lot of isos containing a huge number of audio samples. Some of them are couples of 16bit or 24bit integers, others may be floating point (but I don't think many of them).
I tried arc -m9 -mt2 as usual, then I tested the compression level with 7zip and nanozip. They ALL finished with a 15%-20% worse ratio then the old and fast WinRAR 3.8, that generally stays behind them by light years.
I even tried with StuffIt, that gave me large compression on already compressed media files (actually jpg) but didn't give me any better news.

This incredible result made me look for forums and here I came! Is it possible that compressor full of specific high-technology algorhythms are so badly defeated by a quick general-purpose software!?


A recent iso, made by a setup file containing samples, probably with a already slight compression, gave me these results (KBytes):
Original file 880027
nanozip opt1 (1.3GB) 653425
7zip LZMA Ultra 651059
arc -m9 645500 (v 0.50)
WinRar Max 582162

I cancelled WinRK and didn't run paq because I just could not wait one week... :-) Anyway, with other files, for which I didn't keep statistics, the gap was much larger then this 6%-7%.
These results are really astonishing. Is there a way to implement (if it wasn't done already by using some external compressor) a algorhythm to compress those wavs?

This file I was compressing was from a personal owned commercial program, and it was a setup file, without any extension, and containing several audio files; but there are really many free samples, available online, for example from http://www.freesound.org/ and http://www.sampleswap.org/ .

Thanks for your great work!!

Beppi.

[nanoflooder]

Second of all, recently I really was astonished by a compression argument I came through.

I had to compress a lot of isos containing a huge number of audio samples. Some of them are couples of 16bit or 24bit integers, others may be floating point (but I don't think many of them).

Try UHARC for multimedia. Still unbeatable.