Skip to main content

Topic: TAK 1.0.3 (Read 30618 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • TBeck
  • [*][*][*][*][*]
  • Developer
TAK 1.0.3
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
  • Last Edit: 14 December, 2007, 09:01:28 AM by TBeck

  • TBeck
  • [*][*][*][*][*]
  • Developer
TAK 1.0.3
Reply #1
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.
  • Last Edit: 14 December, 2007, 09:24:11 AM by TBeck

  • Dologan
  • [*][*][*][*]
  • Members (Donating)
TAK 1.0.3
Reply #2
Awesome as always, Tom!

Pipe-support is sweeeet!    It actually makes a significant performance improvement when using foobar2000 on a quad-core machine, since the stress of multi-threaded conversion on the hard drive is much less. Thanks a lot for your efforts!
  • Last Edit: 14 December, 2007, 01:22:48 PM by Dologan

  • TBeck
  • [*][*][*][*][*]
  • Developer
TAK 1.0.3
Reply #3
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!    It actually makes a significant performance improvement when using foobar2000 on a quad-core machine, since the stress of multi-threaded conversion on the hard drive is much less. Thanks a lot for your efforts!

Great!

  Thomas

  • CioCio
  • [*][*]
TAK 1.0.3
Reply #4
Thanks for this!
  • Last Edit: 16 December, 2007, 03:42:31 AM by CioCio

  • shnutils
  • [*][*]
TAK 1.0.3
Reply #5
I've just released shntool 3.0.6, which adds support for TAK encoding.

  • TBeck
  • [*][*][*][*][*]
  • Developer
TAK 1.0.3
Reply #6
I've just released shntool 3.0.6, which adds support for TAK encoding.

Great news!

Thank you.

  Thomas

  • viktor
  • [*][*][*][*]
TAK 1.0.3
Reply #7
nice, but how can one add support for tak on linux/*nix?

  • TBeck
  • [*][*][*][*][*]
  • Developer
TAK 1.0.3
Reply #8
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.
  • Last Edit: 18 January, 2008, 01:36:44 AM by TBeck

  • TBeck
  • [*][*][*][*][*]
  • Developer
TAK 1.0.3
Reply #9
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!