Hydrogenaudio Forums

Lossless Audio Compression => Lossless / Other Codecs => Topic started by: Alexxander on 2007-11-07 16:03:13

Title: FLAC vs TAK encoding results
Post by: Alexxander on 2007-11-07 16:03:13
I wanted to compare the weakest, the default and strongest compression of latest FLAC (v1.2.1) and TAK (v1.2.0). I was interested in compression rate but measured also global encoding time using timer.exe. Encoding was done through commandline on one CPU core.

Total playtime:   20:23:05,507 (20 hours and 23 minutes)
Number of tracks: 245
Original size: 12.945.214.156 Bytes (12,0 GB)

CPU Intel Core 2 Duo @ 3,0 GHz with WinXP SP2
WAV's are Source is on 2 disks in RAID0 (striping)
CompressedEncoded and decoded files are written to an other standalone drive

Code: [Select]
                                                 Encoding Process               Decoding            
                Compressed      Compression  PT    PRate  GT    GRate     PT   PRate  GT   GRate
flac1.2.1 -0    8.801.938.201   67,99%       233   315x   383   192x      180  409x   234  314x
flac1.2.1 -5    8.113.749.200   62,68%       453   162x   584   126x      194  379x   257  285x
flac1.2.1 -8    8.071.892.842   62,35%       1596  46x    1668  44x       204  359x   262  280x
       TAKp0    8.031.153.454   62,04%       262   280x   408   180x      251  293x   290  253x
       TAKp2    7.821.652.842   60,42%       397   185x   542   135x      285  257x   311  236x
      TAKp5m    7.722.405.330   59,65%       3097  24x    3149  23x       347  212x   380  193x

PT=Process Time in seconds
PRate=Process Rate
GT=Global Time in seconds
GRate=Global Rate
Curious to see that in this case weakest TAK compression level compresses slightly more than FLAC's highest compression. The TAK default level compression is impressive considering encoding speed and resulting compression ratio.

I noticed that when compressing at the weakest level (FLAC -0 and TAK -p0) the CPU core usage was between 50 and 70% and not 100% as with the other levels. I suppose this is because CPU encodes faster than input data arrives.

Added 10th of November:
I added the Process Time and the corresponding rate. The Process Time gives better insight in real CPU usage than the Global Time but the latter represents how long the conversion process really took.

I also added the Decoding results (source and destination on different hard disks). The decoding speed of FLAC -8 (best compression) is better than TAK -p0 (weakest compression). As well as in the encoding process I think for decoding TAK -p2 (=default) is also the sweet spot.
Title: FLAC vs TAK encoding results
Post by: Synthetic Soul on 2007-11-07 16:54:55
Curious to see that in this case weakest TAK compression level compresses slightly more than FLAC's highest compression.
I see exactly the same with my test corpus.  TAK Turbo even compresses better than FLAC     -8 -A tukey(0.5) -A flattop in my tests.

