TAK 2.2.0 Options

[TBeck]

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

This release brings support for multi-channel audio and speed optimizations for encoder and decoder.

It consists of:

• TAK Applications 2.2.0.
• TAK Winamp plugin 2.2.0.
• TAK SDK 1.1.1.
• TAK Decoding library 2.2.0.

Download

 TAK_2.2.0.zip ( 919.37K ) Number of downloads: 36485

[TBeck]

Got the samples. Took some time...I didn't take into account als slowness.

Thank you! The analysis will take some time and i can not guarantee, that i will find an (compatible) optimization.

Finally i tried it. I manually selected some of TAK's filters (statically) for each (whole) file and got at least about 0.40 percent better compression for your sample files. A bit more of improvement might be possible, if the filters would be conditionally selected per frame.

Currently i regard those files as special cases, although i have to take into account, that i dont know nearly as much about the compression relevant properties (and their frequency) of-multi channel audio as i possibly know about CD-audio. For now i have added the files to my special cases folder which affects future tunings. Thank you for the files!

Currently i have no idea how to tune the encoder for such files without loosing a lot of encoding speed. I could implement a brute force approach which simply would encode all files with the mentioned filters switched on or off and then would choose the best result. But that's not the way TAK achieves it's high encoding speed. If it would fully calculate all possible combinations of it's many filter variations, it could be easily 1000 times (or more!) slower. Sometimes i read, TAK's encoding is so fast because of it's assembler optimizations. No, that's misleading. It's speed-efficient design and the assembler optimizations may speed up encoding by a factor of about 2 to 3 (for -p4m), but the most important factor are it's heuristics, which base all the filter deceisions on relatively simple estimations. That's where most of the encoder development time has gone.

But sometimes those heuristics fail, as can be seen with m2's files.

A side note: Your (m2) files have wasted bits (low significant bits are zero), this may explain the really bad performance of TTA, which -to my knowledge- doesn't check for this case.

TBeck, do you plan to add a CUDA support for further versions of TAK encoder?
IMHO, such progressive codec as TAK must have a support of such useful feature as CUDA. Maybe it is even possible to increase the compression level this way, isn't it?

I don't want to loose decoding speed, because i still think about possible hardware implementations. Therefore i don't want to significantly increase the complexity of TAK's filters. Then only encoder optimizations are possible. With a lot more of processing power available i could possible replace some of TAK's fast heuristics with brute force approaches. This could for instance help special files like those m2 has sent me, but i doubt, it would significantly increase the average compression ratio for a large corpus of files. Anectdotally: i spend the last two days implementing a brute force approach for one case, where TAK versions earlier than 2.0 could achieve 0.05 percent better compression. This was the most significant advantage i ever found for the brute force way of a filter selection! But with the better design and heuristics of TAK 2.x, the advantage shrinked to about 0.01 percent.

I don't think, the investment of maybe 20 or even 50 times more processing power (which probably would require a quite potent GPU) would result in more than about 0.05 to 0.10 percent better compression on average. But it could help some special files.

And then there is also my personal fun factor: I really like to beat brute force approaches whith more or less clever algorithms... Well, indeed it's often less cleverness but a bit of intuition and a lot of trial and error and collecting and evaluating a lot of relevant data.

Conclusion: Too little to gain for me by CUDA yet, but may be, if i have some new ideas...

It's not that i don't think about opportunities for compression improvements. But it's getting really hard to find some within my efficiency/speed constraints.