Page 21 of 61 FirstFirst ... 11192021222331 ... LastLast
Results 601 to 630 of 1814

Thread: paq8px

  1. #601
    Moderator

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

    Thumbs up

    Quote Originally Posted by Skymmer View Post
    Thank you Bill. Need to wait for compile and check
    Enjoy!
    Attached Files Attached Files

  2. #602
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    985
    Thanks
    594
    Thanked 404 Times in 302 Posts
    Hi!
    Below you can find comparison of paq_v68p3 vs. standard paq_v68. To sum up:

    High redundant files are much better compressed by p3 than standard v68. What's important - there are the same files which are very good compressed by paq8kx_v1 (but paq8kx_v1 compression is even better than p3 - sometimes significantly better). It looks that the CHANGES OF algorithm are paq_kx like.

    Normal, or low-redundant files are compressed a little worse by p3 than v68. Despite of this total score is better than standard v68.

    Here are the numbers:
    file paq8px V68 paq8px V68p3 V68p3 vs 68
    0.WAV 1333912 1333910 -2
    1.BMP 235746 235717 -29
    A.TIF 436050 436210 160
    B.TGA 401330 401493 163
    C.TIF 308098 308497 399
    D.TGA 309331 309863 532
    E.TIF 499084 498906 -178
    F.JPG 89732 89732 0
    G.EXE 1365959 1367751 1792
    H.EXE 483990 481929 -2061
    I.EXE 214227 213838 -389
    J.EXE 43011 42997 -14
    K.WAD 2610773 2610926 153
    L.PAK 2690406 2691036 630
    M.DBF 51398 51872 474
    N.ADX 85127 85385 258
    O.APR 3781 3773 -8
    P.FM3 967 968 1
    Q.WK3 203677 199186 -4491
    R.DOC 28296 28384 88
    S.DOC 24869 24957 88
    T.DOC 17723 17755 32
    U.DOC 8322 8335 13
    V.DOC 17689 17742 53
    W.DOC 12732 12760 28
    X.DOC 10670 10691 21
    Y.CFG 296 295 -1
    Z.MSG 152 150 -2
    TOTAL 11487348 11485058 -2290

    Darek

    @Bill
    I look forward to your next, very slow version of PAQ, especially if it would be paq_kx like.....

  3. #603
    Member
    Join Date
    Sep 2009
    Location
    USA
    Posts
    16
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Darek View Post
    Hi!
    Below you can find comparison of paq_v68p3 vs. standard paq_v68. To sum up:

    High redundant files are much better compressed by p3 than standard v68. What's important - there are the same files which are very good compressed by paq8kx_v1 (but paq8kx_v1 compression is even better than p3 - sometimes significantly better). It looks that the CHANGES OF algorithm are paq_kx like.

    Normal, or low-redundant files are compressed a little worse by p3 than v68. Despite of this total score is better than standard v68.

    Here are the numbers:
    file paq8px V68 paq8px V68p3 V68p3 vs 68
    0.WAV 1333912 1333910 -2
    1.BMP 235746 235717 -29
    A.TIF 436050 436210 160
    B.TGA 401330 401493 163
    C.TIF 308098 308497 399
    D.TGA 309331 309863 532
    E.TIF 499084 498906 -178
    F.JPG 89732 89732 0
    G.EXE 1365959 1367751 1792
    H.EXE 483990 481929 -2061
    I.EXE 214227 213838 -389
    J.EXE 43011 42997 -14
    K.WAD 2610773 2610926 153
    L.PAK 2690406 2691036 630
    M.DBF 51398 51872 474
    N.ADX 85127 85385 258
    O.APR 3781 3773 -8
    P.FM3 967 968 1
    Q.WK3 203677 199186 -4491
    R.DOC 28296 28384 88
    S.DOC 24869 24957 88
    T.DOC 17723 17755 32
    U.DOC 8322 8335 13
    V.DOC 17689 17742 53
    W.DOC 12732 12760 28
    X.DOC 10670 10691 21
    Y.CFG 296 295 -1
    Z.MSG 152 150 -2
    TOTAL 11487348 11485058 -2290

    Darek

    @Bill
    I look forward to your next, very slow version of PAQ, especially if it would be paq_kx like.....
    Thanks for the results! I'm sure it's already getting slower; hopefully I'll find some methods which don't only increase the number of predictions.

  4. #604
    Moderator

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

    Exclamation

    Quote Originally Posted by Skymmer View Post
    Here is my comparison between v68 and v68e conducted on my TestBed.tar file.

    Code:
    vers.\opt.     enc.time      size
    -------------------------------------
    v68  -8        1475.130    5 303 486
    v68e -8        1554.471    5 304 308
    As same as in Darek's tests v68e provided little bit worse compression. Differences in compression time caused by different compiles I think. For v68 I used speed_optimised compile from LP but there is only one LP's compile for v68e and I'm not sure if it optimised or not.
    Here are my usual builds for Bill's v68e and v68p3...

    EDIT: BTW, there is a minor fault with the forum ATM. That's why these files appear to have 0 views.
    Attached Files Attached Files

  5. #605
    Member
    Join Date
    Mar 2010
    Location
    nowhere
    Posts
    1
    Thanks
    0
    Thanked 0 Times in 0 Posts

    v68 and v68e optimized compiles with -DWINDOWS switch for directories

    I can't seem to locate any of the speed optimized compiles of v68 and v68e that used the -DWINDOWS compile switch so that they will work with compiling directories. Can some point me to where they might be, or post the compiles. Thanks.

  6. #606
    Member
    Join Date
    Apr 2010
    Location
    Ukraine
    Posts
    5
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Hi, i have questions. Is it true that generic and SSE-optimized versions work differently on some files? Maybe i can help you to fix that?

  7. #607
    Programmer Jan Ondrus's Avatar
    Join Date
    Sep 2008
    Location
    Rychnov nad Kněžnou, Czech Republic
    Posts
    279
    Thanks
    33
    Thanked 138 Times in 50 Posts
    Quote Originally Posted by Sha Lun View Post
    Hi, i have questions. Is it true that generic and SSE-optimized versions work differently on some files? Maybe i can help you to fix that?
    If someone knows how to rewrite wavModel without using double and long double types and producing same output...

    Code:
    void wavModel(Mixer& m, int info)
    Code:
      static double F[49][49][2],L[49][49];
      long double sum;
      const double a=0.996,a2=1/a;

  8. #608
    Member
    Join Date
    Apr 2010
    Location
    Ukraine
    Posts
    5
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Jan Ondrus View Post
    If someone knows how to rewrite wavModel without using double and long double types and producing same output...

    Code:
    void wavModel(Mixer& m, int info)
    Code:
      static double F[49][49][2],L[49][49];
      long double sum;
      const double a=0.996,a2=1/a;
    Ok, I'll try to help. Give me sources (with used *.asm files, for generic, sse and sse2 optimized), compiler options and sample wav file, for which output is different.

  9. #609
    Administrator Shelwien's Avatar
    Join Date
    May 2008
    Location
    Kharkov, Ukraine
    Posts
    3,691
    Thanks
    265
    Thanked 1,180 Times in 651 Posts
    Did he borrow some money from you, I wonder?

    Anyway, sources are attached a few posts above in the thread,
    and you can compile them without asm parts (of find them yourself,
    they're not intentionally hidden) using #define NOASM (which is explained
    in the source).
    Also double and target files don't matter imho, you just have to completely
    get rid of any float-point types in paq, not necessarily in the wav model only.

    http://paq8.hys.cz/ http://dhost.info/paq8/
    http://mattmahoney.net/dc/#paq http://cs.fit.edu/~mmahoney/compression/#paq
    Last edited by Shelwien; 4th April 2010 at 06:51.

  10. #610
    Member
    Join Date
    Apr 2010
    Location
    Ukraine
    Posts
    5
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Here, it's my compilation. Please, test them.
    I tried every wav file from my C:\WINDOWS\Media and it works fine.
    Attached Files Attached Files

  11. #611
    Member
    Join Date
    May 2009
    Location
    Europe
    Posts
    67
    Thanks
    0
    Thanked 1 Time in 1 Post
    Did you change something in the sources or just compiled them?

  12. #612
    Member
    Join Date
    Apr 2010
    Location
    Ukraine
    Posts
    5
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by M4ST3R View Post
    Did you change something in the sources or just compiled them?
    Just compiled, but with different options.

  13. #613
    Member
    Join Date
    May 2009
    Location
    Europe
    Posts
    67
    Thanks
    0
    Thanked 1 Time in 1 Post
    Well I think you misunderstood a bit the issue.
    We already have mmx/sse2 binaries that provides identical output. At least LovePimple's (hosted in this thread) and mines. The problem is that LovePimple's binaries and mines are incompatible with each other. And maybe (didn't verify) yours generate files that are compatible with none of our binaries.
    A compressor should generate identical output on any system: linux/pentium/gcc, windows/Intel core i7/visual studio, Mac OS/68000,...
    It can only be achieved by modifying the source to avoid te use of floating point operations.

    By the way, the issue do not happen of most sound files. Try your binaries on this collection of files: http://encode.dreamhosters.com/showthread.php?t=408
    It contains 2 or 3 files where you can see the problem (the AIFF files IIRC)
    Last edited by M4ST3R; 5th April 2010 at 18:51.

  14. #614
    Member Skymmer's Avatar
    Join Date
    Mar 2009
    Location
    Russia
    Posts
    688
    Thanks
    41
    Thanked 173 Times in 88 Posts
    Yes, and more exactly speaking the Sine_generator_65Hz.wav is the one. For example here is the CRCs for different persons who provided v68 compiles.
    Tested on -6 level as: paq8px -6 Test Sine_generator_65Hz.wav
    Code:
    Jan Ondrus  149D03F9
    LovePimple  641D5834
    M4ST3R      1F0EF6FA
    Sha Lun     1F0EF6FA
    EDIT:
    Also seems that Shalun's compiles do not support wildcards. As for the speed... Here are the results for TestBed.tar on -6 level.
    Code:
    M4ST3R
    paq8px_v68.exe                    999.181
    paq8px_v68_Wildcard.exe          1003.046
    paq8px_v68_Intel_SSE2.exe         991.797
    paq8px_v68_Intel_SSE2_Wildcard    992.120
    
    Sha Lun
    paq8px_v68_ia32.exe              1132.966
    paq8px_v68_sse2.exe              1111.039
    Last edited by Skymmer; 6th April 2010 at 08:53.

  15. #615
    Member
    Join Date
    Apr 2010
    Location
    Ukraine
    Posts
    5
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Ok, i'll try to modify the source for excluding floating-point arithmetic. But can you show me your compiler options?
    Mine was:
    Code:
    icl /DWINDOWS /Os /arch:IA32 /fp:precise /Fepaq8px_v68_ia32.exe paq8px_v68.cpp paq7asm.obj
    icl /DWINDOWS /Os /arch:SSE2 /fp:precise /Fepaq8px_v68_sse2.exe paq8px_v68.cpp paq7asm_sse2.obj

  16. #616
    Member
    Join Date
    May 2009
    Location
    Europe
    Posts
    67
    Thanks
    0
    Thanked 1 Time in 1 Post
    With these options your mmx and sse2 builds should be compatible with each other.
    Replace /fp:precise by /fp:fast and you should see the issue on Sine_generator_65Hz.wav

  17. #617
    Member Wladmir's Avatar
    Join Date
    Apr 2010
    Location
    Brazil
    Posts
    18
    Thanks
    0
    Thanked 0 Times in 0 Posts

    I can not compress with paq8px v68

    I drag, but it happens that the image shows. I have also tried typing the command line and gives the same message, and it happens with all versions that succeeded v68
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	ScreenHunter_01 Apr. 19 17.41.jpg 
Views:	384 
Size:	28.1 KB 
ID:	1263  

  18. #618
    Member
    Join Date
    Apr 2010
    Location
    CA, USA
    Posts
    1
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Sha Lun View Post
    Ok, i'll try to modify the source for excluding floating-point arithmetic. But can you show me your compiler options?
    Mine was:
    Code:
    icl /DWINDOWS /Os /arch:IA32 /fp:precise /Fepaq8px_v68_ia32.exe paq8px_v68.cpp paq7asm.obj
    icl /DWINDOWS /Os /arch:SSE2 /fp:precise /Fepaq8px_v68_sse2.exe paq8px_v68.cpp paq7asm_sse2.obj
    Use of the Intel compiler can cause large slowdowns on AMD and VIA chips. See http://www.agner.org/optimize/blog/read.php?i=49 for an explanation. There is a workaround, that involves overriding Intel's Dynamic Dispatch code, so that it will no longer force AMD and VIA chips to use the least-optimized path. EDIT: Workaround is linked to at the bottom of the post I linked to. Instead of bothering with the work-around, GCC can be used as an alternative, but its library functions are not as well optimized as the Intel ones.

  19. #619
    Member Wladmir's Avatar
    Join Date
    Apr 2010
    Location
    Brazil
    Posts
    18
    Thanks
    0
    Thanked 0 Times in 0 Posts

    answer my question

    I drag, but it happens that the image shows. I have also tried typing the command line and gives the same message, and it happens with all versions that succeeded v68

  20. #620
    Programmer Jan Ondrus's Avatar
    Join Date
    Sep 2008
    Location
    Rychnov nad Kněžnou, Czech Republic
    Posts
    279
    Thanks
    33
    Thanked 138 Times in 50 Posts
    Quote Originally Posted by Wladmir View Post
    I drag, but it happens that the image shows. I have also tried typing the command line and gives the same message, and it happens with all versions that succeeded v68
    Sorry I can't reproduce your problem. Can you provide more info about your system? What compile was used? Does it fail for all files or only those in your root folder (C:\*.*)?

  21. #621
    Member
    Join Date
    Jun 2009
    Location
    Puerto Rico
    Posts
    190
    Thanks
    84
    Thanked 18 Times in 14 Posts

    Post

    Quote Originally Posted by Jan Ondrus View Post
    Sorry I can't reproduce your problem. Can you provide more info about your system? What compile was used? Does it fail for all files or only those in your root folder (C:\*.*)?
    Hi,

    I also have the same problem with the ALL of the PAQ8PX v68 builds.


    Notice in the image that Wladmir posted that the PAQ executable is located at: C:\paq8px_v68\paq8px.exe

    And that the file he's trying to compress is at: C:\
    and the file is C:\image.jpg

    So, as you can see, the PAQ executable and the file to be compressed are in different paths.

    If you copy image.jpg to C:\paq8px_v68\ folder you should not see this problem as both the paq8px.exe and the image.jpg are in the same folder.

    This problem only happens when both files are in different folders, and this same case happens not only with files, but with folders.

  22. #622
    Member Wladmir's Avatar
    Join Date
    Apr 2010
    Location
    Brazil
    Posts
    18
    Thanks
    0
    Thanked 0 Times in 0 Posts

    paq8px_v68 not working

    This happens with any file in any folder, and all levels of compression. I used the version contained in the file "compiled_v68.zip" and the file "paq8px_v68.zip". My operating system is Windows XP Professional SP3.
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	ScreenHunter_01 Apr. 25 19.23.jpg 
Views:	304 
Size:	28.7 KB 
ID:	1272  

  23. #623
    Programmer Jan Ondrus's Avatar
    Join Date
    Sep 2008
    Location
    Rychnov nad Kněžnou, Czech Republic
    Posts
    279
    Thanks
    33
    Thanked 138 Times in 50 Posts
    Quote Originally Posted by Wladmir View Post
    This happens with any file in any folder, and all levels of compression. I used the version contained in the file "compiled_v68.zip" and the file "paq8px_v68.zip". My operating system is Windows XP Professional SP3.
    paq8px_v69
    - problem with compressing files in different paths fixed.
    Attached Files Attached Files

  24. #624
    Moderator

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

    Thumbs up

    Thanks Jan!

    Compiled...
    Attached Files Attached Files

  25. #625
    Member
    Join Date
    Jun 2009
    Location
    Puerto Rico
    Posts
    190
    Thanks
    84
    Thanked 18 Times in 14 Posts

    Thumbs up

    Thanks Jan Ondrus and LovePimple!

    I've tested this release and it does fix the path problems.

    I've tested this with the PAQ executable on my desktop and compressing a file on my external Hard Disk Drive (letter J:\)

    I've posted a screen of a successful compressed archive.

    Good Job!
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	success.jpg 
Views:	417 
Size:	73.3 KB 
ID:	1276  

  26. #626
    Member Wladmir's Avatar
    Join Date
    Apr 2010
    Location
    Brazil
    Posts
    18
    Thanks
    0
    Thanked 0 Times in 0 Posts

    paq8px_v60.zip

    The 69 compiled version worked, but I wanted to know the differences between the executable files in the file "paq8px_v69.zip" attached by LovePimple.

  27. #627
    Moderator

    Join Date
    May 2008
    Location
    Tristan da Cunha
    Posts
    2,034
    Thanks
    0
    Thanked 4 Times in 4 Posts
    The _alt (alternative) builds will be faster on some machines. Usually AMD processor based machines.

  28. #628
    Member Wladmir's Avatar
    Join Date
    Apr 2010
    Location
    Brazil
    Posts
    18
    Thanks
    0
    Thanked 0 Times in 0 Posts

    paq8px is very slow

    The WinRK has a speed of 10 kbytes/s while the speed has paq8px 3 kbytes/s. The WinRK already higher levels of compression paq8px in various types of files as shown on the site: http://www.maximumcompression.com/
    Several programs are very close to the level of compression in a -3 speed greater good.
    Thinking about it, wondered if it would be developed faster version on machines based on Intel processors.

  29. #629
    Member
    Join Date
    Jun 2009
    Location
    Puerto Rico
    Posts
    190
    Thanks
    84
    Thanked 18 Times in 14 Posts
    There is a faster version of PAQ called PAQ8PF.

    You can read of PAQ8PF here: http://encode.dreamhosters.com/showthread.php?t=457

    It has faster speed but compression is not as good as PAQ8PX. However, I still like PAQ8PF considering the speed it compresses my files and folders.

  30. #630
    Member Wladmir's Avatar
    Join Date
    Apr 2010
    Location
    Brazil
    Posts
    18
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Thumbs up paq8px_v69.zip->paq8px_v69_sse2.exe (the faster build)

    The faster build of paq8px is the paq8px_v69_sse2.exe build. I have a intel based machine.

Page 21 of 61 FirstFirst ... 11192021222331 ... LastLast

Similar Threads

  1. FrontPAQ - GUI frontend for PAQ8PF and PAQ8PX
    By LovePimple in forum Download Area
    Replies: 26
    Last Post: 17th January 2019, 14:36
  2. Alternative paq8px builds
    By M4ST3R in forum Download Area
    Replies: 20
    Last Post: 25th June 2010, 17:19
  3. Optimized paq7asm.asm code not compatible with paq8px?
    By M4ST3R in forum Data Compression
    Replies: 7
    Last Post: 3rd June 2009, 16:34

Tags for this Thread

Posting Permissions

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