PIM 2.02 is here!

**encode** · 26th June 2007, 20:30

It's a big stride in PIM's development!

Many new features added, many bugs fixed.

The highlights:
+ Added "double-click to view a file inside an archive" feature
+ Added ZIP Deflate64 and ZIP DCL Implode decompression
+ Added file associations
+ Added TIFF file compression (Both IBM and Macintosh types)

Enjoy!

http://www.encode.su/

**Nania Francesco** · 26th June 2007, 20:37

Good Job Encode!

**LovePimple** · 26th June 2007, 21:23

Beyond Awesome!!!

Thanks Ilia!

**Fallon** · 26th June 2007, 21:45

Thanks very much!

**LovePimple** · 27th June 2007, 15:57

It would be nice to see a few more people posting a little 'thank you' to authors in appreciation for their hard work and patience.

**Vacon** · 27th June 2007, 16:20

Hello everyone,

thank you Ilia!
A new milestone in compression!

The fact that I have said something similar before doesn't make the repetition wrong!

Best regards!

**Nania Francesco** · 27th June 2007, 17:49

SFC TEST IN ONE ARCHIVE PIM -> 12.000.556 BYTE

**encode** · 27th June 2007, 17:53

Should be - 12,000,506 bytes.

In other words no difference between each file compression separately or all files in a single archive.

Furthermore, you can "unite" existing archives:

copy /b 1.pim+2.pim+3.pim out.pim

this command will unite all three (1.pim, 2.pim, 3.pim) archives in one 'out.pim' - one of the benefits of the PIM archive format I invented.

**encode** · 27th June 2007, 18:03

Results for RAR/7-Zip:

WinRAR 3.51, Best:
non-solid: 12,375,268 bytes
solid: 12,395,411 bytes

7-Zip 4.47, Ultra:
non-solid: 12,091,638 bytes
solid: 12,070,741 bytes

PIM outcompresses both. Super performance of RAR and 7-Zip at SFC is just due to an extra hand tuning for every single file - CHEATING in other words. Secondly, the power of solid archives is a myth!

**Vacon** · 27th June 2007, 19:04

Hello everyone,

Originally Posted by encode

Furthermore, you can "unite" existing archives: ...

I LOVE PIM

Originally Posted by encode

Secondly, the power of solid archives is a myth!

I think it depends on content to compress, doesnt it?

Best regards!

**encode** · 27th June 2007, 19:23

Originally Posted by Vacon

I think it depends on content to compress, doesnt it?

Yep. Also it depends on compression algorithm. For PPM solid archiving often hurts, especially if you compress lots of different files.

**Vacon** · 27th June 2007, 20:08

Hello everyone,

Originally Posted by encode

For PPM solid archiving often hurts, especially if you compress lots of different files.

So it is a good choice to sort archive contents by type (ending [under Windows]) and develop a routine that chooses if solid compression is better or worse?
If I remember correctly Bulat and Igor (Pavlov) have made some efforts into that direction too. Just dont know how far they got (Im no sourcecode-freak).

Best regards!

**encode** · 27th June 2007, 20:48

By the way, PIM v1.x used solid archives only - just recall the "Skipping" process (If you try to extract a file placed near the end or something - all files packed before must be "skipped" - to get the same model state)
Sorting files by type is very good thing. WinRAR perfectly sorts files by their types. The downsides:
+ If file size has been increased (incompressible file) you cannot just store it. Again try to compress SFC with RAR using solid mode - you will able to see that the size of A10.jpg has been increased. It also the baddest thing about PIM v1.x - it also can inflate files.
+ To get any file, you must "skip" all files packed before wanted file. In other words all preceding files must be unpacked to the memory. And now imagine a huge archive and you need only one file which placed somewhere in the middle, for example.

Working on PIM v2 I kept in mind all these issues and did my best!

**Vacon** · 27th June 2007, 21:33

Hello everyone,

Originally Posted by encode

Working on PIM v2 I kept in mind all these issues and did my best!

Thank you! Its nice to see that theory and practical use are both considered (on contrast to PAQ, which is experimental only -> theoretical possibilities preferred)
Another issue with solid archives is: if such an archive is faulty, all contents are lost (most of the time).
What about semi-solid (content sorted by type)?
Are all files with the same ending corrupted too, or does this affect all blocks (even with different file-types)?

Best regards!

**encode** · 27th June 2007, 21:46

Originally Posted by Vacon

What about semi-solid (content sorted by type)?
Are all files with the same ending corrupted too, or does this affect all blocks (even with different file-types)?

