Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Infima - New Compression Technology named LAN

21 views
Skip to first unread message

Nir Halowani

unread,
Apr 4, 2006, 4:36:28 AM4/4/06
to
We would like to introduce you to a new Compression Technology named
LAN (patent pending) which aims to offer good compression ratio's for
most data types (Images, Audio, Video, Texts), a first beta version for
our first product (Infima Archiver) is available at www.myinfima.com.

Thanks.

Nir Halowani
CTO, Infima Technologies

Claudio Grondi

unread,
Apr 4, 2006, 10:13:43 AM4/4/06
to

Visiting the site and getting the right download page requires
JavaScript (and there is also some ActiveX involved I do not allow at all).
The site promises to send an email with the link to the download after
filling a form with own name and email address.

The trouble I have got with it is, that I have not received any email
yet (see return email address of this posting to check what maybe went
wrong on the server).

Claudio

Nir Halowani

unread,
Apr 4, 2006, 10:34:59 AM4/4/06
to

Sorry about the Inconvenient i will send you an email with downloading
URL directly

Giordano Ferdinandi

unread,
Apr 4, 2006, 11:14:47 AM4/4/06
to

When I start the program, it just says "General Error Out of memory".
Any way of using a command line version of your tool?

Nir Halowani

unread,
Apr 4, 2006, 11:17:00 AM4/4/06
to
Only in a few weeks, what OS do you have?

Thanks.

Sportman

unread,
Apr 4, 2006, 11:28:22 AM4/4/06
to

I tested your beta application:

.wav file compression is amazing half the size of the best compressor I
tested so far.
.mp4, .log, .txt, .jpg file compression close to the best compressor or
best I tested.
Compression speed is in most cases ok. Startup program take some time.
CPU load is not used 100%, in graph it looks like CPU is used in
intervals (both options enabled). In some cases CPU was still used
after compression was finished, closing application was then needed.

Problems by testing big .txt file input2.zip:
http://groups.google.com/group/comp.compression/browse_frm/thread/7053c23c0d01c81c/d08c3b27393f124b#d08c3b27393f124b

Compressor jumps from 55% to finish with final size is: 138 bytes, no
file is written in the selected output dir only in the compressor dir.
Uncompressing that file give no error but also no original file.
Same problem I had with testing to compress an .exe file with the
difference the output file 257 bytes was written in the right directory
this case.

VS6 platform is 8 years old maybe it's a good idea to write it in
VS2005 what makes the setup/installer download file size littler.

Downloading the beta is not working in all cases, spyware software
blocking it for example.

Interface was easy to understand. When decompressing I prefer the
program not create by default a directory in the output directory. The
description about the two options is very short, I like to know exact
what they do.

Overall good job, nice program with future!

Jim Leonard

unread,
Apr 4, 2006, 12:36:22 PM4/4/06
to
Nir Halowani wrote:
> We would like to introduce you to a new Compression Technology named
> LAN (patent pending) which aims to offer good compression ratio's for
> most data types (Images, Audio, Video, Texts), a first beta version for
> our first product (Infima Archiver) is available at www.myinfima.com.

At first, I was impressed.