The TAK default level  compression is impressive considering encoding speed and resulting  compression ratio.
TAK Normal is one of the few default settings for codecs that I would probably use (i.e.: for all others I can think of I would use additional switches to choose the setting that I thought was the best).  The performance graph in the wiki article (http://wiki.hydrogenaudio.org/index.php?title=TAK#TAK_Performance_Graph) was originally produced by me from results following testing of TAK 1.0.1.  To me it quite neatly indicates the sweet spot.  Of course, things have improved since then also.
Title: FLAC vs TAK encoding results
Post by: GeSomeone on 2007-11-07 17:24:46
The performance graph in the wiki article (http://wiki.hydrogenaudio.org/index.php?title=TAK#TAK_Performance_Graph) was originally produced by me from results following testing of TAK 1.0.1.

Yes, it's needs updating, especially the link to the software, now 1.0.2 is out. 
Title: FLAC vs TAK encoding results
Post by: Mr Bungle on 2007-11-08 11:58:48
Hey Alexxander do you have the decoding rates too?
Title: FLAC vs TAK encoding results
Post by: Alexxander on 2007-11-09 15:03:31
Hey Alexxander do you have the decoding rates too?

I still have the converted files and the batch script files. I will publish the decoding results soon.
Title: FLAC vs TAK encoding results
Post by: Alexxander on 2007-11-10 16:09:45
Added the decoding results 10th of November in Starters post (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=58850&view=findpost&p=528359).
Title: FLAC vs TAK encoding results
Post by: IgorC on 2007-11-15 04:56:26
I think decoding speed is only important for encoding form lossless to lossy. For playback a few percents of cpu usage aren't noticeble. In case of FLAC and TAK.
As it was already mentioned CPU clock isn't bottleneck but RAM and HDD are.  Practically there shouldn't be a difference of speed when encoding from FLAC or TAK turbo  to lossy for P4 (P3?) and higher. At least for foobar converter it's valid.
Title: FLAC vs TAK encoding results
Post by: Mr Bungle on 2007-11-18 04:33:42
I think decoding speed is only important for encoding form lossless to lossy. For playback a few percents of cpu usage aren't noticeble. In case of FLAC and TAK.
As it was already mentioned CPU clock isn't bottleneck but RAM and HDD are.  Practically there shouldn't be a difference of speed when encoding from FLAC or TAK turbo  to lossy for P4 (P3?) and higher. At least for foobar converter it's valid.

Decoding speed matters for a lot of hardware.  Not all hardware is as powerful as a high-end PC.
Title: FLAC vs TAK encoding results
Post by: Kirya on 2007-11-18 08:27:12

I think decoding speed is only important for encoding form lossless to lossy. For playback a few percents of cpu usage aren't noticeble. In case of FLAC and TAK.
As it was already mentioned CPU clock isn't bottleneck but RAM and HDD are.  Practically there shouldn't be a difference of speed when encoding from FLAC or TAK turbo  to lossy for P4 (P3?) and higher. At least for foobar converter it's valid.

Decoding speed matters for a lot of hardware.  Not all hardware is as powerful as a high-end PC.

I agree. If TAK wants to get hardware support (for example PMP), it must have highest decoding rate.
Title: FLAC vs TAK encoding results
Post by: TBeck on 2007-11-20 05:30:25
I wanted to compare the weakest, the default and strongest compression of latest FLAC (v1.2.1) and TAK (v1.2.0). I was interested in compression rate but measured also global encoding time using timer.exe. Encoding was done through commandline on one CPU core.
...

Thank you! That's very interesting for me.



I think decoding speed is only important for encoding form lossless to lossy. For playback a few percents of cpu usage aren't noticeble. In case of FLAC and TAK.
As it was already mentioned CPU clock isn't bottleneck but RAM and HDD are.  Practically there shouldn't be a difference of speed when encoding from FLAC or TAK turbo  to lossy for P4 (P3?) and higher. At least for foobar converter it's valid.

Decoding speed matters for a lot of hardware.  Not all hardware is as powerful as a high-end PC.

I agree. If TAK wants to get hardware support (for example PMP), it must have highest decoding rate.

Well, there are some cpu dependencies. In Synthetic Souls's comparison (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=58382&view=findpost&p=525853) TAK Turbo is decoding faster than FLAC -8.

And that's not the end of the line. The current development version of TAK 1.0.3 is decoding another 6.5 percent faster on my system. Additionally it will improve the compression of presets Turbo to Normal by about 0.05 percent. Not much, but it comes without any encoding speed penality.

Simultaneously i am working on a slightly modified codec, which will decode another 5 to 10 percent faster.

  Thomas
Title: FLAC vs TAK encoding results
Post by: Polar on 2007-11-20 13:34:55
In Synthetic Souls's comparison (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=58382&view=findpost&p=525853) TAK Turbo is decoding faster than FLAC -8.

And that's not the end of the line. The current development version of TAK 1.0.3 is decoding another 6.5 percent faster on my system. Additionally it will improve the compression of presets Turbo to Normal by about 0.05 percent. Not much, but it comes without any encoding speed penality.

Simultaneously i am working on a slightly modified codec, which will decode another 5 to 10 percent faster.
That's a fabulous prospect, Thomas.  Hats off for all your work on TAK.

If I may humbly coin my personal view, I think you should reduce the number of presets TAK has.  Actually, I have the same criticism for FLAC, WavPack and especially OptimFROG.  Imho, all the latter are suffering from preset bloat, but specifically for TAK goes that the performance difference between the various presets (even after letting out the extra and max switches, so just the "standard" 6 presets turbo, fast, normal, high, extra and insane) does not justify the existence of each of them.

When considering Synthetic Soul's stats (http://www.synthetic-soul.co.uk/comparison/lossless/index.asp?Sort=Compression&Desc=0), TAK (high, extra and insane) is the only codec hovering around Monkey's Audio normal and high settings, with marginal compression differences between them.  Which is why I don't see much need for so many different levels.

Moreover, I have an objection to somewhat informal terminology as in turbo and especially insane, which I suppose tends to have a slightly discrediting psychological connotation, marketing-wise.  So TAK being as fast as it is already, just fast, normal, high and maximum should suffice, imho.

Fast should be situated somewhere between the current turbo and fast presets, maybe closer to turbo than to fast.

The current normal preset probably approaches the greatest common divisor for the average user, a very fine trade-off between ratio, encoding and decoding speed.

My idea of a high preset comes close to the current extra, maybe even insane settings.

The current insane preset is still not quite, well, insane.  It's still fairly fast at encoding, very fast at decoding, while being "only" on par with Monkey's high.  I don't mean to be derogatory at all, I think the designation just doesn't cover the overtones.  From my understanding, TAK's format has so much potential that insane's current compression/speed balance may be pushed even further, and only then it will be worth the label insane, or in my view: maximum.

Edit:
If I could as bold as to extrapolate some thoughts from this FLAC preset usage poll (http://www.hydrogenaudio.org/forums/index.php?showtopic=58731), the settings the "general public" would probably be seeking in a codec like TAK, are its current
normal, high and insane presets, rendering the others largely superfluous.
Title: FLAC vs TAK encoding results
Post by: TBeck on 2007-11-22 02:32:03
When considering Synthetic Soul's stats (http://www.synthetic-soul.co.uk/comparison/lossless/index.asp?Sort=Compression&Desc=0), TAK (high, extra and insane) is the only codec hovering around Monkey's Audio normal and high settings, with marginal compression differences between them.  Which is why I don't see much need for so many different levels.

Synthetic Soul's file set isn't really TAK friendly, because it is already happy with about 16 to 32 predictors. The power of the stronger presets is mostly based on higher predicor orders (up to 256). If files don't benefit from them (as in Synthetic Soul's comparison), the stronger presets are of little advantage. Files likely to benefit are classical music, jazz and speech. The files set of the FLAC comparison (http://flac.sourceforge.net/comparison_all_ratio.html) is better suited to show the power of TAK's stronger presets: Here TAK's strongest preset is performing better than even Monkey's Extra High! You see: If TAK's strong presets are advantegous depends on your music.

If I may humbly coin my personal view, I think you should reduce the number of presets TAK has.  Actually, I have the same criticism for FLAC, WavPack and especially OptimFROG.  Imho, all the latter are suffering from preset bloat, but specifically for TAK goes that the performance difference between the various presets (even after letting out the extra and max switches, so just the "standard" 6 presets turbo, fast, normal, high, extra and insane) does not justify the existence of each of them.

I agree: If you are only regarding pc playback, it doesn't need that much presets and especially the addtional evaluation levels. But when it comes to hardware players, these choices are important:

1) The computational complexity of the presets is increasing from Turbo to Insane. You will be restricted to the strongest preset your hardware device can decode.

2) Then the evaluation levels are your only chance to increase the compression, because they don't affect the decoding requirements.

Surely, if you are into pc based playback and don't care about decoding speed, it's always better to select a higher preset instead of increasing the evaluation level, because this way you will get better compression at a higher encoding speed.

Moreover, I have an objection to somewhat informal terminology as in turbo and especially insane, which I suppose tends to have a slightly discrediting psychological connotation, marketing-wise.  So TAK being as fast as it is already, just fast, normal, high and maximum should suffice, imho.
...
The current insane preset is still not quite, well, insane.  It's still fairly fast at encoding, very fast at decoding, while being "only" on par with Monkey's high.  I don't mean to be derogatory at all, I think the designation just doesn't cover the overtones.  From my understanding, TAK's format has so much potential that insane's current compression/speed balance may be pushed even further, and only then it will be worth the label insane, or in my view: maximum.

Maybe i will sometime unlock some really insane internal options... Currently i don't want to because i regard an encoding speed reduction by a factor of 10 too much for possibly 0.1 percent better compression...

  Thomas
Title: FLAC vs TAK encoding results
Post by: Polar on 2007-11-22 10:44:50
But when it comes to hardware players, these choices are important:

1) The computational complexity of the presets is increasing from Turbo to Insane. You will be restricted to the strongest preset your hardware device can decode.

