Hydrogenaudio Forums

Hydrogenaudio Forum => Validated News => Topic started by: TBeck on 2011-07-10 23:46:42

Title: TAK 2.2.0
Post by: TBeck on 2011-07-10 23:46:42
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:

Download

[attachment=6596:TAK_2.2.0.zip]
Title: TAK 2.2.0
Post by: TBeck on 2011-07-10 23:47:11
What's new

New features:

Improvements:

Fixes:

Known issues:

More information

You 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
Title: TAK 2.2.0
Post by: TBeck on 2011-07-13 02:34:55
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:
Code: [Select]
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:
Code: [Select]
                   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:
Code: [Select]
                   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:
Quote
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


Title: TAK 2.2.0
Post by: _m²_ on 2011-07-13 08:24:06
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.
Title: TAK 2.2.0
Post by: _m²_ on 2011-07-13 11:05:47
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.
Title: TAK 2.2.0
Post by: TBeck on 2011-07-13 17:53:47
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:

Code: [Select]
                   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
Title: TAK 2.2.0
Post by: _m²_ on 2011-07-15 17:11:01
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.
Title: TAK 2.2.0
Post by: TBeck on 2011-07-15 19:32:36
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.
Title: TAK 2.2.0
Post by: Corpulencio on 2011-07-26 17:07:35
This is really awesome. Thanks!
Title: TAK 2.2.0
Post by: Steve Forte Rio on 2011-08-01 11:31:05
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?
Title: TAK 2.2.0
Post by: zerowalker on 2011-08-06 22:52:17
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:)!
Title: TAK 2.2.0
Post by: CoRoNe on 2011-08-07 15:54:50
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).
Title: TAK 2.2.0
Post by: zerowalker on 2011-08-08 05:03:02
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:)
Title: TAK 2.2.0
Post by: CoRoNe on 2011-08-08 09:07:09
Of course it does. That's the point of lossless audio codecs.
Title: TAK 2.2.0
Post by: zerowalker on 2011-08-08 10:25:01
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
Title: TAK 2.2.0
Post by: TBeck on 2011-08-11 01:07:17
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.
Title: TAK 2.2.0
Post by: Steve Forte Rio on 2011-08-12 12:08:24
Thanks for reply.

Seem like now takc works fine with HyperThreading.

Code: [Select]
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
Title: TAK 2.2.0
Post by: jaro1 on 2011-09-24 15:04:52
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.
Title: TAK 2.2.0
Post by: lvqcl on 2011-09-24 16:23:22
But you can always update tak_deco_lib.dll yourself.
Title: TAK 2.2.0
Post by: jaro1 on 2011-09-24 18:46:11
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.
Title: TAK 2.2.0
Post by: boombaard on 2011-09-25 17:54:05
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.
Title: TAK 2.2.0
Post by: Xire on 2011-09-25 19:35:29
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
Title: TAK 2.2.0
Post by: boombaard on 2011-09-25 20:09:53
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.
Title: TAK 2.2.0
Post by: boombaard on 2011-09-26 07:39:36
(PS. Is it normal that I get different RG numbers even when the file I converted from was also lossless?)
Title: TAK 2.2.0
Post by: anishbenji on 2011-09-26 08:17:19
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
Title: TAK 2.2.0
Post by: boombaard on 2011-09-26 09:00:00
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)
Title: TAK 2.2.0
Post by: boombaard on 2011-09-26 09:34:05
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 )
Title: TAK 2.2.0
Post by: TBeck on 2011-09-27 22:31:15
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.
Title: TAK 2.2.0
Post by: TBeck on 2011-09-27 22:45:49
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.
Title: TAK 2.2.0
Post by: boombaard on 2011-09-29 13:23:53
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..
Title: TAK 2.2.0
Post by: boombaard on 2011-10-03 11:49:32
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.
Title: TAK 2.2.0
Post by: tuxman on 2011-10-25 22:49:07
Just out of curiousity: How far is Linux support for TAK? Would make using it with Android quite much easier.
Title: TAK 2.2.0
Post by: lvqcl on 2011-10-26 04:25:41
Win32 binaries + WINE.
Title: TAK 2.2.0
Post by: tuxman on 2011-10-26 09:44:43
Hmm, that would add quite some overhead ...
Title: TAK 2.2.0
Post by: Destroid on 2011-10-26 11:43:51
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.
Title: TAK 2.2.0
Post by: tuxman on 2011-10-26 11:55:24
Linux does not require its software to be open.
Title: TAK 2.2.0
Post by: viktor on 2011-10-26 12:52:08
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.
Title: TAK 2.2.0
Post by: tuxman on 2011-10-26 13:06:56
My preferred Android media player is not open source either, so it should be fine...
Title: TAK 2.2.0
Post by: Anakunda on 2011-10-26 13:11:57
Is there a Linux player support yet? Banshee or Amarok plugin would be nice..
Title: TAK 2.2.0
Post by: _m²_ on 2011-10-26 13:44:04
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.
Title: TAK 2.2.0
Post by: PPeti66x on 2011-12-14 22:28:40
Hi!
It is possible to decode multiple TAK files to single WAV? (For example for burning .CUE files with pregap information (index 00).)
Title: TAK 2.2.0
Post by: Anakunda on 2011-12-17 19:13:41
Any chance to get decoding support for Banshee or Amarok ? Would be awesome!!
Title: TAK 2.2.0
Post by: pikashi on 2012-02-03 11:35:50
I set my command-line options of EAC like this and test it:
Quote
-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:
Quote
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.
Title: TAK 2.2.0
Post by: temp1 on 2012-03-16 15:52:55
any news about new version? 
Title: TAK 2.2.0
Post by: TBeck on 2012-03-20 00:27:47
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:
Quote
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.
Title: TAK 2.2.0
Post by: Dario on 2012-03-25 10:15:11
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.
Title: TAK 2.2.0
Post by: lvqcl on 2012-03-25 10:38:34
About TAK and foobar2000... From http://www.foobar2000.org/changelog (http://www.foobar2000.org/changelog) :

