TAK 2.2.0 - Alpha release
TAK 2.2.0 - Alpha release
Jun 6 2011, 15:03
Joined: 1-April 06
Member No.: 29051
Alpha release 1 of TAK 2.2.0 ((T)om's lossless (A)udio (K)ompressor)
It consists of:
- TAK Applications 2.2.0 Alpha 1 b in "\Applications".
- TAK Winamp plugin 2.2.0 Alpha 1 in "\WinAmp".
- TAK Decoding library 2.2.0 Alpha 1 in "\Deco_Lib".
The final release will additionally contain the SDK.
Download link removed. TAK 2.2.0 Final has been released.
This release brings support for multi-channel audio and speed optimizations for encoder and decoder.
- Support for multi-channel audio. While the stream format supports up to 16 channels, the codec currently is restricted to a maximum of 6 channels.
- Support for the "Wave Format Extensible" file format.
- Encoding speed improvements of up to 10 percent for my primary file set. Most of it is achieved by a modification of the algorithm which selects the optimal predictor order for each subframe. It will now often use less predictors than before, what may on average result in about 0.01 percent worse compression. You will only notice an speed advantage, if your files benefit from high predictor orders.
- Decoding speed improvements of up to 18 percent for my primary file set. Some of it is attributed to the above-noted modification of the encoder's predictor order selection algorithm. Therefore it will only take effect when decoding files encoded with this version and only, if they benefit from high predictor orders. Additionally SSSE3-instructions can be used for predictor counts of 32 and more. This affects the presets p3, p4 and sometimes p2, but only, if a particular file benefits from high predictor orders.
- 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.
This alpha release has already gone through extensive testing performed by my automatic scripts. Nevertheless there may be bugs left. Especially because i had to write a lot of new code for the support of multi-channel audio. This also involved a lot of minor modifications of the existing code. Therefore i would like you to verify the proper function of the codec: Compress -> Decompress -> Compare resulting wave with the original file, either by a binary compare or by the use MD5-check sums.
Certainly i am very interested into efficiency comparisons of the new multi-channel audio codec and other compressors.
The most time consuming part of the new codec is it's channel decorrelation mechanism. The strongest presets sometimes check any possible channel combination. Principially you have n * (n - 1) (n = channel count) possible combinations, if you count "A predicts B" and "B predicts A" as two combinations.
2 channels -> 2 combinations
4 channels -> 12 combinations
5 channels -> 20 combinations
6 channels -> 30 combinations
8 channels -> 56 combinations
This rapid increase is the reason, why the codec currently is restricted to a maximum of 6 channels. I have to find and evaluate more heuristics for a fast estimation of optimal pairings which doesn't require a full evaluation of all possibilities.
Some are alreaday working. Most of them rely on the presence of a speaker assignment mask in the source wave file. If present, some faster presets will only test those combinations, which were most useful in my evaluations. A low frequency channel will never be evaluated.
But this only works, if the speaker assignment is known. Therefore the encoding time of the same audio data may differ considerably dependent on the presence of a speaker mask in the original wave file.
Im my evaluations the new codec often did beat Mpeg4Als -7 compressionwise, if a particular file provided good opportunities for channel decorrelation. Unfortunately for some files there are zero opportunities. My test corpus is still too small to make any generalized statement regarding the new codecs efficiency.
Therefore i am very interested into compression results and comparisons with other codecs.
Thanks for testing and have fun
This post has been edited by TBeck: Jul 10 2011, 23:53
Jul 5 2011, 20:57
Joined: 1-April 06
Member No.: 29051
I dont have any multichannel file, but if any test with standard files is needed I will be happy to help.
Since i have performed a lot of code optimizations which affect standard files as well, i would be happy if you tested the final release.
On the Hydrogenaudio KB I can see cue sheets and cover art are already on your to-do list, but how much of a priority are they?
Currently I'm using WavPack (-hhx -w "Cuesheet=@*.cue" --write-binary-tag "Cover Art (Front)=@*.png"). I've already been experimenting a little with TAK and of course I can add cue sheets and cover art afterwards with Mp3tag because of the APEtag, but once TAK supports it natively I'm really thinking of switching over.
Keep up the good work!
The inclusion of the cuesheet should already work, although not with the '*' placeholder:
-tt # Add textual tag item #, where # is a key/value pair: "key=value",
for instance "TITLE=A nice song". "key=@file" will read the value
from the text(!) file "file" in the source directory.
The support for binary items like pictures is now on my todo list for V2.2.1. If nothing intervenes.
No problems here, all the TAK files decoded with no differences.
Obviously I didn't get my last comparison done, there was desktop computer disaster (an electricity outage in my area made my harddrives disappear from the BIOS, turned out half the power regulating capacitors on the mainboard blew). I'll slate that comparison after final release of 2.2.0.
|Lo-Fi Version||Time is now: 6th October 2015 - 06:14|