Beta release 1 of TAK 1.0.2 ((T)om's lossless (A)udio (K)ompressor)
It consists of:
- TAK Applications 1.0.2
- TAK Winamp plugin 1.0.5.
- TAK SDK 1.0.4.
- TAK Decoding library 1.0.5.
Download:
Download links removed. TAK 1.0.2 Final (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=58783&view=findpost&p=527886) has been released.
1. TAK Applications 1.0.2
containing the GUI and command line compressor:
2. TAK Winamp plugin 1.0.5
containing the playback plugin for Winamp:
3. TAK SDK 1.0.4
containing the SDK documentation and the decoding library dll for developers:
4. TAK Decoding library 1.0.5
containing only the decoding library dll which is part of the SDK. It's provided for end users using third-party applications utilizing the library, who want to update the library to the current version:
After the beta test phase these archives will be removed.
What's new
What's new in the Applications
New preset configuration:
- Most of the presets have been modified to speed them up and to reduce the decoding requirements. Usually they are more than 50 percent faster while loosing only about 0.3 percent of compression efficiency.
- The fastest preset TURBO (-p0) is now using 8 instead of 16 predictors and compresses (on average) nevertheless better than FLAC -8 (with 12 predictors). The reduced cpu requirements should guarantee that this preset can be decoded on any hardware device capable to playback FLAC -8 (maybe even -5).
- Because of the insertion of the new TURBO preset we now have 6 instead of 5 presets: -p0 to -p5. The strongest setting is now -p5m and it's called INSANE.
- The maximum frame size (samples per channel) is now limited as follows: 4096 for TURBO and FAST, 8192 for NORMAL, HIGH and EXTRA, 16384 for INSANE. This way the specification of the memory requirements of the decoder is more accurate.
New Features:
- You can now manually set the frame size to 512, 1024 or 2048 samples to match the frame size of the LossyWav/LossyFlac preprocessor developed by the Hydrogenaudio.org-Members 2Bdecided, Nick C. and halb27. But caution: Frame sizes of 512, 1024 and 2048 are not backwards compatible and can not be decoded by TAK applications and libraries prior to V1.0.2!
Improvements:
- The strongest compression mode -p5m (aka -p4m in V1.0.1) is now encoding 62 percent faster on my system and is on average loosing only 0.01 percent compression!
- Tiny overall speed improvements.
- Better compression of some low passed files and files coming from lossy sources (especially low and medium constant bitrate). Up to more than 1 % for presets Turbo, Fast and Normal, up to 0.3 precent for High, Extra and Insane. This comes without any significant speed penality.
- Modification of the file read function of the decoder. It's now reading the file in smaller blocks. This will hopefully increase the decoding speed of high resolution audio, which seems to be suffering from the io system of V1.0.1.
Fixed:
- The file info function was rounding the file duration to the nearest second. Now it's correctly displaying the fraction with 2 decimal places. (30.53 instead of 36.00 seconds).
- When compressing 96 Khz audio with preset HIGH, preset EXTRA has been stored into the encoder meta data. This had no effect on the decoding or data integrity, but the file info function and media players will display the wrong preset.
What's new in the encoder/decoder library (affecting the applications, the decoding library and the Winamp plugin):
New features:
- Support for frame sizes of 512, 1024 and 2048 samples which have been introduced with TAK V1.0.2.
- Support for the additional preset INSANE introduced with TAK V1.0.2.
Improvements:
- The memory requirements have been reduced. Depending on the preset the encoder is now using 2 to 3 times, the encoder 1.5 to 2.5 times less memory. This may slightly improve the speed on some cpus. But i did it primarily to prepare later hardware implementations.
- Considerable parts of the source code have been partially rewritten or simplified. It's in no way important for the current users (well, like any modification it might even introduce bugs...), but it's part of the preparation of a later source code release. It's only one more step into this direction, there is still much more to do. As always, i can't tell you a release date.
Bug fixes:
- The decoder is expected to process any (damaged) data without any problems. But i have found and corrected two cases, where the decoder could crash. The chance for this was less than 1 : 1000 (for damaged files only!).
- In one place i used an invalid flag combination in a call of Windows' VirtualFree().
What's new in the SDK (compared to 1.0.3):
Interface changes (Adaptions for TAK 1.0.2):
- Added constants for the new frame sizes (Ttak_str_FrameSizeTypes): tak_FrameSizeType_512 to tak_FrameSizeType_12288.
- Added constant for the new preset INSANE (TtakPresets): tak_Preset_Insane.
Interface Compatibility:
- The decoder functions tak_SSD_GetStreamInfo and tak_SSD_GetEncoderInfo may now return the new values for the frame size (Ttak_str_FrameSizeTypes) and the encoder preset/profile (TtakPresets) which have been introduced with TAK 1.0.2 (see "Interface changes").
Beta testing
The beta version has already gone through extensive testing performed by my automatic scripts. But especially because of the many changes for 1.0.2 rare bugs are still possible (as always...). Please try the beta release and report any bugs in this thread.
I would also be happy about tests of compression efficiency and speed. Because the final release will have identical performance (there may be a speed variation of 1 to 3 percent because of different code alignment of another build), it does make sense to test the beta.
Thanks for testing and have fun
Thomas
what archives?
Good news.
When is it planed top get optimizated for speed foobar decoder plugin? Actual TAK plugin for foobar is approx. 30% slower than command line decoder.
Is pipe-encoding support planned for the final version, Tom?
In any case, thank you for your work! TAK is already hands down my lossless format of choice
I would also be happy about tests of compression efficiency and speed. Because the final release will have identical performance (there may be a speed variation of 1 to 3 percent because of different code alignment of another build), it does make sense to test the beta.
I'll get my standard tests done in the next day or so Thomas. Nice to see the codec continuing to improve.
Is pipe-encoding support planned for the final version, Tom?
It's in the pipeline. If you check docs it's on the to-do list.
I just have downloaded the new beta, and done some very quick testing. I normally use the normal max settings and they seem to be a bit worse compression-wise than before; the difference seems to be 0 to 0.5 percent (0 percent for Porcupine Tree and 0.5 percent for Björk - I have yet to try other things) - not too significant though I'd like to set the old normal max settings manually. It's possible, I presume
The decoding library became a bit faster, its speed has increased to 321-fold in one particular case (an 'old' normal max encoded Porcupine Tree track just to be specific ) measured in foobar2k - it was 307-fold before (4.5% increasy, pretty good ). It's good to see every bit of increase in decoding speed, especially if we hope for future hardware support.
Reading the preview of the new encoding parameter set I thought that I'll use high max from now on - it won't be the case. High max preserved its knack for compressing a little bit worse than Normal max in some cases, while it's slower to (encode and) decode. The new settings are not the end of the world, I just liked the old NM better
Now I'm leaning towards using the 1.0.1 encoder (or the new one with manually enforced 'old' normal max) and the new decoder lib - encoding speed doesn't really matter for me, I mostly encode my music once and my system is plenty fast to handle the encoding of those occassional few new albums (I don't have a rapidly growing multi-terabyte music collection, months can pass without anything new ).
But, all in all, TAK still rocks, I always liked its characteristics (I've been watching its birth since last year's 1st of April) - FLAC speed with better compression, and this is still the same
what archives?
I was a bit slower than you...
Good news.
When is it planed top get optimizated for speed foobar decoder plugin? Actual TAK plugin for foobar is approx. 30% slower than command line decoder.
The foobar plugin is using my decoding library which contains exactly the same code as my applications. I suppose that the foobar plugin or foobar itself is responsible for the lower speed. There is nothing i can do...
Is pipe-encoding support planned for the final version, Tom?
Not this time. Sorry... But it's on my todo list.
In any case, thank you for your work! TAK is already hands down my lossless format of choice
I would also be happy about tests of compression efficiency and speed. Because the final release will have identical performance (there may be a speed variation of 1 to 3 percent because of different code alignment of another build), it does make sense to test the beta.
I'll get my standard tests done in the next day or so Thomas. Nice to see the codec continuing to improve.
Great! BTW: I forgot to mention: There is no difference between -p4/-p4e and -p5/-p5e. There were no encoder options left to create an extra evaluation level...
I just have downloaded the new beta, and done some very quick testing. I normally use the normal max settings and they seem to be a bit worse compression-wise than before; the difference seems to be 0 to 0.5 percent (0 percent for Porcupine Tree and 0.5 percent for Björk - I have yet to try other things) - not too significant though I'd like to set the old normal max settings manually. It's possible, I presume
O yes, it is... At least if you are working with the command line version. Please try this: "-p3m,pf0". It will disable the PreFilter which is responsible for the slight decoding speed penality. I will also make this option accessible in the GUI version.
But, all in all, TAK still rocks, I always liked its characteristics (I've been watching its birth since last year's 1st of April) - FLAC speed with better compression, and this is still the same
Thank you! That's very motivating.
Thomas
Here are some results from a 2.6GHz Pentium 4 using 46 files (more or less) representative of my cd collection:
1.0.2 Beta 1 size (bytes) percent encoding speed decoding speed
-p0 1623010174 54,14 123,15 143,82
-p0e 1615739367 53,9 90,77 142,61
-p0m 1612224463 53,78 49,39 143,48
-p1 1606970522 53,6 105,84 128,02
-p1e 1604905867 53,54 84,38 126,64
-p1m 1601617850 53,43 43,95 128,65
-p2 1581734990 52,76 78,44 118,64
-p2e 1578204991 52,64 59,8 118,56
-p2m 1575307844 52,55 32,7 117,73
-p3 1571489425 52,42 46,6 110,66
-p3e 1569148414 52,34 35,55 111,28
-p3m 1567753199 52,3 23,72 110,63
-p4 1561633116 (!) 52,09 29,64 101,24
-p4e 1561633116 (!) 52,09 29,62 100,34
-p4m 1560386681 52,05 16,37 94,28
-p5 1558565633 (!) 51,99 21,82 93,94
-p5e 1558565633 (!) 51,99 21,85 94,16
-p5m 1557170401 51,94 10,43 95
as comparison: 1.0.1
-p0 1612577422 53,79 114,09 129,76
-p0e 1604816093 53,53 85,04 130,2
-p0m 1601334557 53,42 40,34 129,3
-p1 1582760941 52,8 82,75 122,65
-p1e 1578210266 52,65 59,44 121,17
-p1m 1575082039 52,54 30,13 121,68
-p2 1572754511 52,46 51,74 118,28
-p2e 1571904174 52,43 33,34 118,88
-p2m 1569993171 52,37 25,26 119,68
-p3 1562677922 52,13 31,69 98,83
-p3e 1561954330 52,1 19,04 97,81
-p3m 1560108995 52,04 15,44 98,73
-p4 1558386544 51,98 20,21 91,72
-p4e 1557468738 51,95 10,61 94,47
-p4m 1556940882 51,94 7,7 92,94
-p4e and -p5e produce identical files to -p4 and -p5, did you remove the extra evaluation level for those presets?
-p4e and -p5e produce identical files to -p4 and -p5, did you remove the extra evaluation level for those presets?
BTW: I forgot to mention: There is no difference between -p4/-p4e and -p5/-p5e. There were no encoder options left to create an extra evaluation level...
Ah, I missed that (I did look whether it was mentioned anywhere).
Good work Tom.
When it gets tag support and pipe-encoding, I will switch to it !
These are the only features that held me back for a complete switch.
Mind if I ask what pipe-encoding is?
It encodes the file that is inputed on the fly as opposed to converting it to wav than converting it to the format.
I like the new encoding speed. Can't wait for Tak 1.02 final.
Excellent!
Has anyone gotten TAK to work successfully with dbpoweramp? I've been trying to set up a CLI encoder, but keep hitting a dead end.
My interpretation of gaekwad2's results
version preset size (bytes) percent enc.speed dec.speed
1.0.2 -p0 1623010174 54,14 123,15 143,82
1.0.1 -p0f N/A N/A N/A N/A
-
1.0.2 -p1 1606970522 53,60 105,84 128,02
1.0.1 -p0 1612577422 53,79 114,09 129,76
diff 0,19 8,25
-
1.0.2 -p2 1581734990 52,76 78,44 118,64
1.0.1 -p1 1582760941 52,80 82,75 122,65
diff 0,04 4,31
-
1.0.2 -p3 1571489425 52,42 46,60 110,66
1.0.1 -p2 1572754511 52,46 51,74 118,28
diff 0,04 5,14
-
1.0.2 -p4 1561633116 52,09 29,64 101,24
1.0.1 -p3 1562677922 52,13 31,69 98,83
diff 0,04 2,04
-
1.0.2 -p5 1558565633 51,99 21,82 93,94
1.0.1 -p4 1558386544 51,98 20,21 91,72
diff -0,01 -1,61
-
My interpretation of gaekwad2's results
...
You've got it!
The 1.0.1 presets have been moved up by one position to insert the new Turbo preset and to have a faster Normal preset. Some presets are now encoding a bit slower because i have added one or two more encoder options to the standard evaluation level.
Code improvements mostly affect the Maximum and to some degree the Extra evaluation level. From the change log:
- The strongest compression mode -p5m (aka -p4m in V1.0.1) is now encoding 62 percent faster on my system and is on average loosing only 0.01 percent compression!
gaekwad2's results show a speedup of 35 % for -p5m (aka -p4m in V1.0.1). I am confident, that other cpu's (P3, Core Duo) will show a bigger advantage. The P4 never really liked my optimizations...
Thomas
.......
- The strongest compression mode -p5m (aka -p4m in V1.0.1) is now encoding 62 percent faster on my system and is on average loosing only 0.01 percent compression!
.......
Thomas
The same happens with V1.0.1 p4e vs p4m in gaekad2's sample .... loosing 0.01 % compression while it encodes at 10.61x (1.0.1-p4e) vs 7.70x (1.0.1-p4m) ..... vs 10.43x(1.0.2-p5m)
may be the p5e mode is the missing target
Here are some results from a 2.6GHz Pentium 4 using 46 files (more or less) representative of my cd collection:
...
Thank you!
.......
- The strongest compression mode -p5m (aka -p4m in V1.0.1) is now encoding 62 percent faster on my system and is on average loosing only 0.01 percent compression!
.......
Thomas
The same happens with V1.0.1 p4e vs p4m in gaekad2's sample .... loosing 0.01 % compression while it encodes at 10.61x (1.0.1-p4e) vs 7.70x (1.0.1-p4m) ..... vs 10.43x(1.0.2-p5m)
may be the p5e mode is the missing target
Good work Tom.
When it gets tag support and pipe-encoding, I will switch to it !
These are the only features that held me back for a complete switch.
I think internal tagging will come with the next release, but probably (first) without unicode support.
Am i right, that piping support for encoding is most important? I mean: Read the audio data from a pipe and compress it to a file? I would like to implement this first.
Thomas
I think internal tagging will come with the next release, but probably (first) without unicode support.
Since non-unicode capable environments are hardly existing anymore, I'd suggest to take up time to support unicode in the first place. In my opinion unicode is an important feature when tagging music files especially if you already discovered the diversity beyond the mainstream. This is just a remark and not a request.
Am i right, that piping support for encoding is most important? I mean: Read the audio data from a pipe and compress it to a file? I would like to implement this first.
Yes! Please implement piping first! Right now, when encoding using foobar, we can't see how many minutes are remaining or anything which is terrible . Piping support would be awesome!
I'm currently transcoding my entire collection from -p4 to -p5m. I'll post data soon.
Thanks for your hard work!
+1 for piping support.
...and another vote for piping support!
I suspect that Unicode support will broaden the userbase more than piping support does so I doubt which one I prefer.
But I have no doubts about the third place: embedding md5 hash of audio part.
Edit: typo
+1 for piping support.
...and another for piping support at the command line which can at least provide stdout when used with foobar.
I'm currently transcoding my entire collection from -p4 to -p5m. I'll post data soon.
Yes, please do. I'm definitely interested in what results you get
+1 for piping
O yes, it is... At least if you are working with the command line version. Please try this: "-p3m,pf0". It will disable the PreFilter which is responsible for the slight decoding speed penality. I will also make this option accessible in the GUI version.
Thanks, it seems to be very close to the 'legacy' normal max, I'll experiment a bit with it when I'll have some time
piping++;
IMHO, piping support is one of the most important features at this moment.
Thomas,
1.0.2b added to my comparison (http://www.synthetic-soul.co.uk/comparison/lossless/). This list (http://www.synthetic-soul.co.uk/comparison/lossless/?all=1) contains 1.0.2 and 1.0.1 for comparison. You may find the 'download as CSV' functionality useful to get a clearer picture; here's my attempt:
Version Encoder Setting Comp Enc Dec
=====================================================
1.0.1b TAK Turbo 64.929% 104x 118x
1.0.2b TAK Turbo 65.281% 110x 129x
1.0.1b TAK Turbo Max 64.521% 41x 117x
1.0.2b TAK Turbo Max 64.888% 50x 127x
1.0.1b TAK Turbo Extra 64.633% 80x 116x
1.0.2b TAK Turbo Extra 65.003% 85x 127x
1.0.1b TAK Fast 64.145% 66x 112x
1.0.2b TAK Fast 64.732% 94x 122x
1.0.1b TAK Fast Max 63.869% 28x 111x
1.0.2b TAK Fast Max 64.531% 45x 122x
1.0.1b TAK Fast Extra 63.963% 50x 113x
1.0.2b TAK Fast Extra 64.638% 79x 121x
1.0.1b TAK Normal 63.875% 45x 109x
1.0.2b TAK Normal 64.093% 62x 113x
1.0.1b TAK Normal Max 63.795% 25x 110x
1.0.2b TAK Normal Max 63.875% 31x 113x
1.0.1b TAK Normal Extra 63.853% 31x 109x
1.0.2b TAK Normal Extra 63.963% 50x 113x
1.0.1b TAK High 63.684% 28x 96x
1.0.2b TAK High 63.868% 40x 108x
1.0.1b TAK High Max 63.607% 15x 96x
1.0.2b TAK High Max 63.760% 22x 108x
1.0.1b TAK High Extra 63.663% 18x 96x
1.0.2b TAK High Extra 63.801% 31x 109x
1.0.1b TAK Extra 63.585% 19x 87x
1.0.2b TAK Extra 63.657% 27x 101x
1.0.1b TAK Extra Extra 63.547% 10x 88x
1.0.2b TAK Extra Extra 63.657% 27x 101x
1.0.1b TAK Extra Max 63.527% 7x 87x
1.0.2b TAK Extra Max 63.616% 16x 102x
1.0.2b TAK Insane 63.587% 20x 91x
1.0.2b TAK Insane Extra 63.587% 20x 91x
1.0.2b TAK Insane Max 63.532% 10x 93x
New preset p0 with 8 predictors results very interesting for transcoding scenario.
It's faster for en/decoding and has higher compression than FLAC -5 ... -8
Is it possible to see even lower complexity turbo preset? This way it will have compression ratio like FLAC -8 and complexity of FLAC 0. The main goal will be very high decode speed for transcoding lossless to lossy.
Thomas,
1.0.2b added to my comparison (http://www.synthetic-soul.co.uk/comparison/lossless/). This list (http://www.synthetic-soul.co.uk/comparison/lossless/?all=1) contains 1.0.2 and 1.0.1 for comparison. You may find the 'download as CSV' functionality useful to get a clearer picture; here's my attempt:
...
Thank you very much! Nice results...
Some remarks:
1.0.1b TAK Turbo 64.929% 104x 118x
1.0.2b TAK Turbo 65.281% 110x 129x
I like this new very low complexity preset. The speed advantage over old TURBO isn't big but significant and the compression efficiency is still good.
1.0.1b TAK Normal 63.875% 45x 109x
1.0.2b TAK Normal 64.093% 62x 113x
You always told me, that you would like to see a faster NORMAL preset.... Normal is now using only 32 predictors which does make perfect sense, because 32 is the most bang-for-the-buck-condition (efficiency / complexity). I should have done this earlier, but there was some kind of a psychological barrier in my mind: Before the first publication of YALAC/TAK i have always focussed on strong compression and not on speed.
1.0.1b TAK Extra Max 63.527% 7x 87x
1.0.2b TAK Insane Max 63.532% 10x 93x
A nice encoding speed up for the guys who are always using TAK's strongest mode. It's surely worth the compression disadvantage of 0.005 percent. As you can see, i have also improved the decoding speed a bit.
To summarize: I really like the new preset configuration.
New preset p0 with 8 predictors results very interesting for transcoding scenario.
It's faster for en/decoding and has higher compression than FLAC -5 ... -8
Is it possible to see even lower complexity turbo preset? This way it will have compression ratio like FLAC -8 and complexity of FLAC 0. The main goal will be very high decode speed for transcoding lossless to lossy.
I could reduce the predictor count from 8 to 4. But this doesn't make much sense. First you will loose about 0.7 percent of compression. Second: The effect on the decoding speed will be hardly noticable. Going for 4 predictors would have only one real advantage: I could significantly increase the
encoding speed.
BTW: I am working on a new codec which -among other things- will decode a bit faster (currently about 6 percent for Turbo).
Thomas
I could reduce the predictor count from 8 to 4. But this doesn't make much sense. First you will loose about 0.7 percent of compression. Second: The effect on the decoding speed will be hardly noticable. Going for 4 predictors would have only one real advantage: I could significantly increase the encoding speed.
I don't know what others need but oftenly I need to compress wav files to FLAC -0. It permits instantly save a space just for really very short time.
0.7% isn't that much for this purpose. The difference per cd will be 2-4 mb. And compression ratio may be as good as FLAC -5.
I try to see TAK as alternative to my FLAC rips
Have you found any bugs?I would like to release TAK 1.0.2 Final. If you have found any bugs in the beta, please tell me now!
For the feature requestsHm, seems as if the winner is piping... Hopefully i will implement piping support for encoding in V1.0.3.
...
I don't know what others need but oftenly I need to compress wav files to FLAC -0. It permits instantly save a space just for really very short time.
0.7% isn't that much for this purpose. The difference per cd will be 2-4 mb. And compression ratio may be as good as FLAC -5.
I try to see TAK as alternative to my FLAC rips
Fine!
According to Synthetic Soul's comparison TAK Turbo is decoding only 9 percent slower than FLAC -0. And as i wrote earlier, the optimized TAK codec i am working on is allready decoding another 6 percent faster.
Thomas
According to Synthetic Soul's comparison TAK Turbo is decoding only 9 percent slower than FLAC -0. And as i wrote earlier, the optimized TAK codec i am working on is allready decoding another 6 percent faster.
Not to be a pain for nobody but it's 10%. Decoding times:
TAK turbo 01:32.614
FLAC -0 01:24.128
Have you found any bugs?
I would like to release TAK 1.0.2 Final. If you have found any bugs in the beta, please tell me now!
I'm not sure if it's specific to 1.0.2, but when I use the tak winamp plugin in the latest version of winamp (5.5), I have noticed one possible bug. If I have any tak file queued in the playlist when I quit winamp, the next time I try to start winamp it instantly crashes. The only way for me to start winamp again is to delete the local playlist files from winamp's directory.
I admit that this could just be winamp's fault, as I don't think it happened in the last version of winamp, nevertheless, I thought you might be interested to know.
TAK Turbo is decoding only 9 percent slower than FLAC -0.
Not to be a pain for nobody but it's 10%. Decoding times:
TAK turbo 01:32.614
FLAC -0 01:24.128
From those 2 figures it's 9.16%
92.614 / 84.128 = 1,1008701027006466337010270064663
It took TAK 12.8% longer than flac, likewise, using flac saved 11.3% over TAK.
8.48/0.9261=9.1566
8.48/0.8413=10.079
It depends whether you calculate the percentage from the fastest or the slower.
The winamp plugin for TAK still has that weird bug. If I close winamp with a TAK file loaded, I get an error when starting winamp again. Other than that I've had no problems.
The winamp plugin for TAK still has that weird bug. If I close winamp with a TAK file loaded, I get an error when starting winamp again. Other than that I've had no problems.
It's true
However always a good job Thomas
TAK 1.0.2 Final has been released
Please post further comments here (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=58783&view=findpost&p=527886).
Many thanks for testing the beta release!
Thomas