I agree. Even looking at the source code is no way to determine if a complex algorithm (which I believe TAK is) works. The only way to know if it works or not is to test.

Thomas has provided the binaries. All you need to "... be sure that the benefits claimed are true ..." is to compress a WAV file using the binaries, and time it with whatever means you have. Then decompress it, again timing it. Then compare the result of the decompression with the original.

I am very sorry to say that some open source advocates in some way resemble audiophooles.

Some people perhaps don't understand the notion 'bit identical before and after compression & at the stated compression level when compressed'?

I suppose it is logically conceivable that the TAK encoder was actually a rootkit that made any files with the extension .tak have an arbitrary cool-looking %age compared to encodes with other lossless codecs of the same input data, but it seems more likely the individual in question here has been effectively conditioned by the (imo sometimes somewhat idiotically zealous F/OSS crowd that is commanded by the FSF).

It's really odd how think about how his question would have sounded lots more reasonable if he had said he was "just curious to see how and what algorithms were implemented", in order to understand why FLAC(wavpack too¿?) was so much slower and compressed so much worse (no offense josh ), rather than this rather idiotically skeptical sounding question "just because the source isn't available YET" (mind you, it's not as if it hasn't already been pretty much guaranteed it will at some time in the reasonably near future be released).

yes, the FSF has its uses.. but the crusading it inspires seems almost medievally unreasonable

Congratulations Thomas on the first final release of your incredible new lossless codec. I'm yet another person who has been silently watching the development of TAK since your first post on April Fool's day (and at that time was sure you were just joking). It's been really enjoyable to watch it grow from there to this point, and I look forward to seeing what comes next.

That's a lot to answer and many misunderstanding to correct.
[beside, calling me idiotic and stupid will in no way affect me...so you can go on ]

First, i'm in no way related to any work and/or people involved in ANY activity in the FSF or ANY OpenSource movement (apart from the fact that i've a computer with Ubuntu installed...one on so many, and that i've released WMPTSE under a "public domain" license).

Anyway, my point wasn't about "i dont believe your codec isn't doing what your are claiming".
My point was, if you choose to not release the source SAY it right now.
Everybody can endure a closed source codec, and as the developper of WMPTSE, i'm totally open to this.

We just want to know without having to browse all Hydrogen Audio Thread about your codec.

For the "rootkit part", it is true that i believe a piece of closed source software is a security danger in ANY operating system and especially under Windows. There's ways to ensure a program is not doing anything wrong (anti virus and such) to a certain extend.

I DO NOT say that's what your program is doing, i'm just saying that you will endure SUSPICION (mostly from paranoid people like me) as soon as some user have any kind of strange configuration problem with it.

Now, if you are already bored of answering stupid question, i'm sorry to predict nightmarish days when you widely release it (outside HA).

Last, i don't need the source code to compare a file bit-to-bit, thank you for the tips...
I need the source code to have confidence. I can trust a program to behave as deeply as i am permitted to understand its inner working...
You don't give source, i don't give full thrust...That was my point.

Again, i can live with it. But i NEED TO KNOW your politics... in the related thread, you give no answers TAK & License. First you say no to "publish code on release", then you say yes to "publishing code someday", and you conclude by "i've no time to spend on deciding"...

In a way, i was trying to put pressure on you to decide.
To me, it seems Release is the time to make these choices.

Maybe you don't agree...

At least, let's discuss it.


MaB_fr

Well, i should be more service oriented... It wasn't sufficient to guide you to the previous page of this thread. I better had copied the post from page 1 for you:



Your "Pressure" has been the reason for me to react less reserved than usual. Probably it on it's own would not have been sufficient, but trying to put pressure on me while putting absolutely no effort into own (easy) evaluation of this question simply is too much!


Thanks for beeing so careful! But 'already' seems a bit misplaced here, if you take into account that i am answering thoses questions since about 9 months. Usually no problem. There must be something special with your post. But i told you above.

Thomas

I'm about to make a volcano of yourself

But i'm sorry, you didn't answer the question just yet...

