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: foo_input_tak (Read 263496 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

foo_input_tak

Reply #101 –
Quote from: Squeller on
Quote from: foosion on
Adds the ability to read embedded album art. Requires foobar2000 0.9.5.
On http://foosion.foobar2000.org/0.9/ you're linking to an older component (http://foosion.foobar2000.org/0.9/foo_input_tak-0.3.4-20071109.zip).

I hope such album art will be viewable in columns ui internal album "Artwork viewer"...


It is available in the page with the other 0.9.5 components. (Maybe the reason is that the added feature does not benefit those using earlier versions)

foo_input_tak

Reply #102 –
Quote from: kanak on
It is available in the page with the other 0.9.5 components. (Maybe the reason is that the added feature does not benefit those using earlier versions)

The reason is that 0.4 requires foobar2000 0.9.5 or later, it won't even load on earlier versions. I hope I find some time soon to give the site some overhaul to make these things more discoverable.

foo_input_tak

Reply #104 –
Quote from: alvaro84 on
A second question: according to the discussions with TBeck it seems that something in foobar significantly decreases tak decoding speed, in stand-alone decoders it's almost on-par with flac. Not that it's a deadly problem, tak is plenty fast already, but I'm curious if it's some foobar architectural limitation, or some interfacing problem between foobar and the external tak decoding library?

Does this happen with any preset or especially with -p0 to -p3? If the latter, then there is a chance that the new decoding library i will release with TAK 1.0.4 will perform better, because it is using smaller read buffers for -p0 to -p3 (like -p4 and -p5).

Quote from: foosion on
Quote from: alvaro84 on
A second question: according to the discussions with TBeck it seems that something in foobar significantly decreases tak decoding speed, in stand-alone decoders it's almost on-par with flac. Not that it's a deadly problem, tak is plenty fast already, but I'm curious if it's some foobar architectural limitation, or some interfacing problem between foobar and the external tak decoding library?

I don't know what is causing the decreased decoding performance. Considering that the plugin works and that performance isn't abysmal, I however have very little motivation to investigate this further. I can provide the source code, if someone else wants to.

Possibly my earlier advice to always read a whole frame at once is useless or even harmful...

Hm, i am not sure but i seem to remember to have read somewhere that the FLAC plugin is using a separate thread to read the data to decode in the background. If so this might explain it's better performance.

Quote from: foosion on
foo_input_tak 0.4

Adds the ability to read embedded album art. Requires foobar2000 0.9.5.

Great! Thank you very much for your work!

  Thomas

foo_input_tak

Reply #105 –
Thanks for the update.

When double click at the component to show the info in components preference page. foo_input_tak said "Using TAK library version 1.0.6" but the one bundle with the component say it's 1.0.5 If my eye and my PC not deceive me. 
 

foo_input_tak

Reply #106 –
Quote from: TBeck on
Does this happen with any preset or especially with -p0 to -p3? If the latter, then there is a chance that the new decoding library i will release with TAK 1.0.4 will perform better, because it is using smaller read buffers for -p0 to -p3 (like -p4 and -p5).

...

Possibly my earlier advice to always read a whole frame at once is useless or even harmful...

Hm, i am not sure but i seem to remember to have read somewhere that the FLAC plugin is using a separate thread to read the data to decode in the background. If so this might explain it's better performance.


I don't really know, and I always thought that TAK decoding speed is OK as it is in foobar, but when I saw the decoding speed comparison in the TAK topic, I just had to make a remark about the difference in results I experience in foobar. I think it's the same with higher compression settings though, I just made a very quick comparison (with a 'classical' piece of music - Refrain of Memory from the Haibane Renmei soundtrack):

Code: [Select]
FLAC -8    650kbps, 643x
TAK 2 max  623kbps, 346x
TAK 5 max  607kbps, 217x


The comparison made using flac 1.2.1 and tak 1.0.4b1, foo_input_tak 0.4 and 0.9.5.1 default flac decoder.
TAK 2 max is the setting I usually use, I hope the 'max' subsetting won't skew the result (I always use it). For me it seems that the smaller read buffer for higher settings doesn't help at all. And it was a surprise even for me as I always thought to remember that though higher settings are slower to decode, not by this much

...but if FLAC decoding really use a helper thread for data move it can probably explain the difference

foo_input_tak

Reply #107 –
I did some short performance tests. The interesting thing is that performance increases between succeeding TAK versions is quite different depending on the hardware. I only used one file for this test: "Ana'l Haqq" by Secret Chiefs 3, 22 seconds, 1.15 MB, 442 kbps, encoded at p2 by TAK 1.0.2.

Desktop PC: AMD Athlon XP 2500+, 1.84 GHz
Laptop PC: AMD Turion64 MT30, 1.6 GHz
foo_input_tak 0.4.1: not yet released

Decoding with takc.exe was done with the -t switch (test decode). Decoding with foo_input_tak was done using the decoding speed test in foobar2000.

Absolute values:
Code: [Select]
Decoder                                    | Desktop PC | Laptop PC
===================================================================
takc.exe 1.0.2                             |       163x |      156x
takc.exe 1.0.3b                            |       174x |      173x
takc.exe 1.0.4 beta 1                      |       197x |      191x
-------------------------------------------------------------------
foo_input_tak 0.4.1/tak_deco_lib.dll 1.0.5 |       158x |      150x
foo_input_tak 0.4.1/tak_deco_lib.dll 1.0.6 |       169x |      155x

Relative values:
Code: [Select]
Decoder                                    | Desktop PC | Laptop PC
===================================================================
takc.exe 1.0.2                             |     100.0% |    100.0%
takc.exe 1.0.3b                            |     106.7% |    109.0%
takc.exe 1.0.4 beta 1                      |     120.9% |    122.4%
-------------------------------------------------------------------
foo_input_tak 0.4.1/tak_deco_lib.dll 1.0.5 |     100.0% |    100.0%
foo_input_tak 0.4.1/tak_deco_lib.dll 1.0.6 |     107.0% |    103.3%

Note that foo_input_tak will always be slower than the test decode mode of takc.exe, since it does additional processing required by the foobar2000 audio architecture. In particular, it converts the audio data to floating point.

I find it curious how the performance gain when going from takc.exe 1.0.2 to 1.0.3 on the one hand and from tak_deco_lib.dll 1.0.5 to 1.0.6 on the other hand is consistent on the desktop PC, yet it differs significantly on the laptop.

foo_input_tak

Reply #108 –
Some more performance tests. I used a second, longer track which was also encoded by TAK 1.0.2. I also added a third decoding tool: takspeedtest.exe which basically does nothing more than a test decode, but uses tak_deco_lib.dll. Previous Results repeated for completeness.

Track 1 (0:22, 442 kbps, 1.15 MB)
Code: [Select]
Decoder                                    | Desktop PC | Laptop PC
===================================================================
takc.exe 1.0.2                             |       163x |      156x
takc.exe 1.0.3b                            |       174x |      173x
takc.exe 1.0.4 beta 1                      |       197x |      191x
-------------------------------------------------------------------
foo_input_tak 0.4.1/tak_deco_lib.dll 1.0.5 |       158x |      150x
foo_input_tak 0.4.1/tak_deco_lib.dll 1.0.6 |       169x |      155x
-------------------------------------------------------------------
takspeedtest.exe/tak_deco_lib.dll 1.0.5    |       160x |      156x
takspeedtest.exe/tak_deco_lib.dll 1.0.6    |       174x |      165x

Code: [Select]
Decoder                                    | Desktop PC | Laptop PC
===================================================================
takc.exe 1.0.2                             |     100.0% |    100.0%
takc.exe 1.0.3b                            |     106.7% |    109.0%
takc.exe 1.0.4 beta 1                      |     120.9% |    122.4%
-------------------------------------------------------------------
foo_input_tak 0.4.1/tak_deco_lib.dll 1.0.5 |     100.0% |    100.0%
foo_input_tak 0.4.1/tak_deco_lib.dll 1.0.6 |     107.0% |    103.3%
-------------------------------------------------------------------
takspeedtest.exe/tak_deco_lib.dll 1.0.5    |     100.0% |    100.0%
takspeedtest.exe/tak_deco_lib.dll 1.0.6    |     108.6% |    105.8%


Track 2 (3:37, 937 kbps, 24.2 MB)
Code: [Select]
Decoder                                    | Desktop PC | Laptop PC
===================================================================
takc.exe 1.0.2                             |       135x |      131x
takc.exe 1.0.3b                            |       145x |      143x
takc.exe 1.0.4 beta 1                      |       159x |      154x
-------------------------------------------------------------------
foo_input_tak 0.4.1/tak_deco_lib.dll 1.0.5 |       131x |      128x
foo_input_tak 0.4.1/tak_deco_lib.dll 1.0.6 |       142x |      132x
-------------------------------------------------------------------
takspeedtest.exe/tak_deco_lib.dll 1.0.5    |       134x |      131x
takspeedtest.exe/tak_deco_lib.dll 1.0.6    |       147x |      138x

Code: [Select]
Decoder                                    | Desktop PC | Laptop PC
===================================================================
takc.exe 1.0.2                             |     100.0% |    100.0%
takc.exe 1.0.3b                            |     107.4% |    109.2%
takc.exe 1.0.4 beta 1                      |     117.8% |    117.6%
-------------------------------------------------------------------
foo_input_tak 0.4.1/tak_deco_lib.dll 1.0.5 |     100.0% |    100.0%
foo_input_tak 0.4.1/tak_deco_lib.dll 1.0.6 |     108.4% |    103.1%
-------------------------------------------------------------------
takspeedtest.exe/tak_deco_lib.dll 1.0.5    |     100.0% |    100.0%
takspeedtest.exe/tak_deco_lib.dll 1.0.6    |     109.7% |    105.3%


If you want to make your own experiments, you can download takspeedtest.exe. You will need to download tak_deco_lib.dll separately. Like takc.exe it is a command line tool. You can pass it an arbitrary number of TAK files and it will attempt to test decode all of them.

foo_input_tak

Reply #109 –
Quote
Note that foo_input_tak will always be slower than the test decode mode of takc.exe, since it does additional processing required by the foobar2000 audio architecture. In particular, it converts the audio data to floating point.


Does TAK behave differently to FLAC in this respect?  I don't know the source and not even the SDK/protocols, but I'm still curious  Does any of these inputs use any fancy SSE instructions to convert blocks  of int to float?

Thanks for the TAK speed testing utility, unfortunately now I'm working until friday and my brother's rig (that's what I can use in this town) is broken now, let alone that I don't have my music library with me  but I can play with it on a Core2/ddr2-based config (somewhat different architecture, but I don't think it'll differ that much - though I see that K7 and K8 handles the optimization between 1.0.3 and 1.0.4 somewhat differently - maybe it helps more with off-CPU memory controller = longer latency) when I get home if it gives you useful information. I'll try it a little bit for sure just for fun.
(If I can quickly get a cheap second-hand Athlon64 or Sempron mobo+CPU pair here, I can try it on that one too. Converting MP3s from my DAP to TAK and flac is a little bit abstract but can be used for a brief speedtest  - hm, I see you tested it on a K8-based laptop, so that future A64 probably won't help you much )

OK, I finish to talk about my misery

foo_input_tak

Reply #110 –
Quote from: alvaro84 on
Does TAK behave differently to FLAC in this respect?  I don't know the source and not even the SDK/protocols, but I'm still curious  Does any of these inputs use any fancy SSE instructions to convert blocks  of int to float?

The decoding libraries for lossless formats usually return integer data, so foo_input_std converts that into floating point format using functions from shared.dll which comes with foobar2000. Those conversion functions in shared.dll do use processor-specific optimizations. foo_input_tak uses the same conversion functions.

The real surprise for me was that performance between takc.exe and applications using tak_deco_lib.dll diverges.

foo_input_tak

Reply #111 –
Quote from: alvaro84 on
Code: [Select]
FLAC -8    650kbps, 643x
TAK 2 max  623kbps, 346x
TAK 5 max  607kbps, 217x

Thank you. That's indeed a (too) large difference!

Quote from: alvaro84 on
...but if FLAC decoding really use a helper thread for data move it can probably explain the difference

Unfortunately i can't remember where i have read about it...

Quote from: foosion on
I find it curious how the performance gain when going from takc.exe 1.0.2 to 1.0.3 on the one hand and from tak_deco_lib.dll 1.0.5 to 1.0.6 on the other hand is consistent on the desktop PC, yet it differs significantly on the laptop.

First: Thanks for your tests!

TAK's code has been optimized to such an extent, that the speed often depends mostly on the speed of cache and memory accesses. Lately i have tried new optimizations to save a couple of clock cycles, but at least on my system the effect was zero, because the cpu anyhow had to wait for the next data to be read.

Possibly your two cpu's are differing slightly regarding the cache properties.

Quote from: foosion on
The real surprise for me was that performance between takc.exe and applications using tak_deco_lib.dll diverges.

While the application and the library are based upon the same code, there is at least one relevant difference:

The delphi compiler doesn't perform code alignment. I have to trick a bit to nevertheless align the most important loops. Because some of this work has to be performed manually and i am sometimes a bit lazy, the code alignment of the decoding library and the Winamp plugin is less optimal than that of the applications. This can explain up to 5 percent worse performance. Different cpu's are affected to different degrees by bad code alignment.

BTW: I hope to release TAK 1.0.4 today or tomorrow. I am curious if the new decoding library will behave a bit better (more consistent). I have reduced the read buffer size for presets -p0 to -p3 what hopefully will have a positive effect on the performance.

foo_input_tak

Reply #112 –
Quote from: TBeck on
Possibly your two cpu's are differing slightly regarding the cache properties.

Well, they do. Associativity and line size are the same, but the Turion has a larger and faster level 2 cache, although it has a lower core frequency. Considering the performance difference between takc.exe -t and takspeedtest.exe, I'm still betting on the other issue as the main reason.

Quote from: TBeck on
While the application and the library are based upon the same code, there is at least one relevant difference:

The delphi compiler doesn't perform code alignment. I have to trick a bit to nevertheless align the most important loops. Because some of this work has to be performed manually and i am sometimes a bit lazy, the code alignment of the decoding library and the Winamp plugin is less optimal than that of the applications. This can explain up to 5 percent worse performance. Different cpu's are affected to different degrees by bad code alignment.

I now remember that you mentioned the code alignment issue before. I look forward to the C version of TAK when you will be able to use a modern compiler. In the mean time, I'm going to write an FAQ for foo_input_tak.

foo_input_tak

Reply #113 –
foo_input_tak 0.4.1

Compiled with the TAK SDK 1.0.6. Bundled tak_deco_lib.dll 1.0.7.

According to my tests, the performance of tak_deco_lib.dll 1.0.7 should be on par with the takc.exe 1.0.4.

foo_input_tak

Reply #114 –
Talking about -p0 -p1 and foobar decoders only:
I noticed that TAK foobar decoder is faster than FLAC built-in decoder for more compressible source.
For hardly compressible material like loud rock or metal (average bitrate per album >1000 kbit/s)  TAK decoder is slightly slower than FLAC.

There is same effect that  Synthetic Soul experienced in his comparison.  Like FLAC -8 -Ax2 has higher decoding speed than of -5 ....-8 the same way here p1m has slightly higher speed than p0,p0m,p1.
Maybe it's cause of lower bitrate (less data to process).

foo_input_tak

Reply #115 –
I got home, I update my comparison. Two tracks, the Haibane track with classical instruments and a much noisier Rammstein piece with much worse compressability:

Code: [Select]
Refrain of memory:
                         "old"   "new"
FLAC 1.2.1 -8   650kbps   643x
TAK 1.0.4 0m    641kbps          459x
TAK 1.0.4 1m    632kbps          447x
TAK 1.0.4 2m    622kbps   346x   382x
TAK 1.0.4 3m    617kbps   267x   297x
TAK 1.0.4 5m    607kbps   217x   231x


Rammstein -  Keine Lust:

                         "old"   "new"
FLAC 1.2.1 -8  1075kbps   584x
TAK 1.0.4 0m   1071kbps   365x   401x
TAK 1.0.4 1m   1065kbps   348x   392x
TAK 1.0.4 2m   1062kbps   322x   356x
TAK 1.0.4 3m   1061kbps   297x   329x
TAK 1.0.4 5m   1059kbps   276x   298x


I see a nice improvement compared to the last version here

Very interesting that TAK decodes the higher bitrate track much faster from -p3m than the low bitrate one, though everything goes as expected from p0m to p2m. Even more interesting how much the compression settings affect the bitrate of the classical piece and how minimal effect they have on the noisy, industrial/metal sounding one.
I also noticed during this test that encoding with -p0m is essentially not faster at all than with -p1m: probably the speed was limited by something else (disk speed, for example) though I converted only one track at once. When I convert lossless->lossless I usually don't use more than one thread because it's frightening to hear what the HDD does if I let foobar use 2 threads while it essentially not faster at all (if not slower) than with one thread, but it's interesting that TAK encoder is so fast that it can be heavily limited by I/O using a single thread

I also tried to catch that helper thread of the Foobar FLAC decoder, but I couldn't find anything: when I do a long decoding speed test for a FLAC file (30 passes or so), Foobar2000 CPU usage never exceeds 50% on a dual core CPU, which means it's certainly single threaded.

edit. I repeated the decoding speed test with my backup foobar (previous foo_input_tak and tak_deco_lib) and it has the same behaviour - but this at least explains why I remembered that TAK's decoding speed isn't heavily affected by compression settings: I most probably tried it with "heavier" kind of music before.

System specs: Core2 duo e6420 @ 3.33GHz, 2GB ddr2 in dual channel mode @ 832MHz cl4. The aforementioned (probably limiting) HDD is a 250GB SATA2 Hitachi one. XPSP2 32bit resides on another (PATA) disk.

foo_input_tak

Reply #116 –
foo_input_tak 0.4.2

The component now returns audio chunks with a fixed number of samples instead of always returning whole TAK frames which could be quite large depending on the encoding profile. This avoids a bug in the Replay Gain scanner. It may also help to reduce stuttering when using CPU intensive DSP effects and a small output buffer. As a consequence of this change, dynamic bit rate reporting is no longer supported.

The ZIP archive now contains the change log as well as the TAK icon created by picmixer. Moreover the source for this version is available under the BSD license from my components page.

Quote from: alvaro84 on
I also tried to catch that helper thread of the Foobar FLAC decoder, but I couldn't find anything: when I do a long decoding speed test for a FLAC file (30 passes or so), Foobar2000 CPU usage never exceeds 50% on a dual core CPU, which means it's certainly single threaded.
There is no helper thread for I/O for any of the built-in decoders as far as I know.

foo_input_tak

Reply #117 –
Quote from: foosion on
As a consequence of this change, dynamic bit rate reporting is no longer supported.


Strange, mine lost this ability long ago, probably with the install of foobar 0.9.5 (betas?)
(I display bitrate in the status bar only, though. Probably a very unrelated issue...)

foo_input_tak

Reply #118 –
Thanks Foosion  I will try it with some DSP that I have experienced high CPU usage with TAK (I stop using it long ago though) to see if the problem solved.

Quote
Strange, mine lost this ability long ago, probably with the install of foobar 0.9.5 (betas?)


Me too, I also thought it was remove long ago. strange..

foo_input_tak

Reply #119 –
Regarding dynamic bit rate reporting: I re-checked the source code of the older versions, and it happens that I had turned this off to debug something and I forgot to turn it back on for the release builds. The new version no longer has the ability to enable this feature in the source code due to technical differences.

foo_input_tak

Reply #120 –
What I got from 0.4.2
  • Small decoding speed increase. 94.466x VS 91.280x on Athlon XP 1800 (NICE!!)
  • CPU usage reduce with some DSP. 0-4 VS 8-15 % CPU usage.
  • Bug with Replaygain is gone.
  • Nice Icon!
  • I have overall better feeling with foobar  I don't know... It seem when I doing something with TAK (Nearly all of my files) It feel more responsive than before, but maybe it just in my head. 

Thanks again for this release.

foo_input_tak

Reply #121 –
Hey foosion!
One question: There is tak 1.1.1 final released. Kann your plugin handle this? with the new tak_deco.dll or do I have to wait for an update of your plugin?

foo_input_tak

Reply #122 –
Quote
with the new tak_deco.dll or do I have to wait for an update of your plugin?


Didn't tested with 1.1.1, but this plugin does work with TAK 1.1.0.

foo_input_tak

Reply #123 –
TAK Decoder 0.4.2
Quote
Decodes and tags TAK files.

Built for TAK library version 1.0.1
Using TAK library version 1.1.1 (compatible with versions down to 1.0.0)

Copyright © 2007-2008 Holger Stenger
TAK icon by Florian Trendelenburg (used with permission)