Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Horrible performance of lossless codecs (Read 11347 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Horrible performance of lossless codecs

Reply #25 –
Quote
All of them do. Imagine PPM or BWT without arithmetic coding?

-Eugene

Well, bzip2 does use BWT and regular Huffman...  but this is for performance and patent issues, of course.

Btw, have you made a compressor yourself Eugene ?

Horrible performance of lossless codecs

Reply #26 –
Quote
Quote
All of them do. Imagine PPM or BWT without arithmetic coding?

-Eugene

Well, bzip2 does use BWT and regular Huffman...  but this is for performance and patent issues, of course.

Btw, have you made a compressor yourself Eugene ?

I thought bzip2 uses some sort of rangecoding. Seems I was wrong. 
At least, most use rangecoding after BWT

Compressor? I've tried several times, but never got anything usefull. LZW and PPM like things were rather funny, though 

-Eugene
The  greatest  programming  project of all took six days;  on the seventh  day  the  programmer  rested.  We've been trying to debug the !@#$%&* thing ever since. Moral: design before you implement.

Horrible performance of lossless codecs

Reply #27 –
I wrote a LZ77 or LZW program (can't remember) once, but its performance was catastrophic: it inflated files most of the time 

Horrible performance of lossless codecs

Reply #28 –
Garf, could you please make this sample available again? I wanted to try it with WavPack4's assymetrical modes. (quoting David's readme: "Because the standard compression parameters are optimized for "normal" audio, this option works best with "non-standard" audio where it can often achieve enormous gains.")

also:
Quote
RAR (Best) => 80'162 bytes
RAR (Good) => 81'523 bytes
RAR (Normal) => 27'680 bytes 
RAR (Fast) => 55'240 bytes
RAR (Fastest) => 105'302 bytes


The reason is simple. RAR's audio compression routines automatically kick in at Best and Good modes. So at Best and Good it tries to compress it as audio, and at Normal, Fast and Fastest it compresses it as general data.

Quote
In "Auto" mode WinRAR will decide when to use the audio compression depending on source data and only if "Good" or "Best" compression method is selected.


Regards;

Roberto.

Horrible performance of lossless codecs

Reply #29 –
Quote
Garf, could you please make this sample available again?

I still have that file and just ran it through a bunch of lossless audio compressors (plus the old and new WavPacks, of course):

Code: [Select]
             Original File
             -------------
 10,584,044 garf.wav     (orginal file)

          Monkey's Audio 3.97
          -------------------
  5,642,404 garf-xh.ape  (extra high mode)
  5,494,040 garf-h.ape   (high mode)
  4,530,440 garf-n.ape   (normal mode)
  4,527,024 garf-f.ape   (fast mode)

                 FLAC
                 ----
  4,425,222 garf-1.flac  (mode 1)
  4,397,071 garf-5.flac  (mode 5)
  4,392,479 garf-8.flac  (mode 8)

            OptimFROG 4.507
            ---------------
     53,186 garf.ofr     (default mode)
      2,985 garf2.ofr    ("newbest" mode)

               RKAU 1.07
               ---------
    164,261 garf-1.rka   (fast mode)
    590,353 garf-3.rka   (high mode)

                LA 0.4
                ------
  3,343,564 garf-h.la    (high mode)
  2,364,142 garf.la      (default mode)

                WavPack
                -------
  2,134,878 garf-ff.wv    (3.97, very fast mode)
  1,476,068 garf-ff.wv    (4.0a2, very fast mode)
    766,124 garf-ffx4.wv  (4.0a2, very fast mode, extra processing)

  1,804,879 garf-f.wv     (3.97, fast mode)
  1,503,778 garf-f.wv     (4.0a2, fast mode)
    769,248 garf-fx4.wv   (4.0a2, fast mode, extra processing)

  4,034,834 garf-n.wv     (3.97, default mode)
  1,741,260 garf-n.wv     (4.0a2, default mode)
    770,792 garf-x4.wv    (4.0a2, default mode, extra processing)

  4,035,317 garf-h.wv     (3.97, high mode)
  2,675,828 garf-h.wv     (4.0a2, high mode)
    768,158 garf-hx3.wv   (4.0a2, high mode, extra processing)


The first interesting point is that WavPack, RKAU, LA and Monkey's Audio all have the characteristic that the "higher" modes do worse than the "faster" modes.

Second, the "extra" processing mode does significantly help WavPack's performance with this sample.

Finally, OptimFROG is pretty amazing. Good job, Florin!