What will it be (i simplify to make all things crystal clear) :
- Totally close (ok, you say no to this one, so we just pass it) ?
- Closed source (other will not be able to modify it [even if you publish the code]) ?
- Open source (other will be able to modify it under certain condition) ?
- Public domain (you let your code in the wild without condition) ?

Are you exploding yet ?

MaB_fr

For someone who wants to look at the source code of every application they use you seem incredibly bad at reading posts. You said that you'd looked at the TAK - Source code release and conversion thread, in which is written (on whatever it is they write on up there):


Now, this may not be a definitive or conclusive answer, but if you bothered to read the single page in that thread, and the first in this, you would have all the answers you are going to get at this time. If you don't have faith in Thomas' word then please, move on.

TBeck has said numerous times that the sources will be opened when he has ported them from Delphi to C/C++, but that this project will take some time, so no release date is promised(for the sources, i mean).

Sorry, Synthetic Soul was faster than me

Any indication for this happening?


And this already answers your earlier question:




Why raise new questions?

I will not answer them now, simply because i am not sure about the details. I am prefering to write (hopefully useful) code instead of dealing with open source bureaucracy.



Continue dreaming...

Then, sorry for your users and the willing developer...

I will not bother you anymore...just enjoy the release

Good luck anyway, keep containing the fumes


MaB_fr

I'm making a FAQ for you, Thomas. I'll link it here when I'm done.

Thank you!

Put please let me read it first, before publishig it.

Nice to see(read) you again

Thomas

edit1: You have been faster! It's perfectly ok!

edit2: Now i have been too fast.

Two corrections:

1) My name is Thomas Becker, not Thomas Beck.

2) "it is most likely to be very easy to decode on hardware, even in its most compressing modes"

"even in its most compressing modes" is questionable.

Yeah, sorry. I edited it again. I do need a description for forward prediction.

Here's the link. Keep it in your sig?

http://www.hydrogenaudio.org/forums/index....showtopic=52276

I updated to your 11:40 edit.
I was wondering... what's the take on 32-bit floating point files? Can you compress 'em? Should I read the readme? Probably, eh?

Sounds pretty good. Well will it be added to the lossless comparison chart? It will need alot more support before I could consider migrating. To bad its not OS, or the support may be able to be added faster.

http://www.rarewares.org/

http://www.rarewares.org/lossless.html

Glad that version 1.0 is out. Congratulations!



Looking forward to see someone experiment with a freepascal port...

Is it possible to make version with multicore support? Almost all new processors is multicore, why developers do not use this advantages?

I'm pretty sure that this has to wait.

it's complicated, difficult to get right, and non-portable. better to spawn multiple processes for individual files and let the OS handle it.

TAK's actual implementations are generally only limited by IO speed, in case of "turbo" mode. I'm not sure that a multicore implementation would be that useful.

What about WinRar? What about video codecs? It's true and it's present! Why i must use only one core in my multicore system? Why i must run multiple copies instead of put all files in one queu and just run it?


Then it's possible improve speed in other modes!

Thanks Thomas, the coding/decoding-abilities of the new codec seems to be amazing *thumbs up*
I am really astonished that you get it to achive better compression and speed than the other lossless-codecs which have been optimized over a long period - due to a better basic structure/concept or due to smartish coding?

Feinste Grüsse

Properly multi-threaded code is not trivial to do.

Just wanted to say Thank You Tbeck!

I'm really happy to see new lossless codecs being developed and improved upon. I'll probably have to wait until the SDK is out and some playback support is available to fully test it out, but I'm definately interested/excited about this project.

Keep up the good work!
JXL

Would you please STFU and stop whining! Nobody is forcing you to use non-SMP enabled software in the first place and it doesn't make it better that you're whining at a freeware developer, where you haven't even paid a nickle for using his work!

Thank you!


I have been working on this (not with any public release in mind) since about 1997. I have tried anything i could think of to improve the performance. It's the result of some new ideas and very much hard work. Maybe from the things i tried, only 1 out of 10 was working well...

