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
Jun 8 2011, 18:32
Joined: 4-June 02
Member No.: 2220
The -p4m results:
6ch 48KHz 16bit TAK 2.2.0alpha -p2m TAK 2.2.0alpha -p4m MP4alsRM23 -7 -o160 -t6
WAV filesize ratio enc dec ratio enc dec ratio enc dec
----- --------- ------ ------ ------ ------ ------ ------ ------ ------ ------
D1-02 106.15 MB 44.00% 4.184x 76.83x 43.85% 3.079x 62.78x 43.12% 0.206x 7.12x
D1-03 228.73 MB 40.38% 4.231x 74.86x 40.18% 3.121x 60.16x 39.58% 0.209x 7.55x
D1-05 407.76 MB 32.70% 4.357x 84.39x 32.49% 3.312x 61.38x 32.40% 0.220x 8.41x
D1-08 506.63 MB 41.07% 4.087x 75.10x 40.94% 3.018x 68.00x 40.66% 0.211x 9.07x
D1-10 140.89 MB 44.11% 4.134x 79.31x 43.91% 3.159x 62.90% 43.30% 0.209x 7.09x
Note: I initially noticed for the file D1-02 the ratio of -p2m was better than -p4m and found it was a error in calculation or a typo, so it's fixed. I double-checked the other files' ratios for -p2m and there were no further errors/typos.
Speaking of 'no errors,' all my tests with -p0, -p1, p2m and -p4m were decompressed and bit-compared, still no errors found
This post has been edited by Destroid: Jun 8 2011, 18:35
"Something bothering you, Mister Spock?"
|Lo-Fi Version||Time is now: 23rd July 2014 - 01:35|