Skip to main content

Topic: Comparison of lossless codecs with LossyWAV processed files. (Read 7354 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • lvqcl
  • [*][*][*][*][*]
  • Developer
Comparison of lossless codecs with LossyWAV processed files.
There is a number of lossless codec comparisons, but I didn't found a test that compares efficiency and speed of audio compressing after LossyWAV preprocessing. So I did this test myself. This test isn't universal: all test samples fall under the genres of pop and rock, and are relatively loud: their ReplayGain value is about –6…–10 dB. Compression ratio of original files is ~ 67…70% (relatively poor). All files are 44.100 Hz, 16 bit, stereo.

My PC: Core2Duo E4600 (2.4 GHz), 3GB RAM, WinXP SP3 (32bit).

I tested the following codecs:
Code: [Select]
Codec         Version   Additional parameters
FLAC          1.2.1     -b 512
TAK           1.1.2     -fsl512
WavPack       4.50.0    --blocksize=512 --merge-blocks
WMA Lossless  9.2       (none)
Shorten       3.6.1     (none)
LPAC          3.08      (none)
--------------------------------
LossyWAV      1.1.4d    -F
Monkey's Audio (4.06), LA (0.4b), True Audio (3.4.1) are incompatible with LossyWAV. OptimFROG (4.600ex) partially benefits from it, but *.lossy.ofr files are 25…30% bigger than e.g. *.lossy.flac. So these codecs were excluded from the test.

Results:
Code: [Select]
Settings	Compression	Encoding	LossyWAV+encoding	Decoding	
time rate time rate time rate
FLAC -0 35,521 14,5 282 82,1 50 10,8 379
FLAC -1 36,659 16,1 255 83,7 49 11,1 370
FLAC -2 34,587 20 205 87,6 47 10,1 373
FLAC -3 33,56 20,6 199 88,2 47 11,5 357
FLAC -4 34,614 23 178 90,6 45 11,8 347
FLAC -5 32,741 35,9 114 103 40 11,7 350
FLAC -6 32,741 40,9 100 108 38 11,7 350
FLAC -7 32,708 140 29 208 20 11,7 350
FLAC -8 32,698 185 22 253 16 11,7 350
TAK –p0 32,515 15,8 259 83,4 49 11 374
TAK –p0e 32,423 19,4 212 86,9 47 11,1 370
TAK –p0m 32,362 43 95 111 37 11,1 368
TAK –p1 32,251 21,3 193 88,8 46 11,1 368
TAK –p1e 32,057 34,9 118 102 40 11,2 365
TAK –p1m 32,036 66,7 62 134 31 11,3 364
TAK –p2 31,922 33,5 123 101 41 11,4 361
TAK –p2e 31,667 55,1 74 123 33 11,5 356
TAK –p2m 31,657 103 40 171 24 11,7 352
TAK –p3 31,734 69 60 136 30 11,4 361
TAK –p3e 31,648 98 42 165 25 11,6 355
TAK –p3m 31,663 148 28 215 19 11,6 354
TAK –p4 31,646 98 42 165 25 11,5 356
TAK –p4e 31,663 157 26 224 18 11,5 356
TAK –p4m 31,663 169 24 237 17 11,6 354
WavPack –f 35,552 42,1 98 110 37 17,7 231
WavPack –f –x1 35,426 46 89 114 36 17,6 233
WavPack –f –x2 35,105 61,4 67 129 32 17,6 233
WavPack –f –x3 34,95 101 41 168 24 17,7 232
WavPack –f –x4 34,812 226 18 294 14 17,7 232
WavPack –f –x5 34,783 280 15 347 12 17,7 231
WavPack –f –x6 34,772 327 13 394 10 17,7 232
WavPack 34,973 57,8 71 125 33 23 178
WavPack –x1 34,664 66,6 62 134 31 22,7 181
WavPack –x2 34,597 103 40 170 24 22,7 181
WavPack –x3 34,487 191 21 259 16 22,8 180
WavPack –x4 34,217 659 6,2 726 5,6 22,9 179
WavPack –x5 34,171 922 4,5 989 4,1 22,9 179
WavPack –x6 34,101 1793 2,3 1861 2,2 22,9 179
WavPack –h 34,707 87,8 47 155 26 31,6 130
WavPack –h –x1 34,647 103 40 170 24 31,4 131
WavPack –h –x2 34,511 170 24 237 17 31,3 131
WavPack –h –x3 34,421 340 12 407 10 31,4 131
WavPack –h –x4 34,245 1074 3,8 1141 3,6 31,1 132
WavPack –h –x5 34,228 1446 2,8 1513 2,7 31 132
WavPack –h –x6 34,199 2016 2,0 2083 2,0 31,2 132
WavPack –hh 34,846 118 35 185 22 41,4 99
WavPack –hh –x1 34,803 142 29 210 20 41,4 99
WavPack –hh –x2 34,711 250 16 318 13 41,7 98
WavPack –hh –x3 34,647 518 7,9 586 7,0 41,6 99
WavPack –hh –x4 34,437 1546 2,7 1613 2,5 38 108
WavPack –hh –x5 34,42 2243 1,8 2310 1,8 37,9 108
WavPack –hh –x6 34,402 3052 1,3 3120 1,3 37,8 108
WMA Lossless 35,92 95 43 163 25 81,2 51
LPAC -2 34,844 62,2 66 130 32 33,1 124
LPAC -3 34,839 62,9 65 130 31 33 124
LPAC -4 34,815 91,5 45 159 26 38,1 108
LPAC -5 34,806 116 35 183 22 39 105
Shorten 35,055 32,1 128 100 41 16,7 245
Shorten –p 20 34,73 42 98 110 37 19,5 210
LossyWAV processing takes time, so I also added it to encoding time ("LossyWAV+encoding" column).


Graphs:
encoding speed vs. compression ratio:


preprocessing+encoding speed vs. compression ratio:


decoding speed vs. compression ratio:



Some personal conclusions (YMMV):
  • FLAC: -5 seems to be the optimal setting: (almost) best compression ratio and fast speed. FLAC -1 is worse than -0, and -4 is worse than -3. These settings use –M (--adaptive-mid-side) option; it looks like this option isn't good for LossyWAV'ed files.
  • TAK: the best (only FLAC -0 is faster than fastest TAK setting). Settings higher than –p2e are almost useless.
  • WavPack: high settings are worse than normal, and extra high are even worse. Interesting… In addition, all WavPack settings are worse than FLAC -3 or -5. Maybe this codec suffers too much from small block size. Anyway, -x option seems to be the best compromise between compression ratio and encoding speed.
  • WMA Lossless: worse than all other codecs. OTOH, it has good software and some hardware support.
  • Shorten, LPAC: not very popular codecs; FLAC -3 is both faster and gives better compression; almost absent software support for LPAC. I cannot find any reason to use these codecs.

  • Zarggg
  • [*][*][*][*][*]
Comparison of lossless codecs with LossyWAV processed files.
Reply #1
Your graphs might be easier to read if you use compression (%) for the y-axis and processing time (s) for the x-axis.
  • Last Edit: 16 August, 2009, 08:26:24 PM by Zarggg

  • Nick.C
  • [*][*][*][*][*]
  • Developer
Comparison of lossless codecs with LossyWAV processed files.
Reply #2
Thanks very much for taking the time to carry out the relative speed / compression testing. For FLAC at least it corroborates the (less detailed) evaluation I carried out some time ago now (in the first development thread, I think).

I use FLAC -5 for my lossyFLAC parallel library.
lossyWAV -q X -a 4 -s h -A --feedback 1| FLAC -5 -e -p -b 512 -P=4096 -S- ~= 320kbps

  • sauvage78
  • [*][*][*][*][*]
Comparison of lossless codecs with LossyWAV processed files.
Reply #3
Thanks a lot for your test, lossyflac results are very different from lossless flac results: -3 beats -4 & -0 beats -1, it means that the -M switch is not good at all with lossyflac & -4 & -1 should be avoided which is exactly the opposite of KTF's lossless comparison where -4 & -1 were shining.

From now on I will use -5 for lossywav, until Tak become open source then I will use Tak -p0 for all my needs.

Thks for making me realize the -M switch was not lossywav friendly.
  • Last Edit: 27 August, 2009, 04:05:18 PM by sauvage78
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4

  • lvqcl
  • [*][*][*][*][*]
  • Developer
Comparison of lossless codecs with LossyWAV processed files.
Reply #4
Quote
it means that the -M switch is not good at all with lossyflac & -4 & -1 should be avoided which is exactly the opposite of KTF's lossless comparison where -4 & -1 were shining.


I was surprised by this too. I decided to encode original samples just to be sure that there's nothing special with test samples.

encoding speed vs. compression ratio:


decoding speed vs. compression ratio:


So, for original samples flac -4 is almost as good as -5 (as expected!).

  • sauvage78
  • [*][*][*][*][*]
Comparison of lossless codecs with LossyWAV processed files.
Reply #5
... and -1 is better than -2 again now.

This 2nd test is much closer to what I expected, it seems to me that the -M switch is very tied to the test samples & to how large is the test set (Edit: True for lossless only). With a specific samples set you can made -1 & -4 looks unoptimized compared to  -2 & -5 but the bigger is the sample set the lower will be the size difference between -1 & -4 Vs. -2 & -5 ... so in the end -1 & -4 will have a speed advantage, with an almost zero compression penalty compared to -2 & -5.

The majority of flacs users are using -5 when in fact they would have some speed advantage using -4.
I guess most of them don't care as ripping is slower than encoding anyway, but there are some use (like decoding with cuetools for AR checking) where this speed gain is really usefull.
The bigger is your collection/the smaller is your CPU, the more you realize -4 is better than -5. (& -1 better than -2)

Using -4 also makes you less dependent to TAK opensourceness which has became some kind of vaporware over the years (... been waiting for the source since yalac) since the difference between -4 & TAK -p0 is  slightly more acceptable ( ... but Tak wins no doubt)

Edited: The good news is that I can use -4 on lossyflac again you almost made me switch to -3 ! you  little evil

Edit: Due to a miss-understanding the above is only true for flac lossless -4 & -1, not for lossyflac sadly ;(
  • Last Edit: 28 August, 2009, 04:07:27 PM by sauvage78
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4

  • lvqcl
  • [*][*][*][*][*]
  • Developer
Comparison of lossless codecs with LossyWAV processed files.
Reply #6
I'm afraid I didn't express myself clearly: the last 2 graphs show compression ratio of original files, without LossyWAV preprocessing (compression ratio is ~70%, bitrate is ~950 kbps)! So flac -4 is good for compression of original music ripped from CD and bad for the same music after LossyWAV processing.

  • sauvage78
  • [*][*][*][*][*]
Comparison of lossless codecs with LossyWAV processed files.
Reply #7
argh !!! so it's just KTF's test redone  you're playing with my nerve  you're more evil then I thought !!! LOL

PS: the missunderstanding was that I thought "original samples" meant "real life music" vs. non-"original samples" which would be "problem samples", obviously I was wrong, "original samples" meant "lossless" vs. non-"original samples" which meant lossy. Sorry for my bad english  ...
  • Last Edit: 28 August, 2009, 03:57:26 PM by sauvage78
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4