2) Then the evaluation levels are your only chance to increase the compression, because they don't affect the decoding requirements.
I realize portable hardware is the main concern when considering preset switches.  Still, if just about any FLAC compression level, some of the fastest WavPack presets, ALAC on the ubiquitous iPod, and to a lesser extent even True Audio (on 1 DVD player) and WMA Lossless (Zune), are all decodable, does TAK have so much to worry about, speedy as it is?

If you are only regarding pc playback, it doesn't need that much presets and especially the addtional evaluation levels.
(...)
Surely, if you are into pc based playback and don't care about decoding speed, it's always better to select a higher preset instead of increasing the evaluation level, because this way you will get better compression at a higher encoding speed.
Even on a desktop computer, I prefer TAK and FLAC for actual listening, because I try to save my CPU cycles for actual work on my PC, if not for distributed computing stuff such as SETI@home.  Squeezing out the last byte, or the last second of encoding speed, which is one-time anyhow, is of negligable importance.  TAK is already ahead of most of its competition on that field.

Maybe i will sometime unlock some really insane internal options... Currently i don't want to because i regard an encoding speed reduction by a factor of 10 too much for possibly 0.1 percent better compression...
That wouldn't be worth it, indeed.  But that was partly my point: don't aim for the insane, a rationally balanced maximum setting seems to make much more sense.
Title: FLAC vs TAK encoding results
Post by: TBeck on 2007-11-22 11:53:38
But when it comes to hardware players, these choices are important:

