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

It consists of:

- TAK Applications 1.0.1
- TAK Winamp plugin 1.0.4. Updated 2007-05-15.
- TAK SDK 1.0.3. Updated 2007-04-28.
- TAK Decoding library 1.0.4. Updated 2007-04-25.

Download

The main archive and the tools can be downloaded from the upload section: TAK 1.0.1 Final

What's new in the Applications

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.
- One tester send me a very special file which could not be encoded; the encoder stopped with an error message. The fact, that 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 throw the error message. This bug affected only the encoder; if your files have been encoded without the encoder reporting an error, they are fine.

What's new in the Winamp plugin and the SDK (compared to 1.0.1)

Modifications:

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

Fixed:

- When playing high resolution audio, plugin and SDK reported wrong values for the current compressed bitrate.

Thomas

Are there any format changes from 1.0.0 to 1.0.1?

No. V1.0.1 added a medata item to hold information about the encoder, but this will be ignored by V1.0.0, hence it's backwards compatible.

Thomas

When is decoder for foobar2000 expected?

pffff - foo_input_tak

Don't forget to ask mommy for permission

I have a problem with Winamp plugin using last (beta) version 5.34 build 1239.
Shortly, I cannot play any tak file, the Winamp error reporter generates the following:



It seems that it is a Winamp problem, because I don't have it with older versions (2.95 and 5.13).
Unfortunately, I deleted the old version of the plugin before testing the new one so, I could not confirm if this is common behavior with 1.0.1 and 1.0.2.

Does anybody have the same problem? Any hints for overcome it?
Could somebody send me the older version of the plugin?
Thanks.

~

Do you have the audioscrobbler plugin? If so, removing it could help.

Well, I tried a clean installation and it worked fine.
It appeared that in_zip plugin caused the problem. I should report it to Winamp forum maybe.
~

The newest Mp3tag 2.37j Development Build now supports TAK tags.

Great!

The german EAC wiki at arvex.de now also contains information about TAK usage and provides the TAK software archives for downloading.

Thomas

TAK 1.0.1 seems to run fine under WINE: WineHQ - AppDB

Looking at the 1.0 and 1.0.1 changelog, How goes the work on Unicode support?

Unicode support is at position 2 of my current todo list, which can be found in TAK's Readme. Because i have very little experience with unicode, the implementation will need much testing. And because i have no access to systems running under foreign languages, i will have to ask others for helping me with the testing. Such an approach is always quite time consuming: code a bit - let the testers check it - wait for feedback - improve the code - and back to the beginning. Currently i have no time to do it. Please don't expect a new release next month. Possibly in june...

Thomas

In that case, I'll note that i have quite a few Hebrew albums, And am willing to help test Unicode when needed.

Thanks for your offer!

How do I determine the length of a TAK file in seconds? I tested the file with the TAK winamp plugin and for both the TAK and the WAV file it shows a file duration of 1:06 meaning 66 seconds. If I run takc -fi to get the file duration I get 67 secs. Why is there a difference of 1 second?

C:\Program Files\TAK>takc -fi 08-Within_Temptation-Intro.tak
=== 08-Within_Temptation-Intro.tak ============================

File size: 6.18 MB
Header size: 0.42 KB
Compression: 54.85 %
Samples per channel: 2952936
File duration: 67.00 sec
Frame duration: 250 ms
Seek point interval: 1000 ms
Audio format: PCM, 44100 Hz, 16 Bits, 2 Channels
Encoder: V 1.0.1, Extra + Max
Wave file meta data: Header 44, Footer 0 Bytes
APEv2-Tag: Yes / 6 Items / 0.19 KB
Status: Ok

Rounding errors? Possibly Winamp is always truncating. Given your sample count and sample rate the correct length is 66.96 seconds. You may select the file in Winamp and open the file info dialog (provided by the TAK plugin). It should show you the fraction with 3 decimal places (digits) and should match this value.

Hm, TAK's file info function is reporting 67.00? Then i have done something wrong, this should be 66.96. I will look at it and fix it in the next version (I doubt, that it's urgent?).

No worries, I use shntool with the original wav files to create the file durations. but it would be nice to have the same results with takc.exe.

Is the format of TAK frozen?

I agree. I will correct the output of the file info function.


The container format is frozen, but new metadata structures may be added as happened with TAK 1.0.1, which introduced a metadata structure to hold encoder information.

But i plan to add new codecs in the future, for even more speed or higher compression. The container contains a numerical value which indicates the codec used for compression. A decoder has to check this value to select the appropriate codec; new codecs will require an update of the decoding library.

Codecs and container are clearly separated; even older decoders can scan for instance metadata and tags, but will not be capable to decode the audio data compressed with newer codecs.

I know that at this stage of things bit comparisons aren't particularly interesting anymore, but I'm about 2/3rds of the way through transcoding my old FLAC archives to TAK and just wanted to note that I just let foobar do a bit-compare of about 107 hours of music (about 40 gigs) and everything came back as no differences found. Going from FLAC 1.1.2 -8 to TAK -p5 has yielded some very impressive compression improvements as well, not surprisingly.

I've said it before and here again - thanks for a great codec, TBeck.

Will TAK have a Monkey's Audio's APL-liked metafile in the future?
I'd like to use metafile instead of cue files or writing tags directly to the compressed image in order to keep them clean and original.

Update 2007-04-25

TAK Decoding library 1.0.4 now is the officially recommended version. Users of foosions foobar plugin definitely should update to this version.

TAK SDK 1.0.2 still contains the Decoding library 1.0.2 but will be updated too soon. In the meantime it is recommended to manually replace the decoding dll in the SDK with the new version.

