Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: TAK Wiki (Read 25323 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

TAK Wiki

I tried to colect some Infos about the TAK format and publish it in the Wiki.
It's still not complete please help to complete it! :-)

Here is the link to the article.

TAK Wiki

Reply #1 –
Quote from: gottkaiser on
I tried to colect some Infos about the TAK format and publish it in the Wiki.
It's still not complete please help to complete it! :-)

Here is the link to the article.

Thank you!

Some thoughts:

1) I personally don't like the formulation "The development is still in early stages". While it is true, that TAK is still missing many of the features which have to be considered standard today, this formulation also sounds a bit, as if TAK has not been tested enough, isn't stable and shouldn't be trusted. I don't think, that the latter is true...

2) Under features "Very fast seeking" may be added. I think, it's an important feature, because i often read posts of people complaining that some compressors are seeking slowly. "Very fast" seems adeauqate as long as the users of the alpha winamp plugin are sharing my experience, that there is no noticeable delay.

3) It would be nice to add the recommendation to use ApeV2 tags, because i intend to use them as standard in future versions with tagging support.

I hope it's ok for me to post positive comments about my own software. Somehow i have the feeling, i have to take care for my baby...

Feel free to ignore it or to correct me.

Again, many thanks for the article!

  Thomas

TAK Wiki

Reply #2 –
ok, changed some things.

TAK Wiki

Reply #3 –
@TBeck

Actually, whats about a logo for TAK? :-)

TAK Wiki

Reply #5 –
i fixed the wiki up a little(grammar stuff and such).

also, why is there a Hardware section?

TAK Wiki

Reply #6 –
Hm, should con's really contain "No Hybrid / Lossy Mode"? While this is a great additional feature of some codecs (and definitely a pro feature for them), i doubt, that it could be considered a standard feature of lossless codecs. From my understanding, pro and con statements should list positive and negative deviations from the standards. But i may be wrong.

TAK Wiki

Reply #7 –
I'd have to agree with Tbeck here, if you take a look at the FLAC Wiki page there is no similar entry listed under it's Cons. I would consider the inclusion of a Lossy compression/Hybrid mode into a Lossless compressor to be a luxury option.

TAK Wiki

Reply #8 –
Something fundamental: I am feeling a bit uncomfortable when asking for the addition of positive statements about TAK to the wiki. Usually i hate "self praise". But because i have deceided to release TAK (after so many years of secret development, when i was satisfied by my improvements without telling anyone about it...) i now also have to take a bit care for it's promotion. If nobody uses TAK beacuse of bad promotion, all of my work put into the releases would be wasted...

I myself will never add any ratings to the wiki (i only could imagine to correct errors regarding objective technical details, for instance if someone would tell TAK a symmetrical compressor), but i may ask for a discussion of some topics. This time:

Speed seems to be an important property in the other wikis. Then it possibly should be mentioned, that the TURBO and FAST modes of TAK are encoding very fast. I know of no other codec which can compete with those presets encoding speed while providing comparitive compression. If you know one, please tell me.

TAK Wiki

Reply #9 –
Quote from: TBeck on
Something fundamental: I am feeling a bit uncomfortable when asking for the addition of positive statements about TAK to the wiki. Usually i hate "self praise". But because i have deceided to release TAK (after so many years of secret development, when i was satisfied by my improvements without telling anyone about it...) i now also have to take a bit care for it's promotion. If nobody uses TAK beacuse of bad promotion, all of my work put into the releases would be wasted...

I myself will never add any ratings to the wiki (i only could imagine to correct errors regarding objective technical details, for instance if someone would tell TAK a symmetrical compressor), but i may ask for a discussion of some topics. This time:

Speed seems to be an important property in the other wikis. Then it possibly should be mentioned, that the TURBO and FAST modes of TAK are encoding very fast. I know of no other codec which can compete with those presets encoding speed while providing comparitive compression. If you know one, please tell me.



I had added the "No hybrid" as a con because i saw it mentioned in the lossless comparison table under con for other codecs. However, i have removed it because it's would be unfair to mention it as a con in tak and not in flac etc.

I've also added some "pros". Could you please check and make some corrections?


PS: I changed the "Monkey's Audio Extra High" to "monkey's audio high". (didn't want to make a new post just to say this)

TAK Wiki

Reply #10 –
Sorry, that's too good: "Good compression levels (on par with Monkey's Audio Extra High)"

From my experience, TAK is on average on par with Monkey's HIGH, maybe slightly better. Only on selected files or genres TAK can surpass Monkey's Audio Extra High...

TAK Wiki

Reply #11 –
Further corrections:

1) "Fast encoding speed (TAK Turbo encodes faster than Flac -0 or wavpack -f; Tak Extra Max encodes as fast as Flac -8 or Wavpack -hx3)"

I don't know if "TAK Turbo encodes faster than Flac -0 or wavpack -f". I seem to remember that this was true for older FLAC versions but probably not for the latest release.

What is true is: TAK's Turbo encodes several times faster than FLAC -8 while providing better compression.

2) "Tak Extra Max encodes as fast as Flac -8 or Wavpack -hx3"

