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: FLAC vs TAK encoding results (Read 48303 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

FLAC vs TAK encoding results

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.

FLAC vs TAK encoding results

Reply #1
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 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.
I'm on a horse.


FLAC vs TAK encoding results

Reply #3
Hey Alexxander do you have the decoding rates too?

FLAC vs TAK encoding results

Reply #4
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.

FLAC vs TAK encoding results

Reply #5
Added the decoding results 10th of November in Starters post.

FLAC vs TAK encoding results

Reply #6
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.

FLAC vs TAK encoding results

Reply #7
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.

FLAC vs TAK encoding results

Reply #8

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.
Thinking Outside The Box

FLAC vs TAK encoding results

Reply #9
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 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

FLAC vs TAK encoding results

Reply #10
In Synthetic Souls's comparison 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, 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, 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.

FLAC vs TAK encoding results

Reply #11
When considering Synthetic Soul's stats, 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 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

FLAC vs TAK encoding results

Reply #12
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.

FLAC vs TAK encoding results

Reply #13
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

FLAC vs TAK encoding results

Reply #14
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.

FLAC vs TAK encoding results

Reply #15
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

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.
I'm on a horse.

FLAC vs TAK encoding results

Reply #16
Synthetic Soul> Is decoding speed significantly different on your computer with another decoder (i.e. foobar2000 with foo_input_std.dll)?

FLAC vs TAK encoding results

Reply #17
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.
I'm on a horse.

FLAC vs TAK encoding results

Reply #18
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)

FLAC vs TAK encoding results

Reply #19
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

FLAC vs TAK encoding results

Reply #20
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.


FLAC vs TAK encoding results

Reply #22
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

FLAC vs TAK encoding results

Reply #23
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.
I'm on a horse.

FLAC vs TAK encoding results

Reply #24
So, maybe is time to test FLAC -8 and TAK -pMax, am I right?