TAK 1.0.3, (including Winamp plugin 1.0.7 and SDK 1.0.5) |
![]() ![]() |
TAK 1.0.3, (including Winamp plugin 1.0.7 and SDK 1.0.5) |
Dec 14 2007, 13:58
Post
#1
|
|
|
TAK Developer Group: Developer Posts: 1043 Joined: 1-April 06 Member No.: 29051 |
Final release of TAK 1.0.3 ((T)om's lossless (A)udio (K)ompressor)
This version brings pipe encoding, tiny compression improvements for the presets 0 to 2 and slightly faster decoding. It consists of: - TAK Applications 1.0.3 - TAK Winamp plugin 1.0.7. - TAK SDK 1.0.5. - TAK Decoding library 1.0.6. Download and Changelog Download the main archive and tools, and view the changelog, in the upload section: TAK 1.0.3 Final This post has been edited by TBeck: Dec 14 2007, 15:01 |
|
|
|
Dec 14 2007, 15:00
Post
#2
|
|
|
TAK Developer Group: Developer Posts: 1043 Joined: 1-April 06 Member No.: 29051 |
You may find some useful information in the beta thread.
Plans for V1.0.4 The next version will most probabbly implement one or more of those options: - Tagging functions for the command line version (but first without unicode support). - Faster decoding. - Fast seeking without seek table. This post has been edited by TBeck: Dec 14 2007, 15:24 |
|
|
|
Dec 14 2007, 19:22
Post
#3
|
|
![]() Group: Members (Donating) Posts: 478 Joined: 22-November 01 From: United Kingdom Member No.: 519 |
Awesome as always, Tom!
Pipe-support is sweeeet! This post has been edited by Dologan: Dec 14 2007, 19:22 |
|
|
|
Dec 16 2007, 08:18
Post
#4
|
|
|
TAK Developer Group: Developer Posts: 1043 Joined: 1-April 06 Member No.: 29051 |
Bug fix release TAK 1.0.3b
Fixed a bug in the GUI version ("Tak.exe"): - If the maximum size of the wave file meta data was set to 0, the compressor stopped with an "Error writing destination" error. Awesome as always, Tom! Pipe-support is sweeeet! Great! Thomas |
|
|
|
Dec 16 2007, 09:37
Post
#5
|
|
|
Group: Members Posts: 56 Joined: 19-May 07 Member No.: 43592 |
Thanks for this!
This post has been edited by CioCio: Dec 16 2007, 09:42 |
|
|
|
Dec 16 2007, 18:25
Post
#6
|
|
![]() Group: Members Posts: 50 Joined: 5-May 04 From: VA Member No.: 13908 |
I've just released shntool 3.0.6, which adds support for TAK encoding.
|
|
|
|
Dec 19 2007, 23:23
Post
#7
|
|
|
TAK Developer Group: Developer Posts: 1043 Joined: 1-April 06 Member No.: 29051 |
|
|
|
|
Dec 26 2007, 22:59
Post
#8
|
|
![]() Group: Members Posts: 292 Joined: 17-November 06 Member No.: 37682 |
nice, but how can one add support for tak on linux/*nix?
|
|
|
|
Jan 18 2008, 07:34
Post
#9
|
|
|
TAK Developer Group: Developer Posts: 1043 Joined: 1-April 06 Member No.: 29051 |
Synthetic Soul has updated his lossless comparison.
Some comments: The compression advantage over V1.0.2 is less than 0.01 percent while it is on average more than 0.05 percent for my sample sets. No big surprise for me, because Synthetic Soul's sample set isn't very TAK friendly. His files mostly don't benefit from more than 16 predictors, while TAK can use up to 256. Since the improvements in V1.0.3 usually affect files with high predictor orders the advantage here is very small. Decoding is now significantly faster. Up to -p2e TAK is decoding faster than FLAC -8. Synthetic Soul has also provided a comparison with FLAC and it's MD5 check disabled. Even under this condition TAK -p0 is decoding only slightly slower than FLAC -8. I am confident, that later versions of TAK will close this small gap. For instance the prediction filter contains a couple of instructions, which are now obsolete and could be removed, if i hadn't to care for backwards compatibility. Surprisingly even encoding got faster, although i haven't performed any optimizations! Possibly the modification of the window function of the predictor, which is also responsible for the tiny compression improvements, affects the choice of the predictor count: Less predictors = more speed. This post has been edited by TBeck: Jan 18 2008, 07:36 |
|
|
|
Jan 31 2008, 02:15
Post
#10
|
|
|
TAK Developer Group: Developer Posts: 1043 Joined: 1-April 06 Member No.: 29051 |
Surprisingly even encoding got faster, although i haven't performed any optimizations! Possibly the modification of the window function of the predictor, which is also responsible for the tiny compression improvements, affects the choice of the predictor count: Less predictors = more speed. I have to correct me: There was a tiny modification in the encoder's bitcoder which saved a handful of simple instructions, but i never would have expected this could have such a significant effect on the encoding speed! |
|
|
|
![]() ![]() |
|
Lo-Fi Version | Time is now: 21st May 2013 - 15:11 |