Beta release 1 of TAK 1.0.3 ((T)om's lossless (A)udio (K)ompressor)
It consists of:
- TAK Applications 1.0.3
- TAK Winamp plugin 1.0.7.
- TAK SDK 1.0.5.
- TAK Decoding library 1.0.6.
Download links removed. The final version (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=59711&view=findpost&p=535589) is out.
1. TAK Applications 1.0.3
containing the GUI and command line compressor:
2. TAK Winamp plugin 1.0.7
containing the playback plugin for Winamp:
3. TAK SDK 1.0.5
containing the SDK documentation and the decoding library dll for developers:
4. TAK Decoding library 1.0.6
containing only the decoding library dll which is part of the SDK. It's provided for end users using third-party applications utilizing the library, who want to update the library to the current version:
What's new
What's new in the Applications
New Features:
- Support for pipe encoding.
- New command line switch -ihs (ignore header size) for pipe encoding.
- New command line option -sts (set seek table size) for pipe encoding.
- New command line switch -silent (silent operation).
- The command line option -wm now let's you specify a maximum size for the wave meta data.
- New command line switch -pMax to select the strongest encoder preset.
- The file info function shows you how much space (if any) in the header is beeing wasted because of pipe encoding.
Improvements:
- Tiny compression improvements for the presets 0 to 2, rarely also for the stronger presets. The average improvement for my test corpus is about 0.05 percent. Not much, but it comes without a significant speed penality.
- Small decoding speed improvements of 4 (preset 5) to 8 (preset 0) percent on my system.
- The Readme file now contains a simple contents section with links to the most relevant topics. There is also a new section about pipe encoding. If you want to use it, please read the text...
Modifications:
- The decoder had to be modified to guarantee error robustness (decoding through errors) for files created by pipe encoding with the -ihs (ignore header size) switch applied.
- Some modifications of the decoding error log file ("Tak_Deco_Error.txt").
- In TAK 1.0.2 there was no difference between the presets -p4/p4e and -p5/-p5e. This irritated some users. Now they are slightly different.
- Command line: The alternative syntax (-pT to -pI) for the preset specification is no longer supported. Now -p0 to -p5 is obligatory.
- GUI: The buttons for preset and evaluation level selection have been removed from the encoder options dialog. Please use the comparison table instead.
- GUI: Moved the Verify switch from the general encoder options to the details dialog.
- GUI: The Save wave file meta data switch has been removed from the encoder output options sheet. Please use the Wave file meta data - Maximum Size setting on the stream options sheet instead.
- Because of an update of my Delphi compiler the binaries are now about 35 KB bigger.
Fixed:
- Some applications crashed if they tried to redirect the output of the command line version. This seems to have been caused by a bug in the Delphi runtime library. Now i am accessing the console directly, what hopefully avoids this trouble.
What's new in the encoder/decoder library (affecting the applications, the decoding library and the Winamp plugin):
Modifications:
- The decoder had to be modified to guarantee error robustness (decoding through errors) for files created by pipe encoding with the -ihs (ignore header size) switch applied.
What's new in the SDK (compared to 1.0.4):
Interface changes (Adaptions for TAK 1.0.3):
- The tak_Preset_xxx-constants have been removed from the include files. TAK's presets are now named purely numerical (no more Turbo, Fast...).
Beta testing
The beta version has already gone through extensive testing performed by my automatic scripts. But especially because of the many changes for 1.0.3 rare bugs are still possible (as always...). Please try the beta release and report any bugs in this thread.
I would also be happy about tests of compression efficiency and speed. Because the final release will have identical performance (there may be a speed variation of 1 to 3 percent because of different code alignment of another build), it does make sense to test the beta.
Thanks for testing and have fun
Thomas
Thank you! I'm too stupid for the fb2k commandline (pipe encoding). My latest try was:
takc -e -p5m -ihs -sts3 - %d
but I always end in "Encoder has terminated prematurely with code 1".
Thank you! I'm too stupid for the fb2k commandline (pipe encoding). My latest try was:
takc -e -p5m -ihs -sts3 - %d
but I always end in "Encoder has terminated prematurely with code 1".
Good try! This should work. Ok, i don't know much about the foobar part.
Exit code 1 means wrong parameters. Don't know why.
Can you please try to remove the -sts3?
Thomas
Thank you! I'm too stupid for the fb2k commandline (pipe encoding). My latest try was:
takc -e -p5m -ihs -sts3 - %d
but I always end in "Encoder has terminated prematurely with code 1".
I just tried this setting. No problem...
Could it be that you haven't set the file extension to "tak" in foobar's preset configuration dialog?
Works well for me too. This the setting i'm using:
(http://img505.imageshack.us/img505/5209/screenbt4.png)
Congratulations to TBeck on this awesome release! Thanks for your work on TAK.
Edit: I get an error when using -pMax (error code 1) but it works perfectly when using -pmax. You might want to update your first post where you have announced -pMax.
Encoder: takc.exe
Extension: TAK
Parameters: takc[/s] -e -p5m -ihs -sts3 - %d
Strange. Same settings as kanak. This does not work here. I checked twice if I use the correct new takc.exe. I do.
EDIT: AAAARGGGG! See the bold formatted above!
don't put that "takc" part in the beginning of your parameter.
simply use:
-e -p5m -ihs -sts3 - %d
Try removing "takc" from the parameters.
Just saw it myself. This is because I simply copied/pasted from the readme.html. TBeck, maybe you add a working fb2k command line to the readme, to prevent idiots like me
Edit: I get an error when using -pMax (error code 1) but it works perfectly when using -pmax. You might want to update your first post where you have announced -pMax.
Hm, i can't reproduce this.
Just saw it myself. This is because I simply copied/pasted from the readme.html. TBeck, maybe you add a working fb2k command line to the readme, to prevent idiots like me
Very good idea! And a screenshot too!
Sorry for the trouble caused by my incomplete documentation.
Thomas
I thought the sps option will cause us headache. But I tried sps3 on a 60 minutes track; there's no significant delay when seeking through the file on a 3 yrs old computer. Which is good I remember the good old days with mpc slow seeking problem where seeking took a couple of seconds...
New Features:
- Support for pipe encoding.
As expected, this works with shntool:
shntool conv -o "cust ext=tak takc -e -ihs - %f" ...
Of course you can add parameters to taste. I will add support for TAK encoding in the next version. What would you all suggest I use for default encoding parameters?
Now, for pipe decoding...
Thanks Thomas for your hard work!
Now, for pipe decoding...
This would definitely make a few of us command line nuts happy.
Until my rippers are able to provide stdout to TAK (or can dBpa already handle this? EAC cannot) the only piping I'd be doing would go in the other direction.
I thought the sps option will cause us headache. But I tried sps3 on a 60 minutes track; there's no significant delay when seeking through the file on a 3 yrs old computer. Which is good I remember the good old days with mpc slow seeking problem where seeking took a couple of seconds...
Nice news. Thanks for testing!
From the Readme file:
"Some recommendations:
- For hard disk based playback you may choose a seek table size as small as about 1/16 of the audio duration without experiencing a significant delay when seeking. Therefore the default size of 5 minutes may be sufficient for a audio duration of up to 80 minutes.
- If you manually decrease the frame size (for the LossyWav-preprocessor) you are not advised to choose a value which is less than about 1/4 of the audio duration! "
With -sts3 for a 60 minutes file you are a bit outside of the recommendations, because 60 > 48 (3 * 16).
That's still ok (unless you are compressing LossyWav-files) but if the audio duration/seektable size- ratio get's considerably bigger seeking will suddenly get very slow!
I will possibly increase the minimum seektable size to 10 minutes for the final version. You won't loose much compression efficiency.
The following table illustrates this. It shows you how much compression you will loose if compressing 3 minutes of cd audio data with different seek table sizes:
-sts# Loss %
3 0.000
5 0.002
10 0.007
15 0.009
30 0.026
60 0.054
Up to 15 minutes it's less than 0.01 percent.
I will add support for TAK encoding in the next version.
Great! Thank you!
Now, for pipe decoding...
Thomas
I can't seem to replicate the pMax problem either ... i guess it was just a fluke or something.
Anyway, i have a question regarding the sts option. Other than the loss of compression efficiency, is there any problem in using say -sts60 for all files? I ask because i want to have a single tak preset that i can use on all files... i'm willing to sacrifice the tiny amount of compression for this.
I can't seem to replicate the pMax problem either ... i guess it was just a fluke or something.
Fine.
Anyway, i have a question regarding the sts option. Other than the loss of compression efficiency, is there any problem in using say -sts60 for all files? I ask because i want to have a single tak preset that i can use on all files... i'm willing to sacrifice the tiny amount of compression for this.
I will rework the relevant part of the pipe encoding section of my manual and post it here. Hopefully it will make some topics more clear. I myself have to think a bit more about it...
For now a short answer: Personally i would use -sts10 for such an all-in-one setting (single short songs and cd images of up to about 80 minutes). I should make this the default...
Thomas
I encoded a 68 minutes song with sts3 and didn't even recognize any delay when seeking through the song over long distances.
IMO you can simply make 10 the default, and there's btw no need to promote the sts option in the documentation too loud.
Thanks for this release TBeck!
Seemed like old version of decoder 1.0.2 had a problem with detection of optimizations in foobar. Last updated 1.0.2 is faster. And 1.0.3 is still faster 5-6% here for p0.
Now transcoding from TAK p0 to mp3 take the same time as from FLAC for single cpu P4 class via foobar.
Great update. Thank you.
Thomas, I just want to tell you that I appreciate your efforts to make the TAK better.
Excellent work!
So open source for the next 1.0.4 release, right?
And maybe when that happens we'll all rejoice when we see an Audition/Cool Edit plugin! Regardless, great work with this!
So open source for the next 1.0.4 release, right?
It will be nice, because I still dreaming about TAK hardware support on Cowon PMP
1.0.3b1 encoding nicely with more or less default parameters, using stdin, on my AMD x2. Stdin is much appreciated.
Not to create work, but I wonder how much would be involved in the log file reporting encoding time as a factor of playback time. %02 - whatever
Thanks
Wow! Thank you Thomas for your amazing work!
I'm rethinking about using foobar as my complete tool (playing & ripping), so far EAC did the ripping job.
the pipes work only in one-way direction, right ?
Anyway, i have a question regarding the sts option. Other than the loss of compression efficiency, is there any problem in using say -sts60 for all files? I ask because i want to have a single tak preset that i can use on all files... i'm willing to sacrifice the tiny amount of compression for this.
I will rework the relevant part of the pipe encoding section of my manual and post it here. Hopefully it will make some topics more clear. I myself have to think a bit more about it...
For now a short answer: Personally i would use -sts10 for such an all-in-one setting (single short songs and cd images of up to about 80 minutes). I should make this the default...
I encoded a 68 minutes song with sts3 and didn't even recognize any delay when seeking through the song over long distances.
IMO you can simply make 10 the default, and there's btw no need to promote the sts option in the documentation too loud.
The default is now 10 minutes and this setting is recommended for an audio duration of about 1 to 80 minutes.
And here is the updated section of my manual:
Adaptions for very short or long audio dataTAK has to reserve about 5 bytes for each seek point in the seek table, which facilitates fast seeking on playback. By default one seek point is created per 1 second of audio data. If the audio length is not known in advance (that's when you have to specify the -ihs switch), the seek table size can not be exactly calculated. Again some space has to be reserved which in the end may be too big or too small.
By default a seek table for 10 minutes is beeing created. Because it requires very little space and TAK can also compress it to cope with longer files, the default setting is fine for audio files with a duration of about 1 to 80 minutes.
If you are dealing with very short files (less than 1 minute), you may use the set-seek-table-size option to set the seek table size to the minimum:
takc -e -ihs -sts3 - Outfile
reserves space for a seek table containing seek points for 3 minutes of audio data.
If you are dealing with very long files (more than about 80 minutes), you are advised to increase the seek table size. It should never be less than about 1/8 of the audio duration, otherwise seeking may get very slow.
Some example: For 300 minutes of audio data you should manually set the seek table size to 300 / 8 = 38 minutes:
takc -e -ihs -sts38 - Outfile
I hope this is better/more clear.
Thomas
Not to create work, but I wonder how much would be involved in the log file reporting encoding time as a factor of playback time. %02 - whatever
I am not sure, what you mean. The log file already contains the encoding rate defined as a multiple of the realtime/audio duration. Add two zeros and you have it in percent...
the pipes work only in one-way direction, right ?
I am not sure if i understand you right, but currently it is not possible to simultaneously read (the data to compress) and write ( the compressed data) from/to a pipe.
Thomas
I think the question was more whether TAK could read from STDIN (encoding) but not write to STDOUT (decoding).
I believe it can write to STDOUT already, or at least it seems that way when I transcode from TAK to MP3 in Foobar2000. It just transcodes directly between the two for me.
sorry, i meant exactly that, simultaneous use of both stdin and stdout, and it was kind of 'negative' question
(and foobar2000 here is another story)
thanks for the answer.
Thanks for all the encouraging words! They are very much appreciated.
I intend to release the final version on thursday or friday. If you have found any bugs in the beta, please tell me now.
So far it looks as if there will be only modification for the final release:
- Change the default seek table size for pipe encoding with the -ihs switch applied to 10 minutes.
Thanks for testing!
Thomas
I believe it can write to STDOUT already, or at least it seems that way when I transcode from TAK to MP3 in Foobar2000. It just transcodes directly between the two for me.
As Thomas has already indicated, takc does not decode to stdout, regardless...
Great work Thomas!
Is "ihs" syntax could cause tak file have no bit identically in pipe encoding?
I think that syntax mean that encoder will generate a track durations data(samples) and not to care about the source file's track durations data. Than original wave file's track duration's data will not the same to that encoded tak file.
Is "ihs" syntax could cause tak file have no bit identically in pipe encoding?
No. It is for seeking purposes.
im confused about how to get the files to play in foobar. i encoded some files to tak using "-e -ihs -pMax - %d" and that worked fine, but foobar wont play the files. i tried putting the tak_deco_lib.dll in the components folder, and when that didn't work i placed the DLL in the foobar folder and it still didn't work. what am i doing wrong?
im confused about how to get the files to play in foobar. i encoded some files to tak using "-e -ihs -pMax - %d" and that worked fine, but foobar wont play the files. i tried putting the tak_deco_lib.dll in the components folder, and when that didn't work i placed the DLL in the foobar folder and it still didn't work. what am i doing wrong?
You need to put the tak_deco_lib.dll in foobar folder, and put Foosion's TAK plugin (http://www.hydrogenaudio.org/forums/index.php?showtopic=54087) in the components plugin. (the tak deco lib that comes with foosion's zip file is older than the one linked here).
ok, i got it working, thanks!
The only threshold right now to go over to TAK completely is the support, when can we expect Linux support ?
What's the default/recommended setting for the frame size limit? Also, I'm wondering what the recommended command-line setting now when using wapet.exe? Any switch that needs to be added for pipe-encoding or something?
What's the default/recommended setting for the frame size limit?
That's easy: Please don't touch it...
From the readme:
"There is only one situation where you are adviced to change the frame size limit: If you want to encode files generated by the high quality LossyWav- preprocessor, Tak's frame size has to match the preprocessors frame size (usually 512 samples)."
Thomas
That's easy: Please don't touch it...
From the readme:
"There is only one situation where you are adviced to change the frame size limit: If you want to encode files generated by the high quality LossyWav- preprocessor, Tak's frame size has to match the preprocessors frame size (usually 512 samples)."
Thomas
Yeah, I got that, it's just that in the example picture you included, it's set at 4096, whereas my default is at 8192.