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

TAK 2.3.2

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

It consists of:

  • TAK Applications 2.3.2.
  • TAK Winamp plugin 2.3.2
  • TAK Decoding library 2.3.2
  • TAK SDK 2.3.2

Re: TAK 2.3.2

Reply #1 –
What's new

This 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.

SDK

Resources:

  • 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 information

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

Have fun...

Thomas

Re: TAK 2.3.2

Reply #2 –
Results

Here the results for my primary file set.

Code: [Select]
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.

Future

Features 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.

Re: TAK 2.3.2

Reply #3 –
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?

Re: TAK 2.3.2

Reply #4 –
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" ?

Re: TAK 2.3.2

Reply #5 –
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

X

Re: TAK 2.3.2

Reply #6 –
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.

Re: TAK 2.3.2

Reply #7 –
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.

Re: TAK 2.3.2

Reply #8 –
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.

Re: TAK 2.3.2

Reply #9 –
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.

Re: TAK 2.3.2

Reply #10 –
p4m, oldish 3570k
Code: [Select]
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
“We are not stuff that abides, but patterns that perpetuate themselves.” – Norbert Wiener

Re: TAK 2.3.2

Reply #11 –
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.

Re: TAK 2.3.2

Reply #12 –
Quote from: TBeck on
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.
Code: [Select]
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..?

Re: TAK 2.3.2

Reply #14 –
Works on v2.3.2 Window 11 box.

X
EZ CD Audio Converter

Re: TAK 2.3.2

Reply #15 –
Quote from: Fabcore on
I maybe have to report on lossywav thread..?
Seems as if something similar happened with WavPack.

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

Re: TAK 2.3.2

Reply #16 –
Quote from: soundping on
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).

Re: TAK 2.3.2

Reply #17 –
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

Re: TAK 2.3.2

Reply #18 –
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...

Re: TAK 2.3.2

Reply #19 –
/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)

Re: TAK 2.3.2

Reply #20 –
Great! Thanks for reporting.

Re: TAK 2.3.2

Reply #21 –
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.

Re: TAK 2.3.2

Reply #22 –
Quote from: Aleron Ives on
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".

Re: TAK 2.3.2

Reply #24 –
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.