Final release of TAK 1.1.2 ((T)om's lossless (A)udio (K)ompressor)

This version brings tagging support for the command line encoder and speed improvements of up to 10 percent.

It consists of:

- TAK Applications 1.1.2.
- TAK Winamp plugin 1.1.2.
- TAK SDK 1.1.1.
- TAK Decoding library 1.1.2.

Download

Download the archive in the upload section: TAK 1.1.2 Final

What's new

New Features:

- Tagging support for the command line encoder.

Improvements:

- Depending on preset and cpu up to 10 percent faster encoding and decoding compared with V1.1.1.
- Slightly faster encoding and decoding of LossyWav files.
- Slightly faster encoding and decoding if MMX is disabled and the pure pascal code is beeing used.
- Removed some more assembler routines and simplified a lot of code. The binaries are again smaller now.

Fixes:

- The new filter introduced in V1.1.1 revealed a bug in the encoder, which resulted in suboptimal performance especially when compressing LossyWav-files with the presets -p3 or -p4 (BTW: It doesn't make sense to go higher than -p2m when compressing LossyWav-files...).

Known issues:

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

More information

You may find some useful information in the beta thread.

Plans for V1.1.3

I don't know yet.

Have fun...

Thomas

Congratulations on a fine release.

Using this under Linux/x64 with Wine 1.1.5 on a Turion 64 X2 TL-58 system and notice a speed improvement of at least 5% for all settings. Keep up the good work on your promising codec.

Thanks for the continuing development. For my lossless, I use 100% tak, because of its great speed/size ratio and its reliability.

does foobar use pipe decoding?




TBeck: thanks for your work!

TBeck;

Thank you for all the hard work on this codec!

Yes.

Here's a couple of tests, all default settings (all compression ratios were identical):


Great work!

Foobar doesn't use pipe decoding.

I mean, it doesn't use TAKC.exe for decoding and doesn't read pipe from TAKC. Instead, TAK component for foobar2000 relies on tak_deco_lib.dll.

Tom, thank you for your continued work. One day TAK may replace FLAC for me. It definitely is a very promising codec.

I did some tests out of curiosity.. and it seems like 1.1.2 is slower on my computer than 1.1.1 is!

with v1.1.1 encoding with TEST in the GUI i got:
Compression: 70.22 %
Duration: 82.75 sec
Speed: 205.07 * real time

and with 1.1.2 i got:
Compression: 70.22 %
Duration: 157.40 sec
Speed: 107.81 * real time

v1.1.1 seemed to max out at 213x when encoding and 1.1.2 seemed to max out at around 111x or so. This was on a collection of 57 songs

I'm running Windows Vists Ultimate 64bit with an Intel i7 920 (@3.2GhZ) (if you need to know more i can tell you)

One thing i noticed was that was weird was while encoding some songs the encode rate would drop down to 50 to 70x then shoot back up on the next song. I don't know if this is normal or not, so i just wanted to mention it. Also, it wasn't the song that caused it, as one test it would encode at it's max speed then in another test it would slow down to 50x..

I'm willing to do other tests, just let me know what i can do

Thanks for the release Thomas!

Do you plan on adding raw pcm encoding/decoding on the next version?

can you make your official website to english because i can't read German.

http://translate.google.de/translate?hl=de...FTak%2FTak.html

Very much been a fan of TAK for a long time now. Thanks for the ongoing work, Tom. Much appreciated.

Which settings did you use?


That sounds more like something in the background eating cycles, is my guess. I can't imagine that being normal behavior, usually the opposite. There's a few friend's machines I fixed where that was infested with malware, so it might be a good idea to check that since slow encoding is the least worrisome in that scenario.

Many thanks Tom

Thank you very much! Especially for appreciating even small improvements!




A really good reply!

I want to add another possible explaination: TAK is using extremely optimized code in the filters, which may drive CPU's into areas, where the cooling isn't sufficient and they use clock-throttling.



It's on my todo list... But no promises: I am also working hard on the TAK 2.0 codec, and i am progressing faster than expected... I am not sure, if there will be a 1.1.3 release (with new functionality) before the 2.0 release. Possibly you will have to wait for 2.0.1...


Given my rather bad english, i am a bit in a trouble here...

While i myself can tolerate my bad english in some of TAK's documentation (sorry to the readers), i don't want to let it show up on my homepage, where i am also presenting my self employeed work.

I have to look for a solution.

Thomas

I thought a few major players here in HA were affluent in your language, I'm trying to remember them by alias since they would be able to translate your technical terms correctly. And you are correct, people visiting your home page should have the professional prose that equates to the the professional program, if I must say.

Also, thanks for the excellent news about upcoming TAK releases. I, for one, will be eagerly awaiting.

edit: typos

I have had the embarrassment of having my English grammar corrected by fusion.

Personally I am amazed at how well many members here use English. Sebastian Mares and Lyx spring to mind, as proficient English-writing Germans.

Edit: Oh, and I should point out that your English, Thomas, is one thousand times better than any second language I have attempted (which probably totals French and Spanish).

Agreed. Your English is quite up to par with the norm you see from FIRST-LANGUAGE speakers lately.

I have been using TAK since its first final release (having switched to it from Monkey's Audio) and I must say that, while there are many other great (some even awesome) lossless codecs, I love TAK for its rich set of excellent features.

Alas, I must woefully confess that I have had to use WavPack lately. The trouble is TAK doesn't support multichannel audio so far. WavPack is a truly awesome codec, and I respect its developer as much as I do Thomas. Yet I prefer TAK for its speed/compression ratio, and since I always try to get the highest compression a codec offers, I do the same with WavPack using the following options: wavpack.exe -hh -m -x6 *.wav. Space is something always worth saving, and hi-rez multichannel audio certainly calls for that. It is, however, almost intolerable to wait for a file to take five to eight times longer to get compressed than its own length. (I say "almost" because I still tolerate this.)

Indeed, the WavPack help warns that using the -x[4-6] option is very slow, and it is my own choice to do so. Yet from the fact that TAK offers even better compression within a fraction of that time when tested on some 24-bit stereo files I infer (and truly hope) that the speed/compression ratio will be the same for multichannel audio when support for that is implemented.

Itching to see the next TAK release (whether 1.1.3 or 2.0.1).

Big thanks to Thomas. Nice day to all.

Hi TBeck.
It appears that tak_SSD_Create_FromFile can not handle unicode names. It would be nice if multibyte filenames could be used or a function that can accept widechar filenames was created.
Thanks.

By the way, hopefully, the next releases of TAK will support resolutions of up to 192 kHz.

It does already support 192 KHz, but unfortunately no multichannel audio. I will work on it after the 2.0 release.

Thomas

Indeed, my mistake.