IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
TAK 2.1.0
TBeck
post Jan 8 2011, 21:04
Post #1


TAK Developer


Group: Developer
Posts: 1098
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

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
Go to the top of the page
+Quote Post
Steve Forte Rio
post Jan 8 2011, 21:31
Post #2





Group: Members
Posts: 453
Joined: 4-October 08
From: Ukraine
Member No.: 59301



Gteat work! Thank you!


And now let's start testing smile.gif
Go to the top of the page
+Quote Post
meDveD.spb
post Jan 8 2011, 22:17
Post #3





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



BIG THX!
Go to the top of the page
+Quote Post
Steve Forte Rio
post Jan 8 2011, 22:42
Post #4





Group: Members
Posts: 453
Joined: 4-October 08
From: Ukraine
Member No.: 59301



QUOTE (TBeck @ Dec 13 2010, 14:01) *
QUOTE (Steve Forte Rio @ Dec 12 2010, 19:04) *
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 sad.gif

This post has been edited by Steve Forte Rio: Jan 8 2011, 22:43
Go to the top of the page
+Quote Post
jc3213
post Jan 9 2011, 05:02
Post #5





Group: Members
Posts: 11
Joined: 28-January 10
Member No.: 77608



Thanks for your great work! I have been waiting for this so long.
Go to the top of the page
+Quote Post
johnsonlam
post Jan 9 2011, 07:28
Post #6





Group: Members
Posts: 226
Joined: 12-January 03
From: Kowloon, Hong Kong
Member No.: 4533



Thank you very much Thomas!

Wish List (only wish):

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


--------------------
Hong Kong - International Joke Center (after 1997-06-30)
Go to the top of the page
+Quote Post
Steve Forte Rio
post Jan 9 2011, 14:24
Post #7





Group: Members
Posts: 453
Joined: 4-October 08
From: Ukraine
Member No.: 59301



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???? blink.gif

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
Go to the top of the page
+Quote Post
Corpulencio
post Jan 9 2011, 21:13
Post #8





Group: Members
Posts: 3
Joined: 9-January 11
Member No.: 87200



Big thanks!

Thomas, can you say what number on your "to do" list is multichannel support smile.gif? Thank you.
Go to the top of the page
+Quote Post
TBeck
post Jan 10 2011, 12:50
Post #9


TAK Developer


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



QUOTE (Steve Forte Rio @ Jan 8 2011, 22:42) *
QUOTE (TBeck @ Dec 13 2010, 14:01) *
QUOTE (Steve Forte Rio @ Dec 12 2010, 19:04) *
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 sad.gif

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.

QUOTE (johnsonlam @ Jan 9 2011, 07:28) *
Wish List (only wish):

1) Support for HDCD bit recognition

I don't think this is the business of a lossless codec...

QUOTE (johnsonlam @ Jan 9 2011, 07:28) *
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.

QUOTE (Steve Forte Rio @ Jan 9 2011, 14:24) *
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.

QUOTE (Corpulencio @ Jan 9 2011, 21:13) *
Thomas, can you say what number on your "to do" list is multichannel support smile.gif? 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.
Go to the top of the page
+Quote Post
Destroid
post Jan 11 2011, 08:13
Post #10





Group: Members
Posts: 551
Joined: 4-June 02
Member No.: 2220



QUOTE (TBeck @ Jan 10 2011, 11:50) *
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.


--------------------
"Something bothering you, Mister Spock?"
Go to the top of the page
+Quote Post
sauvage78
post Jan 11 2011, 09:20
Post #11





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



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

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


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
johnsonlam
post Jan 13 2011, 04:32
Post #12





Group: Members
Posts: 226
Joined: 12-January 03
From: Kowloon, Hong Kong
Member No.: 4533



QUOTE (TBeck @ Jan 10 2011, 19:50) *
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.

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


--------------------
Hong Kong - International Joke Center (after 1997-06-30)
Go to the top of the page
+Quote Post
GeSomeone
post Jan 13 2011, 10:11
Post #13





Group: Members
Posts: 922
Joined: 22-October 01
From: the Netherlands
Member No.: 335



QUOTE (johnsonlam @ Jan 13 2011, 05:32) *
QUOTE (TBeck @ Jan 10 2011, 19:50) *
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.


--------------------
In theory, there is no difference between theory and practice.
Go to the top of the page
+Quote Post
johnsonlam
post Jan 20 2011, 19:41
Post #14





Group: Members
Posts: 226
Joined: 12-January 03
From: Kowloon, Hong Kong
Member No.: 4533



QUOTE (GeSomeone @ Jan 13 2011, 17:11) *
QUOTE (johnsonlam @ Jan 13 2011, 05:32) *
QUOTE (TBeck @ Jan 10 2011, 19:50) *
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.


--------------------
Hong Kong - International Joke Center (after 1997-06-30)
Go to the top of the page
+Quote Post
list
post Jan 29 2011, 14:33
Post #15





Group: Members
Posts: 27
Joined: 7-September 10
From: Argentina
Member No.: 83667



Congratulations. And thanks a lot smile.gif great job!
Go to the top of the page
+Quote Post
zver
post Jan 31 2011, 02:36
Post #16





Group: Members
Posts: 174
Joined: 12-June 03
From: toronto
Member No.: 7141



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 smile.gif
Go to the top of the page
+Quote Post
Manlord
post Feb 5 2011, 22:52
Post #17





Group: Members
Posts: 25
Joined: 2-April 10
Member No.: 79529



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

Keep the good work, Thomas. Thank you.
Go to the top of the page
+Quote Post
TBeck
post Feb 14 2011, 22:28
Post #18


TAK Developer


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



QUOTE (johnsonlam @ Jan 13 2011, 04:32) *
QUOTE (TBeck @ Jan 10 2011, 19:50) *
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.

QUOTE (zver @ Jan 31 2011, 02:36) *
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.

Go to the top of the page
+Quote Post
krafty
post Feb 14 2011, 22:35
Post #19





Group: Members
Posts: 278
Joined: 20-March 10
Member No.: 79175



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
Go to the top of the page
+Quote Post
greynol
post Feb 14 2011, 23:16
Post #20





Group: Super Moderator
Posts: 10009
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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.


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
zver
post Feb 15 2011, 07:20
Post #21





Group: Members
Posts: 174
Joined: 12-June 03
From: toronto
Member No.: 7141



QUOTE (TBeck @ Feb 14 2011, 13:28) *
QUOTE (johnsonlam @ Jan 13 2011, 04:32) *
QUOTE (TBeck @ Jan 10 2011, 19:50) *
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.

smile.gif
Thank you very much and hope that tak becomes even faster smile.gif
Go to the top of the page
+Quote Post
sl1pkn07
post Nov 27 2011, 21:54
Post #22





Group: Members
Posts: 2
Joined: 27-November 11
From: Spanishtán
Member No.: 95437



QUOTE (krafty @ Feb 14 2011, 22:35) *
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
Go to the top of the page
+Quote Post

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: 2nd October 2014 - 10:52