TAK 2.0.0 Options

[TBeck]

Final release of TAK 2.0.0 ((T)om's lossless (A)udio (K)ompressor)

This version brings a new codec that is both faster and stronger.

It consists of:

- TAK Applications 2.0.0.
- TAK Winamp plugin 2.0.0.
- TAK SDK 1.1.1.
- TAK Decoding library 2.0.0.

Download

Download the archive in the upload section: TAK 2.0.0

What's new

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.

More information

You may find some useful information in the beta thread.

Plans for V2.0.1

Many, therefore i have to deceide what to do first:

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

That's definitely far too much for one release.

Have fun...

Thomas


edit: Download link added

This post has been edited by TBeck: Jan 8 2010, 18:20

[TBeck]

Currently i don't have permission to edit my initial post, therefore i can not set a link to the upload: TAK 2.0.0

[_m²_]

Great, thanks!
I have several albums ripped and left as wavs, waiting for this codec.

This post has been edited by _m²_: Jan 7 2010, 23:03

[dB]

Many thanks Tom

This post has been edited by dB: Jan 8 2010, 00:19

[yerma]

Great work, thanks!

[ssjkakaroto]

Thanks Thomas

[BugHunter]

Thanks again Thomas.

Some tests:

CODE

Graeme Revell - Lara Croft Tomb Raider:
TAK - 228MB (239 205 929 bytes) 2.0 Final
APE - 228MB (239 224 557 bytes) ExtraHigh
TAK - 228MB (239 270 826 bytes) 2.0 Beta
TAK - 228MB (239 922 625 bytes) 1.04

Pulp Fiction OST:
TAK - 211MB (221 785 173 bytes) 711 kbps, 2.0 Final, Great!
TAK - 212MB (222 448 669 bytes) 713 kbps, 2.0 Beta
TAK - 213MB (223 429 990 bytes) 716 kbps, 1.12

David Holmes - Ocean's Thirteen:
TAK - 259MB (272 559 773 bytes) 815 kbps, 2.0 Final
TAK - 259MB (272 611 827 bytes) 816 kbps, 2.0 Beta

CODE

8bit solid file from the game:
OFR - 56.0MB  (58 810 291 bytes) (highnew --experimental --optimize best) better than bestnew
TAK - 59.2MB (62 089 921 bytes) 2.0 Final
TAK - 59.5MB (62 476 667 bytes) 2.0 Beta
TAK - 60.9MB (63 931 215 bytes) 1.12

CODE

AudioDoctor FSQ 2:
TAK - 77.0MB (80 753 075 bytes) 2.0 Beta, strange...
TAK - 77.4MB (81 241 788 bytes) 1.0.3
TAK - 77.6MB (81 455 724 bytes) 2.0 Final
Beta better than final release.  :o

This post has been edited by BugHunter: Jan 8 2010, 15:33

[Perun]

This is great, thanks.

[Compact Dick]

Your stellar work continues to amaze, TBeck

I can confirm that foobar2000 can play back TAK 2.0.0 files after updating tak_deco_lib.

This post has been edited by Compact Dick: Jan 8 2010, 21:29

[_m²_]

Thanks again Thomas.

Some tests:

CODE

Graeme Revell - Lara Croft Tomb Raider:
TAK - 228MB (239 205 929 bytes) 2.0 Final
APE - 228MB (239 224 557 bytes) ExtraHigh
TAK - 228MB (239 270 826 bytes) 2.0 Beta
TAK - 228MB (239 922 625 bytes) 1.04

Pulp Fiction OST:
TAK - 211MB (221 785 173 bytes) 711 kbps, 2.0 Final, Great!
TAK - 212MB (222 448 669 bytes) 713 kbps, 2.0 Beta
TAK - 213MB (223 429 990 bytes) 716 kbps, 1.12

David Holmes - Ocean's Thirteen:
TAK - 259MB (272 559 773 bytes) 815 kbps, 2.0 Final
TAK - 259MB (272 611 827 bytes) 816 kbps, 2.0 Beta

CODE

8bit solid file from the game:
OFR - 56.0MB  (58 810 291 bytes) (highnew --experimental --optimize best) better than bestnew
TAK - 59.2MB (62 089 921 bytes) 2.0 Final
TAK - 59.5MB (62 476 667 bytes) 2.0 Beta
TAK - 60.9MB (63 931 215 bytes) 1.12

CODE

AudioDoctor FSQ 2:
TAK - 77.0MB (80 753 075 bytes) 2.0 Beta, strange...
TAK - 77.4MB (81 241 788 bytes) 1.0.3
TAK - 77.6MB (81 455 724 bytes) 2.0 Final
Beta better than final release.  :o

What switches did you use? -p4e for the latest and -p5e for the older ones?

[BugHunter]

What switches did you use? -p4e for the latest and -p5e for the older ones?

I used p4m for 2.0 and p5m for older ones.

[HotShotFR]

Wow, vielen Dank Thomas!

Some stats and results going from 1.1.2 to 2.0.0, same parameters (-p4 -ihs, all at CD samplerate/quality):

16 hours of "world music" (celtic tunes, enya, african or chinese folk music etc.)

CODE

Total Size : 5.23GB (5 617 564 246 bytes)
Duration : 16:46:26.387 (2663039652 samples)
Avg. Bitrate : 744 kbps
Codec : TAK
Codec Profile : TAK 4
Encoding : lossless
Tool : TAK encoder 1.1.2

Total Size : 5.22GB (5 609 717 481 bytes)
Duration : 16:46:26.387 (2663039652 samples)
Avg. Bitrate : 743 kbps
Codec : TAK
Codec Profile : TAK 4
Encoding : lossless
Tool : TAK encoder 2.0.0

Thats 1kbps less and ~8 MB saved.

Bigger corpus of "ancient" music (medieval, renaissance and barocco)... about 178 hours...

CODE

Total Size : 45.7GB (49 074 526 816 bytes)
Duration : 1wk 0d 10:03:42.702 (28269101153 samples)
Avg. Bitrate : 612 kbps
Codec : TAK
Codec Profile : TAK 4
Encoding : lossless
Tool : TAK encoder 1.1.2

Total Size : 45.5GB (48 915 090 367 bytes)
Duration : 1wk 0d 10:03:42.702 (28269101153 samples)
Avg. Bitrate : 610 kbps
Codec : TAK
Codec Profile : TAK 4
Encoding : lossless
Tool : TAK encoder 2.0.0

Now it's about 2kbps less, saving around 160MB. Got the same -2kbps on a 5 GB corpus of vocal songs.

Re-encoding seems no slower - that means it's fast (no numbers here) - and I confirm efficiency has improved on all files Well done!

[halb27]

The new version's bitrate improvement for my test set of various pop music is
- 3 kbps for -p2
- 2 kbps for -p3 and -p4 (quite in line with recent post).

Thank you, Thomas.

This post has been edited by halb27: Jan 9 2010, 12:57

[_m²_]

The new version's bitrate improvement for my test set of various pop music is
- 3 kbps for -p2
- 2 kbps for -p3 and -p4 (quite in line with recent post).

Thank you, Thomas.

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

[halb27]

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.

[foosion]

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.

This post has been edited by foosion: Jan 9 2010, 20:12

[ssjkakaroto]

I think the zip file is corrupt foosion.

[foosion]

Indeed. Thanks for reporting, I re-uploaded the file.

[Steve Forte Rio]

I use -md5 key but TAK does not add Audio MD5 to the file. Why?

P.S. Pipe encoding using foobar2000 1.0 beta 6 converter.

-e -p4m -md5 -silent -ihs - %d

This post has been edited by Steve Forte Rio: Jan 9 2010, 20:46

[TBeck]

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

[TBeck]

I use -md5 key but TAK does not add Audio MD5 to the file. Why?

How do you know?

[Steve Forte Rio]

I use -md5 key but TAK does not add Audio MD5 to the file. Why?

How do you know?

File properties in foobar2000.

Example (FLAC):

Duration : 7:40.067 (20288940 samples)
Sample Rate : 44100 Hz
Channels : 2
Bits Per Sample : 16
Bitrate : 990 kbps
Codec : FLAC
Encoding : lossless
Tool : reference libFLAC 1.2.1 20070917
Embedded Cuesheet : no
Audio MD5 : 9D5656CD23D06A1E882AE329587D49DA


For TAK "Audio MD5" line is missing.

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

This post has been edited by Steve Forte Rio: Jan 10 2010, 09:56

[foosion]

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?

[Qest]

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?

[TBeck]

First: Thanks to all for testing!

I use -md5 key but TAK does not add Audio MD5 to the file. Why?

How do you know?

File properties in foobar2000.
...
For TAK "Audio MD5" line is missing.

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.

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!

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.

This post has been edited by TBeck: Jan 11 2010, 10:13