1) The computational complexity of the presets is increasing from Turbo to Insane. You will be restricted to the strongest preset your hardware device can decode.

2) Then the evaluation levels are your only chance to increase the compression, because they don't affect the decoding requirements.
I realize portable hardware is the main concern when considering preset switches.  Still, if just about any FLAC compression level, some of the fastest WavPack presets, ALAC on the ubiquitous iPod, and to a lesser extent even True Audio (on 1 DVD player) and WMA Lossless (Zune), are all decodable, does TAK have so much to worry about, speedy as it is?

Currently i don't have much knowledge about portable devices, therefore i am not sure. While TAK's average decoding speed is very high, you also have to take the peak decoding requirements into account, at least for EXTRA and INSANE. The computational complexity of those presets depends mostly on the predictor count. The encoder chooses as many predictors (4 to 256) as are advantageous for an individual frame. Since high- predictor-count-frames are rare, the effect on the decoding speed is on average small. But if a device can't decode those rare frames, you will experience stuttering now and then.

My test corpus contains one file which really likes many predictors (up to 512 supported in early TAK/YALAC versions). Decoding speed of this file is about 3 times lower than the average of my test corpus.

If you are only regarding pc playback, it doesn't need that much presets and especially the addtional evaluation levels.
(...)
Surely, if you are into pc based playback and don't care about decoding speed, it's always better to select a higher preset instead of increasing the evaluation level, because this way you will get better compression at a higher encoding speed.
Even on a desktop computer, I prefer TAK and FLAC for actual listening, because I try to save my CPU cycles for actual work on my PC, if not for distributed computing stuff such as SETI@home.  Squeezing out the last byte, or the last second of encoding speed, which is one-time anyhow, is of negligable importance.  TAK is already ahead of most of its competition on that field.

With "if you ... don't care about decoding speed" i was referring to the TAK preset system and it's small variability of the decoding speed. I am a big friend of fast decoding...

Maybe i will sometime unlock some really insane internal options... Currently i don't want to because i regard an encoding speed reduction by a factor of 10 too much for possibly 0.1 percent better compression...
That wouldn't be worth it, indeed.  But that was partly my point: don't aim for the insane, a rationally balanced maximum setting seems to make much more sense.

You are right, my answer was not complete...

I found that many people talking about TAK reported only the results of the strongest setting, which is encoding relatively slow and not a good example of TAK's speedy performance. I thought, 'INSANE' would give a hint (for readers who don't know TAK), that there must be some faster presets...

Well, and at some point i planned to remove the strongest preset and wanted to discourage it's use... But that's over now.

  Thomas
Title: FLAC vs TAK encoding results
Post by: jcoalson on 2007-11-25 09:46:13
note again that tak is not computing md5 like flac.exe, so comparisons that are timing the command line progs are not indicative of playback complexity.  md5 is a significant (10-20%) part of flac decode time when enabled.
Title: FLAC vs TAK encoding results
Post by: Synthetic Soul on 2007-11-25 12:54:58
I have results in my comparison for FLAC 1.2.0 with no MD5 calculated:

http://www.synthetic-soul.co.uk/comparison...esc=0&All=1 (http://www.synthetic-soul.co.uk/comparison/lossless/index.asp?Sort=Setting&Desc=0&All=1)

I see an 18% improvement on average with my corpus.

NB: They are not part of my main result set as I compare encoders and decoders under normal command line conditions.  As Josh has previously pointed out though, for payback the figures may not be the same.

Edit: LOL. I see that if I had read Josh's post more thoroughly I would not have needed to write my disclaimer.
Title: FLAC vs TAK encoding results
Post by: guruboolez on 2007-11-25 13:03:06
Synthetic Soul> Is decoding speed significantly different on your computer with another decoder (i.e. foobar2000 with foo_input_std.dll)?
Title: FLAC vs TAK encoding results
Post by: Synthetic Soul on 2007-11-25 19:12:01
For you, I will find time to test, and report back.

I have never previously used any other method than the enc/decoders, timer.exe and my scripts.
Title: FLAC vs TAK encoding results
Post by: guruboolez on 2007-11-25 21:12:28
Thank you, but don't misunderstand my question and please don't even try to “foobar” the full set and all possible settings just to satisfy me