I haven't checked it by myself, but Josh's latest comparison shows that only TAK Extra is faster than FLAC -8, Extra + Max ("Insane mode") is considerably slower. I currently don't know about Wavpack -hx3.

TAK Wiki

Reply #12 –
Quote from: TBeck on
Further corrections:

1) "Fast encoding speed (TAK Turbo encodes faster than Flac -0 or wavpack -f; Tak Extra Max encodes as fast as Flac -8 or Wavpack -hx3)"

I don't know if "TAK Turbo encodes faster than Flac -0 or wavpack -f". I seem to remember that this was true for older FLAC versions but probably not for the latest release.

What is true is: TAK's Turbo encodes several times faster than FLAC -8 while providing better compression.

2) "Tak Extra Max encodes as fast as Flac -8 or Wavpack -hx3"

I haven't checked it by myself, but Josh's latest comparison shows that only TAK Extra is faster than FLAC -8, Extra + Max ("Insane mode") is considerably slower. I currently don't know about Wavpack -hx3.


I added those based on synthetic soul's tests (link at the end of document), and based on what seemed to be the consensus of the tests people conducted during beta testing.

TAK Wiki

Reply #13 –
Quote from: kanak on
Quote from: TBeck on

Further corrections:
...


I added those based on synthetic soul's tests (link at the end of document), and based on what seemed to be the consensus of the tests people conducted during beta testing.

Oh yes, thank you!

But this test was not using current version of FLAC. Some things have changed... I am quite sure, that my corrections would be more exact. Well, i am always trying to average any results i am aware of.

And a single test is seldom representative. I would like, if you would add a link to the latest FLAC comparison: FLAC 1.1.4

TAK Wiki

Reply #14 –
Quote from: TBeck on
Further corrections:

1) "Fast encoding speed (TAK Turbo encodes faster than Flac -0 or wavpack -f; Tak Extra Max encodes as fast as Flac -8 or Wavpack -hx3)"

I don't know if "TAK Turbo encodes faster than Flac -0 or wavpack -f". I seem to remember that this was true for older FLAC versions but probably not for the latest release.

yes, tak turbo is faster than wavpack -f but not quite as fast as flac -0 or -1

again, all these speeds are meaningful only on x86.

TAK Wiki

Reply #15 –
Quote from: jcoalson on
yes, tak turbo is faster than wavpack -f but not quite as fast as flac -0 or -1

Currently i have no intention to add modes as weak as flac -0 or -1 to TAK, which are encoding only slightly faster than TAK Turbo. If someone really needs them, please tell me!

Quote from: jcoalson on
again, all these speeds are meaningful only on x86.

If you disable TAK's MMX-optimizations all filters are using plain pascal code, not even any integer assembler optimization. Then encoding speed for Turbo goes down to 61 % of MMX, which is still more than 2 times faster than FLAC -8, which to my knowledge is using assembler optimizations. Decoding speed for turbo is still 82 % of MMX...

Furthermore:

1) My pascal implementation is not fully optimized on high language level. It only serves as a validation of the MMX code.

2) The pascal code is suffering from much compiler debug code, for instance nearly any array access is beeing checked for an bounds error.

3) The Delphi compiler is performing much worse than current C-Compilers. It doesn't support any code alignment and is using only i386 instructions.

I am convinced that a plain pascal or C version, optimized, without debug code and compiled with a better compiler would be about 15 to 25 percent faster. This without using any x86 specific code...

TAK Wiki

Reply #16 –
Quote from: TBeck on
would be about 15 to 25 percent faster.


damn that is some seriously mouth-watering stuff. 

When that day comes, perhaps you might consider adding an even stronger preset than 4m. 

TAK Wiki

Reply #17 –
Quote from: TBeck on
I am convinced that a plain pascal or C version, optimized, without debug code and compiled with a better compiler would be about 15 to 25 percent faster. This without using any x86 specific code...


Or ask buddies help to "port" a x86 assembly version (like BlackSword version of OGG), then this should reveal the true power of Thomas design.

And ... about the FLAC -0 or -1, if TAK is able to achieve a very low CPU usage (say below 5%, sorry I forgot the fastest TAK CPU load percentage), then I think no need an even lower/faster mode, the reason for lower compression ONLY because of the CPU load, usually there's a much CPU loading task running such as recording video with MPEG2 codec.
Hong Kong - International Joke Center (after 1997-06-30)

TAK Wiki

Reply #18 –
Quote from: kanak on
Quote from: TBeck on

would be about 15 to 25 percent faster.


damn that is some seriously mouth-watering stuff. 

When that day comes, perhaps you might consider adding an even stronger preset than 4m. 

Quote from: johnsonlam on
Or ask buddies help to "port" a x86 assembly version (like BlackSword version of OGG), then this should reveal the true power of Thomas design.

Well, i was talking about possible speed improvements of the the plain pascal code, which is only beeing used on very old cpu's without MMX! I doubt. that my MMX assembler implementation, which is beeing used by default, could be made significantly faster...

