TAK 2.1.0 Options

[TBeck]

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

Download the archive in the upload section: TAK 2.1.0

What's new

Improvements:

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

Modifications:

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

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.

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.

More information

You can find some useful information and speed comparisons in the Beta 3 thread.

Have fun...

Thomas

This post has been edited by TBeck: Jan 9 2011, 04:06

[Steve Forte Rio]

Gteat work! Thank you!


And now let's start testing

[meDveD.spb]

BIG THX!

[Steve Forte Rio]

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

This post has been edited by Steve Forte Rio: Jan 8 2011, 22:43

[jc3213]

Thanks for your great work! I have been waiting for this so long.

[johnsonlam]

Thank you very much Thomas!

Wish List (only wish):

1) Support for HDCD bit recognition
2) Optimization for AMD CPU
3) Hardware support

[Steve Forte Rio]

I've noticed a quite strange thing.

On my system two threads encoding is slowed down even when HT is disabled!

just look (HT disabled in BIOS, there are only 2 physical threads!):

CODE

-e -p4m -wm0 -ihs -silent        = 31.01x realtime
-e -p4m -tn2 -wm0 -ihs -silent   = 38.51x realtime

takc loads 2 cores (with -tn2)

what could it be????

Two weeks ago encoding with -tn2 was ~57x

And this is not HDD fragmentation

This post has been edited by Steve Forte Rio: Jan 9 2011, 14:39

[Corpulencio]

Big thanks!

Thomas, can you say what number on your "to do" list is multichannel support ? Thank you.

[TBeck]

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.

[Destroid]

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.

Supposedly future "Bulldozer and Bobcat based" processors will support it. No idea which of these AMD processors will have it nor when those processor will be available.

As for multichannel: it would certainly be interesting to see but myself doesn't use anything with more than 2 channels. I think people who actually use it need to step up and mention their own scenarios.

[sauvage78]

The lack of requests for multichannel is IMHO simply due to the fact that you're listening to HA users instead of D9 users.
If all you need is some requests, just ask here: multichannel trolls' lair if they're interested, IMHO there's potentially 179 861 requests for it

This post has been edited by sauvage78: Jan 11 2011, 09:21

[johnsonlam]

1) Support for HDCD bit recognition
I don't think this is the business of a lossless codec...

That's why I call it 'wish-list', usually wish will not become reality, otherwise the human race will be much better with the earth.

My reason is simple, because the HDCD decoding through Foobar2000 not working, whenever not working should be fixed, of course it's the lowest priority, and I'm not programmer, can't help even if I want to.

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.

Again, I'm no programmer, so if AMD have nothing can help speedup, it's no way.
You did a great job already, thank you for sharing the great codec.

[GeSomeone]

1) Support for HDCD bit recognition
I don't think this is the business of a lossless codec...

My reason is simple, because the HDCD decoding through Foobar2000 not working, whenever not working should be fixed, of course it's the lowest priority, and I'm not programmer, can't help even if I want to.

TBeck is right, every lossless codec just keeps the HDCD control bits and that's it. I think what you really mean has to do with the foobar2000 TAK decoder plugin, it should be made postprocessor aware (as should still be done with the ALAC and Monkey decoders). Maybe you should file your request with foosion, who was so kind to provide the foobar input plugin for TAK.

[johnsonlam]

1) Support for HDCD bit recognition
I don't think this is the business of a lossless codec...

My reason is simple, because the HDCD decoding through Foobar2000 not working, whenever not working should be fixed, of course it's the lowest priority, and I'm not programmer, can't help even if I want to.

TBeck is right, every lossless codec just keeps the HDCD control bits and that's it. I think what you really mean has to do with the foobar2000 TAK decoder plugin, it should be made postprocessor aware (as should still be done with the ALAC and Monkey decoders). Maybe you should file your request with foosion, who was so kind to provide the foobar input plugin for TAK.

Thank you for directing me to foosion, I really need your explain to know the problem.
And thanks Thomas for the hard work.

[list]

Congratulations. And thanks a lot great job!

[zver]