But you could simply compare timer.exe and foobar2000's values with a couple of files and some formats/settings. It shouldn't be long and should be enough to see if your values are the fastest ones and if some formats would appear faster than what official decoder and/or timer.exe are currently showing.

foobar2000 decoding test speed component is easy to use, multipass and offers as option a full buffering mode to avoid disk I/O issues. From my previous tests and if I remember correctly TAK is twice slower than FLAC when using foobar2000 as protocol.


EDIT: exact values (tested on Core2Duo E6300; 1GB RAM; foobar2000 0.95b5 • ~1000 kbps lossless file • entire file in buffer; 10 pass)

TAK 1.02 turbo {fastest mode}: 181.755 max (fastest pass)
FLAC 1.21 -8 {slowest mode}: 312.876 max (fastest pass)
Title: FLAC vs TAK encoding results
Post by: alvaro84 on 2007-11-25 21:22:29
foobar2000 decoding test speed component is easy to use, multipass and offers as option a full buffering mode to avoid disk I/O issues. From my previous tests and if I remember correctly TAK is twice slower than FLAC when using foobar2000 as protocol.


Interesting that flac used to be much slower, about on par with TAK, and got a nice speedup with the new flac decoding library which has been embedded into 0.9.4.5. I think that older flac supporting hardware devices have firmwares based on the older library I still think that TAK is a great candidate for hw playback
Title: FLAC vs TAK encoding results
Post by: Ekstasis on 2007-11-26 08:14:24
I who thought FLAC was the only alternative, TAK seams better in most regards. The only thing I might question is the reliability, FLAC has been under development for a long time so I trust it is good code etc... But yeah, I might switch to TAK soon.
Title: FLAC vs TAK encoding results
Post by: skamp on 2007-11-26 09:29:38
I have results in my comparison for FLAC 1.2.0 with no MD5 calculated

How do you disable MD5?
Title: FLAC vs TAK encoding results
Post by: TBeck on 2007-11-26 09:47:34
foobar2000 decoding test speed component is easy to use, multipass and offers as option a full buffering mode to avoid disk I/O issues. From my previous tests and if I remember correctly TAK is twice slower than FLAC when using foobar2000 as protocol.

Hm, this shouldn't be. Possibly there is some bad interaction between TAK's and Foobar's io buffering. I will look into that when i have more time, but currently i am working on piping support (for encoding) for the next version.

  Thomas
Title: FLAC vs TAK encoding results
Post by: Synthetic Soul on 2008-12-30 16:27:51
Hey, better late than never, my foobar decoding results:

Code: [Select]
Settings:
  Buffer entire file into memory: yes
  High priority: yes
  Passes: 10
  
File      FLAC 1.2.1    TAK 1.1.0b3
Code: [Select]
00.wav    277x          191x
01.wav    289x          209x
02.wav    291x          206x
03.wav    273x          191x
04.wav    257x          187x
05.wav    278x          199x
06.wav    275x          188x
07.wav    277x          196x
08.wav    271x          192x
09.wav    281x          200x
10.wav    278x          191x
11.wav    285x          200x
12.wav    275x          201x
13.wav    275x          192x
14.wav    277x          197x
15.wav    275x          200x
16.wav    273x          191x
17.wav    281x          200x
18.wav    265x          192x
19.wav    278x          200x
20.wav    280x          189x
21.wav    292x          206x
22.wav    277x          192x
23.wav    280x          191x
24.wav    276x          197x
25.wav    277x          199x
26.wav    292x          205x
27.wav    281x          201x
28.wav    275x          190x
29.wav    288x          198x
30.wav    276x          198x
31.wav    285x          198x
32.wav    280x          192x
33.wav    278x          192x
34.wav    287x          202x
35.wav    281x          196x
36.wav    274x          191x
37.wav    275x          186x
38.wav    287x          203x
39.wav    253x          183x
40.wav    279x          193x
41.wav    280x          191x
42.wav    275x          190x
43.wav    280x          198x
44.wav    282x          200x
45.wav    260x          186x
46.wav    272x          199x
47.wav    260x          187x
48.wav    252x          182x
49.wav    255x          183x
Code: [Select]
Average   276x          195x
Edit: BTW, that's the maximum speed for each run, with FLAC -0 and TAK -p0.
Title: FLAC vs TAK encoding results
Post by: adamjk on 2008-12-30 18:50:59
So, maybe is time to test FLAC -8 and TAK -pMax, am I right?
Title: FLAC vs TAK encoding results
Post by: halb27 on 2008-12-30 20:54:01
So, maybe is time to test FLAC -8 and TAK -pMax, am I right?

