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 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'll get my standard tests done in the next day or so Thomas. Nice to see the codec continuing to improve.

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

I was a bit slower than you...


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


Not this time. Sorry... But it's on my todo list.





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


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.


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:



-p4e and -p5e produce identical files to -p4 and -p5, did you remove the extra evaluation level for those presets?

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

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

Thank you!





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

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.

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.

Yes, please do. I'm definitely interested in what results you get

+1 for piping

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. This list 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:

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.

Thank you very much! Nice results...

Some remarks:


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.


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.


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.


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

Hm, seems as if the winner is piping... Hopefully i will implement piping support for encoding in V1.0.3.


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

Not to be a pain for nobody but it's 10%. Decoding times:
TAK turbo 01:32.614
FLAC -0 01:24.128

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.

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.

It's true

However always a good job Thomas

TAK 1.0.2 Final has been released

Please post further comments here.

Many thanks for testing the beta release!

Thomas