Final release of TAK 2.3.2 ((T)om's lossless (A)udio (K)ompressor)
It consists of:
- TAK Decoding library 2.3.2
What's newThis release brings unicode support for the command line version and somewhat limited for the GUI version.
Improvements:
- Tiny compression improvements of usually less than 0.01 percent. I only mention it to explain why compressed files may differ from those created by the previous version.
- Considerably smaller and more portable code for the MD5 calculation.
New features:
- Unicode support. The command line version accepts unicode parameters (file names, tags) and writes unicode to the screen. The GUI version supports unicode file names in the open file dialogs, but any screen output is still limited to the Ansi character set. Therefore characters outside of the windows codepage will be displayed as question mark.
- Log files can now alternatively be stored with UTF-16 encoding. This may compensate for the current limitations of the GUI version output. The encoding can be selected in the General options dialog respectively via the new command line switch -lf.
Bug fixes:
- Two bugs in the encoder could cause an "invalid floating point operation" respectively an "illegal memory access" error. The bugs were slumbering in the now revised code for many years, probably not a big deal since i never heard of users encountering those errors.
Cleanup:
- Removed detection of the command line parameter -sts (SeekTableSize). It was silently ignored since version 1.1.1 and now will cause an error.
SDKResources:
- Long overdue update of the documentation.
Interface changes:
- New function tak_SSD_Create_FromFileW with support for unicode file pathes.
- New function tak_SSD_GetMD5 to retrieve the MD5 checksum of the audio data from the meta data.
- New function tak_SSD_GetStreamInfo_V22 to retrieve extended information about the stream.
- New types TtakAnsiChar and TtakWideChar for 8 respectively 16 bit wide characters, among others used for ANSI (Windows codepage) respectively unicode file pathes.
- Several new types, constants and a function to provide extended information about multi channel audio formats.
- New cpu flags: tak_Cpu_SSE2 to tak_Cpu_AVX2.
Important: "tak_deco_lib.lib" has not yet been updated and therefore does not contain definitions for the new functions. Sorry, i currently don't have the right tools at hand (e.g. Visual Studio).
More informationYou can find some useful information and comparisons in the beta thread (https://hydrogenaud.io/index.php?topic=122334.0).
Have fun...
Thomas
ResultsHere the results for my primary file set.
Preset Compression %
-----------------------------
2.3.1 2.3.2 Win
-----------------------------
-p0 58.74 58.74 0.00
-p0e 58.33 58.33 0.00
-p0m 58.22 58.22 0.00
-p1 57.84 57.84 0.00
-p1e 57.52 57.52 0.00
-p1m 57.42 57.42 0.00
-p2 56.90 56.89 0.01
-p2e 56.70 56.69 0.01
-p2m 56.59 56.58 0.00
-p3 56.36 56.35 0.01
-p3e 56.27 56.26 0.01
-p3m 56.20 56.19 0.01
-p4 56.03 56.00 0.02
-p4e 55.94 55.92 0.01
-p4m 55.89 55.87 0.01
-----------------------------
Compression in percent relative to the original file size.
No speed improvements beyond random variations are to be expected.
FutureFeatures of the next version:
- An 64-bit decoder library. No good reason for 64-bit applications: They are bigger and slower without any advantages for Tak.
- Complete Unicode support for the gui application.
- Speed improvements of about 5 percent for Intel cpus based upon the skylake microarchitecture (6th to 10th Generation Core).
This work is nearly finished. I am not sure, if i will add more to V2.3.3.
Features for later Versions:
- Port to Lazarus / Freepascal. Nice for Linux support.
- Fast integrity check without decoding based upon the checksums only.
- Transcode mode.
- Tuning of the encoder for the problem files which have been reported in the past months.
- Support for the AVX2 instruction set.
The above plans are quite concrete. I also feel some motivation to try some possible compression improvements. That's unknown area: It may take a lot of time and in the end result in nothing useful.
Nice one! i congratulate you for the final release.
Now, since the beta i can't get to work with Lossy wav, it is something that has changed?
Thank you.
Nothing has changed that should affect compatibility with LossyWav.
Do you mean the beta already didn't work? Which version did work? What happens now? Any error messages?
Unlikely, but could it be you are applying the now obsolete command line parameter -"sts" ?
I only replace the old version 1.3.1 to 1.3.2 and this is what appear when i try to convert (as usual) to lossy.tak
Thank you, this is really helpful.
"terminated prematurely with code 1" is interesting. Takc will terminate with this error code, if it encounters illegal parameters on the command line. But i have no clue what is triggering the error. Parameters like -fsl512 and -ihs -which you are using- are part of my automated test set. It might be, that the newer compiler i switched to is doing something different if pipe enccoding is beeing used. Sorry if i can't come up with a quick solution. I will look into that tomorrow.
Thank you, no problem, no need for apologies, take your time, i can live with it but the Unicode support is a big improvement for sure!
Regards.
Thank you for your kind words and your patience.
I will have to check the interaction with foobar.
On the command line this is working well:
Takc -e -p2m -fsl512 -ihs - "Calibration Signal.lossy.tak" <d:\VocComp_Data\Speed\rw_46.wav
Strange.
I just installed the latest version of foobar and created an encoder preset (see below) according to the parameters from your screenshot. Named a wave file like yours. Conversion performed without any problem.
Of course i am not converting the same file as you, but since the exit code 1 is indicating an invalid command line parameter, the file should not even be touched.
I suppose something with your command line respectively the foobar encoder setting is wrong. Maybe an invisible control character has been inserted. Possibly this got somehow filtered out in the previous Tak versions without unicode support. It's also possible one of the visible characters is not what it looks like, for instance a character only available in the unicode character set that looks like the minus "-".
Maybe you should delete your foobar preset and create a new one. Obviously manually without copy and paste from the old one....
And please give a feedback! It's a bit unfortunate (to say the least) to have an unsolved error report on the first page of an official release.
p4m, oldish 3570k
Version 231, 10 passes ..........
Version 232, 10 passes ..........
1985 Verdi Requiem.wav, 01:26:37, 2 ch, 16 bit, 44100 Hz
Version Compress Filesize_bytes Enc_dur_sec Encode_speed Decode_speed
------- -------- -------------- ----------- ------------ ------------
WAV 100 916750844
231 38,58 353649734 19,23 270,45 623,31
232 38,57 353591394 18,73 277,51 634,8
2018 The Prodigy No Tourists.wav, 00:37:45, 2 ch, 24 bit, 44100 Hz
Version Compress Filesize_bytes Enc_dur_sec Encode_speed Decode_speed
------- -------- -------------- ----------- ------------ ------------
WAV 100 599319626
231 78,45 470190270 10,3 219,93 515,09
232 78,45 470174434 10,22 221,96 511,56
2022 Allegaeon Damnum.wav, 01:00:08, 2 ch, 24 bit, 48000 Hz
Version Compress Filesize_bytes Enc_dur_sec Encode_speed Decode_speed
------- -------- -------------- ----------- ------------ ------------
WAV 100 1039104044
231 79,06 821471864 17,24 209,44 480,37
232 79,05 821441496 16,53 218,32 483,55
Thank you. That's 2.6 respectively 1.8 percent. Well inside of the speed variation of about +/- 3 percent (can be more for the faster presets) caused by differing code alignment of less important program parts. I only control the alignment of the true number crunching functions.
I just installed the latest version of foobar and created an encoder preset (see below) according to the parameters from your screenshot. Named a wave file like yours. Conversion performed without any problem.
Of course i am not converting the same file as you, but since the exit code 1 is indicating an invalid command line parameter, the file should not even be touched.
I suppose something with your command line respectively the foobar encoder setting is wrong. Maybe an invisible control character has been inserted. Possibly this got somehow filtered out in the previous Tak versions without unicode support. It's also possible one of the visible characters is not what it looks like, for instance a character only available in the unicode character set that looks like the minus "-".
Maybe you should delete your foobar preset and create a new one. Obviously manually without copy and paste from the old one....
And please give a feedback! It's a bit unfortunate (to say the least) to have an unsolved error report on the first page of an official release.
The normal standalone encoding works just fine as expected, the issue reside when using in combination with lossy wav encoder to get the .lossy.tak file
i tried to rewrite every ' - ' sign but no luck at all.
This is the actual parameter that i am using for this test.
Parameters: /d /c c:\"Program Files (x86)\foobar2000\encoders"\lossywav - -q X -a 4 -s h -A --feedback 2 --limit 15848 --silent --stdout|c:\"Program Files (x86)\foobar2000\encoders"\takc -e -p2m -fsl512 -ihs - %d
I have both versions along and by renaming on the parameters i can switch one to other.
works fine on v2.3.1
doesn't works on v2.3.2
I maybe have to report on lossywav thread..?
Mp3tag just gone to 64bit, and they need a 64 DLL of TAC.
https://community.mp3tag.de/t/notes-on-the-64-bit-version-of-mp3tag/57250
Works on v2.3.2 Window 11 box.
I maybe have to report on lossywav thread..?
Seems as if something similar happened with WavPack (https://hydrogenaud.io/index.php?topic=119119.msg982389#msg982389).
Here is Bryant's (kudos to him, saved me a lot of time) explaination:
"Okay, I sort of figured it out. It had to do with the format of the command-line and my use of CommandLineToArgvW() to handle Unicode command lines (which has "a special interpretation of backslash characters when they are followed by a quotation mark character")."
Instead of
c:\"Program Files (x86)\foobar2000\encoders"\takc -e -p2m -fsl512 -ihs - %d
please try
c:\"Program Files (x86)\foobar2000\encoders\takc" -e -p2m -fsl512 -ihs - %d
Mp3tag just gone to 64bit, and they need a 64 DLL of TAC.
Thanks for the info. I am confident that i will release one within a month (if nothing unexpected happens).
Hi, i tried that and no look
Also, i tried with some variations by inserting a ".exe" in it, and changing the quotes (") on both paths.
"c:\windows\system32\cmd.exe" Parameters: /d /c c:\"Program Files (x86)"\foobar2000\encoders\lossywav - --quality standard --silent --stdout|c:\"Program Files (x86)\foobar2000\encoders\takc" -e -p2m -fsl512 -ihs - %d
This works for me:
/d /c c:"\Program Files (x86)\foobar2000\encoders\lossywav" - -q X -a 4 -s h -A --feedback 2 --limit 15848 --silent --stdout|"c:\Program Files (x86)\foobar2000\encoders\takc" -e -p2m -fsl512 -ihs - %d
The quotation mark has to be placed in front of the drive letter: "c:\ instead of c:\". Don't know how i could overlook this...
/d /c c:"\Program Files (x86)\foobar2000\encoders\lossywav" - -q X -a 4 -s h -A --feedback 2 --limit 15848 --silent --stdout|"c:\Program Files (x86)\foobar2000\encoders\takc" -e -p2m -fsl512 -ihs - %d
:)
i see now, i was doing the same with both paths, but in the end, is on the second path only (remarked on bold), that is only what i had to do
Big thanks for the support!
Regards! 8)
Great! Thanks for reporting.
I've never seen anyone try putting the quotes after the drive letter and before the executable name; that is indeed nonstandard. The entire path must be enclosed in quotes whenever the path contains spaces.
If you want to avoid problems with spaces, you can rely on the old 8.3 naming conventions and use:
C:\Progra~2\foobar2000\encoders\takc
to avoid the need for quotes altogether. Including the .exe extension is only required when there are multiple executables in the same folder, e.g. program.bat and program.exe; if you omit the extension, your command will run the batch file, since .bat comes before .exe alphabetically.
I've never seen anyone try putting the quotes after the drive letter and before the executable name; that is indeed nonstandard.
I too was wondering why this would be done. Only idea: Maybe the origin of the command line was a batch file where the leading part of the path was specified as batch parameter e.g. %1"Constant Path".
Mp3tag just gone to 64bit, and they need a 64 DLL of TAC.
Thanks for the info. I am confident that i will release one within a month (if nothing unexpected happens).
This is also the case for the 64-bit AIMP beta, glad to hear you plan on doing one!
After correction of some bugs in the x64 assembler code the 64 bit decoder DLL passed my standard validation tests for the first time. Looks good.
But since i have changed so much and especially because the last bug was so subtle i see the need for more tests.
That's great! i heard that it's gonna be a foobar2000 x64 too