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 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=68456&view=findpost&p=607828)
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 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=68104&view=findpost&p=605269).
Plans for V1.1.1
I will soon open a thread for the TAK 1.1.1 development.
Have fun...
Thomas
SDK works fine for me
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
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
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
Congratulations for this release!
Any words of a decoder for non-Windows platforms?
@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
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?
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.
Silly question...
Can TAK re-encode itself off previous TAK version?
Something like takc.exe -e file.tak
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
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 it's a good question, but it is easy to test, and therefore a lazy question.
You got it right! Call that lazy...
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?
~
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.
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
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.
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.
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???
Wow, great news! Thanks a lot, Thomas!
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:
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
-pmaxA 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? )
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 (http://www.hydrogenaudio.org/forums/index.php?showtopic=68472).
But no developer replied. :-/
greatings
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
> 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 !
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.
> Could you please send
Done !
Thank you!
I have tested it with TAK 1.1.0 and TAK 1.1.1 Alpha. Here are the compression results:
Preset V1.1.0 V1.1.1 Option
------------------------------------
-p2 20.85 20.85 off
-p2e 19.36 19.30 on
-p2m 19.15 19.07 on
-p3 22.83 22.83 off
-p3e 22.71 19.48 on
-p3m 22.68 19.40 on
-p4 22.77 19.61 on
-p4e 22.74 19.49 on
-p4m 22.73 19.43 on
------------------------------------
As you can see, the presets with the new encoder option activated are performing much better.
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.
It's indeed a very rare problem. The file DOS386 sent me definitely comes from a heavily lossy compressed source. You can easily hear some flanging artifacts.
Because the new encoder option on average does not improve the compression by more than about 0.05 percent (zero for some file sets and probably your one will be among them...), i would usually activate it only in the maximum evaluation levels (-pXm), but since it is operating quite fast, it seemed to be sensible to add it also to the extra evaluation levels (-pXe) of the higher presets.
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.
Thank you for reading my release notes!
No, it has to do with the PreFilter option introduced in YALAC 0.07 or so. You may remember...
Sometimes the PreFilter is beeing used although it does badly affect the compression efficiency. The new encoder option can prevent this most of the time. It also helps a bit outside of the PreFilter issues.
Thomas
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.
Thank you for reading my release notes!
I hope, you didn't get this wrong. It was only meant as a compliment!
Thomas
I hope, you didn't get this wrong. It was only meant as a compliment!
No, not at all Thomas; I understood your meaning.
No, it has to do with the PreFilter option introduced in YALAC 0.07 or so. You may remember...
Sometimes the PreFilter is beeing used although it does badly affect the compression efficiency. The new encoder option can prevent this most of the time. It also helps a bit outside of the PreFilter issues.
Actually I do have a very vague recollection of your pre-filter testing. It seems so long ago...
Thanks for the explanation.
New Features:
- Support for 192 Khz Audio.
Many thanks to Stephan Busch for testing TAK 1.1.0 in his Squeeze Chart 2009 (http://www.squeezechart.com/)!
Here an excerpt of his 24 Bit / 192 KHz Comparison:
Codec Compression %
-------------------------------------------------------------------
OptimFrog v4.600ex (26.06.'06) -max. -experimental 33,20
TAK 1.1.0 (04.01.2009) -p5m Thomas Becker 34,18
WAVPACK v4.42a (08.09.'07) -HHX6 34,29
Monkey's Audio v4.01b2 (GUI) (28.04.06) (insane) 34,49
TTA TrueAudio 3.4.1 (27.07.'07) Alexander Djourik 36,14
FLAC 1.2.1 (17.09.07) Josh Coalson -8 -b 4096 39,14
-------------------------------------------------------------------
Not too bad for TAK
-p5m ? Must be -p4m I suppose.
-p5m ? Must be -p4m I suppose.
You are right. But for backwards compatibility V1.1.0 will map -p5x to -p4x. Therefore -p5m and -p4m are identical.
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.
Tested 2 files a one gave a very bad result.
I have tested it with TAK 1.1.0 and TAK 1.1.1 Alpha. Here are the compression results:
As you can see, the presets with the new encoder option activated are performing much better.
I see ... much better, still the higher compression effort gives (now marginally) worse compression success.
It's indeed a very rare problem. The file definitely comes from a heavily lossy compressed source. You can easily hear some flanging artifacts.
1.3 MiB OGG Vorbis, but probably irrelevant: the thing is cca 80 years old so cca 75 of them it most likely spent on a black PVC disk, and captured the artifacts there
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.
Tested 2 files a one gave a very bad result.
Are you suggesting that this will occur 50% of the time with your collection? Do you think it may be prudent to test a larger corpus and report some figures from that?
I'll admit that your limited results look concerning, but personally I would have been very keen to try to gauge a more accurate percentage from a decent selection of my collection. Your findings may be very useful to Thomas, and other TAK users.