This release introduces a new file format, which can not be decoded by earlier versions of Tak, Takc, in_tak and tak_deco_lib! But surely it can decode files created by any earlier version.

Improvements:

- Slightly better compression of CD-Audio for any preset (ranging from 0.09 to 0.37 percent for my primary test corpus). - More than 2 percent better compression for my 8-bit test corpus. - More than 1.5 percent better compression for my 192 KHz / 24-bit test corpus. - Up to 0.45 percent better compression for my LossyWav test corpus. - Higher encoding speed for any basic preset (without addditional evaluation level), higher decoding speed for any preset. Depending on the cpu up to 11 percent faster encoding for -p0 and up to 15 percent faster decoding for -p3 compared with V1.1.2. - While the new codec is smaller than the previous one, the binaries are a bit bigger because the decoder for the old file format takes up about 18 KB. - The file format is prepared to support some more future improvements.

Modifications:

- Added xrecode II to the list of applications with TAK support in the readme file.

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.

What has changed in comparison to the beta release

- More than 1 percent better compression for my 8 bit test corpus. The modification may also help some very low amplitude 16-bit files.- A bit better compression for some very special problem files.

- Tuning of the new codec.- Implementation of some advanced features of the new codec which are already supported by the decoder.- Evaluation of 320 predictors.- Support for the Wave64 file format.- Support for multi channel audio.

Improvement over 1.1.2 or 2.0 beta?Also, I think that gain in % of the original size would be more useful.

Improvement is over v1.1.2.Average bitrate is 761 kbps for my test set (when using v2.0.0 -p3).This allows for an impression, not for an exact percentage of saving as I recorded just the average bitrate shown by foobar.Sufficient for my purpose, not the whole story.

I've uploaded a new version of foo_input_tak that is bundled with the tak_deco_lib.dll from TAK 2.0.0. It would be interesting to see some timing comparisons between decoding with foo_input_tak.dll/tak_deco_lib.dll and takc.exe. My first, very short test with a file created by TAK 1.0.2 was... surprising.

I've uploaded a new version of foo_input_tak that is bundled with the tak_deco_lib.dll from TAK 2.0.0. It would be interesting to see some timing comparisons between decoding with foo_input_tak.dll/tak_deco_lib.dll and takc.exe. My first, very short test with a file created by TAK 1.0.2 was... surprising.

Well, decoding of pre 2.0.0 encoded files may be slower than with 1.1.2, because i didn't care for proper code alignment of the backwards compatibility sources. If that' s the cause of your surprise...

Well, decoding of pre 2.0.0 encoded files may be slower than with 1.1.2, because i didn't care for proper code alignment of the backwards compatibility sources. If that' s the cause of your surprise...

I was surprised that takc.exe was slower than tak_deco_lib.dll on TAK 1.0 files. I tried it today with a TAK 2.0.0 encode of the same file and tak_deco_lib.dll is slower - like we're used to. Still, having to manually fiddle with code alignment in a high-level programming language in this day and age... may I suggest (again) to use a modern compiler?

Picking up on foosion's comment... I don't know if this has been discussed or not, but how much of an improvement do you think there would be by rewriting TAK in C or C++ and using a bleeding edge compiler?

Also foo_verifier compares calculated MD5 with MD5 stored in the file. For TAK files this feature does not work

Currently the TAK SDK doesn't support access to the MD5 meta data stored in the stream, therefore foobar can't read it. This does not mean, that no MD5 is present in the stream. Please use TAK's file info function to check if the MD5 is available.

QUOTE (foosion @ Jan 10 2010, 12:29)

QUOTE (TBeck @ Jan 9 2010, 20:43)

Well, decoding of pre 2.0.0 encoded files may be slower than with 1.1.2, because i didn't care for proper code alignment of the backwards compatibility sources. If that' s the cause of your surprise...

I was surprised that takc.exe was slower than tak_deco_lib.dll on TAK 1.0 files. I tried it today with a TAK 2.0.0 encode of the same file and tak_deco_lib.dll is slower - like we're used to. Still, having to manually fiddle with code alignment in a high-level programming language in this day and age... may I suggest (again) to use a modern compiler?

Good idea! I still want to switch to C, but am a bit hesitant because of all the code conversion i will have to perform. But i can't wait forever...

Thank you for the new plugin!

QUOTE (Qest @ Jan 11 2010, 03:02)

Picking up on foosion's comment... I don't know if this has been discussed or not, but how much of an improvement do you think there would be by rewriting TAK in C or C++ and using a bleeding edge compiler?

Very little. It primarily would save me some coding time.

And usually speed improvements of the encoder don't necessarily lead to faster presets...

That's my evil habit: I tend to add more features to the encoder which will eat up the speed gain achieved by optimizations.

Here are my rules for the construction of the presets:

- Make p0 as fast as possible but not at any price. The compression strength still has to be competitive.- Make p2 as strong as possible while encoding at least as fast as the competition at their default settings.- Put p1 somewhere in between.- Make p3 about half as fast as p2. Use the same proportion for p4/p3.

For the additional evaluation levels:

- Make EXTRA as strong as possible at about half the encoding speed of the standard preset. - Put any remaining encoder option into MAX. But always keep an eye on the speed of -p4m because many users are judging TAK's performance by its strongest preset.