The good performance is based upon some new ideas and a speed oriented design. Some examples:

1) The codec is using 16-bit arithmetics (14-bits to be exact) with a 32 bit accumulator. This can be very efficiently implemented in MMX-assember. But even without using MMX this concept is advantegeous. For instance the cpu requirements are quite independent from the sample bit depth. Even with 24-bit samples any signal processing will still be performed in 16-bit arithmetic and therefore be very fast. No need to switch to slow 64-bit arithmetic as some other codecs have to.

2) Each frame has to be partitioned into subframes with individual prediction parameters, if the signal characteristics within a frame are changing. While any other asymmetric codec i know is performing this partition selection by some slow (brute force kind) try out approach, TAK is using a new very fast estimation method.

3) The prediction residuals have to be packed into some bit code. FLAC is using the very fast rice code, MPEG4Als -7 some very efficient but slower arithmetic code. TAK is using a very fast variation of the golomb code (works without divisions) and some additional codes specifically designed for low amplitudes. Those codes are nearly as fast as rice codes while providing significantly better compression. I am quite sure, that they are responsible for a good part of the compression advantage over FLAC when compressing low amplitude (for example classical music) files.

4) TAK adds a a very fast and efficient channel decorrelation method to the common mid-side methods.

5) While the features above are most important for the compression efficiency, i have optimized many other common methods. Here the advantage of each single optimization is usually small, but cumulated significant.



My WinAmp input plugin is already working. But i want to use it as test platform for my first sdk version, therefore the release has to wait until the sdk is done. Maybe 1 to 2 months.

Wow, I've only recently started following what's happening on HA, and I this codec looks very promising! I say promising because, to me, to be useful this codec still needs tagging support as well as foobar2000 playback ability. As soon as this is implemented, most chances are my FLAC archive is getting transcoded.

Congratulations for your excellent work, and I look forward to further development very eagerly.

Thats a real bummer. I think a working winamp plugin would be a great way to promote TAK. My advice, from a marketing standpoint, would be to make the masses happy and release the plugin now. No reason you couldn't also use it with your first SDK version. It would get alot of people excited about TAK. As TAK stands now, as nice as it is, with no playback option its just a fun tool. To actually hear a TAK file would be great.

If you heard one lossless codec, you heard them all

For a codec, source code is a very important matter.

Now, if you made a convrter or player - fine, that doesn't matter.

If you're making a codec which people may rely on, you need to guarantee that:

- they will be able to use it on any platform with interest, or make it work themselves
- they will be able to verify the algorithm will always be 100% flawlessly lossless
- etc

Right now, it's a windows only closed source codec. This offers none of those benefits, and at least one person (me) is unable to use it or listen to TAK files at all.

You will be pleased to know that the intention is to release the source in the future, and port to other platforms.

At that time you may chose to evaluate TAK or not. It is all about freedom of choice, which is good news.

Edit: you may find the thread "TAK - Source code release and conversion" of interest.

I am aware of this point of view, but repetition will not change anything.

I am already spending all (more than i should) of my free time for TAK developement. There simply aren't any resources left. The neccessary source code conversion can start, when TAK's feature set is quite complete and i have time again.

While i respect, that some people insist on the source code, i can not agree to all of their arguments.

"windows only" sounds very limiting, but given it's huge user base i don't have to be worried about lack of potential users before the source code release.


Only in theory.

The source code is quite complex. Someone would have to be very knowledgeable and spend very much time to find errors. Would you guarantee that this will happen? If the source code has been released, will you wait until some expert has checked it before using the codec? How do you know, if a trustable expert has checked it?

There are open source codecs available since years, and the developers are still finding bugs. Obviously source code availability can not provide you any guarantee, that the code is bug free.

Besides, linux whiners can use wine.

I don't understand all the fuss about this source code issue or lack of playback plugins. Thomas and others made it clear dozens of times that TAK will be open source and that playback will become available after the SDK was released. All you guys need is patience.

<sarcasm>I suggest you use one of those other lossless codecs in the meantime...</sarcasm>

