Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: TAK 2.0 Development (Read 47832 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

TAK 2.0 Development

TAK 2.0 Development

Well, it looks as if i will be able to release TAK 2.0 this year... Therefore it's very unlikely that there will be an 1.1.3 release unless a bug fix for 1.1.2 is needed.

There are several good reasons for me to open a TAK 2.0 development thread now:

- Most of the new or improved algorithms have been implemented.
- Therefore i can now provide some performance data which will not differ very much from the final release.
- At some point i may need help from interested users to tune the new algorithms.
- It's easier for me to ask for help or opinions if there is already an appropriate thread.
- With this thread started and my goal stated, i have to stop digging even deeper for further improvements...

What to expect from V2.0:

It will introduce a new codec, but no new features from my todo list. The new codec will be no revolution, but an evolution. When i arrived at hydrogen and published first evaluation versions of YALAC, i was focussing more on maximum compression than on maximum speed. But it didn't take long to get aware of what users liked most of YALAC/TAK: It should be as fast as the fastest existing codecs but provide significantly higher compression. Despite of this clear mission statement, it took quite long for me to fully follow this order. Probably the reduction of the maximum predictor count from 256 to 160 in TAK 1.1.0 marks the last step of this process.

The goal of the TAK 2.0 development can be defined as follows:

Get the most bang for the buck. More specifically:

- Try to make it faster.
- Try to make it stronger (compression wise) but without sacrificing (decoding-) speed.

With these constraints present, i haven't managed to perform something revolutionary. But please don't forget, that many users already regarded the efficiency of the TAK 1.x line as revolutionary...

Ok, now for some data. First the results of my primary sample set. It consists of 46 files taken from rarewares.org, combined in one file. This set has proven (in my evaluations) to stress lossless codecs in many different ways and it's my primary choice if i want a quite representative result covering different genres of music. Surely, i could think of an even more representative set, but this one is nice, because it's publically available.

Here we go with a comparison of V1.1.2 and 2.0:

Test system: AMD Sempron 2,2 GHz

Code: [Select]
Preset  Compression            Enco-Speed                 Deco-Speed              
        1.1.2   2.0     Win    1.1.2    2.0       Win     1.1.2    2.0       Win
                                                                           
-p0     58.83   58.78   0.05   264.10   278.26    5.36%   283.52   293.90    3.66%
-p0e    58.67   58.34   0.33   200.29   146.38  -26.92%   284.84   293.52    3.05%
-p0m    58.53   58.27   0.26    88.43    85.90   -2.86%   285.66   293.83    2.86%
-p1     57.98   57.90   0.08   193.18   199.29    3.16%   275.80   285.30    3.44%
-p1e    57.86   57.59   0.27   123.55   114.51   -7.32%   276.19   285.75    3.46%
-p1m    57.73   57.46   0.27    64.98    63.13   -2.85%   276.48   286.04    3.46%
-p2     57.07   56.95   0.12   131.39   133.28    1.44%   250.36   259.74    3.75%
-p2e    56.89   56.80   0.09    81.92    85.53    4.41%   250.04   259.36    3.73%
-p2m    56.78   56.68   0.10    44.80    43.25   -3.46%   249.90   261.00    4.44%
-p3     56.52   56.43   0.09    55.97    61.21    9.36%   190.88   220.69   15.62%
-p3e    56.44   56.33   0.11    43.16    41.62   -3.57%   188.53   219.72   16.54%
-p3m    56.37   56.25   0.12    25.44    23.66   -7.00%   187.45   219.03   16.85%
-p4     56.16   56.10   0.06    32.07    32.94    2.71%   166.89   176.79    5.93%
-p4e    56.10   56.01   0.09    18.57    26.34   41.84%   166.27   176.15    5.94%
-p4m    56.07   55.95   0.12    17.81    13.81  -22.46%   166.47   177.37    6.55%

Compression is relative to the original file size, Enco- and Deco-Speed expressed as multiple of real time.

Some remarks:

- Faster decoding for any preset, especially for -p3x.
- Faster encoding for any basic preset (without additional evaluation level).
- Some compression improvements for any preset.
- -p4m is now compressing a bit stronger than any TAK version before, and this despite the reduction of the maximum predictor count from 256 to 160 in V1.1.0.
- Nice improvement of 0.12 percent for the default preset.
- Highest improvements for p0e/p0m,p1e/p1m, which -while only using 4 respectively 12 predictors- will easily (on average) outperform FLAC -8 with 12 predictors.

Now only the basic presets:

AMD Sempron 2.2 GHz
                                                                       
Code: [Select]
Preset  Compression            Enco-Speed                 Deco-Speed              
        1.1.2   2.0     Win    1.1.2    2.0       Win     1.1.2    2.0       Win
                                                                         
-p0     58.83   58.78   0.05   264.10   278.26    5.36%   283.52   293.90    3.66%
-p1     57.98   57.90   0.08   193.18   199.29    3.16%   275.80   285.30    3.44%
-p2     57.07   56.95   0.12   131.39   133.28    1.44%   250.36   259.74    3.75%
-p3     56.52   56.43   0.09    55.97    61.21    9.36%   190.88   220.69   15.62%
-p4     56.16   56.10   0.06    32.07    32.94    2.71%   166.89   176.79    5.93%
-p4m    56.07   55.95   0.12    17.81    13.81  -22.46%   166.47   177.37    6.55%

Some speed differences on a Intel Pentium Dual Core 2 GHz:

Code: [Select]
                                                                        
Preset  Compression            Enco-Speed                 Deco-Speed              
        1.1.2   2.0     Win    1.1.2    2.0       Win     1.1.2    2.0       Win
                                                                        
-p0     58.83   58.78   0.05   261.83   271.77    3.80%   298.67   314.33    5.24%
-p1     57.98   57.90   0.08   201.75   205.87    2.04%   291.72   306.68    5.13%
-p2     57.07   56.95   0.12   146.14   144.41   -1.18%   262.58   272.50    3.78%
-p3     56.52   56.43   0.09    64.64    68.20    5.51%   214.36   240.91   12.39%
-p4     56.16   56.10   0.06    36.90    36.37   -1.44%   193.97   206.40    6.41%
-p4m    56.07   55.95   0.12    21.07    15.76  -25.20%

Compression advantage for other bit depths than 16:

Code: [Select]
       24 Bit                          8 Bit
       44-48 KHz  96 KHz   192 KHz     8-44 KHz              
-p0     0.02        0.05    0.31        1.24
-p1     0.10        0.16    0.41        1.32
-p2     0.17        0.30    2.07        1.41
-p3     0.03        0.01    1.03        1.48
-p4    -0.02       -0.08    1.03        1.00
-p4m    0.01       -0.03    1.12        0.99

Some remarks:

- Currently there is some regression for 96 KHz. The new algorithms need some fine-tuning.
- In my evaluations only Optimfrog can beat TAK's compression of 192 KHz sample data.

Last but not least some results for LossyWav:

Code: [Select]
Quality Preset  Compression             
                1.1.2   2.0     Win
                                
-q00    -p2m    19.37   19.05   0.32
        -p4m    19.43   19.04   0.39
-q25    -p2m    26.38   26.12   0.26
        -p4m    26.40   26.11   0.29
-q50    -p2m    32.34   32.10   0.24
        -p4m    32.36   32.08   0.28

And no, that's not the results of the dedicated LossyWav codec i intend to develop later.

Well, i hope you are not disappointed!

  Thomas

TAK 2.0 Development

Reply #1 –
Quote from: TBeck on
Well, it looks as if i will be able to release TAK 2.0 this year...

I love this codec because of it speed to encode and decode (at least in foobar) and prefer it then FLAC when some compatibility isn't in question.
I didn't read the tables but I guess it will still be fast enc/dec
Only the date?

[edit] just forgot MD5 -

[edit2] I just saw them quickly, and encoding speed graph is little strange. Default -p3 just jumps from the neighbors (why?) Also -p2 looks like a candidate for default setting.

[edit3] well, -p2 is default, I somehow thought it was -p3, nevermind

TAK 2.0 Development

Reply #2 –
Great news, Thomas!  Nice to see my lossless codec of choice is continuing to be improved upon.

Thank you.

TAK 2.0 Development

Reply #3 –
It's closed source until the day it isn't anymore, and maybe that day will never come. Pressuring with each release by remembering extensively the words said looong ago seems to me a desperate scream to get a personal desire fulfilled.

I do agree with the fact that the evolution of TAK doesn't help getting TAK more widely adopted (lack of specifications for developers, lack of multiplatform, not being open source, lack of features FLAC does have, etc.). In fact, I have the impression that with each TAK release less people participate (posting & testing).

But then, Thomas can do what he want, it's his work.

Back to TAK 2.0. Great to see the improvements, how did you got them? You rewrote the encoder and decoder? Do you think there's a room to make it even faster?

When it's out I will compare it to FLAC and TAK 1.1.2, if I have time by that time

TAK 2.0 Development

Reply #4 –
I am glad to see a new milestone being set for TAK. However, users fixated on the topic of code availability is becoming very irritating. I think certain members should quit threatening the developer by declaring TAK unusable because of their narrow philosophy. For them I say, "Go write your own open-source lossless program," if only just to get an idea of what it takes to make a codec that is different and better.

Kicking aside the soapbox (and getting back to point of main discussion), I also wanted to throw out other questions: Is TAK looking at adding multichannel support sometime in version 2.x? What other additional tools might 2.x be included in the SDK that programmers can utilize?

"Something bothering you, Mister Spock?"

TAK 2.0 Development

Reply #5 –
Thomas, congratulation on new step of evolution of your codec.
I see that all standard presets -q0 ...-q4 have received enco- and deco- speed improvements while sub-presets "extra" and "max" have gone to more asymmetric balance  (slower encoding, faster decoding and better compression). It's great.  The CD ripping (EAC) is more slower than encoding to -p0m or -p1m and many time there is a lot of time to encode without rush while decoding speed is important for playback and converting to the lossy formats. I wouldn't mind see even more asymmetric speeds. Maybe new profile ( -p1u ultra?) could bring more compression and/or faster decoding at cost of something like 2-2.5x slower speed comparing to -p0m and -p1m (which is still comparable with speed of FLAC -8)?
Most of FLAC users encode to -8 level. http://www.hydrogenaudio.org/forums/index....c=58731&hl=

Likewise those numbers are ideal as they don't consider I/O bottleneck. The difference between speeds of -p1 and -p1m is considerably smaller in real scenario.

TAK 2.0 Development

Reply #6 –
Quote from: 2E7AH on
[edit2] I just saw them quickly, and encoding speed graph is little strange. Default -p3 just jumps from the neighbors (why?)

I have replaced something i called "PreFilter", which was present for -p3x and -p4x. The new approach is a lot faster for -p3x.

Quote from: Alexxander on
In fact, I have the impression that with each TAK release less people participate (posting & testing).

I think it would be quite easy for me to evoke more responses, if i would release evaluation versions and would frequently ask for opinions on some tuning deceisions like i did in the YALAC-days. But there is far less need for me to do this, because i now know a lot more about the nature of many of TAK's compression techniques and their effect on even extraordinary audio files. This because of the great support of some past testers of YALAC and TAK.

And as i alreaday wrote: The speed-compression-efficiency of the first YALAC/TAK-versions has been regarded as revolutionary by quite some people, but now there is only some -less exciting- evolution happening. Something users possibly are expecting.

Quote from: Alexxander on
Back to TAK 2.0. Great to see the improvements, how did you got them? You rewrote the encoder and decoder?

What i did:

- Further improvements of the bitcoder for the final residuals. FLAC for instance is using fast but not very efficient rice codes. Monkey's Audio is using range coding: more efficient but noticeable slower. TAK is using codes that are nearly as fast as rice codes and nearly as efficient as range coding. TAK 2 further improves the bitcoder efficiency for very low amplitude signals (here conventional rice codes are very inefficient). You can see a significant effect for 8-bit data, low amplitude parts of for instance classical music and for LossyWav-files.

- I have implemented a simplified variant of the advanced channel decorrelation algorithm used by presets p2 and above. It's about as fast as simple Mid/Side-encoding used by -p0/-p1 in earlier versions. Because of it's speed, it was now possible to bring a good part of the advanced channel decorrelation to the presets p0/p1.

- Presets -p3 and -p4 of the TAK 1.x line are sending each sample through something i called "PreFilter". It's primary effect was the reduction of the space requirements for the storage of the predictor coefficients. Another approach i tried in the YALAC-days was the storage of the predictors as parcor coefficients. Unfortunately this approach was quite slow for high predictor orders, because encoder and decoder have to transform parcor into filter coefficients and this operation required very slow 32*32=64 bit multiplications and the count of those multiplications is growing exponentially with the predictor count.

But now i have managed to modify the algorithm in a way, that it needs only 16*32=32 bit multiplications, what is faster than the PreFilter, if you don't go for extremely high predictor counts > 256.

- I have performed a lot of quite small optimizations to simplify the algorithms and to gain a bit of speed.

Quote from: Alexxander on
Do you think there's a room to make it even faster?

I am quite sure i can speed up encoding for the encoder evaluation levels e and m. Regarding decoding, i have my doubts.

Quote from: Alexxander on
When it's out I will compare it to FLAC and TAK 1.1.2, if I have time by that time

Fine!

Quote from: Destroid on
Kicking aside the soapbox (and getting back to point of main discussion), I also wanted to throw out other questions: Is TAK looking at adding multichannel support sometime in version 2.x? What other additional tools might 2.x be included in the SDK that programmers can utilize?

Yes, i really would like to implement multichannel support. But it's not really easy to do, because i first want to evaluate the possibilities to take advantage of channel correlations of such files.

My todo list for  the SDK:

- Encoding capabilitities.
- Unicode support.
- Access to other meta data than APEv2-Tags.

Quote from: IgorC on
Maybe new profile ( -p1u ultra?) could bring more compression and/or faster decoding at cost of something like 2-2.5x slower speed comparing to -p0m and -p1m (which is still comparable with speed of FLAC -8)?

Well, i could implement a brute-force-approach, which possibly would increase compression by 0.05 to 0.1 percent, but might reduce the encoding speed by a factor of 10 to 50...

Quote from: IgorC on
Likewise those numbers are ideal as they don't consider I/O bottleneck. The difference between speeds of -p1 and -p1m is considerably smaller in real scenario.

How true. And p1 is probably only a tiny bit slower than p0. For now i have modified p1 to be nearly as strong p1e while loosing only very little encoding speed (<= 10 %). I will post some results later.

  Thomas

TAK 2.0 Development

Reply #7 –
Updated results for Version 2.0 Eval 03

Yeah, there is some progress...

Results for my primary sample set:

Code: [Select]
AMD Sempron 2.2 GHz                                                                     
                                                                        
Preset  Compression            Enco-Speed                 Deco-Speed              
        1.1.2   2.0     Win    1.1.2    2.0       Win     1.1.2    2.0       Win
                                                                         
-p0     58.83   58,74   0,09   264.10   290,95   10,17%   283.52   294,06    3,72%
-p1     57.98   57,66   0,32   193.18   192,05   -0,58%   275.80   285,83    3,64%
-p2     57.07   56,93   0,14   131.39   135,30    2,98%   250.36   258,87    3,40%
-p3     56.52   56,40   0,12    55.97    61,18    9,31%   190.88   218,93   14,70%
-p4     56.16   56,08   0,08    32.07    33,83    5,49%   166.89   176,69    5,87%
-p4m    56.07   55,93   0,14    17.81    14,43  -18,98%

Intel Pentium Dual Core 2 GHz                                                                   
                                                                        
Preset  Compression            Enco-Speed                 Deco-Speed              
        1.1.2   2.0     Win    1.1.2    2.0       Win     1.1.2    2.0       Win
                                                                        
-p0     58.83   58,74   0,09   261.83   284,54    8,67%   298.67   311,81    4,40%
-p1     57.98   57,66   0,32   201.75   201,09   -0,33%   291.72   304,66    4,44%
-p2     57.07   56,93   0,14   146.14   148,89    1,88%   262.58   271,37    3,35%
-p3     56.52   56,40   0,12    64.64    69,37    7,32%   214.36   240,48   12,19%
-p4     56.16   56,08   0,08    36.90    37,86    2,60%   193.97   205,73    6,06%
-p4m    56.07   55,93   0,14    21.07    16,68  -20,84%

Compression is relative to the original file size, Enco- and Deco-Speed expressed as multiple of real time.

Some results for LossyWav:

Code: [Select]
Quality Preset  Compression                  
                1.1.2   2.0     Win  
                                     
-q00    -p2m    19.37   18,92   0,45 
-q25    -p2m    26.38   26,00   0,38 
-q50    -p2m    32.34   31,97   0,37

Some remarks:

- Again some tiny compression improvements.
- Again -p0 is encoding significantly faster. Encoding is now nearly as fast as decoding on the Sempron.
- I have deceided, to make -p1 stronger, therefore it's now encoding a bit slower.

  Thomas

TAK 2.0 Development

Reply #8 –
Any news about release date?

TAK 2.0 Development

Reply #9 –
Quote from: TBeck on
Updated results for Version 2.0 Eval 03


Congrats, Thomas. Great to hear about TAK 2 development progress. Looks really promising.
According to your todo list, there are:
Quote
- Encoding capabilitities.
- Unicode support.
- Access to other meta data than APEv2-Tags


Do you plan to add also brute-force mode before public release ? This mode could still be very useful despite slow encoding speed.
And yes, is there any estimated release date for beta version ?

TAK 2.0 Development

Reply #10 –
Quote
This mode could still be very useful despite slow encoding speed.

Monkey's Audio, OptimFROG, LA - they all have better compression ratio than TAK -pMax. But they aren't particularly popular.

There are no DAPs that support TAK. Winamp plugin doesn't support tagging. And yes, no Unicode support. (what else? embedded cover art?)  I think it's much more important for TAK.

TAK 2.0 Development

Reply #11 –
Quote from: lvqcl on
Quote
This mode could still be very useful despite slow encoding speed.

Monkey's Audio, OptimFROG, LA - they all have better compression ratio than TAK -pMax. But they aren't particularly popular.

TAK has one huge advantage over those codecs - very fast decompression.
I can easily live with slower encoding in 'ultra-heavy-brute-force mode', since I compress each album just once. Fast decoding speed stays anyway. So if such mode is possible - why not to have it ?

Quote
There are no DAPs that support TAK. Winamp plugin doesn't support tagging. And yes, no Unicode support. (what else? embedded cover art?)  I think it's much more important for TAK.

Yep. But it seems all these features are already on Thomas's todo-list.

TAK 2.0 Development

Reply #12 –
Quote from: SokilOff on
Quote from: lvqcl on
Quote
This mode could still be very useful despite slow encoding speed.

Monkey's Audio, OptimFROG, LA - they all have better compression ratio than TAK -pMax. But they aren't particularly popular.

TAK has one huge advantage over those codecs - very fast decompression.


2 advantages.  Monkey's and FROG have honestly really dumb names that inhibit adoption.  I remember when I first found out about lossless encoding, the only 2 codecs I was aware of were FLAC and Monkey's.  Before being aware of the other advantages and disadvantages of each (hey, it's lossless after all, I can switch anytime with no quality loss) I chose FLAC because it had a descriptive name with a cool high-tech acronym and file extension, as opposed to littering my hard drive with APE files.  TAK is even better because it sounds like the villain from Stephen King's Desperation.

LA reminds me of vintage Roland synthesizers, which is good, but... I don't even know where to get tools for that which would work on my system anymore.

TAK 2.0 Development

Reply #13 –
_m²_ & SokilOff :

According to TBeck, Tak 2.0 is supposed to be released before the end of this year.
Needless to say, I'm looking forward for its license.

TAK 2.0 Development

Reply #14 –
Quote from: sauvage78 on
Needless to say, I'm looking forward for its license.

Now let's keep this on-topic, sauvage78.  Don't push your luck.

TAK 2.0 Development

Reply #15 –
Quote from: TBeck on
- Unicode support.
What do you mean by that? I have a couple of TAK files with Japanese tags and they show up fine on non-JP systems...
Do you mean unicode support for the command line encoder? (Well, file names fed to the encoder)

TAK 2.0 Development

Reply #16 –
I believe he does... which is something I've been greatly missing.

TAK 2.0 Development

Reply #17 –
Quote from: _m²_ on
Any news about release date?

"Before christmas" seems to be a reasonable date for the final release. But i don't know, how long the beta testing phase will last. Because i have modified so much code, i may need quite a lot of positive feedback (verification of proper encoding and decoding) before i will feel safe enough to perform a final release... Currently i am not too far away from a beta release (notice: i am calling it "beta" instead of "alpha" because i am quite confident, that it is working well).

Quote from: SokilOff on
Do you plan to add also brute-force mode before public release ? This mode could still be very useful despite slow encoding speed.

A complete brute-force-approach would mean to fully encode any combination of all parameter variations of TAK's filters and to choose the best output. This would be very slow!

If i am right, there is something like a "-secret-totally-impracticable" setting for FLAC, that does something like this. I don't know, how significant the effect on the FLAC compression ratio is, but for TAK it would be very small. And extremely slow!

TAK is using more filters and more variations of their parameters than FLAC does. If you want to calculate the complexity of a complete encode, you have (simplified!) to multiply the possible parameter variations (N) of the filters (fx): N(f1) * N(f2) * N(f3) ... It's a bit like putting 2 pieces of grain on the first field of a checkerboard, 4 on the next, then 8 and so on.

But during the development of the codec i have often calculated the maximum possible compression of selected filter combinations by brute-force and than worked very hard to find a much faster heuristic to estimate the optimal parameters. Surprisingly -after many hundreds of hours- i have always found a heuristic that was extremely close to the brute-force-approach.

Summary: A real brute-force-approach may encode about 50 to 100 times slower and gain less than 0.1 percent of compression.

Quote from: nZero on
TAK is even better because it sounds like the villain from Stephen King's Desperation.

Good point! I have read the alternative story based upon the TAK character, called "Regulators". I liked it very much and this was one important reason to call the codec TAK.

Quote from: ChronoSphere on
Quote from: TBeck on
- Unicode support.
What do you mean by that? I have a couple of TAK files with Japanese tags and they show up fine on non-JP systems...
Do you mean unicode support for the command line encoder? (Well, file names fed to the encoder)

Quote from: Zarggg on
I believe he does... which is something I've been greatly missing.

Yes!

  Thomas

TAK 2.0 Development

Reply #18 –
Quote from: TBeck on
If i am right, there is something like a "-secret-totally-impracticable" setting for FLAC, that does something like this. I don't know, how significant the effect on the FLAC compression ratio is, but for TAK it would be very small. And extremely slow!
(...)
Summary: A real brute-force-approach may encode about 50 to 100 times slower and gain less than 0.1 percent of compression.
Ditto with FLAC.  Cf. Omion's test.  Even though it only covers decoding speed, you can clearly see that FLAC's --super-secret-totally-impractical-compression-level yields only nominally, neglectably better compression than -8.  Even if I can't provide hard figures, I can tell by personal experience that it's indeed totally impractically slow at encoding.  Even on a fast machine, encoding occurs at real-time or hardly better.

Apart from that, let me still repeat that - imho - it's a shame that you ditched the -5 compression setting, making -4 the highest preset.  TAK's overall speed and efficiency are its well-known advantages, and to me, too, -5 was far from unreasonably slow at encoding, that is, the extra compression was well worth the wait.  Just a reminder: almost 2/3 of FLAC's userbase (at least the ones who voted in this poll) use the maximum compression setting.  As TAK is a similar, asymmetric codec, I regret that by omitting -5, focus has shifted from the higher to the lower presets.

TAK 2.0 Development

Reply #19 –
Quote from: Polar on
Just a reminder: almost 2/3 of FLAC's userbase (at least the ones who voted in this poll) use the maximum compression setting.


Just some interesting data, without too much significance:

I use FLAC at -8 but TAK at -p2m and enjoy its incredible encoding and near-flac decoding speed (well, officially it should be even faster but in fb2k it seems a bit different) while its compression is significantly better than flac -8.

TAK 2.0 Development

Reply #20 –
Quote from: TBeck on
Quote from: _m²_ on
Any news about release date?

"Before  christmas" seems to be a reasonable date for the final release. But i  don't know, how long the beta testing phase will last. Because i have  modified so much code, i may need quite a lot of positive feedback  (verification of proper encoding and decoding) before i will feel safe  enough to perform a final release... Currently i am not too far away  from a beta release (notice: i am calling it "beta" instead of "alpha"  because i am quite confident, that it is working well).

Thank you for the answer.

Quote from: Polar on
Apart from that, let me still repeat that - imho - it's a shame that you ditched the -5 compression setting, making -4 the highest preset.  TAK's overall speed and efficiency are its well-known advantages, and to me, too, -5 was far from unreasonably slow at encoding, that is, the extra compression was well worth the wait.  Just a reminder: almost 2/3 of FLAC's userbase (at least the ones who voted in this poll) use the maximum compression setting.  As TAK is a similar, asymmetric codec, I regret that by omitting -5, focus has shifted from the higher to the lower presets.

I agree. For me disk space is much more valuable resource than CPU time - I do conversions in background anyway.
The slowest thing that I used (and at the limit of tolerability for me) was wavpack -hhx6... compared to it, p4m is a lightning and I'd be happy to trade some speed to shave a few kilos more.

TAK 2.0 Development

Reply #21 –
Quote
I'd be happy to trade some speed to shave a few kilos more.
  McGruff the crime dog says, "Kids, don't try this at the breakfast table!"  (couldn't resist, lol)

But I did have a serious thought: maybe -p3 and -p4 could get something more aggressive towards compression (i.e. -p3em and -p4em) with the disclaimer that, "This is going to compress reeeally slow for almost an extra 0.04% over -p#m. 
"Something bothering you, Mister Spock?"

TAK 2.0 Development

Reply #22 –
is there any beta or so i could test already?

i'm interested in how good this codec will be

TAK 2.0 Development

Reply #23 –
Quote from: Polar on
Apart from that, let me still repeat that - imho - it's a shame that you ditched the -5 compression setting, making -4 the highest preset.  TAK's overall speed and efficiency are its well-known advantages, and to me, too, -5 was far from unreasonably slow at encoding, that is, the extra compression was well worth the wait.  Just a reminder: almost 2/3 of FLAC's userbase (at least the ones who voted in this poll) use the maximum compression setting.  As TAK is a similar, asymmetric codec, I regret that by omitting -5, focus has shifted from the higher to the lower presets.


Quote from: Polar on
Apart from that, let me still repeat that - imho - it's a shame that you ditched the -5 I agree. For me disk space is much more valuable resource than CPU time - I do conversions in background anyway.
The slowest thing that I used (and at the limit of tolerability for me) was wavpack -hhx6... compared to it, p4m is a lightning and I'd be happy to trade some speed to shave a few kilos more.


Quote from: Destroid on
Quote
I'd be happy to trade some speed to shave a few kilos more.
  McGruff the crime dog says, "Kids, don't try this at the breakfast table!"  (couldn't resist, lol)

But I did have a serious thought: maybe -p3 and -p4 could get something more aggressive towards compression (i.e. -p3em and -p4em) with the disclaimer that, "This is going to compress reeeally slow for almost an extra 0.04% over -p#m. 


Yes, the "focus has shifted from the higher to the lower presets". This was happening from the first presentation of YALAC (as TAK was named before it's first stable release). I have always been affected by user comments at hydrogen. Most users (who posted) wanted it to be as fast as possible. A significant amount of posters (not necessarily users...) kept emphasizing TAK's slower decoding speed than FLAC (especially when using foobar). Maybe i have taken this too serious... Possibly a lot of users indeed would welcome a bit stronger compression in exchange for a bit slower decoding. Possibly i should create a poll?

I have modified the codec to achieve more speed especially for the lower presets. Those modifications may lead to a more significant loss of decoding speed than in previous versions, if i again raise the maximum predictor order for -p4. I will have to try it.

Quote from: tEiS on
is there any beta or so i could test already?

i'm interested in how good this codec will be

Only a bit better than before.

Currently i am modifying the decoder to be capable to decode files created by later, more sophisticated TAK encoders. Then i can prepare a beta release.

  Thomas

TAK 2.0 Development

Reply #24 –
Quote
Yes, the "focus has shifted from the higher to the lower presets". This was happening from the first presentation of YALAC (as TAK was named before it's first stable release). I have always been affected by user comments at hydrogen. Most users (who posted) wanted it to be as fast as possible.
I believe this is still true. Most current TAK users are interested in this still, especially the ones who use the default or lower settings.
Quote
A significant amount of posters (not necessarily users...) kept emphasizing TAK's slower decoding speed than FLAC (especially when using foobar).
Decoding speed is definitely a priority, although in this age of computing I think current TAK decoding speeds will be fine for current portables (FLAC decoding speed may be a bit overkill nowadays as compared to 5 years ago.
Quote
Possibly a lot of users indeed would welcome a bit stronger compression in exchange for a bit slower decoding. Possibly i should create a poll?
Why not? I predict the people who use -p3 and up would be in favor of better compression, whereas -p2 users want the fastest encode/decode performance. I am not sure how much die-hard users who want the best compression would care about slower decompression speed. As far as -p3 settings and higher I think the poll might as well ask if decode speed is a priority (i.e. DAW and HTPC don't need to be battery-saving).
"Something bothering you, Mister Spock?"