TAK 1.1.0 Options

[TBeck]

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

This version brings support for 192 Khz Audio, seeking without seek table and some tiny speed improvements.

It consists of:

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

Download

Download the archive in the upload section: TAK 1.1.0 Final

What's new

New Features:

- Support for 192 Khz Audio.
- Seeking without seek table.

Improvements:

- Encoding and decoding speed improvements of about 3 percent for presets p0 and p1 on my system. Also some decoding speedup for p2.
- Fixed a bug in the encoder that resulted in suboptimal compression of some loud files and especially high resolution audio. Some files may gain about 0.05 percent of compression. Not much, but it comes without any speed penality.
- Further clean up of the Code.

Modifications:

-I hope you don't mind but i always had the feeling 5 presets are enough. Therefore i dropped the appropriately 'Insane' named preset -p5 and instead made presets 3 and 4 stronger. Okay, new -p4 will nevertheless be slightly weaker than old -p5, because i have reduced the maximum predictor count from 256 to 160. Before doing this i performed a detailed analysis of predictor count * compression * speed. There are not many files which benefit from such high predictor orders. Two of my file sets contain many of such files, but even they will only loose about 0.10 percent compression. Not a big loss if in exchange you get nearly half the decoding (cpu power) requirements.
- Removed option to modify the Prefilter sensitivity.

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

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

Have fun...

Thomas

This post has been edited by TBeck: Jan 6 2009, 14:53

[twistedddx]

SDK works fine for me

[gottkaiser]

Great work Thomas.
Thanks!

New Features:

- Support for 192 Khz Audio.
- Seeking without seek table.

Is there any speed penalty in seeking, if I'll won't use a seek table?

greetings

[Destroid]

Using -sts0 (seek table size = zero) has no noticeable delay whenever I randomly seek within a file.

Using P3 733 with FB2k.

edit: "noticeable delay" meaning comparatively to other audio formats, all seeking on system has small lag

This post has been edited by Destroid: Jan 5 2009, 21:49

[TBeck]

SDK works fine for me

Nice to hear that someone is using it.

...
Is there any speed penalty in seeking, if I'll won't use a seek table?

Using -sts0 (seek table size = zero) has no noticeable delay whenever I randomly seek within a file.

Using P3 733 with FB2k.

edit: "noticeable delay" meaning comparatively to other audio formats, all seeking on system has small lag

And so shall it be...

Seeking without seek table requires some more seek and read operations from the storage device and some very fast check sum caclculations which have to be performed by the CPU. The latter is very unlikely to have a significant effect even on quite slow cpus.

The additional io-requests can be noticeable if your storage device is very slow, for instance a cd-rom drive with slow random seek and/or untypically low data transfer rates. Possibly a very slow usb-stick could also cause a noticeable delay.

Hard disk based playback should be equally fast with and without see table.

The decoder wil also build an internal seek table while you are playing the file. Seeks to audio parts that alreday have been played can use this table.

The worst case with the highest seek times is defined as follows:

- The storage medium is slow.
- The file isn't in the os file cache.
- You start the playback and immediately jump to a position in the second half or close to the end of the file.

Thomas

This post has been edited by TBeck: Jan 6 2009, 15:26

[jido]

Congratulations for this release!

Any words of a decoder for non-Windows platforms?

[gottkaiser]

@Thomas
It is already possible to add cover art to the APE tags in the TAK files with Mp3tag. Would it be a big effort to add support to read them with the winamp plugin?
then here wouldn't be any disadvantage over the other formats in Winamp.

greetings

This post has been edited by gottkaiser: Jan 9 2009, 21:42

[hamasaki]

wow.really nice update.30% of my music CDz are backed up in tak format.
so,how could I get my foobar component update for those new feature?

[lvqcl]

wow.really nice update.30% of my music CDz are backed up in tak format.
so,how could I get my foobar component update for those new feature?

Current plugin should work. Just update tak_deco_lib.dll in foobar2000 folder.

[Neasden]

Silly question...

Can TAK re-encode itself off previous TAK version?
Something like takc.exe -e file.tak

[fillip]

