(T)om's lossless (A)udio (K)ompressor.

Download

The beta can be downloaded from the upload section: TAK 1.0.1 Beta

Warning

This is a public beta release of TAK. Although the preceeding releases have been evaluated by a lot of testers, there may still be bugs left.

What's new

Features:

- Some speed optimizations of encoder and decoder. Depending on the preset and your cpu you may see improvements of 2 to 10 percent (if your hard disk is fast enough). Most affected: Encoding and decoding of presets Turbo and Fast, decoding of presets High and Extra.
- Removed the access to internal encoder options. Reintroduced the additional evaluation level EXTRA as compensation.
- Added a dynamic comparison table to illustrate the effect of presets and evaluation levels on compression efficiency, encoding and decoding speed.
- Added a meta data structure to hold encoder version, preset and evaluation level used for compression. Because of rounding errors the addition of this handful of bytes can cause 0.01 percent worse compression be reported (compared to TAK 1.0).
- Added a new command to show selected information about a compressed file.
- The command line version now indicates errors via the exit code. I always thought i already had done this...
- Even better error tolerance of the decoder.

Fixed:

- GUI: When compressing/decompressing the selection of a drives root directory as user specified output destination caused an error.
- It was theoretically possible, that when decoding some verify or source io errors had not been reported properly.

What i would like you to do

- Report possible bugs.
- Tell me, if you like the new features.
- Speed comparisons with TAK 1.0. Because of TAK's high speed and the small speed improvements you will need a very fast disk io system to get valid results.

Have fun!

Thomas

Test file: Poets of the Fall - King of Fools

CODE

Preset        |   TAK 1.0   |   TAK 1.0.1 Beta   |    Compression
--------------+-------------+--------------------+----------------
Turbo         |      127 x  |             133 x  |        72,55 %
Turbo   +Max  |     46,6 x  |            49,2 x  |        72,25 %
Fast          |       93 x  |              97 x  |        72,00 %
Fast    +Max  |     35,6 x  |            36,7 x  |        71,73 %
Normal        |       60 x  |              61 x  |        71,68 %
Normal  +Max  |     29,4 x  |            30,2 x  |        71,61 %
High          |       36 x  |            36,2 x  |        71,57 %
High    +Max  |     17,6 x  |            17,8 x  |        71,50 %
Extra         |     21,7 x  |            21,9 x  |        71,41 %
Extra   +Max  |     7,37 x  |            7,44 x  |        71,36 %
--------------+-------------+--------------------+---------------
FLAC 1.1.4 -8 |     22,4 x  |                    |        73,41 %

Test performed on AMD Athlon XP 2800+ (2083 MHz) using a RAM drive to bypass the disk I/O system.

Thank you!

Well, 5 percent faster encoding for Turbo and Fast is ok. It's about the average of the results i have received so far. If i remember it right, the biggest improvements have been measured on an Athlon 64 and an XEON.

Could you please also test TURBO+EXTRA and FAST+EXTRA? I am really interested into their performance.

Thomas

BTW: How do you setup a ramdisk under Windows XP (if that's your OS)?

50 Cent - High All The Time

P4 2.0 GHz using Test mode, I have 756 MB SDRAM and hard drive spins at 5,400
On both of these songs the original encoder is faster every time.

Thank you!

The implementation of the test mode is different for V1.0 and V1.0.1. V1.0.1 does a bit more, what can make it slower.

But it's also true, that TAK's optimizations generally don't work very well on a P4. When using the encoding mode, you may see an improvement of about only 1 to 2 percent for Turbo and Fast.

TAK's assembler optimizations don't like the P4's very long latencies for the excecution of even some of the simpliest operations. Currently i don't plan to implement an extra code path for the P4, because it's a dying technology; the newer intel cpu's should work very well for TAK (as does the P3).

Thomas

Suggestion:

Since one of the presets is called "Extra" (-P4), i think it'd be less confusing if the extra evaluation level is renamed to something else.

You are right, but unfortunately i have no good idea for a replacement.

The meaning of "Extra" fits perfectly: This evaluation level provides you this (little) extra bit of compression...

Possibly i am not the only one, who missed this:

foo_input_tak, TAK decoder

AR-Soft Ramdisk (discontinued, but freeware)

I'll test the Extra evaluations tonight when I have more time than now. I'll also test the same file on my Pentium M 735 notebook.

This is a silly little thing, certainly not a bug, but I thought I'd mention it. In the decoding options screen of the GUI there is an option to save the error log. Well, the word error is misspelled. For some reason I kind of like it spelled as "errror". It looks cool. Maybe I shouldn't have said anything.

Thanks for the release Tom, now with a foobar plugin TAK can really be useful to me

Same file, same test setup.

CODE

Turbo  +Extra:   100x   72,36%
Fast   +Extra:  70,7x   71,82%
Normal +Extra:  38,7x   71,67%
High   +Extra:  21,7x   71,55%
Extra  +Extra:  11,8x   71,38%

The Pentium M results will follow soon.

What if we replace the preset instead, to "Ultra" ?

So we have:

Turbo
Turbo +Extra
Fast
Fast +Extra
Normal
Normal +Extra
High
High +Extra
Ultra
Ultra +Extra

Like 7-Zip have an "Ultra" level compression

Thank you! Somehow i like the TURBO+EXTRA and FAST+EXTRA settings. Possibly FAST+EXTRA would have been a good alternative to the current NORMAL preset: A bit faster and nearly as strong.


That's an interesting idea. Unfortunately there are some reasons against it:

1) The command line parameters had to be changed. Surprisingly i have already found some TAK guides in the web. They would be incompatible with a new preset -pU.