Just a fast question;
I started using tak few months ago and im really thrilled couse when using p4 profile compression comes around as ape Extra-high or maybe 0.5-1% bigger,but compress double faster and decompress minimum 3 times faster so i hope that you continue your development and get more hardware and software support....btw i was so happy that mp3tag supports tak too:)
Anyway my question is what would be the best option for encoding speedwize;
Im running windows 7 ultimate 64,dual core and encoding is done with foobar.Now i put this line in options for takc
-e -p4 -ihs - %d but im just wondering couse it was written that this new 2.1.0 version have some optimizations,maybe i can get tasks done faster couse its a windows 7 64 b and its intel dual core...
Thanks you T once again for this kickass codec

[Manlord]

With every version of TAK you advance one step beyond the other lossless codecs.

Keep the good work, Thomas. Thank you.

[TBeck]

1) Support for HDCD bit recognition
I don't think this is the business of a lossless codec...

That's why I call it 'wish-list', usually wish will not become reality, otherwise the human race will be much better with the earth.

My reason is simple, because the HDCD decoding through Foobar2000 not working, whenever not working should be fixed, of course it's the lowest priority, and I'm not programmer, can't help even if I want to.

I hope my response didn't appear rude. This was not my intention. To be honest, i don't know much about HDCD.

Im running windows 7 ultimate 64,dual core and encoding is done with foobar.Now i put this line in options for takc
-e -p4 -ihs - %d but im just wondering couse it was written that this new 2.1.0 version have some optimizations,maybe i can get tasks done faster couse its a windows 7 64 b and its intel dual core...

The cpu specific optimizations will be selected automatically, but you may add -tn2 (creates 2 encoder threads) to your command line to utilize both cores. However, some users have reported even better performance when using foobar's inbuilt multi threading.

BTW: I am already working on the next release. This is what i have done so far:

- SSE2/3 optimizations of the decoder (affecting only p2, p3 and p4).
- Some tiny general speed optimizations.
- Slightly better compression for some problem files and especially for 96/192 KHz 24-bit audio.
- Some preparations for multi channel audio.

[krafty]

My wishlist:

A linux version!

tak (a binary)

libtakenc.so (closed-source, hey that works for me...)

and

libtakdec.so (open source, but with restricting license, so everyone can implement it, with authorization and credits due).

This post has been edited by krafty: Feb 14 2011, 22:37

[greynol]

Thomas is well aware of any and all comments/discussions/arguments about linux versions and/or opening TAK's source code. Unless Thomas expressly welcomes such a conversation, further posts in this vein will be removed. This initial request is more than adequate and will remain. The reason for this moderation decision is to keep the thread from escalating into debate as has happened in the past.

This post has been edited by greynol: Feb 20 2011, 18:56

Reason for edit: Included part about opening source code.

[zver]

1) Support for HDCD bit recognition
I don't think this is the business of a lossless codec...

That's why I call it 'wish-list', usually wish will not become reality, otherwise the human race will be much better with the earth.

My reason is simple, because the HDCD decoding through Foobar2000 not working, whenever not working should be fixed, of course it's the lowest priority, and I'm not programmer, can't help even if I want to.

I hope my response didn't appear rude. This was not my intention. To be honest, i don't know much about HDCD.

The cpu specific optimizations will be selected automatically, but you may add -tn2 (creates 2 encoder threads) to your command line to utilize both cores. However, some users have reported even better performance when using foobar's inbuilt multi threading.

BTW: I am already working on the next release. This is what i have done so far:

- SSE2/3 optimizations of the decoder (affecting only p2, p3 and p4).
- Some tiny general speed optimizations.
- Slightly better compression for some problem files and especially for 96/192 KHz 24-bit audio.
- Some preparations for multi channel audio.

Thank you very much and hope that tak becomes even faster

[sl1pkn07]

My wishlist:

A linux version!

tak (a binary)

libtakenc.so (closed-source, hey that works for me...)

and

libtakdec.so (open source, but with restricting license, so everyone can implement it, with authorization and credits due).

yes please! release linux version!

EDIT: do'h! sorry. exist newer version of TAK. :S

sorry for this

This post has been edited by sl1pkn07: Nov 27 2011, 21:56