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


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.

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.

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.

Yes, it's needs updating, especially the link to the software, now 1.0.2 is out.

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.

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

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.

Thank you! That's very interesting for me.


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

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.

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.


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.


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

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?

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.

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.

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.


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


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

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.

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.

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

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.

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)

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

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.

How do you disable MD5?

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