Wav Compression in Freearc, from TTA to TAK ?

[eleria]

Hello, I've heard from the folks at Hydrogenaudio that freearc uses a modified TTA encoder for wavefiles.

Have you heard/ considered using TAK (Tom's Audio Kodec) maybe as part of the "powerpack" since the source isn't open?

Speed is near-flac, compression is equal/better than monkey's audio using lvl 4 preset (called p4 which is maximum).
But you can also use a bruteforce p4m mode that is 2x slower :3

Link to official site http://thbeck.de/Tak/Tak.html
Link to 2.0 release binaries : http://thbeck.de/Download/TAK_2.0.0.zip

[Bulat Ziganshin]

it's hard to consider external programs as part of archiver

if you wanna use tak, just use it as part of PP

[Skymmer]

Speed is near-flac, compression is equal/better than monkey's audio using lvl 4 preset (called p4 which is maximum).

Excuse me, but its not true. First of all regarding FLAC vs. TAK. You can feed em such options so FLAC will be faster then TAK and vice versa. But generally speaking TAK is faster than FLAC. For example look into the following test conducted using RAM disk and fastest switches. I used Chick Corea - The Ultimate Adventure album as one WAV image. Original size is 773 930 348 bytes.

TAK v2.0.0 -p0                        16.323     518 060 595
FLAC v1.2.1 -0                        19.972     544 925 862
FLAC v1.2.1 -l 0 -r 0 --no-mid-side   19.748     547 445 407

Speed optimised compiles from RareWares.org don't help here. For some reasons they provide worser speed than usual compile.

As for TAK vs. APE... You're wrong too. Compression ratio of TAK is not equal and moreover not better than APE. TAK never reaches the same ratio as APE. Look here please. Results given in form of time\size.

   testfile          TAK v2.0.0 -p4m         MAC v4.06 -c4000
--------------     -------------------     -------------------
01_orbital.wav     260 |   478 748 550     143 |   477 052 628
02_4hero.wav       558 | 1 008 998 880     298 | 1 006 754 612
03_chick.wav       271 |   503 451 469     140 |   499 526 784

It was also true with early versions of TAK called YALAC with possibility to almost completely control the codec internals. See attachment.

[eleria]

Haha gotta love semantics.
Anyway from encoding/reencoding over 300Go of lossless music I always take the worse example in terms of speed, and flac happens to be faster on quite a few tracks.
And yes I do use a ramdisk.
(ofcourse I can run that fiber-pooled compile or that other optimized flac and have better speed than TAK at any setting)

About APE, fair enough it compresses better most of the time but not always.
I was kinda showing my love for TAK and looking down on APE for being old slow as hell close-sourced and completely discontinued.

Afterall, I haven't seen many recent talk about TAK, and here is a Data Compression thread ... right ?
Even TAK -p4 would compress more than any TTA setting, that is if source hasn't been much improved when merging it into Freearc

But thanks for such a nice post O_o

[m^2]

Haha gotta love semantics.
Anyway from encoding/reencoding over 300Go of lossless music I always take the worse example in terms of speed, and flac happens to be faster on quite a few tracks.
And yes I do use a ramdisk.
(ofcourse I can run that fiber-pooled compile or that other optimized flac and have better speed than TAK at any setting)

About APE, fair enough it compresses better most of the time but not always.
I was kinda showing my love for TAK and looking down on APE for being old slow as hell close-sourced and completely discontinued.

Afterall, I haven't seen many recent talk about TAK, and here is a Data Compression thread ... right ?
Even TAK -p4 would compress more than any TTA setting, that is if source hasn't been much improved when merging it into Freearc

But thanks for such a nice post O_o

Monkey's Audio is open source. Though I remember sb. mentioning some licensing issues which prevented using the sources. It was something related to Matroska container.

[Black_Fox]

Yup, read something like that on hydrogen-audio too (regarding the "(un)openness")

TAK sometimes can be better than FLAC in at least some aspects, though since these comparisons about 5 new versions of TAK and 0 versions of FLAC were released, so it may have changed.

The only problem is unwillingness of its author to at least produce binaries for some other OSs than win32, which stems from TAK being written in Pascal/Delphi.

EDIT: Word goes around that TAK is faster than FLAC because of absence of MD5 checking, but I don't read about it often enough to be sure it's still true or ever was.

[m^2]

Yup, read something like that on hydrogen-audio too (regarding the "(un)openness")

TAK sometimes can be better than FLAC in at least some aspects, though since these comparisons about 5 new versions of TAK and 0 versions of FLAC were released, so it may have changed.

The only problem is unwillingness of its author to at least produce binaries for some other OSs than win32, which stems from TAK being written in Pascal/Delphi.

EDIT: Word goes around that TAK is faster than FLAC because of absence of MD5 checking, but I don't read about it often enough to be sure it's still true or ever was.

It has a switch to create / check MD5, so it probably doesn't check it by default.
And if you compare speed at similar strength (tak 1 ~= flac then TAK just blows FLAC away and MD5 won't change it.

[Black_Fox]

Oh, so that's how it is with MD5, ok! I agree with the rest. Too bad Thomas wants to keep the codec his and the source closed, therefore limiting non-official encoders and supported non-Win32 OSs for playback to zero.

[Skymmer]

I was kinda showing my love for TAK and looking down on APE for being old slow as hell close-sourced and completely discontinued.

I wouldn't say that. There were no official statement from Matthew about stopping the development. Last version of Monkey have been released on 17 Mar 2009 while last FLAC version have been released on 17 Sep 2007.

TAK sometimes can be better than FLAC in at least some aspects, though since these comparisons about 5 new versions of TAK and 0 versions of FLAC were released, so it may have changed.

Better - is very relative term. If we talk about compression speed and ratio then TAK is definitely better. Shortly speaking. If we have some FLAC speed\ratio result then TAK will give better ratio while being faster. My brief test above clearly shows it and it happens on other options too.
But I'm agree with you. Speed and ratio are the only advantages of TAK over FLAC. FLAC is open-source, very well known, ported to a lot of OSes, have a good software and hardware support, stable format. TAK is close-source and judging the following topic I think will never be, at least in near future. It has only official Winamp and unofficial foobar2000 plugins and basicly that is all. Authors of other software don't rush to include TAK support in their products although SDK is available. Furthermore author of TAK doesn't care about compatibility since new v2.0.0 breaks it. Forward at least.
So, although TAK is very promising, Its author goes into the wrong way from my point of view.

[m^2]

Speed and ratio are the only advantages of TAK over FLAC.

And isn't it the main thing we're after on this forum?

Furthermore author of TAK doesn't care about compatibility since new v2.0.0 breaks it. Forward at least.

Just forward. And there is forward compatibility for everything except for playback.
*EDIT* corrected, the second sentence said "backward".

[Black_Fox]

Skymmer: Ah, now I see what you meant. Well, yes, there are now many problems that one man cannot fix quickly. Since "nobody" uses TAK, its author can at least afford to improve codecs in incompatible ways We can hope he someday releases format specification if not source.