I just transcoded 3.84GB (774kbps TAK 1.0.3/1.0.4 -pMax) to 3.84GB (774kbps TAK 1.1.0 -pMax) and saved 1047KB! This sentence may seem sarcastic, but the fact given, that it's actually a weaker setting it's quite impressive, isn't it? I have to try to keep track of the other transcodings, still more than 400GB to go

[Synthetic Soul]

Silly question...

Can TAK re-encode itself off previous TAK version?
Something like takc.exe -e file.tak

I think it's a good question, but it is easy to test, and therefore a lazy question.

I get "Command line error: invalid file extension" when trying to encode a .tak file.

I think this would be a welcome addition. As takc.exe can decode as well as encode I presume it would not be a mammoth task to include.

[Neasden]

I think it's a good question, but it is easy to test, and therefore a lazy question.

You got it right! Call that lazy...

[Antonski]

I think this would be a welcome addition. As takc.exe can decode as well as encode I presume it would not be a mammoth task to include.

Isn't it possible to pipe the takc output to another instance of takc? It should be possible to run multiple instances?
~

[Synthetic Soul]

True. Once takc.exe supports writing tags though it would be nice if tag data was just copied across. If you decode one file and pipe it to takc.exe all tags will be lost.

Of course, you could use Case's Tag to copy the tags from one to the other.

[TBeck]

Any words of a decoder for non-Windows platforms?

For now only the hint, that TAK is known to work with wine...

It is already possible to add cover art to the APE tags in the TAK files with Mp3tag. Would it be a big effort to add support to read them with the winamp plugin?

I think i would have to to use the new winamp plugin interface to provide access to binary data, but i am not really sure. If so, it would be a considerable amount of work. But at some point i will do it. BTW: A developer could use my decoder library to write a winamp plugin.

I just transcoded 3.84GB (774kbps TAK 1.0.3/1.0.4 -pMax) to 3.84GB (774kbps TAK 1.1.0 -pMax) and saved 1047KB! This sentence may seem sarcastic, but the fact given, that it's actually a weaker setting it's quite impressive, isn't it? I have to try to keep track of the other transcodings, still more than 400GB to go

That's nice!

Silly question...

Can TAK re-encode itself off previous TAK version?
Something like takc.exe -e file.tak

I think it's a good question, but it is easy to test, and therefore a lazy question.

I get "Command line error: invalid file extension" when trying to encode a .tak file.

I think this would be a welcome addition. As takc.exe can decode as well as encode I presume it would not be a mammoth task to include.

I think this would be a welcome addition. As takc.exe can decode as well as encode I presume it would not be a mammoth task to include.

Isn't it possible to pipe the takc output to another instance of takc? It should be possible to run multiple instances?
~

I am not really sure if an internal transcoding mode in TAK would be advantegous. It won't be faster than the foobar approach.

Please tell me, why i should add a transcoding mode. Is it because of the tags? Wouldn't foobar copy them?

To be honest, i myself am not performing a lot of audio processing, therefore i don't know much about those issues...

Thomas

[Synthetic Soul]

Foobar could do the job.

For my part, I thought that having this ability inbuilt to the TAK encoder would mean that command line users could easily upgrade their TAK collection to the latest version, as and when major versions bring major benefits. It's almost like TAK taking care of its own. FLAC 1.1.3 introduced this feature, and it just seemed to make sense to me: that an encoder can understand its own format, and save time for existing users to move their files from an older version to the latest, possibly helping resolve backward-compatibility issues with major releases.

Not a major issue for me though, by any means.

[Neasden]

Sythetic Soul said everything... I really like this ability to upgrade a huge collection with one command line through a script... It becomes painful if you need to convert to WAV before, and lose the tags.

[Neasden]

It is already possible to add cover art to the APE tags in the TAK files with Mp3tag. Would it be a big effort to add support to read them with the winamp plugin?
then here wouldn't be any disadvantage over the other formats in Winamp.

greetings

If you don't mind switching, foobar2000 already displays TAK+APEv2+Cover

To let you know... I am dropping FLAC today, doing a mass conversion of files to new TAK!
Let the future come...