I guess you worry a bit about usage of FLAC -0 and TAK -p0 which aren't very interesting settings - at least for FLAC. I too would have preferred a more usual FLAC setting like -5 or -8 (though I don't think speed will be significantly lower). With TAK a low setting (like -p2, but even -p 0 is a good choice) is appropriate IMO as compression ratio is still advantageous.
Title: FLAC vs TAK encoding results
Post by: IgorC on 2008-12-30 20:59:44
foobar 0.9.6.1 beta 2
decoding test - 10 passes
FLAC 1.2.1
-8 -A2 309x
-0      310x

I did wrong measurements


It's actually.
-8 -A2 309.5x
-0      377.0x
Title: FLAC vs TAK encoding results
Post by: halb27 on 2009-01-01 09:41:45
Thanks.
I guessed the results are close, but I didn't expect them to be so close.
Title: FLAC vs TAK encoding results
Post by: Synthetic Soul on 2009-01-01 12:44:42
I did actually get quite a variation with my machine (Athlon XP 2400+, 1GB RAM).  I'm going to run a test again on just a few files to double check, but these are the figures I have thus far:

Code: [Select]
Settings:
  Buffer entire file into memory: yes
  High priority: yes
  Passes: 10

File      FLAC 1.2.1      TAK 1.1.0
          -0      -8      -p0     -p4
Code: [Select]
00.wav    277x    206x    191x    132x
01.wav    289x    238x    209x    136x
02.wav    291x    222x    206x    130x
03.wav    273x    211x    191x    129x
04.wav    257x    199x    187x    103x
05.wav    278x    216x    199x    124x
06.wav    275x    211x    188x    142x
07.wav    277x    216x    196x    129x
08.wav    271x    214x    192x    138x
09.wav    281x    218x    200x    131x
10.wav    278x    208x    191x    146x
11.wav    285x    217x    200x    128x
12.wav    275x    219x    201x    125x
13.wav    275x    209x    192x    119x
14.wav    277x    209x    197x    125x
15.wav    275x    215x    200x    128x
16.wav    273x    233x    191x    140x
17.wav    281x    216x    200x    121x
18.wav    265x    212x    192x    108x
19.wav    278x    211x    200x    122x
20.wav    280x    219x    189x    134x
21.wav    292x    223x    206x    118x
22.wav    277x    209x    192x    125x
23.wav    280x    213x    191x    133x
24.wav    276x    209x    197x    124x
25.wav    277x    208x    199x    119x
26.wav    292x    230x    205x    126x
27.wav    281x    217x    201x    153x
28.wav    275x    205x    190x    149x
29.wav    288x    221x    198x    133x
30.wav    276x    221x    198x    130x
31.wav    285x    211x    198x    134x
32.wav    280x    207x    192x    142x
33.wav    278x    211x    192x    147x
34.wav    287x    216x    202x    121x
35.wav    281x    209x    196x    139x
36.wav    274x    209x    191x    122x
37.wav    275x    201x    186x    135x
38.wav    287x    222x    203x    133x
39.wav    253x    195x    183x    106x
40.wav    279x    211x    193x    137x
41.wav    280x    215x    191x    124x
42.wav    275x    206x    190x    137x
43.wav    280x    218x    198x    137x
44.wav    282x    225x    200x    148x
45.wav    260x    199x    186x    121x
46.wav    272x    214x    199x    112x
47.wav    260x    201x    187x    118x
48.wav    252x    193x    182x    116x
49.wav    255x    195x    183x    121x
Code: [Select]
Average   276x    213x    195x    129x
[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]
(Late) Edit: spelling[/size]
Title: FLAC vs TAK encoding results
Post by: halb27 on 2009-01-01 15:47:10
Thanks for your results.
I don't care about ultra-precision of results, the rather rough impression is enough.
As from that you do have significantly slower results using FLAC -8 compared to -0 (while 'slower' still means 'very fast').
It's still faster than TAK -p0, but not by much.
Considering that TAK -p1 should yield pretty much the same decoding speed as -p0 TAK -p1 may be the best TAK solution when focussing on decompression speed while still taking care of good compression ratio. TAK -p2's compression speed is not expected to be much lower, so maybe TAK -p 2 is the best solution when focussing the same on both decompression speed and compression ratio. All a matter of taste of course.
So FLAC is still the decompression speed king, but has a strong competitor.
Title: FLAC vs TAK encoding results
Post by: Synthetic Soul on 2009-01-01 15:58:58
I don't care about ultra-precision of results, the rather rough impression is enough.
I wasn't after more precision, only checking that they weren't wildly off.  I can confirm that a smaller test yielded very similar results.

