IPB

Welcome Guest ( Log In | Register )

10 Pages V  « < 3 4 5 6 7 > »   
Reply to this topicStart new topic
foo_input_tak, TAK decoder
Squeller
post Mar 9 2008, 20:55
Post #101





Group: Members
Posts: 2351
Joined: 28-August 02
Member No.: 3218



QUOTE (foosion @ Mar 9 2008, 18:32) *
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"...

This post has been edited by Squeller: Mar 9 2008, 20:57
Go to the top of the page
+Quote Post
kanak
post Mar 9 2008, 20:59
Post #102





Group: Members
Posts: 1190
Joined: 12-January 06
From: Cambridge, MA
Member No.: 27052



QUOTE (Squeller @ Mar 9 2008, 14:55) *
QUOTE (foosion @ Mar 9 2008, 18:32) *
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)
Go to the top of the page
+Quote Post
foosion
post Mar 9 2008, 22:07
Post #103





Group: FB2K Moderator (Donating)
Posts: 4484
Joined: 24-February 03
Member No.: 5153



QUOTE (kanak @ Mar 9 2008, 20:59) *
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.


--------------------
http://foosion.foobar2000.org/ - my components for foobar2000
Go to the top of the page
+Quote Post
alvaro84
post Mar 9 2008, 22:34
Post #104





Group: Members
Posts: 128
Joined: 9-August 06
Member No.: 33830



QUOTE (foosion @ Mar 9 2008, 17:32) *
foo_input_tak 0.4

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


Thanks, works like a charm smile.gif
Go to the top of the page
+Quote Post
TBeck
post Mar 10 2008, 02:59
Post #105


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



QUOTE (alvaro84 @ Mar 5 2008, 15:04) *
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? huh.gif

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 (foosion @ Mar 5 2008, 16:56) *
QUOTE (alvaro84 @ Mar 5 2008, 15:04) *
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? huh.gif

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 (foosion @ Mar 9 2008, 17:32) *
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
Go to the top of the page
+Quote Post
buktore
post Mar 10 2008, 03:06
Post #106





Group: Members
Posts: 506
Joined: 24-November 06
Member No.: 38011



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. huh.gif
Go to the top of the page
+Quote Post
alvaro84
post Mar 10 2008, 07:54
Post #107





Group: Members
Posts: 128
Joined: 9-August 06
Member No.: 33830



QUOTE (TBeck @ Mar 10 2008, 02:59) *
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
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 unsure.gif

...but if FLAC decoding really use a helper thread for data move it can probably explain the difference smile.gif
Go to the top of the page
+Quote Post
foosion
post Mar 10 2008, 14:34
Post #108





Group: FB2K Moderator (Donating)
Posts: 4484
Joined: 24-February 03
Member No.: 5153



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


--------------------
http://foosion.foobar2000.org/ - my components for foobar2000
Go to the top of the page
+Quote Post
foosion
post Mar 10 2008, 17:01
Post #109





Group: FB2K Moderator (Donating)
Posts: 4484
Joined: 24-February 03
Member No.: 5153



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


--------------------
http://foosion.foobar2000.org/ - my components for foobar2000
Go to the top of the page
+Quote Post
alvaro84
post Mar 10 2008, 22:10
Post #110





Group: Members
Posts: 128
Joined: 9-August 06
Member No.: 33830



QUOTE ("foosion")
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? unsure.gif I don't know the source and not even the SDK/protocols, but I'm still curious smile.gif 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 sad.gif 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 biggrin.gif - hm, I see you tested it on a K8-based laptop, so that future A64 probably won't help you much unsure.gif)

OK, I finish to talk about my misery biggrin.gif
Go to the top of the page
+Quote Post
foosion
post Mar 10 2008, 22:41
Post #111





Group: FB2K Moderator (Donating)
Posts: 4484
Joined: 24-February 03
Member No.: 5153



QUOTE (alvaro84 @ Mar 10 2008, 22:10) *
Does TAK behave differently to FLAC in this respect? unsure.gif I don't know the source and not even the SDK/protocols, but I'm still curious smile.gif 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.


--------------------
http://foosion.foobar2000.org/ - my components for foobar2000
Go to the top of the page
+Quote Post
TBeck
post Mar 11 2008, 07:36
Post #112


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



QUOTE (alvaro84 @ Mar 10 2008, 07:54) *
CODE
FLAC -8    650kbps, 643x
TAK 2 max  623kbps, 346x
TAK 5 max  607kbps, 217x

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