Update 2007-04-28

Replaced TAK SDK 1.0.2 with 1.0.3, which contains the TAK Decoding library 1.0.4 (instead of 1.0.2). No other changes.

Update 2007-05-15

Repaced the Winamp plugin 1.0.2 with 1.0.4, which fixes a bug when using the in_zip plugin.

is there a foobar output plugin planed?

foobar output plugins are a thing of the past.

All encoding is done by command line encoders, including the default presets.

NB: the 0.9 input component can be found here.

TBeck, can you add the ability for TAK files to store CD TOC files? If you need more information spoon (dBpoweramp) can give you more details.

thanks synthetic,

didnt know that.

err, how to integrate TAK with the command line?
i always get an error when encoding.
i put the following line into settings:
-e %d

I use "-e -p3 %s %d". I believe the p3 stands for preset 3 (High), You can change that if you want.

Stevie, you command has no source specified.

TAKC.EXE cannot yet accept input from STDIN, so you need to specify %s as the source (which means that foobar will create a tempory WAVE and then encode that file (%s).

As ChaosBladE has already stated, that means a syntax like:



Take a look at the TAK wiki page for more info, including a full explanation of setting up foobar.

thanks a lot guys, youre helpful as always!

Good work.
Can you develop TAK filter for Adobe Audition?

Any news about TAK for non-Windows users?
Back in mid March you (TBeck] mentioned that generating binaries for *nix was on your internal to do list. I have heard nothing about it since then, and wonder if its still on this list or if its currently being worked on...

Thanks!

You are the first one asking for this. Which means a very low priority on my to do list...


What happened since mid of march:

- i wrote a SDK and its documentation
- i coded TAK 1.0.1 and released it mid of april
- then i had nearly no time to work on TAK, nevertheless i released some bug fixes for the SDK and the Winamp plugin.

What i want to say: There was no time to work on any new features. And support for other platforms is not at the top of my to do list... (as mentioned earlier: not, because i don't want to do it, but because it means very much work. Other important items on my to do list are easier to do).

Thomas

Thanks for the fast reply!
I was hoping that you started looking into support for other platforms when TAK reached a stable stage (version 1.0.1). But I now understand that is belongs somewhere in the distant future... (2008 maybe?)

Until then.. Thanks!

Is it possible for you to release a static library version for decoding?

Is there a directshow splitter available?
This would be a good thing

I think that is largely because it is not widely implemented in other formats and people do not understand the benefits. The wiki lossless table should be expanded to show this feature. ATM only WMA supports this among lossless codecs. Hopefully, FLAC will soon support it as well. Basically it will make it much easier to go back and update metadata with this feature because most metadata services use the original CD TOC to find metadata. In addition, my understanding is that it should not be difficult to support, meaning that while maybe a low priority it should not take long.

hmmm any chance of making a rockbox plugin?

Good idea! I'd really appreciate it, if there would be some in the near future.

The header file "tak_dec_lib.h" should be modified like below:

So I can include this header file in different position for serval times.

BTW: Is it possible for you to release a static library verson?
and, you can update the .h header file to support loading tak_dec_lib.dll by developers through "LoadLibrary()" so that we can put the .dll file into other folders other than the local working directory.

2008 seems to be realistic.


I agree. Possibly you will have to wait until somebody else writes one based upon the SDK. Currently i don't intend to do it myself. But maybe i get interested into doing it sometime (if i want to see, if i can do it...).


To be honest: When i had read your post i first had to google a bit to find out, what the embedding of the CD TOC would be good for. Now it looks as if i understood it right.

Is there a standard for APEv2 to put it into? This would be the easiest way (no work for me). Otherwises i would have to integrate a new meta data structure in the TAK container. This is always much work; even if it's easy to code it always involves a lot of testing.


Probably not before a source code release, which means not in the near future (this year).


You are right. I often tend to forget this, because it isn't needed in Delphi Pascal...


Maybe someone else likes to do this for me? I am not too fast in C.


I doubt that it is possible. The library is written in Delphi Pascal and therefore using Delphi's runtime library. But sooner or later i will translate it to C, then no problem.

Thomas

I can have spoon email you the details. dBpoweramp is able to place raw CD TOC files into metadata, so he is a much better resource on what is required.

If you still need testers for this, I have a lot of Japanese, Chinese, Korean, and Thai albums. Plus some of the Japanese ones use other characters from other Unicode ranges like 𝄐, ∮, and ♥.

...

Hi, TBeck:
I'm using your tak decoder library for writing a decoder plug-in for a Media player.
I found that the "tak_SSD_Seek" always returned the fatal error "tak_res_ssd_Undecodable" whenever I invoked it.
Any idea about this situation?

Thank you! I will ask you for help when i work on Unicode support.


Great!


Not really.

1) Are you sure, that the files are intact? Can you decode them with the TAK applications? Because the TAK applications will not use the seektable you should also check if playback and seeking with other players (foobar and Winamp) is working.

2) Does at least sequential playback work with your plugin?

3) Are you using the TtakStreamIoInterface? It's easy to implement it wrong...


Thomas

Here is two pieces of my code
the Open decoder function:

and the Seek function


P.S. My "mediareader" only support read, seek, getlength, getcurpostion routines. I think it is not important for a decoder to support write function.

I know this has probably already been brought up by someone but... is any work being done to get Rockbox to play TAK files? I know TAK doesn't have the following of some of the other lossless codecs but man, it should. Anyway, just curious guys. Keep up the good work. Thanks.