PS: Ok, maybe the version numbering was confusing. Many people expect a full-blown software kit when a major release number is used. But then again the "1.0" refers to the core of the codec itself and everything else will have to wait for the next major release, I guess.

...only if they run Linux on x86.
What about those of us running Linux or Mac OS X on PowerPC?

I appreciate the work TBeck have put into this TAK codec, even if I have no chance to actually try it out.
He reach the largest user base by putting out a MS Windows binary, while at the same time excluding lots of potential TAK users/testers. Can't blame him for taking that road, especially since he provide the applicaation for free.
But I hope he will satisfy us non-Windows users sometimes in the, not too far away, future!

wine is nice but I've yet to figure out how to pass PCM data via a pipe or fifo to a "wine"-ed encoder. I'd like to avoid intermediate .WAV files for transcoding. Doesn't seem to work with wine. (I only tried it with Nero's aac encoder)

This sounds really interesting, however im curious about one thing. The 2 biggest advantages, from what I gather, is taht it can compress the track better than monkeys audio and it can decompress (is that the right word?) faster than FLAC.

I obviously understand the advantage of greater compression, however I dont quite understand the latter. What effect does decompression have?

Thx

some people want to be able to to play back files that weigh in at ~50mb each on a 486 with a 100mb HD seamlessly ;-)

seriously though, it mostly has something to do with the possibility of DAP support these days.. can't really think of any other reason that would hold up in court

You can use a fifo. I only copied the snippet from this board for later, which I think originated from Doom9.

actually right now they're about the same on x86 and the current flac in CVS is 15% faster.

I currently use WAVPACK to convert lossless albums which I have in .wav / track format. Since I can't store tags inside the WAVs, I want a format which can hold id3v2 / apev2 tags so that I can replaygain, and then compress to mp3 with replaygain. I basically chose the fastest compression candidate I had, but now comes wonderful TAK with Turbo mode. That should cut 2-3 minutes off of every album's compression.

Wait.

Playback with <1% CPU usage, fast replaygain scanning, somewhat faster conversion to lossy (eg. for portable usage).

Fast decoding is not an issue for playback purposses, unless if talking hardware-wise or if having an anchient PC, but instead the great advantage of fast decoding is the big time savings you'll get when repeatedly transcoding to lossy track files or re-encode to lossless when either a) a new release is made(which is worth it) or b) you change your mind about the compression settings used.

@Josh

Wow, 15% faster decoding allready in current FLAC CVS I can't wait for the next official release (no rush of course ) Nice to have something to look forward to Your continued efforts are much appreciated, mate

Competition is motivating...

I am very confident, that my new dedicated Turbo codec (in planning) will change this.

Maybe it will also compress even better than TAK's current Turbo preset.

But now back to work. I am not allowed to work on further optimizations, before some new features from my to do list have been added to TAK...

TBeck, and entirely new codec? As in, a codec distinct from TAK? Or do you just mean a new Turbo mode for TAK?

A new turbo mode.

If i say codec, i usually mean the compression core, the part of my code which does nothing else but compressing and decompressing audio frames.

Those compressed frames are beeing put into TAK's container (the file). The container itself contains a codec id indicating which TAK-codec has been used to compress the frames embedded in the container. When decoding TAK uses this codec id to determine, which of it's internal codecs to use.

If i add a new (internal) codec to TAK, older versions of my applications and the coming SDK have to be replaced with the current version to be able to decompress files created with the new codec.

Currently TAK contains only one (internal) codec which is beeing used for any preset, hence for fastest and strongest compression. But the design is more directed to strong compression than to highest (decoding) speed! Therefore i will built a variation of TAK's existing all purpose codec which will take more care for speed. Probably it will also compress a bit better than the current turbo preset...

Exactly!
So all linux whiners can not use wine...

isn't that w(h)ine's fault, though?

I've just tested TAK against the best codecs.
This is just a small sample which benefits clearly from high-orders,
but perhaps in the future you like to include a strong adaptive codec,
perhaps for archiving purposes only.