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 1.0 - Final release of the new lossless codec (Read 250164 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

TAK 1.0 - Final release of the new lossless codec

Reply #75 –
Quote from: sPeziFisH on
Thanks Thomas, the coding/decoding-abilities of the new codec seems to be amazing *thumbs up* 

Thank you!

Quote from: sPeziFisH on
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?

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.


Quote from: JunkieXL on
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.

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.

TAK 1.0 - Final release of the new lossless codec

Reply #76 –
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.
 

TAK 1.0 - Final release of the new lossless codec

Reply #77 –
Quote from: TBeck on
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.


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.

TAK 1.0 - Final release of the new lossless codec

Reply #78 –
Quote from: spockep on
To actually hear a TAK file would be great.

If you heard one lossless codec, you heard them all 
In theory, there is no difference between theory and practice. In practice there is.

TAK 1.0 - Final release of the new lossless codec

Reply #79 –
Quote from: pepoluan on
Quote from: gib on
Quote from: MaB_fr on
At first, you end up with scepticism from people like me, who'd like to just take a peek at the code, just to be sure that the benefits claim are true and to be able to see the perks...
Now I'm not a programmer, so I might be way off base here.  But why do you need to look at the source code to alleviate your skepticism when TAK has been heavily tested by many people and, more importantly, has been publically available for anyone to try for the last 3 iterations (2 betas and the final)?  I can certainly understand preferring open source software, and this post is in no way a comment on whether TAK should be open or closed, but the notion that you need to look at the source code "to be sure that the benefits claim are true" strikes me as nonsensical.
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.

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.
err... i'm not using windows any more ;)

TAK 1.0 - Final release of the new lossless codec

Reply #80 –
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'm on a horse.

TAK 1.0 - Final release of the new lossless codec

Reply #81 –
Quote from: ...Just Elliott on
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.

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.

Quote
- they will be able to verify the algorithm will always be 100% flawlessly lossless

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.

TAK 1.0 - Final release of the new lossless codec

Reply #82 –
Quote from: TBeck on
"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.


Besides, linux whiners can use wine.

TAK 1.0 - Final release of the new lossless codec

Reply #83 –
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.

TAK 1.0 - Final release of the new lossless codec

Reply #84 –
Quote from: rjamorim on
Quote from: TBeck on
"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.

Besides, linux whiners can use wine.
...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!

TAK 1.0 - Final release of the new lossless codec

Reply #85 –
Quote from: rjamorim on
Besides, linux whiners can use wine.

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)

TAK 1.0 - Final release of the new lossless codec

Reply #86 –
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

TAK 1.0 - Final release of the new lossless codec

Reply #87 –
Quote from: Psyphre on
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

TAK 1.0 - Final release of the new lossless codec

Reply #88 –
Quote from: SebastianG on
Quote from: rjamorim on

Besides, linux whiners can use wine.

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)


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

Code: [Select]
$ mkfifo audiodump.wav
$ wine ./neroAacEnc.exe -ignorelength -q 0.3 -if audiodump.wav -of output.mp4 & mplayer input.ac3 -af channels=6:6:0:0:1:1:2:4:3:5:4:2:5:3 -ao pcm:waveheader:file=audiodump.wav -channels 6

TAK 1.0 - Final release of the new lossless codec

Reply #89 –
Quote from: Psyphre on
it can decompress (is that the right word?) faster than FLAC.

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

TAK 1.0 - Final release of the new lossless codec

Reply #90 –
Quote from: boombaard on
Quote from: Psyphre on
I obviously understand the advantage of greater compression, however I dont quite understand the latter. What effect does decompression have?
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
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.

TAK 1.0 - Final release of the new lossless codec

Reply #92 –
Quote from: Psyphre on
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

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

TAK 1.0 - Final release of the new lossless codec

Reply #93 –
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

TAK 1.0 - Final release of the new lossless codec

Reply #94 –
Quote from: jcoalson on
Quote from: Psyphre on
it can decompress (is that the right word?) faster than FLAC.

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

Quote from: Martin H on
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...

TAK 1.0 - Final release of the new lossless codec

Reply #95 –
Quote from: TBeck on
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?

TAK 1.0 - Final release of the new lossless codec

Reply #96 –
Quote from: Heliologue on
Quote from: TBeck on

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

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

TAK 1.0 - Final release of the new lossless codec

Reply #99 –
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.

Code: [Select]
original      (nothingelse.wav)       11.250.652    EncTime
Sac              --best                3.907.383     41:00    34.73%
OFR v4.600ex     --max --experimental  3.942.855     15:00    35.05%
LA 0.4b          -high                 3.962.097     00:38    35.22%
MAC v4.01        -c4000                4.022.412     00:20    35.75%
TAK v1.0         -extra -max           4.110.974     00:30    36.54%