Jan 8 2011, 21:04
Joined: 1-April 06
Member No.: 29051
Final release of TAK 2.1.0 ((T)om's lossless (A)udio (K)ompressor)
This release brings speed optimizations and multi core support for the encoder. The dedicated LossyWav-codec that was available in the beta releases has been removed.
It consists of:
- TAK Applications 2.1.0.
- TAK Winamp plugin 2.1.0.
- TAK SDK 1.1.1.
- TAK Decoding library 2.1.0.
Download the archive in the upload section: TAK 2.1.0
- Encoding speed improvements of about 10 to 20 percent (depends on preset and cpu) for cpus with the SSSE3 instruction set. Since SSSE3 (note the three 'S') isn't supported by AMD, only Intel users will benefit from those optimizations.
- The encoder now creates up to four threads to utilize multiple cpu cores. Specify the thread number in the General Options dialog of the GUI-version or with the -tn option of the command line version. By default only one thread is created. You will only notice a speed up, if the encoding speed isn't already limited by the performance of your drives.
- Added the -cpu# switch to the command line version, which lets you control some cpu optimizations.
- The file info function now also shows the name of the codec used to compress the file.
- Moved the verify-option from the details-dialog to the general compression options dialog.
- All dialogs with an Add-files-option locked the source folder until the dialog was closed. Hopefully this is no longer the case.
- If you use pipe decoding and the application reading the pipe is beeing terminated before the whole file has been read, TAKC may get into an endless loop and has to be manually killed with the task manager. I don't think this is a big issue but i will try to fix it in one of the next versions. BTW: Big thanks to shnutils for testing the pipe decoding!
- There seem to be some compatibility issues with pipe decoding to some other applications ("crc1632.exe" has been reported). I will try to fix it in the next release.
Why is it called 2.1 and not 2.0.1?
Usually i increase the second place of the version number if some option has been added which isn't backwards compatible (can not be decoded by earlier versions) but will only take effect, if it is explicitly activated by the user. This was true for the LossyWav-codec that now has been removed. But i didn't want to go down to 2.0.1 because of the possible confusion occuring when i later released another 2.1 which would have nothing in common with the current beta 2.1.
You can find some useful information and speed comparisons in the Beta 3 thread.
This post has been edited by TBeck: Jan 9 2011, 04:06
Jan 10 2011, 12:50
Joined: 1-April 06
Member No.: 29051
And now, can you add the switch for choosing what CPU's encoder must use?
It can be useful for dual core processors with hyperthreading technology (like Core i) - to prevent using of two threads of one physical CPU
Look how a big difference is there between results for enabled and disabled Hyper Threading...
I am just working on it, but i think you will have to wait until V2.1.1 for a solution. That because a lot of testing on different systems may be required.
I hope this will be fixed in the near future..
-tn2 on systems with 2 and 4 physical/logical processors respectively (HyperThreading) is really slow
As i wrote in the beta 3 thread, i am still quite reluctant to add such an option, because it is generally recommended to let the OS distribute the cores. I will think a bit more about it.
Wish List (only wish):
1) Support for HDCD bit recognition
I don't think this is the business of a lossless codec...
2) Optimization for AMD CPU
There is nearly no CPU specific code. I always try to optimize in a way that is advantegous for most Intel and Amd CPUs. The only exception are the SSSE3 optimizations. But since AMD doesn't support them, there is nothing i can do.
I've noticed a quite strange thing.
On my system two threads encoding is slowed down even when HT is disabled!
The only difference between the beta 3b and the final release is the removal of the dedicated LossyWav-codec. Nothing else has changed.
One ad hoc explaination: Some functions of the new build may be a tiny bit faster or slower because of a different code alignment. It is possible, that even speed variations of only a couple of percent result in a worse syncronization with foobars activity. Such an interaction can be extremely subtle and is usually very system dependend.
Thomas, can you say what number on your "to do" list is multichannel support ? Thank you.
It's on the top! One reason, why i haven't alreday done it, is the contrast between the large amount of work required and the lack of user requests.
|Lo-Fi Version||Time is now: 29th December 2014 - 00:15|