Some of TAK highlights at the moment for me:
- FB2k transcoding TAK/2 to TAK/2 is dead fast on my machine, and that not using pipe encoding.
- Adding album art does not re-write the entire TAK file because I assume it places the metadata at the end of the file. With FLAC, if there's not enough padding, the entire file gets re-written on disc (spending up to 3 seconds to get written on a SATAII/7.200rpm disc and probably more time on slower hard drives.) Removing art also cleanses the space occupied, whereas FLAC file will remain the same size because padding space won't go away automatically.

I tested that when FB2k transcodes TAK to TAK, it will transfer tags but won't transfer embedded cover art and replaygain values.
Is there any way to keep all metadata by using FB2k???

This post has been edited by Neasden: Jan 16 2009, 02:02

[Dologan]

Wow, great news! Thanks a lot, Thomas!

[DOS386]

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

Very good, faster and better compression (minimal test so far)

Sadly there are files giving much worse compression with -pmax than default ... problem exists in 1.0.4 already:

CODE

01/15/2009  03:21  31,705,004 p.wav

>t -e p.wav
p.wav                               ..........  20.85%   21*

Compression:     20.85 %
Duration:         8.72 sec
Speed:           20.61 * real time

>t -e -pmax p.wav
p.wav                               ..........  22.73%    4*

Compression:     22.73 %
Duration:        42.64 sec
Speed:            4.22 * real time

>t -d p.tak
p.tak                               ..........   51* Ok

Duration:        3.52 sec
Speed:          51.03 * real time

01/15/2009  03:23  6,609,076 pdef.tak
01/15/2009  03:24  7,207,262 p.tak

>t4 -e p.wav  
p.wav                               ..........  20.85%   30*

Compression:     20.85 %
Duration:         5.92 sec
Speed:           30.36 * real time

>t4 -e -pmax p.wav
p.wav                               ..........  22.74%    3*

Compression:     22.74 %
Duration:        68.05 sec
Speed:            2.64 * real time

>t4 -d p.tak
p.tak                               ..........   29* Ok

Duration:        6.11 sec
Speed:          29.44 * real time

01/15/2009  03:24   6,610,883 pdef.tak
01/15/2009  03:25   7,209,408 p.tak

T is 1.0.10 and T4 is 1.0.4
pdef.tak is default and p.tak is -pmax


A few minor things:

- © is expired
- Screenshots are bloated, could be 3 times smaller (this is about very best compression, isn't ?)
- Package is bloated, could be 2 times smaller (still, one package onlyis good, add decoder source one day also? )

This post has been edited by DOS386: Jan 16 2009, 15:44

[gottkaiser]

I tested that when FB2k transcodes TAK to TAK, it will transfer tags but won't transfer embedded cover art and replaygain values.
Is there any way to keep all metadata by using FB2k???

Thats what I was asking in the foobar2000 forum. right here.
But no developer replied. :-/

greatings

[TBeck]

Sadly there are files giving much worse compression with -pmax than default ... problem exists in 1.0.4 already:

Good timing! I am just working on a new encoder option in TAK 1.1.1 to minimize such (usually rare) problems...

Could you please send me 2 to 3 second snippets (which show the misbehaviour) of one or more of your problem files? I would be happy to use them to test the new method!

Thomas

[DOS386]

> new encoder option in TAK 1.1.1 to minimize such (usually rare) problems...

IMHO SEVERE problem ... the "very best" compression is much worse

> Could you please send

Done !

[Synthetic Soul]

Surely a "severe problem" would be near-zero percent compression, lossy encoding, or a complete lack of error tolerance?

A few more MiB in your collection... "severe"? I suppose it depends on how rare "rare" is.

Edit: FYI I Just checked my comparison and none of the fifty files suffer from this. Obviously this doesn't prove a whole lot, but it does indicate to me that the issue is not normal.

Fixed a bug in the encoder that resulted in suboptimal compression of some loud files and especially high resolution audio. Some files may gain about 0.05 percent of compression. Not much, but it comes without any speed penality.

Thomas, is this issue related to the above, or is it something totally unrelated? Apologies if this has been done a thousand times before.

This post has been edited by Synthetic Soul: Jan 17 2009, 20:18