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.3.0 (Read 137968 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

TAK 2.3.0

Final release of TAK 2.3.0 ((T)om's lossless (A)udio (K)ompressor)

This release brings significant speed optimizations for encoder and decoder.

It consists of:
  • TAK Applications 2.3.0
  • TAK Winamp plugin 2.3.0
  • TAK Decoding library 2.3.0
  • TAK SDK 1.1.1

Download
[attachment=7541:TAK_2.3.0.zip]

TAK 2.3.0

Reply #1
What's new

Improvements:
  • Encoding speed improvements between 5 and 44 percent for my primary file set. The faster presets benefit most. Only the compression performance of preset -p0e has changed. It's now performing about 0.03 percent worse on my primary file set. I modified the preset to make it faster, because -p0e and -p0m got to close after the speed optimizations.
  • Decoding speed improvements between 14 and 29 percent for my primary file set. The faster presets benefit most.

New features:
  • Two new file info modes -fim4/5 which output one line of raw data per file.
  • New mode switch -version to display the program version.

Fixes:
  • Takc.exe now contains a proper version info record.
  • Removed an obsolete reference to the dedicated LossyWav-codec, which was part of V2.1.0 Beta, from the command line description of Takc.exe.

Many thanks to Justin Ruggles for reporting this bug! The old decoder would deliver a corrupted frame under these extremely rare conditions:
  • The samples are signed and the bit depth isn't higher than 16.
  • The frame contains at least 16 samples per channel.
  • The frame only contains samples with the maximum negative value (-32768 for 16 bit samples) or value 0.
  • The first sample in the frame has the maximum negative value.

Since a frame usually consists of thousands of samples and samples of maximum negative value usually mean clipping, it's extremely unlikely to encounter such data in real life. The probability is higher for the last frame, which can be quite small. But usually the very last samples of a song don't represent only negative clips.

Modifications:
  • Added caudec, dsfTAKSource and ImgBurn to the list of software with TAK support in the readme file.

Known issues:
  • If you use pipe decoding and the application reading the pipe is beeing terminated before the whole file has been read, TAKC may get into an endless loop and has to be manually killed with the task manager. I don't think this is a big issue but i will try to fix it in one of the next versions. BTW: Big thanks to shnutils for testing the pipe decoding!
  • There seem to be some compatibility issues with pipe decoding to some other applications ("crc1632.exe" has been reported). I will try to fix it in the next release.

More information

You can find some useful information and comparisons in the beta thread.

Have fun...

Thomas

TAK 2.3.0

Reply #2
Here the (single thread) results for my primary file set.

Test system: Pentium Dual Core E5200 (2.5 GHz), Windows 7 / 32 bit.

Code: [Select]
Preset  Compression %           Enco-Speed                Deco-Speed             
---------------------------------------------------------------------------------                            
        2.2.0   2.3.0    Win    2.2.0    2.3.0    Win %   2.2.0    2.3.0    Win %
---------------------------------------------------------------------------------                            
-p0     58.75   58.75    0.00   390.13   470.54   20.61   389.82   505.05   29.56
-p0e    58.30   58.33   -0.03   239.84   347.38   44.84   390.32   504.16   29.17
-p0m    58.22   58.22    0.00   133.99   192.11   43.38   391.08   506.40   29.49
-p1     57.84   57.84    0.00   312.56   370.65   18.59   386.80   481.24   24.42
-p1e    57.52   57.52    0.00   198.91   218.80   10.00   387.12   481.74   24.44
-p1m    57.42   57.42    0.00   105.05   137.64   31.02   388.84   483.49   24.34
-p2     56.90   56.90    0.00   233.32   259.47   11.21   356.84   427.91   19.92
-p2e    56.70   56.70    0.00   132.38   141.04    6.54   354.78   425.05   19.81
-p2m    56.59   56.59    0.00    65.64    76.69   16.83   356.87   426.95   19.64
-p3     56.36   56.36    0.00   115.94   122.37    5.55   331.84   388.69   17.13
-p3e    56.27   56.27    0.00    80.43    97.20   20.85   332.10   388.82   17.08
-p3m    56.20   56.20    0.00    43.93    48.51   10.43   331.16   387.65   17.06
-p4     56.03   56.03    0.00    63.65    73.28   15.13   302.79   348.11   14.97
-p4e    55.94   55.94    0.00    55.21    62.29   12.82   302.37   347.78   15.02
-p4m    55.89   55.89    0.00    28.09    29.95    6.62   301.86   347.56   15.14
---------------------------------------------------------------------------------

Compression in percent relative to the original file size. Speed as multiple of realtime playback.

TAK 2.3.0

Reply #3
Added caudec, dsfTAKSource and ImgBurn to the list of software with TAK support in the readme file.


Thanks for the inclusion!

Encoding a double disc album (37 files for a total of 2 hours, 27 minutes, 1494 MiB) with caudec, 8 processes, 2.2GHz mobile Core i7 CPU:

  • FLAC -8: 40.67 seconds, 218.3x, 1021.7 MiB, 965 kbps
  • FLAC -5: 14.91 seconds, 595.6x, 1023.6 MiB, 967 kbps
  • TAK -p2: 10.3 seconds, 862.3x, 998.6 MiB, 943 kbps
  • TAK -p0: 7.57 seconds, 1173.3x, 1022.7 MiB, 966 kbps


Decoding:

  • FLAC -8: 5.23 seconds, 1697.2x
  • FLAC -5: 4.99 seconds, 1778.5x
  • TAK -p2: 10.32 seconds, 860.7x
  • TAK -p0: 5.96 seconds, 1489.2x


Excellent!

TAK 2.3.0

Reply #4
Another interesting use case: a 74 minutes album, single WAV file.

Encoding:

  • FLAC --best: 73.56 seconds, 490 MiB
  • TAK -p0 -tn4: 7.02 seconds (that's not a typo), 490 MiB
  • TAK -p0 -tn1: 10.45 seconds, 490 MiB


Decoding:

  • FLAC --best: 8.10 seconds
  • TAK -p0: 8.24 seconds


Edit: it has been brought to my attention that such comparisons are not fair to FLAC, since faster implementations exist, such as FLACCL. I'm unable to run the latter, however. And even so, comparing a GPU implementation to a CPU implementation wouldn't be fair either. So it seems that in the current state of affairs, no TAK comparison will satisfy all parties.

TAK 2.3.0

Reply #5
Added caudec, dsfTAKSource and ImgBurn to the list of software with TAK support in the readme file.


Thanks for the inclusion!

Im happy if there is something good to add!

  • TAK -p0 -tn4: 7.02 seconds (that's not a typo), 490 MiB
  • TAK -p0 -tn1: 10.45 seconds, 490 MiB

If neither file io nor ram speed are the bottleneck, this might be another hint, that i have to improve the multi-thread-performance...

Edit: it has been brought to my attention that such comparisons are not fair to FLAC, since faster implementations exist, such as FLACCL. I'm unable to run the latter, however. And even so, comparing a GPU implementation to a CPU implementation wouldn't be fair either. So it seems that in the current state of affairs, no TAK comparison will satisfy all parties.

It must be unfair, if a codec has been designed in a way, that makes it very fast without using brute force...

And in the past some people argued the other way round: "Comparisons between TAK and FLAC are unfair, because TAK is using MMX (what FLAC does too) or even SSSE3."

Shall i predict, what comes next?  "TAK will never play in FLAC's league, because it's cpu usage on decoding is 0.020 instead of 0.015 percent!"

Please don't take me wrong: I think, the FLAC-team is doing a great job. And FLACCL is a great piece of software too.

But sometimes i am really irritated, what strange arguments some people are using, if something does not fit into their world view (possibly the wrong term).

TAK 2.3.0

Reply #6
But sometimes i am really irritated, what strange arguments some people are using, if something does not fit into their world view (possibly the wrong term).


How about reserving judgment when all you have is a decontextualized misrepresentation of a conversation which happened  somewhere else w/o you present. 

Much as the "source code" debate there is really no need for taking this topic off the rails on silly issues.

Creature of habit.

TAK 2.3.0

Reply #7
But sometimes i am really irritated, what strange arguments some people are using, if something does not fit into their world view (possibly the wrong term).

How about reserving judgment when all you have is a decontextualized misrepresentation of a conversation which happened  somewhere else w/o you present. 

Good point.

It's not that i was out for confrontation. That's the last i am looking for when i release a new version. But the post triggered memories of bad experiences with earlier releases.

You are right. I did overreact.

TAK 2.3.0

Reply #8
It's not that i was out for confrontation.


I apologize if I made it seem as if I were calling you out as "looking for confrontation." 
Creature of habit.

TAK 2.3.0

Reply #9
It's not that i was out for confrontation.


I apologize if I made it seem as if I were calling you out as "looking for confrontation."

Thank you. It was just my interpretation, not really backed up by your words.

And i apologize for having been too thin-skinned. Well, not the best start for a release thread...

TAK 2.3.0

Reply #10
No harm/no foul.

Since the issue was raised here (as well as in the beta thread), posts complaining about the availability of source code will be viewed as trolling and will be binned without regard to any other information they may contain (useful or otherwise).

It's a shame that I feel the need to repeat this for every new announcement about TAK.

TAK 2.3.0

Reply #11
If neither file io nor ram speed are the bottleneck, this might be another hint, that i have to improve the multi-thread-performance...


That equates to about 106MiB/s, and I did it all on a ramdisk, so there is likely no I/O bottleneck in my tests.

  • -p0 -tn4 uses about 215% of my CPU (i.e. a little over 2 CPU cores)
  • -p1 -tn4 uses about 250%
  • -p2 -tn4 uses about 340%
  • -p3 -tn4 uses about 450%
  • -p4 -tn4 uses about 410%


Note that my CPU has 4 physical cores, with "Hyperthreading" (2 threads per core). Though I'm not sure if Wine has any effect on my results (I don't think so, but I can't be sure).

TAK 2.3.0

Reply #12
Really some food for thought...

I have to admit, that i don't have much experience with multi-threading. I can't estimate, how much faster the multi-thread-encoder will be, when i have corrected the design flaw i know of.

But i am optimistic.

Note that my CPU has 4 physical cores, with "Hyperthreading" (2 threads per core). Though I'm not sure if Wine has any effect on my results (I don't think so, but I can't be sure).

As long as Wine is prioritizing the physical cores for -tn4, it should be ok.

TAK 2.3.0

Reply #13
I just finished a TAK/FLAC encoding comparison test for three albums on a RAM disk. The machine is a Core 2 Quad Q9550 (2,83 GHz). The results may be a little shaky as the machine was under occasional slight load from a local server, a couple of file watchers and an IDE (all mostly idle).

Since FLAC doesn't seem to have an option to do a test encode only without writing anything to the disk, I tested the normal encode of TAK for the sake of comparability and TAK's because I wanted to see how fast it can get if it doesn't have to write a file anywhere.

Abbreviations:
  • Comp: Compression ratio in %
  • tEnc(1): Encoding time using 1 thread (-tn1) in seconds
  • xRT(1): Realtime factor using 1 thread
  • tEnc(4) Encoding time using 4 threads (-tn4) in seconds
  • xRT(4): Realtime factor using 4 threads
  • tEst(4): Test encoding time using 4 threads (-te -tn4) in seconds
  • xRTtest(4): Realtime factor for test encoding using 4 threads
Test albums (as single WAV files each):
  • Barrington Pheloung - Broken Sword Director's Cut OST (40:46 min, 411 MByte)
  • Disasterpeace - FEZ OST (78:08 min, 788 MByte)
  • OCRemix - Deus Ex: Sonic Augmentation (36:13 min, 365 MByte)
Results:
Code: [Select]
Broken Sword Director's Cut OST

Codec/preset Comp tE(1) xRT(1) tE(4) xRT(4) tEst(4) xRTtest(4)

TAK -p0 44,69 4,88 501,39 2,12 1151,21 1,52 1604,29
TAK -p0e 44,32 6,49 377,10 2,36 1036,75 2,00 1221,70
TAK -p0m 44,23 11,41 214,48 3,76 651,38 3,49 700,56
TAK -p1 44,09 5,91 414,04 2,19 1119,18 1,97 1239,26
TAK -p1e 43,78 9,88 247,65 3,39 721,17 3,01 811,62
TAK -p1m 43,71 15,46 158,25 5,37 455,85 4,77 513,09
TAK -p2 43,33 8,13 301,07 2,76 891,70 2,52 971,64
TAK -p2e 43,25 14,79 165,44 4,98 490,80 4,69 521,62
TAK -p2m 43,17 29,37 83,29 8,65 282,75 8,20 298,44
TAK -p3 42,52 16,57 147,65 5,55 440,86 5,07 482,52
TAK -p3e 42,46 21,10 115,94 6,69 365,51 6,41 381,86
TAK -p3m 42,43 40,12 60,97 12,73 192,19 12,27 199,40
TAK -p4 41,86 27,14 90,13 8,75 276,47 8,30 294,65
TAK -p4e 41,83 32,27 75,81 10,27 238,22 9,93 246,30
TAK -p4m 41,81 60,18 40,24 19,39 126,17 19,32 126,61

FLAC -0 49,7 8,78 278,51
FLAC -1 47,8 9,33 262,20
FLAC -2 47,3 10,97 223,04
FLAC -3 47,3 12,03 203,38
FLAC -4 45,3 14,00 174,61
FLAC -5 45,0 18,30 133,67
FLAC -6 45,0 18,46 132,54
FLAC -7 44,9 35,07 69,75
FLAC -8 44,8 51,87 47,15


FEZ OST

Codec/preset Comp tEnc(1) xRT(1) tEnc(4) xRT(4) tEst(4) xRTtest(4)

TAK -p0 59,75 10,13 462,66 4,39 1068,33 3,52 1332,33
TAK -p0e 59,44 13,19 355,44 4,89 959,13 4,00 1171,39
TAK -p0m 59,19 22,48 208,55 7,40 633,46 6,81 688,82
TAK -p1 58,99 11,99 390,97 4,56 1027,12 3,61 1298,82
TAK -p1e 58,92 19,66 238,41 6,66 704,13 5,94 789,51
TAK -p1m 58,71 30,14 155,53 9,94 471,79 9,15 512,09
TAK -p2 58,52 16,09 291,42 5,58 840,45 4,89 959,47
TAK -p2e 58,48 28,71 163,27 9,77 479,68 9,06 517,34
TAK -p2m 58,28 51,73 90,61 16,77 279,51 15,88 295,20
TAK -p3 57,84 31,95 146,69 10,28 456,05 9,73 481,89
TAK -p3e 57,70 40,44 115,93 13,07 358,78 12,28 381,64
TAK -p3m 57,67 75,82 61,83 23,67 198,01 22,98 204,01
TAK -p4 57,12 51,22 91,51 16,41 285,72 15,69 298,74
TAK -p4e 57,11 60,89 76,98 19,86 235,98 18,70 250,61
TAK -p4m 57,09 110,78 42,31 38,19 122,74 34,57 135,59

FLAC -0 62,4 18,23 257,05
FLAC -1 61,7 19,49 240,57
FLAC -2 61,5 22,85 205,11
FLAC -3 59,9 23,96 195,62
FLAC -4 59,0 27,75 168,90
FLAC -5 58,9 35,99 130,25
FLAC -6 58,9 36,44 128,63
FLAC -7 58,9 70,34 66,64
FLAC -8 58,8 102,52 45,72


Deus Ex: Sonic Augmentation

Codec/preset Comp tEnc(1) xRT(1) tEnc(4) xRT(4) tEst(4) xRTtest(4)

TAK -p0 68,09 4,83 450,11 2,21 983,19 1,63 1329,46
TAK -p0e 67,69 6,25 347,38 2,37 917,68  1,88 1154,36
TAK -p0m 67,59 10,74 202,35 3,77 575,57  3,26 666,80
TAK -p1 67,05 5,84 372,09 2,27 956,61  1,73 1255,01
TAK -p1e 66,81 9,55 227,40 3,49 623,28  2,87 757,20
TAK -p1m 66,71 14,75 147,30 5,30 410,11  4,55 477,30
TAK -p2 66,45 8,12 267,52 2,96 735,01  2,49 871,00
TAK -p2e 66,32 14,10 154,05 5,30 409,59  4,62 469,93
TAK -p2m 66,20 25,78 84,26 9,35 232,36  8,40 258,74
TAK -p3 66,06 16,27 133,53 5,93 366,20  5,29 410,53
TAK -p3e 66,00 20,17 107,74 7,48 290,57  6,66 326,17
TAK -p3m 65,94 40,22 54,02 14,57 149,14  13,63 159,43
TAK -p4 65,85 26,75 81,22 9,95 218,34  9,22 253,72
TAK -p4e 65,79 31,18 69,68 11,59 187,47  10,73 202,42
TAK -p4m 65,75 64,87 33,49 24,72 87,89  23,50   92,45

FLAC -0 71,9 9,92 218,99
FLAC -1 71,1 9,77 222,49
FLAC -2 70,8 11,17 194,50
FLAC -3 69,7 11,72 185,44
FLAC -4 68,5 13,37 162,51
FLAC -5 68,3 17,27 125,81
FLAC -6 68,3 17,50 124,13
FLAC -7 68,2 32,81 66,22
FLAC -8 68,0 47,88 45,37
I double-checked that there are no typos. This thing is ridiculously fast.
Nothing is impossible if you don't need to do it yourself.

TAK 2.3.0

Reply #14
Great, thanks.

No streaming support? foo_input_tak failed and now Winamp Plugin too.

TAK 2.3.0

Reply #15
The SDK header appears to be missing a few things, like tak_SSD_GetStreamInfo_V22, TtakAudioFormat::HasExtension, TtakAudioFormat::HasSpeakerAssignment, TtakAudioFormat::ValidBitsPerSample, tak_GetWaveExtensibleSpeakerMask, TMD5State, and tak_SSD_GetMD5, all of which foo_input_tak uses. I could locate and pull tak_deco_lib.h from an older beta SDK, but it would be nice if I could get these with the latest SDK. Some or all of them do appear to be in the import library, and they are in the dll, as it works with the current binary version of the component.

TAK 2.3.0

Reply #16
As far as I understand, foo_input_tak was using non-official, hacked version of tak_deco_lib.h  (by lvqcl) to make use of those functions/structures that exist in the official 2.2.0 lib binary but are not declared in the official C header.

I also love to see official tak_deco_lib.h updated. But since library ABI hasn't changed, I think foo_input_tak can keep using it's hacked tak_deco_lib.h until then.

TAK 2.3.0

Reply #17
Oh, I wasn't aware that he hacked the API header file.

TAK 2.3.0

Reply #18
As for the ever recurring question on opening the source: Have a look at
http://wiki.hydrogenaudio.org/index.php?ti...Asked_Questions

This is a case where users who take an effort searching the forum and reading FAQs before asking questions, only will get knocked over it. Internet forums would normally approve upon new users reading FAQs rather than asking them, and when FAQreading will get you labeled a troll, then something is wrong somewhere – hopefully in the FAQ.

Would a phrasing like
[blockquote]“There is an independently implemented open source decoder available with ffmpeg. The official encoder/decoder is closed source; Thomas did express intention to open the source at some point in time, but as of June 2013 he thinks ‘a lot of (not very exciting) work is required’ until the code is ready to be published, and that may or may not happen in the foreseeable future. This is a question that generally generates more noise than fruitful discussion.”[/blockquote]be (i) useful to the reader, and (ii) appropriate (I took the quote from the beta thread)?


In addition the “What can I compress” question only refers to what v1.0.3 can do. Maybe update to, whatever the current status is?

TAK 2.3.0

Reply #19
I just finished a TAK/FLAC encoding comparison test for three albums on a RAM disk. The machine is a Core 2 Quad Q9550 (2,83 GHz). The results may be a little shaky as the machine was under occasional slight load from a local server, a couple of file watchers and an IDE (all mostly idle).

Thank you very much for those interesting results!

Some quick thoughts:

1. I wouldn't have expected a significant encoding speed difference between -e and -te if a ram disk is beeing used. Interesting.

2. Two of your albums show nice improvements for -p4m over -p3m. They seem to benefit from the higher predictor order (160 vs. 80). I already contemplated about the possibility to raise the maximum predictor count for -p4m to 256, what would be a backwards compatible modification.

No streaming support? foo_input_tak failed and now Winamp Plugin too.

To be honest, i never use it. I am not even sure, if i exactly know what you mean... Well, i am performing very little audio processing and my playback setup is extremely simple and unambitious.

What i can say: The TAK format is perepared to connect to a running stream (which can not be seeked) at any time, but neither the tak_deco_lib nor my WinAmp-plugin provide support for it.

Possibly more knowledgeable peope than me can help a bit?

As far as I understand, foo_input_tak was using non-official, hacked version of tak_deco_lib.h  (by lvqcl) to make use of those functions/structures that exist in the official 2.2.0 lib binary but are not declared in the official C header.

I also love to see official tak_deco_lib.h updated. But since library ABI hasn't changed, I think foo_input_tak can keep using it's hacked tak_deco_lib.h until then.

You are right. And it is safe to use the undocumented functions the lib exports. They will not be removed or modified unless a fundamental format change takes place or a severe bug or design flaw has to be fixed.

And i really should update the SDK! But i had not enough time. V2.3.0 rather was a suprise-release, not only for the users but for me too. I had some ideas and suddenly some time to implement them. More wasn't possible this time.

Would a phrasing like
[blockquote]“There is an independently implemented open source decoder available with ffmpeg. The official encoder/decoder is closed source; Thomas did express intention to open the source at some point in time, but as of June 2013 he thinks ‘a lot of (not very exciting) work is required’ until the code is ready to be published, and that may or may not happen in the foreseeable future. This is a question that generally generates more noise than fruitful discussion.”[/blockquote]be (i) useful to the reader, and (ii) appropriate (I took the quote from the beta thread)?

That's not exact, but it has to be, because this issue is so delicate . I have expressed the intention to release an open source decoder. That would be the first realistic step.

But otherwise a good idea!

TAK 2.3.0

Reply #20
I tried to combine the suggestion by Porcus with both your reply and what was previously on the page:
Quote
The official encoder and decoder are currently closed-source. Thomas has expressed an intention to open the source of the decoder at some point in time, stipulating preconditions of its first being further refined, ported to C or C++, and documented. This may or may not lead to releases of other code. However, as of June of 2013, he feels that “a lot of (not very exciting) work is required” until the decoding source would be ready to be published, and that may or may not happen in the foreseeable future. Such questions generally generate more noise than fruitful discussion, so it is best to wait and see what happens. In any case, there is an independently implemented open source decoder available, bundled with ffmpeg.
I hope this is along the right lines.  Of course, just change anything that you want to.

TAK 2.3.0

Reply #21
That's not exact, but it has to be, because this issue is so delicate . I have expressed the intention to release an open source decoder. That would be the first realistic step.


Ah, I should have read better, sorry.

Revised suggestion:
[blockquote]Is TAK available as open source?
ffmpeg offers a free open source decoder. Thomas did express intention to release an official decoder as open source, but as of June 2013 he thinks ‘a lot of (not very exciting) work is required’ until the code is ready to be published. There are no plans to release the encoder source code.[/blockquote]
The warning over noise content can be included or not.

edit: db1989 beat me at it. Oh well, someone can just take the editor-in-chief role and pick the wording. I tend to think that the ffmpeg implementation could be mentioned first (so users can get that “yes” first without having to read the detail).

TAK 2.3.0

Reply #22
I tried to combine the suggestion by Porcus with both your reply and what was previously on the page:

Thank you! This seems to be as cautiously worded as possible. Fine.

I would like to put it in more concrete terms, but i can't.

TAK 2.3.0

Reply #23
I've tested the Broken Sword Director's Cut OST with the LossyWAV 1.3.0 treatment. I skipped the -tn1 encodings as their encoding speed would have been quite predictably slower than that of the -tn4 encodings and otherwise uninteresting. Bear in mind that I used a different machine for this test (Core i7-3740QM, 2,7-3,7 GHz), so the encoding times do not compare to the other times posted above.
The command line used was "takc -e -p[XX] -fsl512 -tn4 bs-[Y].lossy.wav"

Results:
Code: [Select]
Broken Sword Director's Cut OST (40:46 min, 411 MByte)

LossyWAV --quality insane LossyWAV --quality standard LossyWAV --quality extraportable
Mode Comp tEnc(4) Mode Comp tEnc(4) Mode Comp tEnc(4)
-p0 38,18 % 2,94 s -p0 29,16 % 2,75 s -p0 19,82 % 2,66 s
-p0e 37,71 % 2,93 s -p0e 28,70 % 2,78 s -p0e 19,61 % 2,67 s
-p0m 37,65 % 3,65 s -p0m 28,64 % 3,55 s -p0m 19,56 % 3,44 s
-p1 37,80 % 2,88 s -p1 28,82 % 2,76 s -p1 19,55 % 2,65 s
-p1e 37,33 % 3,31 s -p1e 28,37 % 3,28 s -p1e 19,33 % 3,24 s
-p1m 37,29 % 5,27 s -p1m 28,33 % 5,18 s -p1m 19,31 % 5,14 s
-p2 37,39 % 3,13 s -p2 28,45 % 3,20 s -p2 19,39 % 3,21 s
-p2e 37,29 % 6,53 s -p2e 28,35 % 6,52 s -p2e 19,30 % 6,72 s
-p2m 37,12 % 11,71 s -p2m 28,20 % 11,82 s -p2m 19,23 % 11,90 s
-p3 37,24 % 5,29 s -p3 28,30 % 5,25 s -p3 19,27 % 5,29 s
-p3e 37,08 % 8,09 s -p3e 28,17 % 8,05 s -p3e 19,21 % 8,00 s
-p3m 37,08 % 13,61 s -p3m 28,16 % 13,41 s -p3m 19,20 % 13,99 s
-p4 37,20 % 5,73 s -p4 28,27 % 5,79 s -p4 19,25 % 5,73 s
-p4e 37,08 % 8,09 s -p4e 28,16 % 8,31 s -p4e 19,21 % 8,36 s
-p4m 37,08 % 13,58 s -p4m 28,16 % 13,51 s -p4m 19,20 % 13,88 s
Interesting details:
  • Basically, -p3e and -p4e yield the same results regarding compression AND encoding time, same with -p3m and -p4m. I had expected negligible compression differences, but I did not expect the complete lack of speed differences.
  • Contrary to the non-LossyWAV test, -pXe -pXm compress better than -p(X+1) with the exception of -p0e/-p0m.
  • Not in the results: When not using -fsl512, for every file the -p4/-p4e/-p4m encodings compress worse than even the -p1/-p1e/-p1m encodings.
Nothing is impossible if you don't need to do it yourself.

TAK 2.3.0

Reply #24
Basically, -p3e and -p4e yield the same results regarding compression AND encoding time, same with -p3m and -p4m. I had expected negligible compression differences, but I did not expect the complete lack of speed differences.

No surprise. -p3x and -p4m support up to 80 respectively 160 predictors. If the frame size is limited to 512, the overhead for storing that much predictors is too high. Only the dedicated LossyWav-codec, which was available in TAK 2.1.0 Beta, could take advantage of such high predictor orders. And TAK will not even try higher predictor orders, if the frame is too small. Therefore only tiny speed differences.

Not in the results: When not using -fsl512, for every file the -p4/-p4e/-p4m encodings compress worse than even the -p1/-p1e/-p1m encodings.

Again no surprise. Larger frames have to use the lowest wasted bit count of the 512-samples LossyWav-sub frames the frame contains. Only such files, where LossyWav deceides to remove nearly not bits, would benefit from larger TAK-Frames. Well, unless you use the dedicated LossyWav-codec, which is quite immune to such effects. It will nearly always achieve the optimum result.