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
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.
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.
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.
Hey Alexxander do you have the decoding rates too?
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 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=58850&view=findpost&p=528359).
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.
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 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.
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
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.
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
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.
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
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 (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.
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)
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
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.
I have results in my comparison for FLAC 1.2.0 with no MD5 calculated
How do you disable MD5?
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
Hey, better late than never, my foobar decoding results:
Settings:
Buffer entire file into memory: yes
High priority: yes
Passes: 10
File FLAC 1.2.1 TAK 1.1.0b3
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
Average 276x 195x
Edit: BTW, that's the maximum speed for each run, with FLAC -0 and TAK -p0.
So, maybe is time to test FLAC -8 and TAK -pMax, am I right?
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.
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
Thanks.
I guessed the results are close, but I didn't expect them to be so close.
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:
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
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
Average 276x 213x 195x 129x
[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]
(Late) Edit: spelling[/size]
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.
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.
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.
| 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:
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]
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.
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).
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?
Don't ask me, I wouldn't run FLAC below -8.