For those who haven't tried the beta yet, what it does is essentially
combine all the smart tactics into a single program. There is a filter
for very many models, including images, PCM audio data, text, etc. and
each of those datatypes gets compressed as one continuous stream run
through a filter for that particular type. I tried to fool it by
including some .ZIP and other already-compressed archive files in my
test set, and (unless I'm horribly misinterpreting what I saw) it was
smart enough to extract the data from the archives and include it in
the filters/models instead of just trying to blindly compress
already-compressed .ZIP files. The filter for MIDI files (*.mid) was
particularly impressive (and ran the longest).

My (very informal) test set included 16-bit DOS executables, some
easily-compressable data (raw screen dumps, text) but using
non-traditional filenames, .ZIP files, and other miscellany from some
old data I was working with. I checked all three options (maximize
resources, optimize files, recursive directory traversal) and the
initial results were surprising and promising:

1,101,209 phun.lan
1,571,338 phun_lzma.7z
1,656,885 phun.rar
1,737,227 phun_ppmd.7z
1,788,834 phun_bzip2.7z
1,845,340 phun.zip
3,060,392 phun_no_compression.rar

I was going to uncompress all of the archive files in the test set and
re-run the tests to put all programs at a more even level, but then I
noticed that some of my files were MISSING from the archive. Out of
197 source files, only 178 were present. The missing files were all
.EXE files with the exception of three .BAS files (tokenized).

In addition, it mangled the filenames of some of my source data.
Original files looking like this:

01/26/1989 11:29 AM 880 BABYLON

...where renamed to this:

01/26/1989 11:29 AM 880 BABYLON.$N$N$n

The extracted files had the correct names, but this is no excuse for
renaming existing files during compression and then leaving them at the
new name.

So the software has a few bugs to work out before it can be considered
for serious testing.

Nir Halowani

unread,
Apr 4, 2006, 12:54:52 PM4/4/06
to

Thanks for all your feedbacks we will considered all of them in our fix
release version (I guess it will be available next week).
As for the input2.zip file at least for me it seems to work fine and
generated: 3,469Kb while running without the Max Resource usage option.

- Nir

Nir Halowani

unread,
Apr 4, 2006, 12:57:58 PM4/4/06
to
Hello Jim,

You are correct there seems to be a problem while trying to compress
16-bit executables we will fix it ASAP.
The re-naming problem is also a bug, sorry for that....

- Nir

Claudio Grondi

unread,
Apr 4, 2006, 1:03:01 PM4/4/06
to

Received the email with the download link.

Downloaded: InfimaArchiveInstallFull.exe
size: 17.593.929 bytes
MD5: 43B41F0BBF99D09ADFDE9048FC63DDB0
CRC32: 8580678F

I am on Windows XP professional.

The execution of the InfimaArchiveInstallFull.exe failed. MS Windows XP
reported problems with the executable and the necessity of shutting it
down.

Any hints why does it not work for me?

Claudio

Gian-Carlo Pascutto

unread,
Apr 4, 2006, 1:58:14 PM4/4/06
to

It seems that some of these "incredible" results are attained by, well,
not being able to decompress the data correctly again:

http://www.hydrogenaudio.org/forums/index.php?showtopic=43311

--
GCP

Nir Halowani

unread,
Apr 4, 2006, 2:12:15 PM4/4/06
to
Hi,

Yep, But all of the reported bugs will be fixed ASAP.
The differences which are reported on hydrogenaudio are just a result
of bad correction files generated for the WAV.
In any case the decompressed files are normally undistinguishable from
the original in all ABX tests (Even in the current version).

As mentioned, this is a first beta release which will be upgraded every
2-3 days.

You can try other files, and again all feedbacks are mostly
appreciated.

Thanks.

Sportman

unread,
Apr 4, 2006, 2:27:10 PM4/4/06
to
Gian-Carlo Pascutto wrote:
> It seems that some of these "incredible" results are attained by, well,
> not being able to decompress the data correctly again:
>
> http://www.hydrogenaudio.org/forums/index.php?showtopic=43311

At least for the .wav file you are right, bit compare show differences,
I only played with success the decompressed .wav in an audio player in
my first test. Also with everything disabled bit compare fail, in this
case with decompress, the output directory contain not only the output
file but also a file named 0.filename.wav.ln a little smaller in size
then the compressed input file.

Nir Halowani

unread,
Apr 4, 2006, 3:44:21 PM4/4/06
to

Thanks, We will fix it in the upcoming release (Tomorrow).

Sportman

unread,
Apr 5, 2006, 8:47:58 PM4/5/06
to
Nir Halowani wrote:
> Thanks, We will fix it in the upcoming release (Tomorrow).

I saw that Meridian asks $2500 for the Professional MLP Encoder:
http://www.meridian-audio.com/p_mlpenc.htm

I can't test Meridian compression product on my test files but reading
Meridian website I understand their software do 50-55% lossless
compression at average wav files. Your program do round 70-75% (maybe
lossless after bug fix?) compression at some big wav files (130MB+) I
tested. If this is true and the speed is comparable they are probably
interested to buy your company share or audio compression license.

john wayne

unread,
Apr 6, 2006, 2:10:00 PM4/6/06
to
I've seen the pic at http://www.myinfima.com/audio/ and I think that
distorsion is the real problem of you wave form. This kind of analysis
is old and bad. With your compression Pavarotti begin a goldfinch ;-)

john wayne

unread,
Apr 7, 2006, 9:01:40 AM4/7/06
to
When we could hear an audio file with you compression?

0 new messages