Quote from: johnsonlam on
And ... about the FLAC -0 or -1, if TAK is able to achieve a very low CPU usage (say below 5%, sorry I forgot the fastest TAK CPU load percentage), then I think no need an even lower/faster mode, the reason for lower compression ONLY because of the CPU load, usually there's a much CPU loading task running such as recording video with MPEG2 codec.

Speeds (without disk io) for preset Turbo on my old Pentium 3 / 866 MHz:

Encoding: 58 * real time
Decoding: 77 * real time

TAK Wiki

Reply #19 –
re: flac -0, I was just confirming what thomas said earlier about the wiki text, based on my own tests.  my point about the x86 speed is that for all the areas where the current codecs are very close, there is enough variation across architectures to affect the ranking.  general comments about speed should be based on algorithmic complexity but unfortunately all comparisons are done on x86 implementations.

TAK Wiki

Reply #20 –
Quote from: TBeck on
Well, i was talking about possible speed improvements of the the plain pascal code, which is only beeing used on very old cpu's without MMX! I doubt. that my MMX assembler implementation, which is beeing used by default, could be made significantly faster...


Sorry, I'm a bit 'look ahead'.
If the pascal code still have the room to improved, that's really awesome!

Quote from: johnsonlam on
Speeds (without disk io) for preset Turbo on my old Pentium 3 / 866 MHz:

Encoding: 58 * real time
Decoding: 77 * real time


Really impressive!

I think somebody here can help to make a direct comparison chart, with a single same machine, by using the same hard disk, same CPU, same WAV file ... many factors can be eliminated, the figure will be purely the codec speed.
Hong Kong - International Joke Center (after 1997-06-30)

TAK Wiki

Reply #21 –
Quote from: jcoalson on
re: flac -0, I was just confirming what thomas said earlier about the wiki text, based on my own tests.
...

Oh yes! Hopefully someone will apply the two corrections i asked for to the wiki:

Quote from: TBeck on
Further corrections:

1) "Fast encoding speed (TAK Turbo encodes faster than Flac -0 or wavpack -f; Tak Extra Max encodes as fast as Flac -8 or Wavpack -hx3)"

I don't know if "TAK Turbo encodes faster than Flac -0 or wavpack -f". I seem to remember that this was true for older FLAC versions but probably not for the latest release.

What is true is: TAK's Turbo encodes several times faster than FLAC -8 while providing better compression.

2) "Tak Extra Max encodes as fast as Flac -8 or Wavpack -hx3"

I haven't checked it by myself, but Josh's latest comparison shows that only TAK Extra is faster than FLAC -8, Extra + Max ("Insane mode") is considerably slower. I currently don't know about Wavpack -hx3.



Quote from: jcoalson on
...
my point about the x86 speed is that for all the areas where the current codecs are very close, there is enough variation across architectures to affect the ranking.  general comments about speed should be based on algorithmic complexity but unfortunately all comparisons are done on x86 implementations.

Regarding general statements i agree. Nevertheless speed comparisons on specific platforms obviously are interesting for people working on those platforms.

Quote from: johnsonlam on
Quote from: TBeck on

Speeds (without disk io) for preset Turbo on my old Pentium 3 / 866 MHz:

Encoding: 58 * real time
Decoding: 77 * real time


Really impressive!

I think somebody here can help to make a direct comparison chart, with a single same machine, by using the same hard disk, same CPU, same WAV file ... many factors can be eliminated, the figure will be purely the codec speed.

There are already many comparisons available. "same WAV file" is a bad idea, because the performance of any codec can be very variable on different files. You have to test many files to get somewhat representative results. And there is also some cpu dependency. TAK for instance will perform a bit worse on the P4. But because i never liked this CPU (Intel itselfs doesn't like it anymore...) i have no interest into specific optimizations for the P4.

TAK Wiki

Reply #22 –
Quote from: TBeck on
Oh yes! Hopefully someone will apply the two corrections i asked for to the wiki:
I would love to, but I deem myself not really an 'expert' for this. I think gottkaiser should do it

Quote from: TBeck on
And there is also some cpu dependency. TAK for instance will perform a bit worse on the P4. But because i never liked this CPU (Intel itselfs doesn't like it anymore...) i have no interest into specific optimizations for the P4.
I don't like it too  but seriously, I do think not optimizing specifically for P4 is a wise decision. IIRC some P4 optimizations is rendered slower on P3's and AthlonXP's (though to a lesser extent).

It is better to optimize for P3's, as all modern microprocessor benefits (to differing extents).

TAK Wiki

Reply #23 –
Ok update done! :-)

Maybe somone could add the comparison to Wavpack. I don't know much about it. Or we leave it and people can check it themselves in the external comparison sites.

TAK Wiki

Reply #24 –
Quote from: TBeck on
I am convinced that a plain pascal or C version, optimized, without debug code and compiled with a better compiler would be about 15 to 25 percent faster. This without using any x86 specific code...
may i suggest - if you or anyone else is going to use c - that you please don't forget other platforms than windows? i.e. please look to providing a portable source code and fallbacks in c for assembler routines in case anyone is using esoteric systems. being portable also generally helps overall code quality so it's not just an additional hassle.

thanks