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

[CoRoNe]

Therefore i am very interested into compression results and comparisons with other codecs.

I have done some testing:

CODE

Chris Rea_test (Driving Home For Christmas sample)
WAV (16bit 44.1KHz, 11.733s)                                             1411Kbps, 2021.23KB, 100%
FLAC 1.2.1          [-8]                                                  861Kbps, 1233.17KB, 61.01%
TTA 3.4.1           [-e]                                                  852Kbps, 1220.10KB, 60.36%
WavPack 4.60.1      [-hhx]                                                837Kbps, 1199.49KB, 59.34%
TAK 2.0.0           [-e -p4m]                                             812Kbps, 1163.19KB, 57.55%
TAK 2.1.0           [-e -p4m]                                             812Kbps, 1163.02KB, 57.54%
TAK 2.2.0           [-e -p4m]                                             812Kbps, 1163.10KB, 57.54%
Monkey's Audio 4.10 [-c3000]                                              819Kbps, 1172.99KB, 58.03%
Monkey's Audio 4.10 [-c4000]                                              804Kbps, 1151.77KB, 56.98%
Monkey's Audio 4.10 [-c5000]                                              796Kbps, 1140.78KB, 56.44%
OptimFROG 4.600ex   [--encode --mode bestnew --seek min --optimize best]  791Kbps, 1133.00KB, 56.05%
OptimFROG 4.910b    [--encode --mode bestnew --seek min --optimize best]  790Kbps, 1131.81KB, 56.00%
OptimFROG 4.600ex   [--maximumcompression --experimental] (decode error!) 788Kbps, 1129.07KB, 55.86%
OptimFROG 4.910b    [--maximumcompression --experimental] (±55% cpu lol!) 787Kbps, 1127.71KB, 55.79%
LA 0.4b             [-high]                                               790Kbps, 1130.99KB, 55.96%

Gladiator Soundtrack
WAV (16bit 44.1KHz, 1h:01m:38.293s)     1411Kbps, 637088.86KB (622.16MB), 100%
FLAC 1.2.1          [--best]             706Kbps, 318757.12KB (311.29MB), 50.03%
WavPack 4.60.1      [-hhx]               702Kbps, 317369.66KB (309.93MB), 49.82%
TAK 2.1.0           [-e -p4m]            684Kbps, 308839.48KB (301.60MB), 48.48%
TAK 2.2.0           [-e -p4m]            684Kbps, 308865.17KB (301.63MB), 48.48%
Monkey's Audio 4.10 [-c3000]             687Kbps, 310348.86KB (303.08MB), 48.71%
Monkey's Audio 4.10 [-c4000]             680Kbps, 307066.54KB (299.87MB), 48.20%
Monkey's Audio 4.10 [-c5000]             676Kbps, 305098.90KB (297.95MB), 47.89%

Angra - Temple of Shadows
WAV (16bit 44.1KHz, 1h:06m:34.533s)     1411Kbps, 688120.82KB (671.99MB), 100%
FLAC 1.2.1          [--best]             986Kbps, 480797.87KB (469.53MB), 69.87%
WavPack 4.60.1      [-hhx]               971Kbps, 473486.58KB (462.39MB), 68.81%
TAK 2.1.0           [-e -p4m]            957Kbps, 466692.68KB (455.75MB), 67.82%
TAK 2.2.0           [-e -p4m]            957Kbps, 466720.24KB (455.78MB), 67.83%
Monkey's Audio 4.10 [-c3000]             960Kbps, 468348.68KB (457.37MB), 68.06%
Monkey's Audio 4.10 [-c4000]             952Kbps, 464030.97KB (453.16MB), 67.43%
Monkey's Audio 4.10 [-c5000]             948Kbps, 462497.08KB (451.66MB), 67.21%
LA 0.4b             [-high]              939Kbps, 457720.45KB (446.99MB), 66.52%

