TAK 2.2.0 - Alpha release Options

[TBeck]

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:

Download link removed. TAK 2.2.0 Final has been released.

What's new

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

New features:

- 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.

Improvements:

- 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.

Known issues:

- 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.

Alpha testing

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.

Some remarks:

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.

Some figures:

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

Thomas

This post has been edited by TBeck: Jul 10 2011, 23:53

[lvqcl]

Anyone give me hint at fixing this (possibly) WAV header issue?

1) Convert DTS to W64.
2) Convert W64 to WAV, encode to TAK with (the above-mentioned) -ihs switch.
3) Compare W64 and TAK.

Added: according to takc help, -ihs works only in pipe mode...
takc.exe -e -ihs -p2 - out.tak < in.wav


This post has been edited by lvqcl: Jun 7 2011, 13:23

[TBeck]

takc.exe -e -ihs -p2 - out.tak < in.wav

Good idea! Currently i have no time to look at the source to check if this works for files larger than 4 GB. TAK's stream functions definitely support more than 4 GB, but i am not sure, if i have somewhere coded some restriction. Anyway, you will not be able to decode such a file while TAK only supports the standard wave format as output format...

[lvqcl]

Good idea! Currently i have no time to look at the source to check if this works for files larger than 4 GB. TAK's stream functions definitely support more than 4 GB, but i am not sure, if i have somewhere coded some restriction. Anyway, you will not be able to decode such a file while TAK only supports the standard wave format as output format...

What can I say...

a) 12.7GB .W64 file was converted to 12.7GB .WAV
b) This .WAV file was converted to 5.56 GB .TAK file (takc.exe -e -ihs -p2 - out.tak < in.wav).
c) Then .TAK file was decoded back to .W64 with foobar2000.

Resulting .w64 file is identical to the source.

[TBeck]

What can I say...

a) 12.7GB .W64 file was converted to 12.7GB .WAV
b) This .WAV file was converted to 5.56 GB .TAK file (takc.exe -e -ihs -p2 - out.tak < in.wav).
c) Then .TAK file was decoded back to .W64 with foobar2000.

Resulting .w64 file is identical to the source.

Thank you! I am surprised. Really nice.

[Destroid]

What can I say...

a) 12.7GB .W64 file was converted to 12.7GB .WAV
b) This .WAV file was converted to 5.56 GB .TAK file (takc.exe -e -ihs -p2 - out.tak < in.wav).
c) Then .TAK file was decoded back to .W64 with foobar2000.

Resulting .w64 file is identical to the source.

Thank you! I am surprised. Really nice.

I somehow overlooked lvqcl using pipe input off redirect instead of using FB2K. Now I should start saving up for glasses, apologies.

I also wanted to inquire: would there be interest for other testing 24-bit DTS->WAV files? I can see one point of interest (to measure TAK's ability on that bit-depth) as well as a point of non-interest (persons don't much convert DTS->WAV anyway, much less at 24-bit since there nearly zero audible advantages). At any rate, the DTS decoder gave me the option of 16 or 24 bits. I suppose it's more interesting to test on 24/48 or even 24/96 multichannel material but I have no such material.

[TBeck]

I also wanted to inquire: would there be interest for other testing 24-bit DTS->WAV files? I can see one point of interest (to measure TAK's ability on that bit-depth) as well as a point of non-interest (persons don't much convert DTS->WAV anyway, much less at 24-bit since there nearly zero audible advantages). At any rate, the DTS decoder gave me the option of 16 or 24 bits. I suppose it's more interesting to test on 24/48 or even 24/96 multichannel material but I have no such material.

I agree. Testing of true 24-bit material would be nice, but testing of an 24-bit version of your DTS files would not really be informative. The results may be similar to the 16-bit results. If not, the difference may be attributed to the output stage of the decoder, whose properties are of little interest for us.

Maybe you could test your files with FLAC and WavPack to obtain a more complete picture?

Well, somehow this release is a bit problematic because it adds a feature only few users will be using and this means even less testers. I am not sure, if i will immediately release a final version or insert a beta release. The latter may be tried by more users who possibly don't want to touch alpha releases. In fact this only means a different label, because only the wave reader has been slightly modified.