Quote
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 
Title: TAK 2.2.0
Post by: CoRoNe on 2012-04-30 11:42:08
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!
Title: TAK 2.2.0
Post by: Dario on 2012-05-07 10:49:12
Are there any updates regarding TAK?
Title: TAK 2.2.0
Post by: Mr.Duck on 2012-05-11 06:23:33
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?
Title: TAK 2.2.0
Post by: lvqcl on 2012-05-11 16:01:22
The tak command line encoder can't read tak files!

It can.
Title: TAK 2.2.0
Post by: Mr.Duck on 2012-05-12 21:55:46
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"
Title: TAK 2.2.0
Post by: marc2003 on 2012-05-12 22:25:57
you are using -d to decode, right?

(http://dl.dropbox.com/u/22801321/takc.png)
Title: TAK 2.2.0
Post by: Mr.Duck on 2012-05-14 02:04:44
you are using -d to decode, right?

No, I'm using -e to encode.
Title: TAK 2.2.0
Post by: Destroid on 2012-05-14 06:39:17
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).
Title: TAK 2.2.0
Post by: 06_taro on 2012-05-14 08:54:02
Code: [Select]
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
Title: TAK 2.2.0
Post by: Destroid on 2012-05-14 16:56:50
@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.
Title: TAK 2.2.0
Post by: Mr.Duck on 2012-05-15 01:18:34
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?

Title: TAK 2.2.0
Post by: marc2003 on 2012-05-15 01:30:26
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)


Title: TAK 2.2.0
Post by: Mr.Duck on 2012-05-20 15:40:27
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
Title: TAK 2.2.0
Post by: CoRoNe on 2012-05-20 16:27:10
Tool: Mp3tag (http://www.mp3tag.de/en/)
Command line tool: Tag 2.0.52 (http://synthetic-soul.co.uk/tag/) (with --fromfile)
Title: TAK 2.2.0
Post by: e354412 on 2012-06-21 01:59:01
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.
Title: TAK 2.2.0
Post by: Mr.Duck on 2012-11-11 22:54:21
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.
Title: TAK 2.2.0
Post by: hmasterwang on 2013-06-11 13:48:38
This version doesn't support wav file exceeded 4GB, is there any fix?
Title: TAK 2.2.0
Post by: lvqcl on 2013-06-11 14:49:30
Code: [Select]
takc.exe -e -p2 -ihs - outfile.tak < infile.wav
Title: TAK 2.2.0
Post by: hmasterwang on 2013-06-12 15:13:18
Code: [Select]
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.
Title: TAK 2.2.0
Post by: naturfreak on 2013-06-12 15:20:01
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.
Title: TAK 2.2.0
Post by: db1989 on 2013-06-12 15:25:38
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?
Title: TAK 2.2.0
Post by: hmasterwang on 2013-06-12 15:41:42
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 :-).
Title: TAK 2.2.0
Post by: lvqcl on 2013-06-12 15:43:13
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?
Title: TAK 2.2.0
Post by: hmasterwang on 2013-06-12 16:01:43
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.
SimplePortal 1.0.0 RC1 © 2008-2020