2) Ultra sounds very extreme. Possibly it would be a good name for the EXTRA+MAX setting, which indeed is extremely slow in comparison with other TAK modes. But EXTRA (+Standard) isn't really extreme, just a bit slower than HIGH and usually not much stronger.

Drats.

What about changing +Extra to +Enhanced?

That would be possible.

BTW: Regarding the naming of evaluation level you are less restricted: (S)tandard and (M)ax are reserved, because they have been already available in TAK 1.0, but the new Extra or whatever we will call it can start with any other letter.

So, here are the test results of my notebook.

Pentium M 735, 1700 MHz, RAM drive

Thank you again!

This lightens me, because it confirms, that my statement about up to 10 percent faster encoding was right...

Tbeck, i think you should consider shifting to just numbers and NOT giving presets names. Reasons:

1. If you add more presets in the future, you don't have to bother thinking of new names
2. Having two names for the same thing only creates confusion: why call it "Extra" when the switch is -p4? Let's just call it setting 4. Also, it isn't exactly intuitive that the Extra setting is activated by the -4 switch, but ANYONE can figure out that the -4 switch is for the -4 compression strength.
3. And while we're at it, let's shift to a wavpack style system for the extra evaluations. i.e. Extra evaluation becomes -x1, Max evaluation becomes -x2. Any future extra evaluation routine becomes -x3 and so on.

So basically, this is a the mixture of the Flac (-0,-1...) system and the Wavpack system (-x1, -x2)

Hm, what's about the new dynamic comparison table in the encoder options dialog?

Is it understandable, how it works? I know, the documentation in the Readme could be improved.

The idea was to give new users an idea about the effect of the Preset+Evaluation level settings on compression efficiency, encoding and decoding speed.

I like it because of the simple access to the different encoding presets, though I must admit the efficiency columns are a bit confusing at first. I often catch myself confusing the values with compression ratios. The speed values, on the other hand, are very useful.

I very much agree with Silversight. The speed portion of the table is very useful, but the efficiency portion is confusing and not really useful. If a new user sees the Turbo mode as having 0% efficiency, does that mean it doesn't compress at all? If the difference between two modes is 38%, does that mean the stronger mode will be 38% smaller?

I've read the documentation, so I understand what you were trying to accomplish, but the efficiency numbers still don't mean much because I don't know what sort of compression differences you saw on your test corpus.

I think it would be more useful if the table just showed relative compression rates. Whatever row is selected is the baseline, and then the stronger settings will be .4% or whatever and the weaker modes will be -.4% and such.

Any chance of adding APE2 tagging support? So we don't need to rely on 3d party apps...

One "errror" less in the final release, i am sorry


(Integer) numbers have a disadvantage: You can not insert something in between later (like the new evaluation level extra between standard and max). With letters it's possible, at least if you find an appropriate name. But i don't intend to add any more options, 5 * 3 is already quite much. There may be one exception:

The addition of a (secret) maximum compression level. There are some internal options in the encoder, which i never exposed. Possibly they could add 0.05 to 0.10 percent better compression, but encoding would be unbelievable slow... No other compressor i know would be slower. But this special feature would deserve a separate switch, maybe:



I think it's too late to switch to an incompatible preset option system. Possibly i will later add another (maybe number based) one as alternative.




You are right. Probably i will go back to relative compression rates. The first (internal) version was using them, but i myself and some hydrogen members feared, that newbies would take such values as guaranteed and would keep on telling me that i should correct the table or even call me a liar.

Possibly this dialog really needs a HELP button wich shows some short explaination or warning to avoid such trouble.

