Results 1 to 9 of 9

Thread: tzpaq

  1. #1
    Member
    Join Date
    Jun 2008
    Location
    G
    Posts
    372
    Thanks
    26
    Thanked 22 Times in 15 Posts

    tzpaq

    Hi,

    iam building tzpaq (thometals zpaq) which aims to create a zpaq compatibile archiver with more features and other stuff. Help is highly welcome as feedback.

    https://github.com/thometal/tzpaq

    This thread should mainly used to collect feedback.

  2. The Following 3 Users Say Thank You to thometal For This Useful Post:

    Bulat Ziganshin (15th October 2016),Christoph Diegelmann (15th October 2016),Matt Mahoney (20th October 2016)

  3. #2
    Administrator Shelwien's Avatar
    Join Date
    May 2008
    Location
    Kharkov, Ukraine
    Posts
    3,134
    Thanks
    179
    Thanked 921 Times in 469 Posts
    The main problem with zpaq afaik is the whole future-compatibility idea - it already failed once before in winrar,
    and I didn't see any proof that its worth the trouble of having it in zpaq.
    Actually I agree that its a good idea in theory, but component design seems still to be too immature for it to work as expected.

    So, what do you think about stripping all the script handling, and just using all the models as C++ code?
    It might even improve compression, because it won't be necessary to store script code in archive anymore.

    Also, do you have any plans about adding new model components etc?

  4. #3
    Member
    Join Date
    Jun 2008
    Location
    G
    Posts
    372
    Thanks
    26
    Thanked 22 Times in 15 Posts
    Quote Originally Posted by Shelwien View Post
    The main problem with zpaq afaik is the whole future-compatibility idea - it already failed once before in winrar,
    and I didn't see any proof that its worth the trouble of having it in zpaq.
    Actually I agree that its a good idea in theory, but component design seems still to be too immature for it to work as expected.

    So, what do you think about stripping all the script handling, and just using all the models as C++ code?
    It might even improve compression, because it won't be necessary to store script code in archive anymore.

    Also, do you have any plans about adding new model components etc?

    1. i dont wanna make any change which is incompatible to zpaqs format specification, I just want to improve "zpaq" as tool
    2. In the roadmap under point 4 (other stuff), there is a plan to add a cutom plugin architecture to load additional scipts or binaries as compressionmethods to improve the compression for certain filetypes. For example if you have many bmps you can add bmp_j4c.cfg and the script will dynamically executed if there are bmps which needs to compress. This will all done in the archive format specification 2. Due to the fact iam not a compression expert i will not have the knowledge to add new models anytime soon. Also I want to bring back lost features of zpaq, like the "since" option.

    But if you have any idea too improve compression without break zpaq compatibility, please let me know.

  5. #4
    Administrator Shelwien's Avatar
    Join Date
    May 2008
    Location
    Kharkov, Ukraine
    Posts
    3,134
    Thanks
    179
    Thanked 921 Times in 469 Posts
    > 1. i dont wanna make any change which is incompatible to zpaqs format
    > specification, I just want to improve "zpaq" as tool

    Winrar can apply rarvm scripts by crc - if zpaq has a similar option (without storing the scripts),
    it might be still possible.

    > For example if you have many bmps you can add bmp_j4c.cfg

    Sure, but why does it have to be a write-only script like that?
    Can't you normally compile it in advance, instead of having to maintain
    the whole scripting system?

    > But if you have any idea too improve compression without break zpaq compatibility, please let me know.

    I have some ideas, but not without breaking compatibility.
    The most obvious one is about optimizing codec parameters for specific data sets.

    Anyway, I think you shouldn't mind the compatibility with standard zpaq format.
    Imho its much more important to focus on making it convenient for practical use - then,
    if you'd manage to not break anything, you can think about enforcing the compatibility.
    And from what I know, its really easy to break with any new useful metainfo etc.

    Also, how about looking further than "certain filetypes". Like, detect embedded
    structures in files (by signatures etc), and assign relevant codecs to these?

  6. #5
    Member
    Join Date
    Jul 2014
    Location
    Mars
    Posts
    164
    Thanks
    115
    Thanked 10 Times in 9 Posts
    win binary?

  7. #6
    Member
    Join Date
    Jun 2008
    Location
    G
    Posts
    372
    Thanks
    26
    Thanked 22 Times in 15 Posts
    Quote Originally Posted by necros View Post
    win binary?
    If some one will create a win binary he can do it I try to support it, but I have no win to do it myself

  8. #7
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,497
    Thanks
    733
    Thanked 659 Times in 354 Posts
    gcc version 4.9.2 (i686-posix-sjlj-rev2, Built by MinGW-W64 project)
    g++ -O3 -s -static -std=c++11 zpaq.cpp libzpaq.cpp sha1.cpp sha256.cpp -m32 -msse2 -o tzpaq32
    g++ -O3 -s -static -std=c++11 zpaq.cpp libzpaq.cpp sha1.cpp sha256.cpp -m64 -o zpaq64
    Attached Files Attached Files

  9. The Following User Says Thank You to Bulat Ziganshin For This Useful Post:

    necros (17th October 2016)

  10. #8
    Member
    Join Date
    Jun 2008
    Location
    G
    Posts
    372
    Thanks
    26
    Thanked 22 Times in 15 Posts
    Quote Originally Posted by Bulat Ziganshin View Post
    gcc version 4.9.2 (i686-posix-sjlj-rev2, Built by MinGW-W64 project)
    g++ -O3 -s -static -std=c++11 zpaq.cpp libzpaq.cpp sha1.cpp sha256.cpp -m32 -msse2 -o tzpaq32
    g++ -O3 -s -static -std=c++11 zpaq.cpp libzpaq.cpp sha1.cpp sha256.cpp -m64 -o zpaq64
    Thx Bulat, but the current win version is just zpaq with 2 splitted classes from libzpaq

  11. #9
    Member
    Join Date
    Jun 2008
    Location
    G
    Posts
    372
    Thanks
    26
    Thanked 22 Times in 15 Posts
    Quote Originally Posted by Shelwien View Post
    > 1. i dont wanna make any change which is incompatible to zpaqs format
    > specification, I just want to improve "zpaq" as tool

    Winrar can apply rarvm scripts by crc - if zpaq has a similar option (without storing the scripts),
    it might be still possible.

    > For example if you have many bmps you can add bmp_j4c.cfg

    Sure, but why does it have to be a write-only script like that?
    Can't you normally compile it in advance, instead of having to maintain
    the whole scripting system?

    > But if you have any idea too improve compression without break zpaq compatibility, please let me know.

    I have some ideas, but not without breaking compatibility.
    The most obvious one is about optimizing codec parameters for specific data sets.

    Anyway, I think you shouldn't mind the compatibility with standard zpaq format.
    Imho its much more important to focus on making it convenient for practical use - then,
    if you'd manage to not break anything, you can think about enforcing the compatibility.
    And from what I know, its really easy to break with any new useful metainfo etc.

    Also, how about looking further than "certain filetypes". Like, detect embedded
    structures in files (by signatures etc), and assign relevant codecs to these?
    I want compatibility with the zpaq format because

    1. It's much more work to design create maintain a new format
    2. I want to improve the usability with zpaq format because I have several backups in zpaq and I want to use the files further. For example purge etc.
    3. but if the architecture was refined it should not be a big problem to switch some components

    The idea with creating a method which dynamically uses the correct model inside a file itself like paq8 sounds great. But first other things need to be done. Also I think I haven't enough knowledge/time to implement this anytime soon. But again if there is a volunteer Iam open for discussion and collaboration

Posting Permissions

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