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.1.1 (Read 85753 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

TAK 1.1.1

Final release of TAK 1.1.1 ((T)om's lossless (A)udio (K)ompressor)

This version brings support for MD5 checksums, an option to lower the process priority and compression improvements for some files.

It consists of:

- TAK Applications 1.1.1.
- TAK Winamp plugin 1.1.1.
- TAK SDK 1.1.1.
- TAK Decoding library 1.1.1.

Download

Download the archive in the upload section: TAK 1.1.1

What's new

New Features:

- In very rare cases the presets -p3 and -p4 could compress much worse than the lower presets. A new filter in the encoder will nearly eliminate this annoying effect. It can also increase the average compression by a tiny (<= 0.05 percent) amount.
- Creation and verification of MD5 checksums of the raw audio data. The file info command can show you the MD5.
- Option to lower the process priority. Nice for background processing.

Improvements:

- Up to 9 KB smaller binaries. Although i have removed a lot of the assembler optimizations, the speed is still very close to the previous version.
- Further clean up of the Code.

Modifications:

- Support for seek tables removed. The new version will neither add seek tables to newly encoded files nor use seek tables contained in files created with older program versions. Important: Seeking in files without seek table is only supported since V1.1.0. Please update the WinAmp plugin and/or the decoding library for full seeking support in media players.
- There is a new metadata object which contains position and size of the last frame in the stream. This info is useful for seeking and tag detection.

Known issues:

- If you use pipe decoding and the application reading the pipe is beeing terminated before the whole file has been read, TAKC may get into an endless loop and has to be manually killed with the task manager. I don't think this is a big issue but i will try to fix it in one of the next versions. BTW: Big thanks to shnutils for testing the pipe decoding!
- There seem to be some compatibility issues with pipe decoding to some other applications ("crc1632.exe" has been reported). I will try to fix it in the next release.

More information

You may find some useful information in the beta thread.

Plans for V1.1.2

I will soon open a thread for the TAK 1.1.2 development.

Have fun...

Thomas

TAK 1.1.1

Reply #1 –
Quote from: TBeck on
Final release of TAK 1.1.1 ((T)om's lossless (A)udio (K)ompressor)


10 days elapsed and no feedback ???

Quote
compression improvements for some files.

Up to 9 KB smaller binaries


Very good  It works (limited test), 9.5 KiB smaller, "pmax vs p2" problem reported in 1.1.0 is fixed
/\/\/\/\/\/\

TAK 1.1.1

Reply #2 –
Codec's working just fine. I have nothing to say other than "thank you".

TAK 1.1.1

Reply #3 –
For me TAK has gotten to be a software for daily use completely!
Thank you !

TAK 1.1.1

Reply #4 –
Glad to see that development of TAK goes further but unfortunately I'm rather disappointed with both v1.1.0 and v1.1.1
First of all, I don't completely understand the reason of removing -p5 preset. What is it ? Some kind of "Developer Paranoia" ? I'm seriously. Not the first time I see how the developers due unknown reasons "emasculate" some useful stuff from the tools they produce. Probably they think: "Oh, its too slow. Every new user will immediately use the maximum setting and will decide that tool is too slow".
Excuse me, but lossless compressors are always have been the part of advanced area, so you just anger the users by taking away the things which can help to squeez out the maximum from the given tool. Furthermore it's somehow breaks your own words given in "Missing Features" section of Readme.html: "Even more speed and better compression."
Anyway here are some brief tests I made. Three versions have been used: 1.0.4, 1.1.0 and 1.1.1 with two lossless albums, converted each one to one big WAV file. Timer v8.00 have been used for measuring and output is redirected to another HDD to keep minimal impact on IO system.

[font= "Courier New"]
Code: [Select]
Chick Corea '2006 - The Ultimate Adventure (773 930 348)
--------------------------------------------------------
takc104 -e -p5m -fsl16384 -wm0 -sts3    290.972         504 605 505
takc110 -e -p4m -fsl16384 -wm0 -sts0    213.665         504 827 649
takc111 -e -p4m -fsl16384 -wm0          228.194         504 612 442

Squarepusher '2004 - Ultravisitor (844 452 716)
-----------------------------------------------
takc104 -e -p5m -fsl16384 -wm0 -sts3    289.281         471 284 005
takc110 -e -p4m -fsl16384 -wm0 -sts0    213.270         471 621 610
takc111 -e -p4m -fsl16384 -wm0          229.862         471 431 438
[/font][/size]

The results here are pretty expected. Averagely v1.1.1 -p4m is 7.3% slower than v1.1.0 -p4m but it's decreases the compression ratio gap showed by v1.1.0.
Now v1.1.1 maximum mode is 21.1% faster than v1.0.4 one and negligibly (0.016%) worse on compression ratio. Well, its OK. But look on the next tests with -fsl512

[font= "Courier New"]
Code: [Select]
Chick Corea '2006 - The Ultimate Adventure
------------------------------------------
takc104 -e -p5m -fsl512 -wm0 -sts3    139.929     519 996 238
takc110 -e -p4m -fsl512 -wm0 -sts0    193.307     519 875 895 (110 packs better than 104)
takc111 -e -p4m -fsl512 -wm0          201.356     522 506 351 (111 packs much worse than 104)

Squarepusher '2004 - Ultravisitor
---------------------------------
takc104 -e -p5m -fsl512 -wm0 -sts3    152.894     492 159 222
takc110 -e -p4m -fsl512 -wm0 -sts0    211.687     491 492 454 (110 packs better than 104)
takc111 -e -p4m -fsl512 -wm0          223.147     494 896 627 (111 packs much worse than 104)
[/font][/size]

Results here are very unpleasant. With -fsl512 v1.1.1 not only 0.520% worse compresses but also 44.9% SLOWER !
Also you may notice that v1.1.0 somehow packs better than v1.0.4 although it shouldn't.
I suppose you know that -fsl512 is used for compressing the files processed with LossyWAV. By the way, results with LossyWAV processed files are even worse.
I used latest DEV version 1.1.3e at default -q 5 level.

[font= "Courier New"]
Code: [Select]
Chick Corea '2006 - The Ultimate Adventure
------------------------------------------
takc104 -e -p5m -fsl512 -wm0 -sts3      138.360         253 372 934
takc110 -e -p4m -fsl512 -wm0 -sts0      190.513         253 408 503
takc111 -e -p4m -fsl512 -wm0            208.103         258 427 682
[/font][/size]

So, with LossyWAV processed files v1.1.1 is 50.4% slower and 1.994% worse on compression. Now let's see what will happens with another -fsl values.
Now I will use only one test file because they are both show quite similar behaviour.

[font= "Courier New"]
Code: [Select]
Chick Corea '2006 - The Ultimate Adventure
------------------------------------------
takc104 -e -p5m -fsl1024 -wm0 -sts3    207.017         512 660 380
takc110 -e -p4m -fsl1024 -wm0 -sts0    197.920         512 648 369
takc111 -e -p4m -fsl1024 -wm0          209.851         512 915 726 (still worse)

takc104 -e -p5m -fsl2048 -wm0 -sts3    257.169         508 215 882
takc110 -e -p4m -fsl2048 -wm0 -sts0    203.414         508 167 598
takc111 -e -p4m -fsl2048 -wm0          219.218         508 407 219 (14.8% faster than 1.0.4)

takc104 -e -p5m -fsl4096 -wm0 -sts3    263.727         505 789 477
takc110 -e -p4m -fsl4096 -wm0 -sts0    191.189         505 777 818
takc111 -e -p4m -fsl4096 -wm0          206.334         505 679 778 (21.8% faster than 1.0.4)

takc104 -e -p5m -fsl8192 -wm0 -sts3    285.178         504 967 305
takc110 -e -p4m -fsl8192 -wm0 -sts0    208.951         504 801 487
takc111 -e -p4m -fsl8192 -wm0          222.858         504 767 462 (21.9% faster than 1.0.4)
[/font][/size]

Well, I suppose problem is in -fsl values of 512, 1024 and partially 2048, but who knows ?
Truly speaking it doesn't fit in my head how such simple things haven't been noticed by you after compilation.
Anfortunately I can't test all permutations of presets\evaluation levels\fsl values. First of all because presets map have been changed (and that's another reason against changes you made) and furthermore I just have no time.
Anyway if I were you, I would return to v1.0.4 compression algo but obliviously I'm not you
Hope that such brief tests will help to narrow your search but NO thanksgiving for v1.1.0 and v1.1.1 from me. Goodluck.

TAK 1.1.1

Reply #5 –
Well,the md5 checksum seems have problem---The value in tak is not match with the original wav file...

TAK 1.1.1

Reply #6 –
Quote from: xaeroak15 on
Well,the md5 checksum seems have problem---The value in tak is not match with the original wav file...

TAK calculates the MD5 from the audio data only. It does not include the header or footer of a wave file.

What have you done? Is your MD5 from the whole wave file?

TAK 1.1.1

Reply #7 –
Quote from: TBeck on
Quote from: xaeroak15 on
Well,the md5 checksum seems have problem---The value in tak is not match with the original wav file...

TAK calculates the MD5 from the audio data only. It does not include the header or footer of a wave file.

What have you done? Is your MD5 from the whole wave file?

Yes mine is calculated from the whole wave file.Now I see,thank you:)
BTW,is there any tool can calculate the MD5 from the audio data only?


====================
Thanks a lot ,Synthetic Soul!

TAK 1.1.1

Reply #9 –
Hi Skymmer,

sorry for my very late reply. Unfortunately i had nearly no time to work on TAK for the past months. There are also quite some mails i haven't replied to yet.

Quote from: Skymmer on
First of all, I don't completely understand the reason of removing -p5 preset. What is it ? Some kind of "Developer Paranoia" ? I'm seriously. Not the first time I see how the developers due unknown reasons "emasculate" some useful stuff from the tools they produce. Probably they think: "Oh, its too slow. Every new user will immediately use the maximum setting and will decide that tool is too slow".

In TAK 1.1.0 i have reduced the maximum predictor count in the main filter from 256 to 160. This significantly reduces the peak cpu load in the decoder, what does make a lot of sense if you take possible later hardware implementations into account. The loss of average compression efficiency is minimal. Even those of my file sets which love high predictor orders don't loose more than about 0.10 percent of compression; for most file sets the loss is smaller than 0.05 percent.

Okay, there are some rare files (for instance harpsichord music) which loose more than 1 percent. But those files would also benefit from up to 512 predictors (maybe even more). It wouldn't make sense to drastically increase the cpu requirements of the decoder to optimize such rare cases.

TAK 1.0.4 was using 256 predictors with -p5 and 128 with -p4.  After the reduction of the maximum predictor count from 256 to 160, there was little reason to keep both presets, beacuse the difference of 160 and 128 predictors is rarely noticeable.

Quote from: Skymmer on
Furthermore it's somehow breaks your own words given in "Missing Features" section of Readme.html: "Even more speed and better compression."

No, because you often can't have both. This time i have deceided for more speed, or, to be more exact, for a reduction of the peak cpu load in the decoder. Unfortunately you will hardly notice a increase of the average decompression speed, because high predictor counts (responsible for the peak cpu load) are rarely beeing used.

Quote from: Skymmer on
The results here are pretty expected. Averagely v1.1.1 -p4m is 7.3% slower than v1.1.0 -p4m but it's decreases the compression ratio gap showed by v1.1.0.
Now v1.1.1 maximum mode is 21.1% faster than v1.0.4 one and negligibly (0.016%) worse on compression ratio. Well, its OK.

That's fine and seems to support my deceision to reduce the maximum predictor count.

Quote from: Skymmer on
So, with LossyWAV processed files v1.1.1 is 50.4% slower and 1.994% worse on compression.

Indeed, that's annoying.

Quote from: Skymmer on
Truly speaking it doesn't fit in my head how such simple things haven't been noticed by you after compilation.

That's because i was following my own advice: Don't use presets higher than -p2m if processing LossyWav-Files. Yes, i didn't try it with higher presets, but now i can confirm your findings.

The compression inefficiency of -p3/p4 is beeing caused by a new filter introduced with V1.1.1, which obviously doesn't work well with LossyWav files. The solution is very simple: I will disable it, if -fsl512 is beeing used. Then the compression efficiency of -p3/p4 will be the same as in 1.1.0.

Thank you for reporting your findings! The good and also the bad ones.

But honestly, your response seems a bit harsh to me...

  Thomas

TAK 1.1.1

Reply #10 –
A bit aside: Does TAK 1.1.1 still need wapet for using it with Exact Audio Copy like HA Wiki mentions? Is this because takc.exe can't write tags?

TAK 1.1.1

Reply #11 –
Quote from: Alexxander on
A bit aside: Does TAK 1.1.1 still need wapet for using it with Exact Audio Copy like HA Wiki mentions? Is this because takc.exe can't write tags?

Yes. 

But possibly this would be a nice option to add in V1.1.2... 

TAK 1.1.1

Reply #12 –
Quote from: TBeck on
Hi Skymmer,
sorry for my very late reply. Unfortunately i had nearly no time to work on TAK for the past months. There are also quite some mails i haven't replied to yet.

Good day! Finally!    Truly speaking I thought that you just ignoring me but obliviously you're not.

Quote
Thank you for reporting your findings! The good and also the bad ones.

You're welcome.

Quote
But honestly, your response seems a bit harsh to me...

Well, the day after I've read it again and it became harsh even to me so I must admit that I'm really was a little bit harsh but I was under some kind of affect so I hope you'll understand and accept my apologies.

TAK 1.1.1

Reply #13 –
I can't play tak generated by TAK 1.1.1 with foobar2000 0.9.6.1 beta 1 and TAK decoder 0.4.2. The tak file can be decompressed to wav with the decompressor in TAK 1.1.1.
Can anyone double check this?

TAK 1.1.1

Reply #14 –
Quote from: oversky on
I can't play tak generated by TAK 1.1.1 with foobar2000 0.9.6.1 beta 1 and TAK decoder 0.4.2. The tak file can be decompressed to wav with the decompressor in TAK 1.1.1.
Can anyone double check this?

You should update tak_deco_lib.dll yourself because foo_input_tak 0.4.2 contains older version (1.0.7).
Detailed explanation: http://www.hydrogenaudio.org/forums/index....st&p=633005

TAK 1.1.1

Reply #15 –
Thank you. The problem solved. When I entered the forum, this was the first topic entered into my eyes. So I think it is the topic to discuss because my foobar used to be able to play tak, and I forgot to search before asking.


Quote from: lvqcl on
Quote from: oversky on
I can't play tak generated by TAK 1.1.1 with foobar2000 0.9.6.1 beta 1 and TAK decoder 0.4.2. The tak file can be decompressed to wav with the decompressor in TAK 1.1.1.
Can anyone double check this?

You should update tak_deco_lib.dll yourself because foo_input_tak 0.4.2 contains older version (1.0.7).
Detailed explanation: http://www.hydrogenaudio.org/forums/index....st&p=633005

TAK 1.1.1

Reply #16 –
Great job!
I discovered TAK a week ago. It seems so fast!
I've got Tak 1.1.1.
I wrote a source plugin for CoolEdit / Audition; it seems to work...
I wrote a source plugin for Nero; even this seems to work!
No tags support.

Now I can record (.wav) my live concerts, do some editing in Audition, archive the files in TAK format, and whenever I need, I can directly do further editing or burn with Nero. Saving 50% disk space, taking no more time than .wav files.

I'l try beta 1.1.2.

When can we have the library (.h, .lib, .dll) with the encoder?


I think your license allows me to put the filters for public download. Is this right?

I have to read carefully Audition and Nero SDK licenses.
Can someone help me? Does Audition and Nero allow me to put in the internet a freeware filter ?

TAK 1.1.1

Reply #17 –
Quote
You should update tak_deco_lib.dll yourself because foo_input_tak 0.4.2 contains older version (1.0.7).
Detailed explanation: http://www.hydrogenaudio.org/forums/index....st&p=633005

I think it's really annoying, since the official homepage of TAK is the hydrogenaudio forum instead of Thoma's own homepage (I don't know German), the information was scattered around the threads, making it hard to search.

To promote TAK, or make TAK easier, someone need to make a homepage with all the latest development news, 3rd-party tools link and files for download, otherwise thousands of repeated questions will come up.

Yes I know TAK have a WIKI, but for some people WIKI is not reading-friendly, and usually not very up to date.

Personally I'm very concern about the OSX version, I didn't see anyone implement TAK support for OSX! Even for windows, should have "TAK Drop" to simplified the encode/decode job, otherwise it will be less popular.

Thomas put a lot of effort to make it better, it's a waste not to utilize this excellent codec.
Hong Kong - International Joke Center (after 1997-06-30)