Page 1 of 3 123 LastLast
Results 1 to 30 of 84

Thread: PIM 2.02 is here!

  1. #1
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,985
    Thanks
    377
    Thanked 353 Times in 141 Posts
    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/


  2. #2
    Tester
    Nania Francesco's Avatar
    Join Date
    May 2008
    Location
    Italy
    Posts
    1,565
    Thanks
    220
    Thanked 146 Times in 83 Posts
    Good Job Encode!

  3. #3
    Moderator

    Join Date
    May 2008
    Location
    Tristan da Cunha
    Posts
    2,034
    Thanks
    0
    Thanked 4 Times in 4 Posts
    Beyond Awesome!!!

    Thanks Ilia!

  4. #4
    Member Fallon's Avatar
    Join Date
    May 2008
    Location
    Europe - The Netherlands
    Posts
    158
    Thanks
    14
    Thanked 10 Times in 5 Posts
    Thanks very much!

  5. #5
    Moderator

    Join Date
    May 2008
    Location
    Tristan da Cunha
    Posts
    2,034
    Thanks
    0
    Thanked 4 Times in 4 Posts
    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.

  6. #6
    Member Vacon's Avatar
    Join Date
    May 2008
    Location
    Germany
    Posts
    523
    Thanks
    0
    Thanked 0 Times in 0 Posts
    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!

  7. #7
    Tester
    Nania Francesco's Avatar
    Join Date
    May 2008
    Location
    Italy
    Posts
    1,565
    Thanks
    220
    Thanked 146 Times in 83 Posts
    SFC TEST IN ONE ARCHIVE PIM -> 12.000.556 BYTE

  8. #8
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,985
    Thanks
    377
    Thanked 353 Times in 141 Posts
    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.


  9. #9
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,985
    Thanks
    377
    Thanked 353 Times in 141 Posts
    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!


  10. #10
    Member Vacon's Avatar
    Join Date
    May 2008
    Location
    Germany
    Posts
    523
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Hello everyone,

    Quote Originally Posted by encode
    Furthermore, you can "unite" existing archives: ...
    I LOVE PIM

    Quote 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!

  11. #11
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,985
    Thanks
    377
    Thanked 353 Times in 141 Posts
    Quote 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.

  12. #12
    Member Vacon's Avatar
    Join Date
    May 2008
    Location
    Germany
    Posts
    523
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Hello everyone,

    Quote 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!

  13. #13
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,985
    Thanks
    377
    Thanked 353 Times in 141 Posts
    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!

  14. #14
    Member Vacon's Avatar
    Join Date
    May 2008
    Location
    Germany
    Posts
    523
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Hello everyone,

    Quote 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!

  15. #15
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,985
    Thanks
    377
    Thanked 353 Times in 141 Posts
    Quote 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.

  16. #16
    Member Vacon's Avatar
    Join Date
    May 2008
    Location
    Germany
    Posts
    523
    Thanks
    0
    Thanked 0 Times in 0 Posts
    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!

    Quote 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!

  17. #17
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,985
    Thanks
    377
    Thanked 353 Times in 141 Posts
    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


  18. #18
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,985
    Thanks
    377
    Thanked 353 Times in 141 Posts
    Quote 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!

    Quote 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...

  19. #19
    Member Vacon's Avatar
    Join Date
    May 2008
    Location
    Germany
    Posts
    523
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Hello everyone,

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

    Best regards!

  20. #20
    Tester

    Join Date
    May 2008
    Location
    St-Petersburg, Russia
    Posts
    182
    Thanks
    3
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by encode
    Anyway, Im thinking about audio compression
    Great news! Cool!

  21. #21
    Member
    Join Date
    Dec 2006
    Posts
    611
    Thanks
    0
    Thanked 1 Time in 1 Post
    Thanks encode!

  22. #22
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,985
    Thanks
    377
    Thanked 353 Times in 141 Posts
    I redesign the main icon to meet the Vista standard. Now PIM has even 256x256 icon:


  23. #23
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,985
    Thanks
    377
    Thanked 353 Times in 141 Posts
    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...

  24. #24
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,985
    Thanks
    377
    Thanked 353 Times in 141 Posts
    + Added WAVE file compression:
    PCM 16-Bit Stereo/Mono
    PCM 8-Bit Stereo/Mono

    + Added compression for 32-bit BMP files


  25. #25
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,985
    Thanks
    377
    Thanked 353 Times in 141 Posts
    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


  26. #26
    Moderator

    Join Date
    May 2008
    Location
    Tristan da Cunha
    Posts
    2,034
    Thanks
    0
    Thanked 4 Times in 4 Posts
    Quote Originally Posted by encode
    PIM 2.02 - 366,332,744 bytes
    PIM 2.03 - 277,279,718 bytes
    Thats what I call progress!

  27. #27
    Member
    Join Date
    Jul 2008
    Posts
    54
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Where i can found the 2.03?

  28. #28
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,985
    Thanks
    377
    Thanked 353 Times in 141 Posts
    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!


  29. #29
    Moderator

    Join Date
    May 2008
    Location
    Tristan da Cunha
    Posts
    2,034
    Thanks
    0
    Thanked 4 Times in 4 Posts
    First one is my favorite as well!

  30. #30
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,985
    Thanks
    377
    Thanked 353 Times in 141 Posts

Page 1 of 3 123 LastLast

Similar Threads

  1. Replies: 9
    Last Post: 28th June 2007, 15:02

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •