Page 13 of 24 FirstFirst ... 3111213141523 ... LastLast
Results 361 to 390 of 717

Thread: Paq8pxd dict

  1. #361
    Tester
    Stephan Busch's Avatar
    Join Date
    May 2008
    Location
    Bremen, Germany
    Posts
    876
    Thanks
    474
    Thanked 175 Times in 85 Posts
    @kaido

    The summary of paq8pxd is confusing me because it is split up in different levels that are not reader-friendly.
    I would prefer a summary that lists all those detected streams and just lists below base64 and zlib, was was detected inside (in bytes).
    And could we write 'PNG' as detected stream on png rather than zlib?

    Could the detection/recompression issue be fixed I reported?
    The 8.3GB .tar gets recompressed to 8.6GB with latest Precomp (without bz2/lzma compression).
    paq8pxd_v32 created temp files of 100GB in size and preprocessing was still in process but disk was full.
    Several times, really large blocks like this were reported before:

    34623 | default |18446744069414584000 b [4592626267 - 297658983]
    ..
    34641 | default |18446744069417353000 b [4593154572 - 300956980]
    ..
    34643 | jpeg |18446744069414724000 b [4597491971 - 302662997]
    ..

  2. #362
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    451
    Thanks
    181
    Thanked 271 Times in 149 Posts
    paq8pxd_v34

    This version has most of the changes made in paq8px thread.
    Can handle properly +2GB files.

    Big thanks to mpais for getting 24 bit png model to work in pxd version.
    Attached Files Attached Files
    KZo


  3. Thanks (2):

    Darek (10th September 2017),Stephan Busch (10th September 2017)

  4. #363
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    997
    Thanks
    602
    Thanked 409 Times in 307 Posts
    Here scores for v34 from my testbed. Great improvement! Mostly from image and exe files but there also some gains from other kind of files!
    Total improvement = 88KB - great!

    As I wrote earlier - there is also an opportunity in M.DBF file which have better ratio for paq8px and other compressors.
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	paq8pxd_v34.jpg 
Views:	111 
Size:	411.2 KB 
ID:	5298  

  5. Thanks:

    kaitz (18th September 2017)

  6. #364
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    997
    Thanks
    602
    Thanked 409 Times in 307 Posts
    I've started to test SILESIA corpus and in Mozilla file there are communicates that "Transform fail at 0, skipping..." on some zlib and zlib PNG32 segments like at attached screenshot.
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	Transf_fails.jpg 
Views:	65 
Size:	135.1 KB 
ID:	5316  

  7. #365
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    3,257
    Thanks
    307
    Thanked 795 Times in 488 Posts
    Updated LTCB. I used zip rather than 7zip to get the decompressor sizes. http://mattmahoney.net/dc/text.html#1283

  8. Thanks:

    Darek (25th September 2017)

  9. #366
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    451
    Thanks
    181
    Thanked 271 Times in 149 Posts
    I am working on new version (really slowly). Table shows that compression time is reduced and output size is larger. Size is not large. This is idea, so more testing and tweaking is needed. Probably can gain some better compression. What this new version is doing? It skips context if there is no point to add it to contextmap.
    Say word list of only text. So no point to add number0 as context. Something like that. Also one ppm is missing, for this test. So compression time depends on input type.
    Click image for larger version. 

Name:	Untitled.png 
Views:	58 
Size:	10.4 KB 
ID:	5489

    nc - context set in model cm
    zc - context set to zero´skipped in model cm
    Code:
     nc 73060884 zc 28019225 
    sparseModel1
     nc 10450170 zc 6393 
     nc 10450129 zc 6434 
     nc 13934710 zc 7374 
     nc 17419052 zc 8553 
     nc 6966811 zc 4231 
    recordModelw
     nc 133326498 zc 44435073 
    wordModel
     nc 41761189 zc 65063 
    indirectModel
     nc 41241777 zc 584475 
    nestModel
     nc 13942084 zc 0 
    XMLModel
    KZo


  10. Thanks:

    Stephan Busch (9th November 2017)

  11. #367
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    997
    Thanks
    602
    Thanked 409 Times in 307 Posts
    Looks promising -> 15% time reduce and 3.5% less memory usage at the "cost" of 0.2%-0.4% larger output!
    If you need some testing - I'm here.

  12. Thanks:

    Stephan Busch (9th November 2017)

  13. #368
    Member
    Join Date
    Sep 2015
    Location
    Italy
    Posts
    264
    Thanks
    110
    Thanked 153 Times in 112 Posts
    Quote Originally Posted by kaitz View Post
    It skips context if there is no point to add it to contextmap
    Do you skips dynamically (during compression) or statically (whole file) the contexts?
    If dynamically, how do you handle the skipped predictions in the mixer?
    Do you renormalize the mixer prediction?
    In cmv there are contexts that may not give predictions (sometimes or often, depending by the data), my current best solution is to not renormalize and not update the weights of the skipped predictors.
    TIA

  14. #369
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    451
    Thanks
    181
    Thanked 271 Times in 149 Posts
    Quote Originally Posted by Mauro Vezzosi View Post
    Do you skips dynamically (during compression) or statically (whole file) the contexts?
    It is dynamic. If intent of context is to use for example word0 word3, and it is meant to be relevant only if word3 is not zero then skip it.
    Quote Originally Posted by Mauro Vezzosi View Post
    If dynamically, how do you handle the skipped predictions in the mixer?
    Do you renormalize the mixer prediction?
    Nothing special, mixer has same amount of inputs. I need t test without it.
    Quote Originally Posted by Mauro Vezzosi View Post

    In cmv there are contexts that may not give predictions (sometimes or often, depending by the data), my current best solution is to not renormalize and not update the weights of the skipped predictors.
    TIA
    weights are updated, not sure if this is a problem.

    Code:
    
    
    
    
    if(word3  ) cm.set(hash(279,h, word1,word3));else cm.set(0);
    ....
    if (fl<7) cm.set(hash(528,mask,0));else cm.set(0);
    and contextmap skips this and adds mixer inputs with 0.

    Whole point is not to use contextmap hash lookup. And/or there are context that are useless. At least this is how i can see...
    KZo


  15. Thanks:

    Mauro Vezzosi (10th November 2017)

  16. #370
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    451
    Thanks
    181
    Thanked 271 Times in 149 Posts
    paq8pxd_v35

    • -zlib,im8 changes from paq8px_v120
    • -remove one ppm model
    • -skip zero context in contextmap for speed
    • -change wordmodel
    • -small fixes


    So, speed, effect is only on text files and it depends on file content. On some files it can be slower, mostly is (compared to v34). Final version is not what i wanted to do.
    maximumcompression corpus has some gains, and silesia should be better. enwik8 will be worse i think.
    Also removed SIMD RLC in ContexMap (added this in v24), current setup will not work with this.
    Attached Files Attached Files
    KZo


  17. Thanks (2):

    Darek (26th November 2017),Stephan Busch (26th November 2017)

  18. #371
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    997
    Thanks
    602
    Thanked 409 Times in 307 Posts
    Here are scores for my testset with v35 and v34 comparison. Quite nice improvements for image files, I.EXE and M.DBF. Some loses for the biggest K.WAD and P.FM3.
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	paq8px_121_pxd_35.jpg 
Views:	64 
Size:	504.4 KB 
ID:	5517  

  19. #372
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    997
    Thanks
    602
    Thanked 409 Times in 307 Posts
    I've found two errors in v35 version.

    The first is regarding G.EXE file with option -s4 and lower - program crash. I've attached g.exe file in this post and screen from this error.

    The second is observed during enwik9 compression - at first paq8pxd found some zlib parts inside enwik9 then it didn't stop after 100% of main part compression
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	error_v35.jpg 
Views:	43 
Size:	85.8 KB 
ID:	5529  
    Attached Files Attached Files
    • File Type: 7z G.7z (1.38 MB, 32 views)

  20. Thanks:

    kaitz (8th December 2017)

  21. #373
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    997
    Thanks
    602
    Thanked 409 Times in 307 Posts
    And paq8pxd_v35 scores for Calgary, Canterbury, Silesia and maximum Compression Corpuses.
    Silesia w/o preprocessing is approaching to less than 31'xxx'xxx bytes!
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	paq8pxd_v35_can_cal_sil_max.jpg 
Views:	76 
Size:	567.9 KB 
ID:	5532  

  22. Thanks:

    kaitz (8th December 2017)

  23. #374
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    451
    Thanks
    181
    Thanked 271 Times in 149 Posts
    I will see what can i do to fix this problems. No eta for fix.
    KZo


  24. #375
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    451
    Thanks
    181
    Thanked 271 Times in 149 Posts
    progress...

    squeezechart bible set rus.txt
    UTF8 capital letter conversion only for dictionary. (v36 has greek,russian,latin suplement)




    Code:
                                     Size     Compressed   Capital conversion
    paq8pxd_v36 -s0   rus.txt        6356919  3691648      off
    paq8pxd_v36 -s0   rus.txt        6356919  3783460      on
    paq8pxd_v36 -s8:2 rus.txt        6356919   689904      on
    paq8pxd_v36 -s8:2 rus.txt        6356919   695247      off
    paq8px_v121 -8    rus.txt        6356919   724538      no conversion
    paq8px_v121 -8    rus.txt.pxd36  3691648   710124      off
    paq8px_v121 -8    rus.txt.pxd36  3783460   705990      on


    I tested paq8pxd_v36 with recursion on pxd36 -s0 output, forced to text mode and wrt output reduced size about 200kb but compressed result was about 20kb larger.


    enwik8 seems to benefit from this.
    Wonder if phda9 (https://encode.su/threads/2858-Hutte...ll=1#post55202) has this conversion or would it benefit from this type of conversion?
    KZo


  25. Thanks (2):

    byronknoll (19th December 2017),Darek (18th December 2017)

  26. #376
    Member
    Join Date
    Mar 2011
    Location
    USA
    Posts
    240
    Thanks
    112
    Thanked 113 Times in 69 Posts
    Thanks kaitz - can you post the code for UTF8 capital letter conversion? cmix might benefit from this.

  27. #377
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    451
    Thanks
    181
    Thanked 271 Times in 149 Posts
    Quote Originally Posted by byronknoll View Post
    Thanks kaitz - can you post the code for UTF8 capital letter conversion? cmix might benefit from this.
     
    //cyrillic
    if (buf(1)>=0x90 && buf(1)<=0x9F && buf(2)==0xd0 ){
    buf[buf.pos]=buf(1)+0x20,c=buf(1),x.c4=(x.c4&0xffffff00)+buf(1);
    }
    else if (buf(1)> 0x9F && buf(1)<=0xAF && buf(2)==0xd0){
    buf[buf.pos]=buf(1)+0xE0,c=buf(1);
    buf[buf.pos-1]=0xD1,x.c4=(x.c4&0xffff0000)+buf(1)+(buf(2)<<8);
    }
    //greek
    else if (buf[1]>=0x91 && buf(1)<=0x9f && buf(2)==0xce ){
    buf[buf.pos]=buf(1)+0x20,c=buf(1),x.c4=(x.c4&0xffffff00)+buf(1);
    }
    else if (buf(1)> 0x9f && buf(1)<=0xA9 && buf(2)==0xce){
    buf[buf.pos]=buf(1)+0xE0,c=buf(1);
    buf[buf.pos-1]=0xcf,x.c4=(x.c4&0xffff0000)+buf(1)+(buf(2)<<8);
    }
    //latin 1 suplement
    else if (((buf(1)>=0x80 && buf(1)<=0x96)||(buf(1)>=0x98 && buf(1)<=0x9e)) && buf(2)==0xc3){
    buf[buf.pos]=buf(1)+0x20,c=buf(1),x.c4=(x.c4&0xffffff00)+buf(1);
    }

    I have similar to this on wrt. I did not have online version in wordmodel. Add this before A-z conversion in wordmodel. So above is quick test and on rus.txt in online mode its about 1kb worse compared to dictionary solution.
    This may have some bad results on unknown binary data.
    KZo


  28. #378
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    451
    Thanks
    181
    Thanked 271 Times in 149 Posts
    paq8pxd_v36
    -wrt utf8 capital conversion for greek,cyrillic,latin suplement
    -reduce arhcive size for small files
    -changed wordmodel
    -small fixes
    -bintext data type
    -progress to stderr so you can see it and it will not pollute 'prog arg >resultfile'
    -24 bit image model changes from paq8px_v123
    -change encoder
    -zlib image fix


    So this version does better on enwik8,mc/silesia set, bible set.
    Well you can look at source code to see what really has changed.

    I recommend -s0 test first for unknown data. (vm.dll is identical)
    Attached Files Attached Files
    KZo


  29. Thanks:

    Darek (20th December 2017)

  30. #379
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    997
    Thanks
    602
    Thanked 409 Times in 307 Posts
    Here are scores for my testset for v36. 37KB of gain in total.
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	paq8pxd_v36x64.jpg 
Views:	54 
Size:	507.7 KB 
ID:	5554  

  31. Thanks:

    kaitz (20th December 2017)

  32. #380
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    451
    Thanks
    181
    Thanked 271 Times in 149 Posts

    new version

    Quote Originally Posted by Darek View Post
    I've found two errors in v35 version.

    The first is regarding G.EXE file with option -s4 and lower - program crash. I've attached g.exe file in this post and screen from this error.
    paq8pxd_v37
    Should be fixed.

    paq8pxd_v38
    im4 model: replace HashTable with BH
    v37 still failed to decompress correctly g.exe, not sure why.
    Attached Files Attached Files
    Last edited by kaitz; 20th December 2017 at 18:16.
    KZo


  33. Thanks:

    Darek (20th December 2017)

  34. #381
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    997
    Thanks
    602
    Thanked 409 Times in 307 Posts
    I've found some kind of strange behaviour of newer versions of paq8pxd - it needs quite big disc temporary memory/file to compress - I've found it when I tried to compress enwik9 but maybe it occurs with files contains lots of small founded segments.
    If there are lack of disk space then program cut one or more transformation parts with communicate "transform fails at xxxxxx, skipping" and only already processed part is compressed - that means not 100% of file could be compressed. No error communicate and program runs - however sometimes didn't stop at 100%.

    Did you check free space on disk?

  35. #382
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    451
    Thanks
    181
    Thanked 271 Times in 149 Posts
    paq8pxd_v39
    - detect dBase files (based on paq8px_v124)
    - detect 1 bit images in pdf
    - gif gray (paq8px_v124)
    - recordmodel changes (paq8px_v124)
    - text detect change
    - zlib fix for negative pos
    - reduce compiler warnings
    - modify DEC Alpha detection, enable

    Link contains sample pdf file witch has about 11000 1bit images.
    https://drive.google.com/open?id=1CW...W1zG8Sr-pVS1-h

    ARUAREPS.DBF
    Code:
                      Size     Compressed
    paq8pxd_v39 -s8:2 1332427  16828 
    paq8px_v124 -8    1332427  16602 
    paq8pxd_v38 -s8:2 1332427  18684
    DEC filter should now work.
    query.dll
    Code:
                      Size    Compressed
    paq8pxd_v39 -s8:2 1952016 378427 
    paq8px_v124 -8    1952016 388010 
    paq8pxd_v38 -s8:2 1952016 386316
    Quote Originally Posted by Darek View Post
    I've found some kind of strange behaviour of newer versions of paq8pxd - it needs quite big disc temporary memory/file to compress - I've found it when I tried to compress enwik9 but maybe it occurs with files contains lots of small founded segments.
    If there are lack of disk space then program cut one or more transformation parts with communicate "transform fails at xxxxxx, skipping" and only already processed part is compressed - that means not 100% of file could be compressed. No error communicate and program runs - however sometimes didn't stop at 100%.

    Did you check free space on disk?
    No free disk space is checked.
    Attached Files Attached Files
    KZo


  36. Thanks (4):

    Darek (23rd December 2017),Mike (23rd December 2017),mpais (23rd December 2017),WhatTheBlock (25th December 2017)

  37. #383
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    451
    Thanks
    181
    Thanked 271 Times in 149 Posts
    paq8pxd_v40


    • resolve conflict in WRT vs EOLencode
    • modify wordmodel



    For this version enwik8 has best result up to v40. I will test enwik9.
    Attached Files Attached Files
    KZo


  38. #384
    Member
    Join Date
    Aug 2015
    Location
    indonesia
    Posts
    155
    Thanks
    15
    Thanked 17 Times in 15 Posts
    Quote Originally Posted by kaitz View Post
    paq8pxd_v40


    • resolve conflict in WRT vs EOLencode
    • modify wordmodel



    For this version enwik8 has best result up to v40. I will test enwik9.
    when i compile using dev c++ why this is happen ?
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	paq8pxd40.JPG 
Views:	63 
Size:	127.2 KB 
ID:	5576  

  39. #385
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    451
    Thanks
    181
    Thanked 271 Times in 149 Posts
    Silesia:
    Click image for larger version. 

Name:	paq8pxd_v40_silesia.png 
Views:	47 
Size:	9.7 KB 
ID:	5577

    enwik8:
    Code:
    paq8pxd_v40    -s8  16475908  2581 MB 6543.31 sec
    paq8pxd_v40    -s9  16327321  5093 MB 6583.51 sec
    paq8pxd_v40    -s10 16262212  9021 MB 6768.32 sec
    paq8pxd_v40    -s11 16253422 10733 MB 6720.49 sec
    paq8pxd_v40    -s12 16249392 12109 MB 6648.78 sec
    paq8pxd_v40    -s13 16247871 14861 MB 6680.45 sec
    paq8pxd_v40    -s14      cant test, disk swap
    enwik9:
    Code:
    paq8pxd_v40    -s8   134237571 2581 MB 67317.43 sec
    Last edited by kaitz; 26th December 2017 at 13:35. Reason: timings and -s11 - s13 for enwik8
    KZo


  40. Thanks (2):

    Darek (25th December 2017),WhatTheBlock (25th December 2017)

  41. #386
    Member WhatTheBlock's Avatar
    Join Date
    Dec 2017
    Location
    Taiwan
    Posts
    1
    Thanks
    2
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by suryakandau@yahoo.co.id View Post
    when i compile using dev c++ why this is happen ?
    you need zlib header file
    just a newbie

  42. #387
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    997
    Thanks
    602
    Thanked 409 Times in 307 Posts
    Here are two tables: comparison of my testset with v40 vs. latest v39, and some enwik scores for paq/cmix/emma/cmv. Red numbers are estimates, yellow label is a option to test in the near future.
    Then I'll test v40 for enwik8/enwik8.drt and enwik9_1423, however I need to wait next 27h to finish enwik9 decompression test by latest cmve (i need it to fullfil LTCB data). cmve decompression consumes 19GB of memory and best paq8pxd results for both enwik8 and enwik9 are with -s15 option which consumes also 20-30GB of memory. I'll need to wait a while.
    From my estimates v40 mcould go to 128'00x'xxx bytes - 200'000 bytes better than previous LTCB submission
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	paq8pxd_v40.jpg 
Views:	52 
Size:	560.8 KB 
ID:	5584   Click image for larger version. 

Name:	enwik_table_dec.jpg 
Views:	40 
Size:	163.4 KB 
ID:	5585  

  43. #388
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    997
    Thanks
    602
    Thanked 409 Times in 307 Posts
    Here are some scores for v40 - my testset, Calgary, Canterbury, Silesia and MaxCompression corpuses and enwik8/9.
    ENWIK8 -s14 score is 16'227'868 - quite big difference than -s13 option but I've checked -s13 and I've got the same result as Kaitz.
    ENWIK8 -s15 score is 16'227'279 - small difference.

    Looks like v36 have best enwik9 compression up to date despite best enwik8 compression by v40. Red numbers are estimated and I'll check pure enwik9 scores also for v36 and v40.

    However I've found some errors. There are crashes for:

    G.EXE and H.EXE files for options -s13 and higher
    AcroRd32.exe, FlashMX.pdf and MSO97.DLL from MaximumCompression Corpus for options -s13 and higher (I've tested these files with -s12 option)
    mozilla from Silesia corpus for option -s15 (I've tested this file with -s14 option)

    One insight more - there are strange difference between paq8pxd and paq8px for samba file from Silesia corpus =+70KB. Other files from all corpuses have similar compression except textual files when paq8pxd got better results. This one have quite big disadvantage...
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	LTCB_v40.jpg 
Views:	40 
Size:	205.9 KB 
ID:	5600   Click image for larger version. 

Name:	All_corpuses_v40.jpg 
Views:	43 
Size:	567.5 KB 
ID:	5601   Click image for larger version. 

Name:	paq8pxd_v40.jpg 
Views:	38 
Size:	560.7 KB 
ID:	5599  

  44. Thanks:

    kaitz (3rd January 2018)

  45. #389
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    997
    Thanks
    602
    Thanked 409 Times in 307 Posts
    I've finished test of pure enwik9 by v36. Now v40 is in progress.
    It looks that rations are unchanged until previous versions - still pure enwik9 is about 80-90KB less compressible than enwik9_1423. DRT versions even worse.

    v36 scores:
    128'166'102 - enwik9 by paq8pxd_v36 -s15
    128'080'625 - enwik9_1423 by paq8pxd_v36 -s15 - this score is about 130KB better than best paq8pxd submission to LTCB! Only about 450KB worse score than durilca'kingsize second place

    v40 scores:
    128'164'463 - enwik9 by paq8pxd_v40 -s15
    128'081'941 - enwik9_1423 by paq8pxd_v40 -s15
    Last edited by Darek; 4th January 2018 at 18:17.

  46. #390
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    451
    Thanks
    181
    Thanked 271 Times in 149 Posts
    v41



    • - file class, image model, wordmodel changes from paq8px_v128
    • - removed option -q -f
    • - small gain on heavily segmented files.
    • - tweak tar parsing, fixes samba compression
    • - another change to wordmodel
    • - tweak jpeg class


    There are more changes but, count them as etc.

    maximumcompression should be around 625xxxx bytes compressed with option -s8
    silesia should be around 311xxxxx bytes compressed with option -s8




    exe compression is still problematic, cant figure out why it is so much worse then px version.
    Attached Files Attached Files
    KZo


  47. Thanks:

    Darek (5th January 2018)

Page 13 of 24 FirstFirst ... 3111213141523 ... LastLast

Similar Threads

  1. FreeArc compression suite (4x4, Tornado, REP, Delta, Dict...)
    By Bulat Ziganshin in forum Data Compression
    Replies: 554
    Last Post: 26th September 2018, 03:41
  2. Dict preprocessor
    By pat357 in forum Data Compression
    Replies: 5
    Last Post: 2nd May 2014, 22:51

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
  •