Royal Hunt - Paper Blood
WAV (16bit 44.1KHz, 56m:51.027s)        1411Kbps, 587602.68KB (573.83MB), 100%
FLAC 1.2.1          [--best]            1097Kbps, 456942.46KB (446.23MB), 77.76%
WavPack 4.60.1      [-hhx]              1089Kbps, 453645.32KB (443.01MB), 77.20%
TAK 2.1.0           [-e -p4m]           1082Kbps, 450697.51KB (440.13MB), 76.70%
TAK 2.2.0           [-e -p4m]           1083Kbps, 450738.92KB (440.17MB), 76.71%
Monkey's Audio 4.10 [-c3000]            1081Kbps, 449852.87KB (439.31MB), 76.56%
Monkey's Audio 4.10 [-c4000]            1078Kbps, 448739.60KB (438.22MB), 76.37%
Monkey's Audio 4.10 [-c5000]            1075Kbps, 447681.16KB (437.19MB), 76.19%

...what may on average result in about 0.01 percent worse compression.

I come to the same conclusion, although I would've loved seeing some more compression strength. The codec is already fast enough imho.
One funny detail about about my results; TAK -e -p4m beats Monkey's Audio 'High' in all cases except the last one (1082 vs 1081Kbps). Although my lossless collection is still rather small, Paper Blood appeared to be the hardest to compress.

The inclusion of the cuesheet should already work, although not with the '*' placeholder:

CODE

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

Takc.exe -e -p4m -tt "Cuesheet=@filename.cue" <infile> <outfile.tak> doesn't work. Neither when I include the full directory path.
"Command line error: Error reading tag file" is what I get.

[TBeck]

I have done some testing:

Thank you!

...what may on average result in about 0.01 percent worse compression.

I come to the same conclusion, although I would've loved seeing some more compression strength. The codec is already fast enough imho.

I don't think i can significantly improve the compression without making decoding slower.

One funny detail about about my results; TAK -e -p4m beats Monkey's Audio 'High' in all cases except the last one (1082 vs 1081Kbps). Although my lossless collection is still rather small, Paper Blood appeared to be the hardest to compress.

As a rule of thumb: The harder files are to compress, the worse TAK will perform compared to MAC. When it comes to highly compressible files, usually dynamically rich and tonal, TAK can do even better than MAC Extra, as can be seen in the FLAC comparison.

The inclusion of the cuesheet should already work, although not with the '*' placeholder:

Takc.exe -e -p4m -tt "Cuesheet=@filename.cue" <infile> <outfile.tak> doesn't work. Neither when I include the full directory path.
"Command line error: Error reading tag file" is what I get.

Strange. Where is the cue file located? In the source directory?

[CoRoNe]

Strange. Where is the cue file located? In the source directory?

Yes, in the source directory. But I think I figured it out. Initially I used the following command line:

CODE

wvunpack <infile.wv> - | Takc -e -p4m -tt "Cuesheet=@infile.cue" - <outfile.tak>

Which results in the error I mentioned before.
When I first decode the wv-file and use the wav-file as source it does seem to work. So it appears the TAK encoder can't load the cue-file properly when being used in a pipe.
When I then insert the tak-file in Foobar however, it doesn't load the cuesheet at all. After examining the tak-file in MP3tag there appear to be two cuesheet-entries. A cuesheet-entry with the correct content, but also a blank one (with no content). Manually deleting the blank cuesheet-entry in MP3tag does the trick, but still there appears to be something going wrong in the process.

I don't think i can significantly improve the compression without making decoding slower.

As long as it doesn't become as slow as Monkey's Audio 'Insane' I really don't mind some degeneration. I think a lot more people wouldn't mind either. Someone should hold a poll some time.

This post has been edited by CoRoNe: Jul 13 2011, 17:46

[TBeck]

Thank you for the info! I will look into it for the next release. Probably very few (if any) users have tried TAK's tagging functionality, what might explain why this bug has not been reported earlier.

This post has been edited by TBeck: Jul 13 2011, 17:41