I personally wonder whether the fact that the TAK foobar decoding component has to use an external library makes some difference.  I have no idea about such matters though.
Title: FLAC vs TAK encoding results
Post by: guruboolez on 2009-01-01 19:07:57
I tested on my side.
foobar2000 0.9.6.1b2
Intel C2Duo E6300 (1.83 GHz) // 1 GB RAM)
I set foobar2000's test speed to 10 pass and I took the fastest one to fill the table.

I also choose four files from my own music library having four different level of complexity: the first one reaches 250 kbps; the second 500 kbps; the third 750 kbps and the last one 1000 kbps (all originally encoded with flac -5). Why? Simply because I noticed that decoding speed changes a lot depending on the file and its bitrate.

Code: [Select]
          | FLAC -0 | FLAC -8 |  TAK -p0 |  TAK -p4
----------|---------|---------|----------|-----------
250 kbps  |  x528   |  x488   |  x284    |  x192
500 kbps  |  x444   |  x406   |  x282    |  x165
750 kbps  |  x434   |  x370   |  x259    |  x151
1000 kbps |  x422   |  x325   |  x243    |  x150

If I compare this table to the past test (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=58850&view=findpost&p=531937) I performed one year ago on the same computer and with a ~1000 kbps file:
- flac decoding speed is similar (x312 vs x325)
- TAK decoding speed on fb2k significantly increased (x181 vs x243)

foobar2000 exact values:
Code: [Select]
File: C:\flac\test\test\250kbps FLAC-0.flac
  Opening time: 0:00.001 min, 0:00.018 max, 0:00.002 average
  Decoding time: 0:00.349 min, 0:00.351 max, 0:00.350 average
  Speed (x realtime): 524.197 min, 528.377 max, 526.773 average
File: C:\flac\test\test\250kbps FLAC-8.flac
  Opening time: 0:00.001 min, 0:00.017 max, 0:00.002 average
  Decoding time: 0:00.377 min, 0:00.385 max, 0:00.380 average
  Speed (x realtime): 478.679 min, 488.796 max, 484.094 average
File: C:\flac\test\test\250kbps TAK p0.tak
  Opening time: 0:00.000 min, 0:00.016 max, 0:00.002 average
  Decoding time: 0:00.646 min, 0:00.649 max, 0:00.648 average
  Speed (x realtime): 283.568 min, 284.903 max, 284.317 average
File: C:\flac\test\test\250kbps TAK p4.tak
  Opening time: 0:00.001 min, 0:00.015 max, 0:00.002 average
  Decoding time: 0:00.958 min, 0:00.960 max, 0:00.959 average
  Speed (x realtime): 191.794 min, 192.300 max, 192.107 average

************************************************************************

File: C:\flac\test\test\500kbps FLAC-0.flac
  Opening time: 0:00.001 min, 0:00.026 max, 0:00.003 average
  Decoding time: 0:00.331 min, 0:00.335 max, 0:00.332 average
  Speed (x realtime): 440.209 min, 444.940 max, 443.115 average
File: C:\flac\test\test\500kbps FLAC-8.flac
  Opening time: 0:00.001 min, 0:00.026 max, 0:00.003 average
  Decoding time: 0:00.362 min, 0:00.366 max, 0:00.364 average
  Speed (x realtime): 402.274 min, 406.770 max, 404.358 average
File: C:\flac\test\test\500kbps TAK p0.tak
  Opening time: 0:00.000 min, 0:00.025 max, 0:00.003 average
  Decoding time: 0:00.521 min, 0:00.524 max, 0:00.522 average
  Speed (x realtime): 280.986 min, 282.703 max, 282.039 average
File: C:\flac\test\test\500kbps TAK p4.tak
  Opening time: 0:00.001 min, 0:00.025 max, 0:00.004 average
  Decoding time: 0:00.888 min, 0:00.891 max, 0:00.889 average
  Speed (x realtime): 165.397 min, 165.853 max, 165.623 average

************************************************************************

File: C:\flac\test\test\750kbps FLAC-0.flac
  Opening time: 0:00.001 min, 0:00.063 max, 0:00.007 average
  Decoding time: 0:00.575 min, 0:00.577 max, 0:00.576 average
  Speed (x realtime): 432.590 min, 434.455 max, 433.582 average
File: C:\flac\test\test\750kbps FLAC-8.flac
  Opening time: 0:00.001 min, 0:00.063 max, 0:00.007 average
  Decoding time: 0:00.675 min, 0:00.678 max, 0:00.677 average
  Speed (x realtime): 368.238 min, 370.070 max, 369.082 average
File: C:\flac\test\test\750kbps TAK p0.tak
  Opening time: 0:00.000 min, 0:00.062 max, 0:00.007 average
  Decoding time: 0:00.963 min, 0:00.967 max, 0:00.965 average
  Speed (x realtime): 258.226 min, 259.176 max, 258.667 average