QUOTE (alvaro84 @ Mar 10 2008, 07:54) *
...but if FLAC decoding really use a helper thread for data move it can probably explain the difference smile.gif

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

QUOTE (foosion @ Mar 10 2008, 14:34) *
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 (foosion @ Mar 10 2008, 22:41) *
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.
Go to the top of the page
+Quote Post
foosion
post Mar 11 2008, 12:32
Post #113





Group: FB2K Moderator (Donating)
Posts: 4484
Joined: 24-February 03
Member No.: 5153



QUOTE (TBeck @ Mar 11 2008, 07:36) *
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 (TBeck @ Mar 11 2008, 07:36) *
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.

This post has been edited by foosion: Mar 11 2008, 12:33


--------------------
http://foosion.foobar2000.org/ - my components for foobar2000
Go to the top of the page
+Quote Post
foosion
post Mar 13 2008, 14:56
Post #114





Group: FB2K Moderator (Donating)
Posts: 4484
Joined: 24-February 03
Member No.: 5153



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.


--------------------
http://foosion.foobar2000.org/ - my components for foobar2000
Go to the top of the page
+Quote Post
IgorC
post Mar 14 2008, 05:08
Post #115





Group: Members
Posts: 1581
Joined: 3-January 05
From: ARG/RUS
Member No.: 18803



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

This post has been edited by IgorC: Mar 14 2008, 05:11
Go to the top of the page
+Quote Post
alvaro84
post Mar 14 2008, 15:23
Post #116





Group: Members
Posts: 128
Joined: 9-August 06
Member No.: 33830



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

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

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.

This post has been edited by alvaro84: Mar 14 2008, 15:24
Go to the top of the page
+Quote Post
foosion
post Apr 8 2008, 11:14
Post #117





Group: FB2K Moderator (Donating)
Posts: 4484
Joined: 24-February 03
Member No.: 5153



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 (alvaro84 @ Mar 14 2008, 15:23) *
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.


--------------------
http://foosion.foobar2000.org/ - my components for foobar2000
Go to the top of the page
+Quote Post
alvaro84
post Apr 8 2008, 12:51
Post #118





Group: Members
Posts: 128
Joined: 9-August 06
Member No.: 33830



QUOTE (foosion @ Apr 8 2008, 11:14) *
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?) unsure.gif
(I display bitrate in the status bar only, though. Probably a very unrelated issue...)

This post has been edited by alvaro84: Apr 8 2008, 12:54
Go to the top of the page
+Quote Post
buktore
post Apr 8 2008, 13:39
Post #119





Group: Members
Posts: 506
Joined: 24-November 06
Member No.: 38011



Thanks Foosion biggrin.gif 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.. unsure.gif
Go to the top of the page
+Quote Post
foosion
post Apr 8 2008, 14:08
Post #120





Group: FB2K Moderator (Donating)
Posts: 4484
Joined: 24-February 03
Member No.: 5153



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.


--------------------
http://foosion.foobar2000.org/ - my components for foobar2000
Go to the top of the page
+Quote Post
buktore
post Apr 8 2008, 14:57
Post #121





Group: Members
Posts: 506
Joined: 24-November 06
Member No.: 38011



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 rolleyes.gif 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. wink.gif

Thanks again for this release.
Go to the top of the page
+Quote Post
Spirit_of_the_oc...
post Mar 15 2009, 11:51
Post #122





Group: Members
Posts: 583
Joined: 12-September 06
Member No.: 35092



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?
Go to the top of the page
+Quote Post
lvqcl
post Mar 15 2009, 12:21
Post #123





Group: Developer
Posts: 3468
Joined: 2-December 07
Member No.: 49183



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.
Go to the top of the page
+Quote Post
meDveD.spb
post Mar 15 2009, 12:47
Post #124





Group: Members
Posts: 52
Joined: 4-April 07
Member No.: 42192



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)


This post has been edited by meDveD.spb: Mar 15 2009, 12:49
Go to the top of the page
+Quote Post
Hommit
post Apr 12 2009, 21:14
Post #125





Group: Members
Posts: 2
Joined: 16-January 09
Member No.: 65638



Hi.
any reason for not playing this one?
http://www.nyaatorrents.org/?page=torrenti...amp;showfiles=1

QUOTE
Unable to open item for playback (Undecodable.):
"M:\Haruka Shimotsuki\temp\Haruka Shimotsuki\break time\KDSD-00272.tak"


This post has been edited by Hommit: Apr 12 2009, 21:18
Go to the top of the page
+Quote Post

10 Pages V  « < 3 4 5 6 7 > » 
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 26th December 2014 - 12:12