In the readme you can find my to do list, sorted by current priority. The top items are:

- Tag writing functions for the TAK applications.
- Unicode support.

As i wrote in some other posts, i plan to add tag writing function to the applications with the next release. I prefer to extend TAK's functionality step by step: Add something, let it be tested, if it works perform the next step.

Following the evolution of TAK meanwhile gives me the feeling it can be the best thing since Flac (sorry for not calling it the best thing ever)
Tom doesn´t feel nerved answering many questions some ape tamers never had the nerve.
Me feels pretty stupid meanwhile to pin down the sense of TAK in another thread.

All i can say: Move on Tom with your consequent work!!

I did it. I removed the first column ("Efficiency") and replaced the second one ("Relative") with compression difference values. If you slecet preset NORMAL, this column will tell you, that on my sample set TURBO achieved -1,25 percent less compression and EXTRA+MAX performed +0,75 percent better. After those modifications the rightmost column was empty. I filled it with the corresponding command line parameters: p0 to p4m. This hopefully makes several things clearer.

Thanks for your suggestions.

I don't know if this is a real 'bug' of the commandline encoder. But the log file created, when using the -l2a option with the commandline encoder in foobar2000, is partly in german.

See the "ja" and "nein" in the log file below:


For the rest I want to thank you.
I'm encoding and decoding in foobar2000 right now and it works very good!

Thank you for reporting. I am using some of my general purpose modules for the protocol generation, which i am also using in some projects i got paid for. Currently i don't want to touch them, therefore this tiny bug will persist, until i replace the protocol generation code with something else. It's also possible, that i remove this protocol mode. I already removed the diagnostics tables from it which were part of the yalac evaluation releases. They will come back, when i ask for help for the evaluation of a new optimized codec and probably then i will also replace the german words.

Great!

Thomas

Preparation of the final release

I plan to release the final version as well as an updated SDK and Winamp plugin tomorrow (saturday). I would have preferred to wait a bit longer for possible bug reports, but unfortunately i will have little time to work on TAK for several weeks, starting on monday. Since the preparation of a new release (it has to go through a couple of validation tools i wrote) takes up to a whole day, i will have to release the final tomorrow what gives me the opportunity to perform corrections until monday morning, if something with the final should go wrong.

Fortunately the beta already seems to be very stable.

Here is a list of the fixes and modifications. If you have found any bug not listed here, please tell me now!

TAK Applications

Improvements:

- GUI Comparison table: I removed the first column ("Efficiency") and replaced the second one ("Relative") with compression difference values. If you slecet preset NORMAL, this column will tell you, that on my sample set TURBO achieved -1,25 percent less compression and EXTRA+MAX performed +0,75 percent better. After those modifications the rightmost column was empty. I filled it with the corresponding command line parameters: p0 to p4m. This hopefully makes several things clearer.

Bug fixes:

- One tester has sent me a very special file which could not be encoded; the encoder stopped with an error message. The fact, that TAK 1.0 was also affected by this bug and nobody before reported such problems, confirms, that this file generated a very special conndition. Fortunately TAK still contains much self check code (which is slowing it down a bit), which detected this error condition and threw the error message. This bug affected only the encoder; if your files have been encoded without the encoder reporting an error, they are fine.

TAK SDK, library and Winamp plugin

Modifications:

- The APEv2 tag reading functions are a bit more tolerant when reading invalid tag headers not following the official APEv2 specification.

Bug fixes:

- When playing back (or decoding) high resolution audio, the library and the Winamp plugin reported wrong values for the current compressed bitrate.

If you have something to add, please tell me!

Thomas

Has anyone compared decompressed files with the original (via binary compare or checksums)?

It's been quite a while someone has reported doing this.

Thomas

I just did with a few of the albums I've encoded and foobar says that they're all equal

Thanks.

Well, my question has been motivated by an email i received. An user reported TAK creating files with MD5-checksums different from the original. Panic!!!

Fortunately he soon send me also the checksum files and some screenshots. The checksums were identical, but the screenshots show, that the checksum software couln't find the files to check anymore. Obviously an operator error...

But this was really shocking...

Thomas

Or just "plus" (extra compression is hardly an enhancement). "Slow" would be understandable (but a setting like "-Fast +Slow" would not make it really better).
Or call "Extra" "Very High" and keep +Extra (or -x[n] like suggested)

I am trying to encode TAK with foobar but I have strange resultsin here because I don't use commandline encoding very often. I have problems to create the commendline
It would be nice to have some examples within the readme.

Could someone help me?

Spirit,

take a look at the WIKI...

.sundance.

strange I searched here for Information about TAK but didn't find this side.

so thanks a lot