If files are sorted by their types - its the same solid archive, the only difference is the file order. If archive is damaged all files in current solid block (often its the whole archive) followed by damaged file will be lost. The file type doesnt matter. At the same time, with non-solid archives each file packed independently - so you can just skip corrupted file, this also allows you to view and extract partially downloaded archive.

**Vacon** · 27th June 2007, 22:26

Hello everyone,

so its pretty dangerous to compress to solid archives:
- if you do not have a secure back-up of the archive
- even more if (for instance) you have a defective memory-module and compress to a corrupted archive already (without verifiing it)
Right?
On the other hand solid compression _sometimes_ gives a gain.
-> Keep an eye on your compressed files!
Thank you for clearifying that!

Originally Posted by encode

...this also allows you to view and extract partially downloaded archive.

Thats what makes repairing defective Zip, Rar and Sqx-archives possible, right?
Is this possible for Pim-archives too?

Best regards!

**encode** · 27th June 2007, 22:27

Anyway, I'm thinking about audio compression. Also I tested an advanced BMP transformer with lossless color transformation - on some files it improves compression, however in some cases it hurts compression - so current filter is good enough. About audio, with 8-bit WAV files simple filter gives just a small improvement, however on 16-bit files, this filter can give a nice gain:

track5.wav:
PIM 2.02 + SNDFLT: 19,125,972 bytes
PIM 2.02: 24,991,768 bytes
Original: 29,644,608 bytes

barcelona.wav:
PIM 2.02 + SNDFLT: 39,982,378 bytes
PIM 2.02: 50,244,050 bytes
Original: 59,853,696 bytes

**encode** · 27th June 2007, 22:53

Originally Posted by Vacon

Thats what makes repairing defective Zip, Rar and Sqx-archives possible, right?

Like Malcolm Taylor said - repairing archives is at almost for users calmness. In real world if an archive is really damaged its quite impossible to restore the data. There is a few data correction algorithms exists - you maybe hear - some archivers can include so called recovery records to restore damaged archive. In practice this helps only a little. Its like CDs are more reliable than DVDs - the amount of information vs. physical space - even a small scratch can hurt info on DVD. The same with archives - with modern compression techniques if you change even one byte of a compressed stream - say "good bye" to the original data!

Originally Posted by Vacon

Is this possible for Pim-archives too?

If header structure untouched, you can freely select each "valid" file and extract it with no problems. To ensure the archive integrity there is a Test command exists - PIM will extract all files into memory and check their checksums (CRC32). If a header structure was also damaged - PIM will raise an error message. Such archive cannot be extracted directly by PIM - however not all files are damaged. Here you can use a HexEditor - to remove damaged parts. In addition, if needed in future versions I will include auto archive header fixing - as currently used by PIM for ZIP files. Anyway, I never see the problems with PIM archives - nowadays, we have reliable enough internet connection and hard-disc storage...

**Vacon** · 27th June 2007, 23:12

Hello everyone,

thank you Ilia for taking the time to explain that to us!

Best regards!

**squxe** · 28th June 2007, 00:45

Originally Posted by encode

Anyway, Im thinking about audio compression

Great news! Cool!

**Black_Fox1** · 28th June 2007, 01:07

Thanks encode!

**encode** · 28th June 2007, 17:01

I redesign the main icon to meet the Vista standard. Now PIM has even 256x256 icon:

**encode** · 28th June 2007, 17:20

Also I met with some compiler related problems - it wont link the ICO with compressed 256x256 image. Uncompressed image makes PIM fatter by 257 KB...

So the 48x48 icons will be largest available...

**encode** · 28th June 2007, 19:48

+ Added WAVE file compression:
PCM 16-Bit Stereo/Mono
PCM 8-Bit Stereo/Mono

+ Added compression for 32-bit BMP files

**encode** · 28th June 2007, 20:05

Some test:
ProSessions Loops - a folder with various loops, total size: 514,371,908 bytes

PIM 2.02 - 366,332,744 bytes
PIM 2.03 - 277,279,718 bytes

**LovePimple** · 28th June 2007, 22:19

Originally Posted by encode

PIM 2.02 - 366,332,744 bytes
PIM 2.03 - 277,279,718 bytes

Thats what I call progress!

**John** · 28th June 2007, 23:42

Where i can found the 2.03?

**encode** · 28th June 2007, 23:42

In addition, I will change the main icon. Look at these icons:

Both are very nice ones. Isn't it? Anyway, the first one is my favorite!

You can vote for icons or even suggest your own!

**LovePimple** · 28th June 2007, 23:57

First one is my favorite as well!

**encode** · 29th June 2007, 00:12

Thread: PIM 2.02 is here!

Thread Tools

Search Thread

Display

Similar Threads

PIM - did you plan to open source console version of pim ?

Posting Permissions