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

ok, changed some things.

@TBeck

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

Thank you.


Yes, it's desperately missing!

Unfortunately i have absolutely no talent in graphics... But possibly i could provide some ideas.

i fixed the wiki up a little(grammar stuff and such).

also, why is there a Hardware section?

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.

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.

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)

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

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.

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

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.

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!


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

damn that is some seriously mouth-watering stuff.

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

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.

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


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

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

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.

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



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.

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





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


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.

I would love to, but I deem myself not really an 'expert' for this. I think gottkaiser should do it

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

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.

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

Maybe the wiki could be updated using questions and answers from the TAK FAQ topic...

It looks, as if someone is updating the wiki. Let me say "Thank you"!

I did some updating last time. Turns out the syntax i had kept was wrong (i had written -4m instead of -p4m for max compression). I also put in the FAQ.

TBeck: Have you tried compiling your code with gpc (GNU Pascal)?

You might consider not doing the port yourself to c/c++, and open the source in pascal to let others do the port if its worth.

Also, before you release your code, if you manage to make it compile with gpc, binaries for non windows platforms could be provided.

there'a also Kylix which is the Linux equivalent of Delphi.

It's easier said than done. You may read my short explaination here and David Bryant's confirmation. It can't be done within a couple of days.


A big NO, because

- i am convinced, that such an open source project needs a stable and clean code base as reference. IMHO one of the most important reasons for FLAC's success was Josh Coalson's absolutely perfect preparation (Good code, perfect documentation, home page and information politics).

- What if there are not enough interested and good developers who know both Pascal and C?

- Given the code complexity i wouldn't expect the translation beeing performed by one single person. But many people working on this would possibly result in a worse outcome and a not very homogenous code.

There are more reasons, but those listed above are already sufficient for me.

Thomas

Just as a curiousity, would you maintain both a C and Pascal version of your code if you made the C port?

No, no, no!

I already find it a bit annoying to care for a C and Pascal header file for my decoding library. And those are tiny pieces of code...

And because of the structural or conceptual differences of both languages it isn't possible to translate source line by line, what can make things quite complicated. Correction: This isn't true if i first transform my pascal code into something more C like.

Ah OK, so I take it you'd stick with the C version once it's completed?

Do you think that if you made your Pascal code more C-like it would still maintain it's speed?

Yes. Possibly i will still use my Pascal code for the internal evaluation of new compression methods, because it contains many analysis functions which i don't intend to translate to C.


Because i wouldn't publish the C-like Pascal code, i will answer the question, if the C version will maintain the speed:

No, i expect it to be significantly faster!

Reasons:

- My Delphi compiler is from 2001. It's limited to i386-instructions and therefore doesn't use any of the sophisticated features and instruction sets of the newer CPUs.
- It doesn't even perform code alignment.
- It doesn't allow for cpu specific builds. Just look at the performance evaluation of different FLAC builds, which can be found in another thread (no time to provide you the link). There are significant speed differences if the proper compiler switches for the CPU have been applied.

I was just curious if it would it would still be as fast than if it was Pascal like. I don't know if it's possible to make such assumptions until it's actually made though.

If you can make at any more faster then jaws will be dropping. Can't wait!

Thanks for taking the time out to answer my questions

Somewhat off-topic, but...

I truly don't see the need to convert any good-running program from Pascal to C (or from any language to another language). Too big a danger of botching up something in the non-literal porting.

For you case, Thomas, FreePascal claims that it is able to compile Delphi sources, with processor optimizations.

Delphi 6 was released in 2001. Borland Pascal compilers are generally well optimised, I am not sure new instructions (other than SSE2 etc) would help much.
For code alignment, try {$CODEALIGN n}?
http://www.freepascal.org/docs-html/prog/p...#x14-120001.1.7

So far i can agree...


...but here i have to contradict. There are many possibilities for cpu specific optimizations, which DELPHI's "one compile fits all" can not adreess. I have looked at the assembler instructions of the DELPHI generated code and i have found many possibilities for improvements.

SSE2 is a different matter: I don't expect significant improvements without hand optimized assembler code. The same was true for my MMX code.

BTW: If i say significant improvements, i am talking about speed ups of about 10 percent, mainly for the presets TURBO and FAST.


Unfortunately the Delphi 6 compiler doesn't support this... I had to perform some dirty tricks to achieve code alignment for at least the most critical code parts.

I was looking over the recommended settings and commented over at the "TAK(ing) with EAC" thread.

Please have a look:
http://www.hydrogenaudio.org/forums/index....st&p=489302