TAK 2.2.0 - Alpha release |
TAK 2.2.0 - Alpha release |
Jun 6 2011, 15:03
Post
#1
|
|
|
TAK Developer Group: Developer Posts: 1073 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: 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 |
|
|
|
![]() |
Jul 11 2011, 20:28
Post
#2
|
|
![]() Group: Members Posts: 128 Joined: 31-May 05 From: Netherlands Member No.: 22417 |
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. -------------------- DC-Bass Source Mod: http://reino.degeelebosch.nl
|
|
|
|
Jul 13 2011, 02:50
Post
#3
|
|
|
TAK Developer Group: Developer Posts: 1073 Joined: 1-April 06 Member No.: 29051 |
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? |
|
|
|
TBeck TAK 2.2.0 - Alpha release Jun 6 2011, 15:03
_m²_ I get "Wave file not supported" on all f... Jun 6 2011, 17:17
TBeck QUOTE (_m²_ @ Jun 6 2011, 18:17) I get ... Jun 6 2011, 17:31
lvqcl QUOTE Hm, works for me.
Works here too. Jun 6 2011, 17:52
TBeck Although there is no hint, i just looked at my wav... Jun 6 2011, 17:54
_m²_ The file was created with sox. I just tried Tak in... Jun 6 2011, 18:06
TBeck QUOTE (_m²_ @ Jun 6 2011, 19:06) The file... Jun 6 2011, 18:14
lvqcl QUOTE The file was created with sox.
What version?... Jun 6 2011, 18:09
TBeck QUOTE (_m²_ @ Jun 6 2011, 19:06) I can on... Jun 6 2011, 18:28
lvqcl I decoded d2.flac to 2 wav files with SoX 14.3.1 a... Jun 6 2011, 18:40
TBeck QUOTE (lvqcl @ Jun 6 2011, 19:40) I decod... Jun 6 2011, 18:57
lvqcl -- Jun 6 2011, 19:09
TBeck QUOTE (TBeck @ Jun 6 2011, 19:57) QUOTE (... Jun 6 2011, 19:10
_m²_ Sorry, my bad, seems to be a flake bug, the flac d... Jun 6 2011, 19:13
TBeck QUOTE (_m²_ @ Jun 6 2011, 20:13) Sorry, m... Jun 6 2011, 19:34
lvqcl From SoX changelog:
"Fix bug where FACT chu... Jun 6 2011, 19:51
TBeck QUOTE (lvqcl @ Jun 6 2011, 20:51) From So... Jun 6 2011, 20:00
[JAZ] Indeed, that last check shouldn't be made.
Mi... Jun 6 2011, 20:05
TBeck QUOTE ([JAZ] @ Jun 6 2011, 21:05)... Jun 6 2011, 20:14
lvqcl QUOTE Read up to chunk size, and if you are not at... Jun 6 2011, 20:11
TBeck QUOTE (lvqcl @ Jun 6 2011, 21:11) QUOTE R... Jun 6 2011, 20:16
Destroid I managed to finish a preview of a TAK benchmark d... Jun 7 2011, 00:18
lvqcl QUOTE Anyone give me hint at fixing this (possibly... Jun 7 2011, 01:27
TBeck QUOTE (lvqcl @ Jun 7 2011, 02:27) takc.ex... Jun 7 2011, 03:13
lvqcl QUOTE (TBeck @ Jun 7 2011, 06:13) Good id... Jun 7 2011, 13:02
TBeck QUOTE (lvqcl @ Jun 7 2011, 14:02) What ca... Jun 7 2011, 14:54
Destroid QUOTE (TBeck @ Jun 7 2011, 13:54) QUOTE (... Jun 14 2011, 03:12
TBeck QUOTE (Destroid @ Jun 14 2011, 04:12) I a... Jun 14 2011, 17:08
bryant QUOTE (TBeck @ Jun 14 2011, 09:08) Maybe ... Jun 14 2011, 21:07
Destroid QUOTE (bryant @ Jun 14 2011, 20:07) QUOTE... Jun 16 2011, 10:48
TBeck QUOTE (Destroid @ Jun 7 2011, 01:18) I ma... Jun 7 2011, 02:57
Destroid QUOTE (TBeck @ Jun 7 2011, 01:57) Well, a... Jun 7 2011, 07:40
Destroid Didn't have doubt about data integrity of TAK,... Jun 7 2011, 18:47
Destroid And here's some test results
Not sure exactly... Jun 8 2011, 03:18
TBeck QUOTE (Destroid @ Jun 7 2011, 19:47) Didn... Jun 8 2011, 17:07
Destroid The -p4m results:
CODE6ch 48KHz 16bit TAK 2.2.0... Jun 8 2011, 18:32
TBeck QUOTE (Destroid @ Jun 8 2011, 19:32) The ... Jun 8 2011, 18:48
Destroid QUOTE (TBeck @ Jun 8 2011, 17:48) Ok, nev... Jun 8 2011, 20:04
RastaMan Tested TAK 2.2.0 Alpha on an HDCD album "Sara... Jun 16 2011, 09:56
bryant QUOTE (RastaMan @ Jun 16 2011, 01:56) Ran... Jun 17 2011, 07:17
TBeck QUOTE (bryant @ Jun 14 2011, 22:07) Maybe... Jun 16 2011, 23:18
RastaMan The original tests were run using the highest comp... Jun 17 2011, 13:34
Ljubo44 Any chance to play tak format with windows media p... Jun 17 2011, 15:48
lvqcl Ljubo44: http://liviocavallo.altervista.org/ Jun 17 2011, 15:51
Ljubo44 Tired before, installed from C:/Temp from bat as a... Jun 18 2011, 02:13
TBeck I want to prepare a final release.
Therefore, if ... Jun 30 2011, 21:11
Destroid QUOTE (TBeck @ Jun 30 2011, 20:11) Theref... Jul 3 2011, 00:05
Manlord I dont have any multichannel file, but if any test... Jun 30 2011, 21:34
CoRoNe *bump*
QUOTE (http://www.hydrogenaudio.org/forums/... Jul 2 2011, 21:42
TBeck QUOTE (Manlord @ Jun 30 2011, 22:34) I do... Jul 5 2011, 20:57
TBeck TAK 2.2.0 Final
has been released. Jul 10 2011, 23:55
Steve Forte Rio surprisingly!
Very good news!
Thank you... Jul 11 2011, 11:32
CoRoNe QUOTE (TBeck @ Jul 13 2011, 03:50) Strang... Jul 13 2011, 17:28
TBeck Thank you for the info! I will look into it fo... Jul 13 2011, 17:40
_m²_ Updated my test with TTA, WavPack, TAK.
Generally,... Jul 12 2011, 10:21
TBeck QUOTE (_m²_ @ Jul 12 2011, 11:21) Updated... Jul 13 2011, 02:37
_m²_ QUOTE (TBeck @ Jul 13 2011, 03:37) QUOTE ... Jul 13 2011, 08:21![]() ![]() |
|
Lo-Fi Version | Time is now: 19th June 2013 - 15:39 |