IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
Comparison of lossless codecs with LossyWAV processed files., (FLAC, TAK, WavPack, WMAL, LPAC, Shorten)
lvqcl
post Aug 16 2009, 23:03
Post #1





Group: Developer
Posts: 3338
Joined: 2-December 07
Member No.: 49183



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
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
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):
  1. 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.
  2. TAK: the best (only FLAC -0 is faster than fastest TAK setting). Settings higher than –p2e are almost useless.
  3. 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.
  4. WMA Lossless: worse than all other codecs. OTOH, it has good software and some hardware support.
  5. 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.

Go to the top of the page
+Quote Post
Zarggg
post Aug 17 2009, 01:25
Post #2





Group: Members
Posts: 547
Joined: 18-January 04
From: bethlehem.pa.us
Member No.: 11318



Your graphs might be easier to read if you use compression (%) for the y-axis and processing time (s) for the x-axis.

This post has been edited by Zarggg: Aug 17 2009, 01:26
Go to the top of the page
+Quote Post
Nick.C
post Aug 27 2009, 19:44
Post #3


lossyWAV Developer


Group: Developer
Posts: 1787
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



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 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
sauvage78
post Aug 27 2009, 20:47
Post #4





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



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.

This post has been edited by sauvage78: Aug 27 2009, 21:05


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
lvqcl
post Aug 28 2009, 16:50
Post #5





Group: Developer
Posts: 3338
Joined: 2-December 07
Member No.: 49183



QUOTE (sauvage78)
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!).
Go to the top of the page
+Quote Post
sauvage78
post Aug 28 2009, 20:17
Post #6





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



... 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 wink.gif you almost made me switch to -3 ! you little evil wink.gif

Edit: Due to a miss-understanding the above is only true for flac lossless -4 & -1, not for lossyflac sadly ;(

This post has been edited by sauvage78: Aug 28 2009, 21:07


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
lvqcl
post Aug 28 2009, 20:37
Post #7





Group: Developer
Posts: 3338
Joined: 2-December 07
Member No.: 49183



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.
Go to the top of the page
+Quote Post
sauvage78
post Aug 28 2009, 20:39
Post #8





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



argh !!! so it's just KTF's test redone wink.gif you're playing with my nerve wink.gif 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 wink.gif ...

This post has been edited by sauvage78: Aug 28 2009, 20:57


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 30th July 2014 - 02:57