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 151397 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 –
Quote from: TBeck on
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 –
Quote from: skamp on
Quote from: TBeck on
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!

Quote from: skamp on
  • 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...

Quote from: skamp on
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 –
Quote from: TBeck on
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 –
Quote from: Soap on
Quote from: TBeck on
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 –
Quote from: TBeck on
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 –
Quote from: Soap on
Quote from: TBeck on
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 –
Quote from: TBeck on
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.

Quote from: skamp on
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 –
Quote from: Silversight on
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.

Quote from: sintapilgo on
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?

Quote from: nu774 on
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.

Quote from: Porcus on
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 –
Quote from: TBeck on
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 –
Quote from: db1989 on
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 –
Quote from: Silversight on
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.

Quote from: Silversight on
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.