The error in WinAmp plugin persists
Good news: Seems as if i have found the bug. Well, it wasn't really a bug: If Winamp was calling the winampGetExtendedFileInfo()-function with a request for the LENGTH info, my plugin indicated, that this info isn't available. That's no reason for Winamp to crash...
Hopefully i will release a new Winamp plugin in 1 or 2 days.
I have been playing around with this and I must say that I am impressed. With TAK 1.0.2 I not only end up smaller files than my WavPack -hhx files with -p5m but the TAK files decode quite a bit faster.
I actually have a few of my CDs encoded as TAK with embedded cuesheets now and will probably have more soon. Thank you for TAK, TBeck
Thank you for the encouragement! It's always a pleasure for me to hear that someone finds TAK useful.
I have just uploaded a new version of foo_input_tak for foobar2000 0.9.x (does not require 0.9.5) that adds recognition for the "Insane" profile in TAK 1.0.2 (full change list).
I did some quick testing with the CPU optimization options:
Encoder: TAK 1.0.2
Profile: normal
Decoder: foo_input_tak 0.3.4 / tak_deco_lib 1.0.5
Decoding test settings (foo_benchmark):
Buffer entire file into memory: yes
High priority: yes
Passes: 3
Desktop PC: AMD Athlon XP 2500+ (1.84 GHz)
Laptop PC: AMD Turion64 MT30 (1.60 GHz)
Results:
Setting | Desktop PC | Laptop PC
==========================================
Any | 134.264x realtime | 126.254x realtime
None | 91.834x realtime | 104.393x realtime
ASM only | 91.834x realtime | 105.475x realtime
MMX only | 133.722x realtime | 128.006x realtime
SSE only | 91.959x realtime | 105.537x realtime
TBeck: Is SSE support implemented or is that flag only a placeholder?
Sorry, i should have written a bit more about this in the SDK documentation:
1) Currently i don't use SSE. I tried it, but it wasn't any faster than my MMX (integer) implementation.
2) ASM also has no effect. It should enable/disable non-MMX assembler optimizations, but there are very few and they mostly only compensate limitations of the delphi compiler (no code alignment, suboptimal floating point code generation, no arithmetic right shift operation). I think a well optimizing compiler would achieve similar results with plain Delphi or C code.
TBeck: Is SSE support implemented or is that flag only a placeholder?
Wow... MMX is slower than none? What was this compiled with?
[edit]
nevermind, i just answered my own question... Borland Delphi 6 or 7
[/edit]
You are wrong: The values in the table represent rates and not absolute time values. But the effect of MMX is small for fast presets. The more demanding ones may be 2 to 3 times faster with MMX.
Hi there.
In the file access relation, when multibytes character is included in the filename and the pathname, etc. , it is likely to become an error in the file access relation.
It puts on Liisachan's post for this problem before and ..Liisachan's.. post.
It would be greatly appreciated when the part where the filename and the pathname are processed can be made unicode base as Liisachan's says, and the multibytes be supported.
It's on my todo list...
I can see very nice point in the future plans... Piped encoding. Finally we will be able to use tak encoder in foobar.
What you mean? It already is possible to encode to tak with foobar2000 (and all other commandline encoders for windows).
Indeed just recoded my lossless lib from 1.0.1 -p4m to 1.0.2 -p5m without any problems.
Nice to hear...
Thomas