Final release of TAK 2.2.0 ((T)om's lossless (A)udio (K)ompressor)
This release brings support for multi-channel audio and speed optimizations for encoder and decoder.
It consists of:
- TAK Applications 2.2.0.
- TAK Winamp plugin 2.2.0.
- TAK SDK 1.1.1.
- TAK Decoding library 2.2.0.
Download[attachment=6596:TAK_2.2.0.zip]
What's newNew features:
- Support for multi-channel audio. While the stream format supports up to 16 channels, the codec currently is restricted to a maximum of 6 channels.
- Support for the "Wave Format Extensible" file format.
Improvements:
- Encoding speed improvements of up to 10 percent for my primary file set. Most of it is achieved by a modification of the algorithm which selects the optimal predictor order for each subframe. It will now often use less predictors than before, what may on average result in about 0.01 percent worse compression. You will only notice an advantage, if your files benefit from high predictor orders.
- Decoding speed improvements of up to 18 percent for my primary file set. Some of it is attributed to the above-noted modification of the encoder's predictor order selection algorithm. Therefore it will only take effect when decoding files encoded with this version and only, if they benefit from high predictor orders. Additionally SSSE3-instructions can be used for predictor counts of 32 and more. This affects the presets p3, p4 and sometimes p2, but only, if a particular file benefits from high predictor orders.
Fixes:
- The wave file reader reported an error if a file contained additional (meta) data following the audio data.
- The wave file writer didn't add an optional zero byte to make the audio data chunk size a multiple of 2. This was only relevant when decoding mono audio with 8- or 24-bit samples without restoring the wave meta data (-wm0 applied on encoding and/or decoding).
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 informationYou can find some useful information and comparisons in the Alpha thread (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=88968&view=findpost&p=758341).
Have fun...
Thomas
I took the freedom to compile an excerpt of the extensive compression results which m² has posted in the Alpha thread (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=88968&view=findpost&p=762766).
His notes:
All samples come from DVD-A discs and are 5.1
Albums:
Sting - Brand New Day (samples d*, r*), 24/48
Nightwish - Dark Passion Play (a*), 24/48
Ton Koopman - Bach: Organ Spectacular (t*), 24/96
Foreigner - 4 (u*, v*, w*), 24/96
Codecs:
als rm23 (-7, other switches as indicated)
flake SVN r264 (-12)
wavpack 4.60.1
ttaenc 3.4.1
tak 2.2.0 (-p4m -wm0)
The 24/48 results:
a0 a1 a3 a4 d0 d2 d3 d4 d5 d6 r0 r1 r2 r3
WavPack -hx4 58,88 66,86 60,53 67,12 33,08 39,28 48,57 48,81 47,97 52,46 41,06 49,60 52,68 52,42
WavPack -hx6 58,84 66,86 60,49 67,12 32,98 39,07 48,18 47,98 47,40 51,61 40,84 48,79 51,63 51,52
WavPack -hhx6 58,79 66,83 60,44 67,09 32,76 38,79 47,74 47,58 47,09 51,12 40,51 48,37 51,18 51,07
Flake -12 58,33 66,01 60,25 66,25 32,82 37,46 47,63 47,59 46,96 50,97 40,77 48,45 51,11 51,16
TTA 65,76 74,80 66,77 74,94 51,35 55,96 67,49 66,45 66,50 71,47 63,61 70,14 72,08 73,33
TAK -p4m 56,78 64,59 58,36 64,93 30,79 34,68 44,71 43,74 44,20 47,94 37,92 45,99 47,80 49,42
Als -7 -o160 -t6 56,61 64,45 58,23 64,78 30,52 34,24 44,44 44,02 43,84 47,85 38,30 46,02 47,89 48,87
Als -7 -o1023 -t6 56,43 64,37 58,13 64,72 30,18 33,99 44,43 43,99 43,78 47,84 38,25 45,98 47,83 48,79
Als -z3 -t6 57,55 65,68 59,62 65,89 42,89 47,52 58,93 57,99 57,91 61,81 50,45 59,03 61,46 63,11
Compression ratio expressed as percentage of the original size.
The 24/96 results:
t0 t1 t2 t3 u0 u1 u2 u3 v0 v1 w0 w1 w2 w3 w4
WavPack -hx4 47,91 48,00 46,94 48,16 58,05 59,77 59,43 60,70 47,34 55,27 50,10 57,34 59,08 60,37 61,71
WavPack -hx6 47,89 47,99 46,94 48,16 57,97 59,69 59,33 60,57 47,23 55,22 50,00 57,26 58,98 60,31 61,68
WavPack -hhx6 47,88 47,97 46,93 48,16 57,32 59,11 58,77 59,92 46,66 54,70 49,49 56,86 58,52 59,92 61,37
Flake -12 47,73 47,87 46,96 48,21 56,79 58,62 58,18 59,36 46,01 53,91 48,81 55,89 57,48 59,00 60,81
TTA 49,61 49,66 48,69 49,87 66,98 69,26 68,71 70,62 55,04 63,73 59,10 66,16 67,55 69,29 71,25
TAK -p4m 42,80 43,10 41,94 43,01 55,73 57,72 57,33 58,46 45,23 52,62 47,82 54,92 56,30 57,94 59,95
Als -7 -o160 -t6 45,60 46,03 45,01 45,98 54,97 56,91 56,34 57,43 44,97 52,18 47,63 54,40 55,65 57,22 59,07
Als -7 -o511 -t6 45,26 45,76 44,78 45,53 54,97 56,91 56,34 57,42 44,94 52,19 47,27 54,36 55,65 57,17 59,05
Als -z3 -t6 41,22 41,96 41,07 41,92 60,96 62,86 62,30 63,24 50,94 58,03 53,28 60,33 61,66 63,11 64,85
m²'s comment:
Generally, TAK looses to ALS, but is rocket fast.
I haven't decided which one do I want to use yet...Really, I expected TAK to do better.
I feel quite comfortable with your results.
For the 24/48 samples the performance of TAK -p4m is quite similar to Als -7 -o160 -t6. TAK compresses the t-set of the 24/96 samples better than Als -7 -o160 -t6, but indeed looses on the Foreigner 4 samples u, v and w.
Would it be possible to send me one or two 30 second snippets of the Foreigner files, where ALS's advantage manifests? I would like to look for tuning opportunities.
BTW: Thank you very much for such an extensive evaluation!
Thomas
Would it be possible to send me one or two 30 second snippets of the Foreigner files, where ALS's advantage manifests? I would like to look for tuning opportunities.
No problem. Will do it later today.
Would it be possible to send me one or two 30 second snippets of the Foreigner files, where ALS's advantage manifests? I would like to look for tuning opportunities.
No problem. Will do it later today.
BTW by 'ALS's advantage' do you mean o160 or o512? For my purposes I compare to the latter, but can check with either.
BTW by 'ALS's advantage' do you mean o160 or o512? For my purposes I compare to the latter, but can check with either.
I don't think TAK's worse performance has to be attributed to ALS's higher predictor count, therefore please use the one you like to. I don't know if the factor which determines TAK's worse performance is present in any section of the files, hence you may have to check several parts.
I have created a new table, which probably is easier to evaluate. I took TAK's compression ratio as baseline and substracted it from the other results. This way positive values indicate other compressors performing worse, negative values represent better performance:
a0 a1 a3 a4 d0 d2 d3 d4 d5 d6 r0 r1 r2 r3
WavPack -hx4 2.10 2.27 2.17 2.19 2.29 4.60 3.86 5.07 3.77 4.52 3.15 3.61 4.88 3.00
WavPack -hx6 2.06 2.27 2.13 2.19 2.19 4.39 3.48 4.24 3.21 3.67 2.92 2.80 3.84 2.10
WavPack -hhx6 2.02 2.23 2.08 2.16 1.97 4.11 3.03 3.84 2.90 3.18 2.59 2.38 3.39 1.66
Flake -12 1.55 1.42 1.89 1.32 2.04 2.78 2.93 3.84 2.77 3.03 2.85 2.46 3.32 1.74
TTA 8.98 10.21 8.41 10.01 20.56 21.28 22.78 22.71 22.31 23.53 25.69 24.15 24.28 23.91
TAK -p4m 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Als -7 -o160 -t6 -0.17 -0.15 -0.12 -0.15 -0.27 -0.43 -0.26 0.28 -0.36 -0.09 0.38 0.03 0.09 -0.54
Als -7 -o1023 -t6 -0.35 -0.22 -0.22 -0.21 -0.61 -0.68 -0.27 0.24 -0.41 -0.10 0.33 -0.01 0.03 -0.63
Als -z3 -t6 0.77 1.09 1.26 0.96 12.11 12.84 14.22 14.24 13.72 13.87 12.53 13.04 13.67 13.70
t0 t1 t2 t3 u0 u1 u2 u3 v0 v1 w0 w1 w2 w3 w4
WavPack -hx4 5.11 4.90 5.00 5.16 2.32 2.05 2.10 2.23 2.10 2.65 2.27 2.43 2.78 2.43 1.76
WavPack -hx6 5.09 4.89 5.00 5.16 2.24 1.97 2.00 2.11 2.00 2.61 2.18 2.34 2.68 2.37 1.72
WavPack -hhx6 5.08 4.87 4.99 5.16 1.59 1.38 1.44 1.46 1.43 2.08 1.66 1.94 2.22 1.98 1.42
Flake -12 4.93 4.77 5.03 5.20 1.07 0.90 0.85 0.90 0.78 1.29 0.98 0.97 1.19 1.06 0.86
TTA 6.81 6.56 6.75 6.86 11.26 11.54 11.39 12.16 9.81 11.11 11.27 11.25 11.25 11.35 11.30
TAK -p4m 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Als -7 -o160 -t6 2.80 2.93 3.08 2.98 -0.76 -0.81 -0.99 -1.03 -0.26 -0.44 -0.20 -0.52 -0.65 -0.72 -0.88
Als -7 -o511 -t6 2.45 2.66 2.84 2.52 -0.75 -0.81 -0.98 -1.04 -0.29 -0.42 -0.55 -0.56 -0.65 -0.77 -0.90
Als -z3 -t6 -1.58 -1.14 -0.87 -1.09 5.23 5.13 4.97 4.78 5.71 5.42 5.46 5.42 5.37 5.17 4.90
Got the samples. Took some time...I didn't take into account als slowness.
http://tiny.pl/hfzwq (http://tiny.pl/hfzwq)
BTW restrictions on where I can link are wrong. If I'm not supposed to use file lockers, give me enough space here.
Got the samples. Took some time...I didn't take into account als slowness.
Thank you! The analysis will take some time and i can not guarantee, that i will find an (compatible) optimization.
This is really awesome. Thanks!
TBeck, do you plan to add a CUDA support for further versions of TAK encoder?
IMHO, such progressive codec as TAK must have a support of such useful feature as CUDA. Maybe it is even possible to increase the compression level this way, isn't it?
Is there plans to make it playable on any player?
Or atleast Zoom Player and the like;O?
Cause i love this kind of thing, lossless music now in less size, what more can you ask for:D?
Good work, keep on going as much as you want and can:)!
Unlike WinAMP and Foobar, Zoom Player is a DirectShow media player. You'll need a DirectShow source/decoder filter in that case.
Take a look at my website for Livio Cavallo's TAK Source Filter (packed within my DSFP).
Unlike WinAMP and Foobar, Zoom Player is a DirectShow media player. You'll need a DirectShow source/decoder filter in that case.
Take a look at my website for Livio Cavallo's TAK Source Filter (packed within my DSFP).
Nice got it working thanks:D
But does it output lossless as it is?
As i wonder if i can convert many FLAC files to TAK, without anything changing, as well as it decodes them right and such:)
Of course it does. That's the point of lossless audio codecs.
Of course it does. That's the point of lossless audio codecs.
Yeah but you never know if the decoder does it´s job corretly, so it is as if it was Wave.
Or atleast i don´t know:D
Got the samples. Took some time...I didn't take into account als slowness.
Thank you! The analysis will take some time and i can not guarantee, that i will find an (compatible) optimization.
Finally i tried it. I manually selected some of TAK's filters (statically) for each (whole) file and got at least about 0.40 percent better compression for your sample files. A bit more of improvement might be possible, if the filters would be conditionally selected per frame.
Currently i regard those files as special cases, although i have to take into account, that i dont know nearly as much about the compression relevant properties (and their frequency) of-multi channel audio as i possibly know about CD-audio. For now i have added the files to my special cases folder which affects future tunings. Thank you for the files!
Currently i have no idea how to tune the encoder for such files without loosing a lot of encoding speed. I could implement a brute force approach which simply would encode all files with the mentioned filters switched on or off and then would choose the best result. But that's not the way TAK achieves it's high encoding speed. If it would fully calculate all possible combinations of it's many filter variations, it could be easily 1000 times (or more!) slower. Sometimes i read, TAK's encoding is so fast because of it's assembler optimizations. No, that's misleading. It's speed-efficient design and the assembler optimizations may speed up encoding by a factor of about 2 to 3 (for -p4m), but the most important factor are it's heuristics, which base all the filter deceisions on relatively simple estimations. That's where most of the encoder development time has gone.
But sometimes those heuristics fail, as can be seen with m2's files.
A side note: Your (m2) files have wasted bits (low significant bits are zero), this may explain the really bad performance of TTA, which -to my knowledge- doesn't check for this case.
TBeck, do you plan to add a CUDA support for further versions of TAK encoder?
IMHO, such progressive codec as TAK must have a support of such useful feature as CUDA. Maybe it is even possible to increase the compression level this way, isn't it?
I don't want to loose decoding speed, because i still think about possible hardware implementations. Therefore i don't want to significantly increase the complexity of TAK's filters. Then only encoder optimizations are possible. With a lot more of processing power available i could possible replace some of TAK's fast heuristics with brute force approaches. This could for instance help special files like those m2 has sent me, but i doubt, it would significantly increase the average compression ratio for a large corpus of files. Anectdotally: i spend the last two days implementing a brute force approach for one case, where TAK versions earlier than 2.0 could achieve 0.05 percent better compression. This was the most significant advantage i ever found for the brute force way of a filter selection! But with the better design and heuristics of TAK 2.x, the advantage shrinked to about 0.01 percent.
I don't think, the investment of maybe 20 or even 50 times more processing power (which probably would require a quite potent GPU) would result in more than about 0.05 to 0.10 percent better compression on average. But it could help some special files.
And then there is also my personal fun factor: I really like to beat brute force approaches whith more or less clever algorithms... Well, indeed it's often less cleverness but a bit of intuition and a lot of trial and error and collecting and evaluating a lot of relevant data.
Conclusion: Too little to gain for me by CUDA yet, but may be, if i have some new ideas...
It's not that i don't think about opportunities for compression improvements. But it's getting really hard to find some within my efficiency/speed constraints.
Thanks for reply.
Seem like now takc works fine with HyperThreading.
HT on:
takc -e -p4m 34.22 * real time
takc -e -p4m -tn1 34.28 * real time
takc -e -p4m -tn2 50.21 * real time
takc -e -p4m -tn4 66.48 * real time
HT off:
takc -e -p4m -tn2 50.49 * real time
(Core i3 530)
So, there is a speed improvement with -tn4 compared to -tn2 and lower, -tn2 with HT off/on is equal, and by default encoder uses only one thread. Everything is quite good. Thank you, TBeck
request: Mr. Beckers own fb2k decoder, i'll be always updated in the case of decoding improvements, and provided together with main TAK encoder release, as WA decoder is.
But you can always update tak_deco_lib.dll yourself.
But you can always update tak_deco_lib.dll yourself.
If the whole point of foosions plugin is only link to tak_deco_lib.dll to use all of its functions, then yes. Otherwise, i don't know if it makes sense, coz there could be e.g. some new decoding functions in the library, which will not be used with old plugin. Simply i thought Mr. Beckers plugin would be handier solution IMHO, with only one library (maybe). Don't want to discuss much about current plugin here, this was only my "small" (but maybe reasonless) request.
Final release of TAK 2.2.0 ((T)om's lossless (A)udio (K)ompressor)
This release brings support for multi-channel audio and speed optimizations for encoder and decoder.
It consists of:
- TAK Applications 2.2.0.
- TAK Winamp plugin 2.2.0.
- TAK SDK 1.1.1.
- TAK Decoding library 2.2.0.
Download
[attachment=6596:TAK_2.2.0.zip]
Impressive.. Thank you for your dedication.
Have you tried to compile it with 64bit Delphi or 64bit FreePascal? Would be interesting to see the results and a 64bit library would be nice as well
It appears as though the encoder refuses to encode when it has to output a file with non-western unicode characters somewhere in the file path. (e.g. Прокофьев, Сергей Сергеевич). It works fine when the input filenames have such chars, but it bugs when it has to output to them.
(PS. Is it normal that I get different RG numbers even when the file I converted from was also lossless?)
If you used a recent version of foobar2000 (v1.1.6 or later) to calculate the replaygain values, a new algorithm is used which results in slightly different values. You can double check this by recalculating the replaygain of the original files using the latest version of foobar2000.
Anish
If you used a recent version of foobar2000 (v1.1.6 or later) to calculate the replaygain values, a new algorithm is used which results in slightly different values. You can double check this by recalculating the replaygain of the original files using the latest version of foobar2000.
Anish
much obliged; that seems to explain it. Though the difference can be quite stark (2-4dB is not uncommon for my classical collection)
It appears as though the encoder refuses to encode when it has to output a file with non-western unicode characters somewhere in the file path. (e.g. ?????????, ?????? ?????????). It works fine when the input filenames have such chars, but it bugs when it has to output to them.
(Dubravka Tomši? Srebotnjak isn't accepted either )
Seem like now takc works fine with HyperThreading.
...
So, there is a speed improvement with -tn4 compared to -tn2 and lower, -tn2 with HT off/on is equal, and by default encoder uses only one thread. Everything is quite good. Thank you, TBeck
Fine! But i don't deserve any credit, because i haven't modified the multi-threading code... Maybe your system configuration has changed a bit and windows now makes more clever choices regarding the cpu assignment.
But you can always update tak_deco_lib.dll yourself.
If the whole point of foosions plugin is only link to tak_deco_lib.dll to use all of its functions, then yes.
That's the way it works.
Otherwise, i don't know if it makes sense, coz there could be e.g. some new decoding functions in the library, which will not be used with old plugin. Simply i thought Mr. Beckers plugin would be handier solution IMHO, with only one library (maybe). Don't want to discuss much about current plugin here, this was only my "small" (but maybe reasonless) request.
I don't think it's reasonless. But it's a lot easier for me to test and provide only one universal library and leave the interfacing to people who know more about the specific application. I remember it' took me quite long to make the winamp plugin work well.
Indeed there are some new functions in the latest library (get the MD5, get the channel assignment of multi-channel-audio) which have not been documented yet. Too little time.
It appears as though the encoder refuses to encode when it has to output a file with non-western unicode characters somewhere in the file path. (e.g. ?????????, ?????? ?????????). It works fine when the input filenames have such chars, but it bugs when it has to output to them.
I am surprised that it works for the input file. Did you read from a pipe?
Unicode support is on my todo list, but unfortunately i can't make any promises. Now and then i have a bit of time to work on TAK, but it's not calculable.
Have you tried to compile it with 64bit Delphi or 64bit FreePascal? Would be interesting to see the results and a 64bit library would be nice as well
Well, a 64-bit version could be a bit slower... 64-bit code can be less efficient, for instance because it's bigger and may not fit as well into the cpu's code cache. Some instructions may be slower. It's faster when performing 64-bit arithmetic (especially multiplications) but TAK has been designed to work with 32-bit arithmetic (it doesn't need more). The only advantage i could think of is the doubling of the register count. This could help some of my assembler optimizations and possibly yield 5 to 10 percent faster encoding if i am lucky.
Mpeg4Als probably would benefit a lot from 64-bit arithmetic because it makes heavy use of it.
Yes, the fact that piping worked got me confused. Anyway, love what you're doing with the codec, so please don't worry about the unicode support more just because I mentioned it..
Just a heads-up: I haven't kept any statistics, but for most of my classical music collection, and especially for recordings from the 1940s-60s, tak -p4m actually performs on par with (within 2kbps), or better than, Monkey's Audio Extra High. In a number of cases, especially of piano and/or piano-violin recordings, this has meant a compression increase of 30-40kbps for ~400kbps recordings. (In certain recent recordings -- such as the Claude Frank or Badura-Skoda beethoven piano sonata sets -- this is notably untrue, though, with tak doing about 8kbps worse.
Just out of curiousity: How far is Linux support for TAK? Would make using it with Android quite much easier.
Win32 binaries + WINE.
Hmm, that would add quite some overhead ...
Linux platform was touched on numerous times and the priority still remains rather low.
You do bring up a point, as the computer trends show that mobile market growth exploding. Makes me ponder a power laptop upgrade over another boxy desktop (except I still prefer the mechanical/optical mass storage options). At any rate, the issue of other platforms is heavily dependent on the developer and- in this case- how much a single developer can devote the time on this request. Also, I don't want to open the whole licensing thing, but I would imagine some headaches when dealing with a closed-source project and the Linux platform, so I'll just mention that and leave it there.
Linux does not require its software to be open.
Linux does not require its software to be open.
that's only true if it's a standalone app. i don't think you'd want a standalone app for just tak. rather, you'll want a dynamically loaded (and previously linked) plugin for your existing app, which, along with the app it gets load into, form one software as a whole (in a legal sense at least). and in that case, the plugin must adhere to the app's license requirements. in the case of gpl, that means it has to be open source as well.
My preferred Android media player is not open source either, so it should be fine...
Is there a Linux player support yet? Banshee or Amarok plugin would be nice..
Linux does not require its software to be open.
that's only true if it's a standalone app. i don't think you'd want a standalone app for just tak. rather, you'll want a dynamically loaded (and previously linked) plugin for your existing app, which, along with the app it gets load into, form one software as a whole (in a legal sense at least). and in that case, the plugin must adhere to the app's license requirements. in the case of gpl, that means it has to be open source as well.
Not true.
If anybody was to distribute them together, that would be the case, but as long as user is the person bundling them together, there are no issues.
Hi!
It is possible to decode multiple TAK files to single WAV? (For example for burning .CUE files with pregap information (index 00).)
Any chance to get decoding support for Banshee or Amarok ? Would be awesome!!
I set my command-line options of EAC like this and test it:
-e -p0 -tn2 -l1 -fim0 -cpuSSSE3 -tt "ALBUM ARTIST=%albumartist%" -tt "ARTIST=%artist%" -tt "TITLE=%title%" -tt "ALBUM=%albumtitle%" -tt "DATE=%year%" -tt "tracknumber=%tracknr%" -tt "GENRE=%genre%" %source% %dest%
The test result seems to be no problems with my parameters, but when I rip my CDs, the popup window tells me that something is wrong.
Finally I found the Tag value of -tt should not be empty.
Just like this one:
takc.exe -e -p0 -tt "GENRE="
It tells me "Command line error: Tag: Invalid value"
I hope to get a small fix to make my parameters work correctly.
The wapet.exe seem to be too old to use.
any news about new version?
Sorry for the lack of active participation. I have been and still am quite busy. Nevertheless i am checking this thread regulary. Just in case someone would report a severe bug...
Hi!
It is possible to decode multiple TAK files to single WAV? (For example for burning .CUE files with pregap information (index 00).)
It can't be done with the TAK applications. Maybe it's possible with foobar (for instance)? Hopefully someone else can provide you with more helpful information.
Any chance to get decoding support for Banshee or Amarok ? Would be awesome!!
I doubt this will happen unless i release an open source decoder. Unfortunately that's a topic i don't comment on (especially a release date), because of a remarkable history of me arousing wrong expactations and receiving rather fierce reactions (among them insults). I will release it, when it's done.
Finally I found the Tag value of -tt should not be empty.
Just like this one:
takc.exe -e -p0 -tt "GENRE="
It tells me "Command line error: Tag: Invalid value"
I hope to get a small fix to make my parameters work correctly.
The wapet.exe seem to be too old to use.
I checked it and indeed, my tag reader will reject empty item values. I put it on my to do list for the next release.
any news about new version?
No plans yet. I don't think i could improve TAK's speed significantly. An 64-Bit version could help a bit, not because of the 64-bit arithmetic, but because of twice as many registers available for my assembler routines. And SSE 4.1 instructions possibly could provide some opportunities. I will check this after an operating system and cpu update.
And i am still evaluating opportunities for compression improvements. Unfortunately they usually are quite slow in relation to the compression improvement and would require modifications of the file format and thus breaking compatibility.
Another relevant factor is lack of time. The last release brought you extremely efficient compression of multi channel files and this required nearly 2 months of full time work.
So i am hoping for a really good idea (what is sometimes sheer luck...) and sufficient time to realize it.
Tom,
could you please document the function that gets the MD5 of the audio? I would really, really like to be able to view it (the MD5 checksum) in my foobar2000. Of course, that would require an update to the foosion's decoding plug-in, but I don't think that'd be a problem.
Thanks.
About TAK and foobar2000... From http://www.foobar2000.org/changelog (http://www.foobar2000.org/changelog) :
Fixed multi-channel FLAC encoding (channel mask now gets preserved).
Fixed multi-channel WavPack decoding (channel mask now gets preserved).
It seems that documenting tak_GetWaveExtensibleSpeakerMask is also a good idea
Could someone who has access to TAK's Wiki page (http://wiki.hydrogenaudio.org/index.php?title=TAK#Windows) add dsfTAKSource (http://www.liviocavallo.altervista.org/) and DC-Bass Source Mod (http://reino.degeelebosch.nl), two DirectShow filters capable of decoding TAK audio, to the Software - Windows section? With TAK 1.1.0 still being mentioned as recommended encoder, the page needs an update anyhow!
Are there any updates regarding TAK?
How do you use the md5 data? It gets written into the TAK files somewhere?
The tak command line encoder can't read tak files! Is there any plan to change this?
The tak command line encoder can't read tak files!
It can.
The tak command line encoder can't read tak files!
It can.
Did you try it? It gives error... "Command line error: invalid file extension"
you are using -d to decode, right?
(http://dl.dropbox.com/u/22801321/takc.png)
you are using -d to decode, right?
No, I'm using -e to encode.
Yes, I could find no internal conversion either (if what I understand is TAK->TAK conversion), which would be handy- for example- -p0 to -p4m compression.
As a matter of fact, not long ago I also couldn't get TAK.EXE nor TakC.exe or even SHNTool to help me with TAK->TAK conversion. Long story short, CUETools' embedded .CUE sheets into TAK made FB2K conversion of CDImage's a pain because of track-splitting instead of keeping solitary image file. I tried to pipe TakC.EXE decode to TakC.EXE encode and I failed at that too.
Hope I didn't derail thread (my solution ended up being I'd strip APEv2 tags prior to conversion and use FB2K so no track-splitting would occur).
D:\Program Files\Media\Foobar2000\encoders>takc -d input.tak -| takc -e -md5 -v -lp -tn4 - output.tak
< STDIN .......... 73.44% 102*
Compression: 73.44 %
Duration: 2.15 sec
Speed: 101.91 * real time
D:\Program Files\Media\Foobar2000\encoders>takc -fi input.tak
=== input.tak =================================================
File size: 26.70 MB
Header size: 0.07 KB
Unused: 0.00 KB
Compression: 72.28 %
Samples per channel: 9682596
File duration: 219.56 sec
Frame duration: 250 ms
Seek table: Not available
Audio format: PCM, 44100 Hz, 16 Bits, 2 Channels
Encoder: V 2.2.0, -p4m
Codec: 2 Integer 24 bit (TAK 2.0)
Wave file meta data: Not available
MD5: 84f051642b3b70a144f4a3ecc7647803
APEv2-Tag: No
Status: Ok
D:\Program Files\Media\Foobar2000\encoders>takc -fi output.tak
=== output.tak ================================================
File size: 27.13 MB
Header size: 0.13 KB
Unused: 0.01 KB
Compression: 73.44 %
Samples per channel: 9682596
File duration: 219.56 sec
Frame duration: 125 ms
Seek table: Not available
Audio format: PCM, 44100 Hz, 16 Bits, 2 Channels
Encoder: V 2.2.0, -p2
Codec: 2 Integer 24 bit (TAK 2.0)
Wave file meta data: Header 44, Footer 0 Bytes
MD5: 84f051642b3b70a144f4a3ecc7647803
APEv2-Tag: No
Status: Ok
@06_taro - Ok, it works for me too, now. Can't remember what error I had gotten before but the proof of above I can confirm
@Mr.Duck - Hope that answers your question.
Ah that's helpful, thanks.
But all the tags get lost with that method I'm wondering, does anyone have any other working solutions that preserves file tags?
using foobar2000 would preserve tags (except embedded album art). as well as setting up a custom encoder, you'll need foo_input_tak - http://www.foobar2000.org/components/view/foo_input_tak (http://www.foobar2000.org/components/view/foo_input_tak)
If anyone knows of a (command line) tool that can copy tags from 1 file to another, I would be interested in taking a look at it.
Also hoping TBeck to reply to thread soon-ish
Tool: Mp3tag (http://www.mp3tag.de/en/)
Command line tool: Tag 2.0.52 (http://synthetic-soul.co.uk/tag/) (with --fromfile)
TAK is really a great codec which compresses much better than FLAC but I really miss one feature in the winamp plug-in and that is the transcoder for decoding (I think this is all that's needed "link (http://forums.winamp.com/showpost.php?p=2062773&postcount=144)") to other formats for portable devices. I don't need encoding just decoding would be enough.
So I finally got round to writing this batch file to encode both WAV files and TAK files into new TAK files with maximum compression. You can download it here (http://dl.dropbox.com/u/2678996/TakEncoder.7z) if you are interested.
After unpacking, you just drag a folder onto the batch file and it will recursively process all the WAV and TAK files inside. Or you can drag some individual files onto it and it processes just those files. It saves you having to load the media files into some GUI program like foobar2000 to encode them. If you like a GUI interface to do everything manually, then this won't be of any value to you.
This version doesn't support wav file exceeded 4GB, is there any fix?
takc.exe -e -p2 -ihs - outfile.tak < infile.wav
takc.exe -e -p2 -ihs - outfile.tak < infile.wav
Thanks, but I mean "decoded wav exceeds 4GB". I have a 2GB TAK file; its decoded wave file is 5GB. No player plays the wave file correctly. It seems to produce a very big single data chunk exceeds 4GB.
According to the official specifications the size of WAV files is limited to 4 GB. Larger files can be created but they are not conforming to the specs.
All signs point to that being a problem with WAV, not TAK.
Are you implying that the audio was stored as WAV before encoding and was playable without problems in that state?
All signs point to that being a problem with WAV, not TAK.
Are you implying that the audio was stored as WAV before encoding and was playable without problems in that state?
I am not sure. I got the tak file from the Internet.
Won't TAK store the wave file larger than 4GB as RF64 or Multiple Data Chunk format?
Since wave is the only format TAK will be decoded as, I believe we should fix it here :-).
Unfortunately TAK itself doesn't support RIFF64 or Wave64 file formats. BTW, foobar2000 (+foo_input_tak plugin) can convert .TAK files to .W64.
On the other hand, why do you want to decode it to WAV?
Unfortunately TAK itself doesn't support RIFF64 or Wave64 file formats. BTW, foobar2000 (+foo_input_tak plugin) can convert .TAK files to .W64.
Thanks
On the other hand, why do you want to decode it to WAV?
WAV is the only format support by TAK 2.2.0. I am reluctant to use foobar2000 -- I am obsessive.
I have to use it now.
Thanks anyway.