File: C:\flac\test\test\750kbps TAK p4.tak
  Opening time: 0:00.001 min, 0:00.061 max, 0:00.007 average
  Decoding time: 0:01.651 min, 0:01.655 max, 0:01.653 average
  Speed (x realtime): 150.874 min, 151.224 max, 151.091 average

************************************************************************

File: C:\flac\test\test\1000kbps FLAC-0.flac
  Opening time: 0:00.001 min, 0:00.059 max, 0:00.006 average
  Decoding time: 0:00.412 min, 0:00.416 max, 0:00.413 average
  Speed (x realtime): 418.770 min, 422.565 max, 421.343 average
File: C:\flac\test\test\1000kbps FLAC-8.flac
  Opening time: 0:00.001 min, 0:00.059 max, 0:00.006 average
  Decoding time: 0:00.535 min, 0:00.537 max, 0:00.535 average
  Speed (x realtime): 323.822 min, 325.526 max, 325.008 average
File: C:\flac\test\test\1000kbps TAK p0.tak
  Opening time: 0:00.000 min, 0:00.058 max, 0:00.006 average
  Decoding time: 0:00.714 min, 0:00.717 max, 0:00.715 average
  Speed (x realtime): 242.555 min, 243.622 max, 243.214 average
File: C:\flac\test\test\1000kbps TAK p4.tak
  Opening time: 0:00.000 min, 0:00.055 max, 0:00.006 average
  Decoding time: 0:01.155 min, 0:01.159 max, 0:01.157 average
  Speed (x realtime): 150.079 min, 150.697 max, 150.406 average

[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]EDIT: changed CPU name from E4300 to E6300[/size]
Title: FLAC vs TAK encoding results
Post by: IgorC on 2009-01-11 00:02:06
I made  wrong measurements in previous post. The correct results are:
Intel E2160 (1.8 GHz x2) 2 GB DDR2 667 Mhz RAM. OS Windows XP SP3
foobar 0.9.6.1
decoding test - 10 passes
FLAC 1.2.1 -  13 songs from Steve Vai - The Ultra Zone
-8 -A2 309.5x
-0 377.0x

For real usage on PC such high decoding speed doesn't bring real benefit. Let's see two cases
1. Real playback
2. Encoding

1. Real playback:
FLAC -8 -A2 309.5x decoded at 1 core - 0.323% of CPU usage (1 core) for real time playback
FLAC -0 377.0x  decoded  at 1 core    - 0.265% of CPU usage (1 core) for real time playback

Nobody will notice this difference, less than 1% (actually it's even less than 0.1% of difference in CPU usage). In fact pure FLAC decoding can be masked with slower decoding features like: dithering, 24 bits decoding, equalizer and etc.


2. Encoding. LAME 3.98.2 -V0
WAV -> MP3 = 41x
FLAC -8 -> MP3 = 41x (MP3 encoding) + 309.5x (FLAC decoding) = 36.20x
FLAC -0 -> MP3 = 41x (MP3 encoding) + 377.0x (FLAC decoding) = 36.98x


I did it wrong again. Calculations were done with doble speed (real speed) for encoding mp3 as it's dual core. But erroneously the speed of decoding for flac was not doubled.
FLAC -8 -A2 309.5x2 =619 
FLAC -0  377x2 = 754

So
FLAC -8 -> MP3 = 41x (MP3 encoding) + 619x (FLAC decoding) = 38.45x
FLAC -0 -> MP3 = 41x (MP3 encoding) + 754x (FLAC decoding) = 38.89x
It's pretty the same numbers what I get for real encodes.


So encoding from FLAC -8 is only 2.15% 1.12% slower than from FLAC -0.


My personal conclusion:  There is no benefit for PC usage from high speed decoding of FLAC -0.
Exception can be DAP and other kinds of audio/video hardware.
Title: FLAC vs TAK encoding results
Post by: skamp on 2009-01-11 11:47:50
There is no benefit for PC usage from high speed decoding of FLAC -0.

Any CPU cycle that is spared from FLAC decoding is useful when transcoding, whether you use a piping method or decode FLAC to WAV files first. Any spared CPU cycle can then be used to the encoding processes (provided you transcode multiple files in parallel).
Title: FLAC vs TAK encoding results
Post by: IgorC on 2009-01-11 17:33:22
So you would use FLAC -0 instead of -8 because encode speed to MP3 would arise +1.12% and CPU usage would decrease from 0.323% to 0.265% during playback, right? While your FLAC -0 files will be 8% bigger than FLAC-0?
Title: FLAC vs TAK encoding results
Post by: skamp on 2009-01-11 19:30:40
Don't ask me, I wouldn't run FLAC below -8.
SimplePortal 1.0.0 RC1 © 2008-2020