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

TAK 2.1.0 - Beta release 2

Beta release 2 of TAK 2.1.0 ((T)om's lossless (A)udio (K)ompressor)

It consists of:

- TAK Applications 2.1.0 Beta 2
- TAK Winamp plugin 2.1.0 Beta 2
- TAK Decoding library 2.1.0 Beta 2

The final release will additionally contain the SDK.

Download:

Download link removed. Beta 3 has been released.

What's new

This release brings speed optimizations for the encoder (new in Beta 2!) and adds a new user selectable codec, which significantly improves the compression efficiency of LossyWav-processed files. Files compressed with this codec can not be decoded by earlier versions of Tak, Takc, in_tak and tak_deco_lib! The default codec remains unchanged und is therefore backwards compatible to TAK V2.0.0.

Improvements:

- Encoding speed improvements of about 10 percent for cpus with the SSSE3 instruction set. Since SSSE3 (note the three 'S') isn't supported by AMD, only intel users will benefit from those optimizations. Probably early implementations of SSSE3 will work less efficiently. My results are from a 65 nm Pentium Dual Core. 45-nm-Cores are expected to work a bit faster.
- New additional codec that improves the compression efficiency of LossyWav-processed files by up to about 2 percent (relative to the original file size) for the quality setting -q5.0 (less or more for other settings). It supports any block size that is an integer multiple of 256 samples. Please don't specify the -fsl512 option at the command line. While this was required for the standard codec, it will severily hurt the performance of the new dedicated LossyWav-codec. Another advantage of the new codec: You will not loose much compression if LossyWav deceides to remove no bits, as can happen with for instance some low amplitude files with little signal complexity. Simply specify -cLW at the command line to activate the new codec. Earlier it wasn't advantegous to use presets higher than -p2m when encoding LossyWav-Files. That's no longer true, you may even benefit from -p4m.
Modifications:
- The file info function now also shows the name of the codec used to compress the file. The new codec is called "3 LossyWav (TAK 2.1)".
- Moved the verify-option from the details-dialog to the general compression options dialog.

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.

Results of the encoder optimizations

Here are some encoding speed results for my primary test corpus. Cpu was a Pentium Dual Core 2180 with 2 GHz, 65 nm.

Comparison of Codecs
Code: [Select]
        V 2.0     V 2.1     Improvement

-p0     285,43    298,92      4,73%
-p1     218,33    240,65     10,22%
-p2     151,61    170,76     12,63%
-p3      70,40     78,90     12,07%
-p4      39,25     42,79      9,02%
-p4m     17,30     18,90      9,25%

Speed values as multiple of real time.

Results of the LossyWaw-codec

Here are some compression results for my primary test corpus. First a comparison of different codecs and LossyWav quality settings.

Comparison of Codecs
Code: [Select]
         FLAC 1.2.1 TAK 2.0    TAK 2.1    Advantage over
         -8         -p2m       -p4m       FLAC       TAK 2.0

-q0.0    20,61      19,07      17,25       3,36       1,82
-q2.5    27,43      25,95      23,93       3,50       2,02
-q5.0    33,26      31,78      29,62       3,64       2,16
-q7.5    38,79      37,28      35,03       3,76       2,25

Compression in percent relative to the original file size.

Sometimes LossyWav deceides not to remove any or only very few bits from a file. Then it can happen, that the LossyWav-Mode of the codec is less efficient then the standard mode. To test this i used a worst case scenario. I compressed my test corpus with TAK's standard (-cStd) and LossyWav (-cLW) codec, but without prior processing with LossyWav.

Compression of unprocessed files
Code: [Select]
TAK 2.1    TAK 2.1
         -cStd      -cLW       Loss

-p0      58,74      58,99      -0,25
-p1      57,84      57,73       0,11
-p2      56,90      57,00      -0,10
-p3      56,36      56,44      -0,08
-p4      56,02      56,06      -0,04
-p4m     55,88      55,97      -0,09

Since the presets of the 2 codecs are constructed slightly different, they are not directly comparable. But i think it is safe to say, that the average loss is usually not bigger than about 0.1 percent.

Encoding and decoding speed are close to the standard codec, therefore i conducted no tests.

Beta testing

The beta version has already gone through extensive testing performed by my automatic scripts. Please try the beta release and report any bugs in this thread.

I would also be happy about tests of compression efficiency and speed.

Thanks for testing and have fun

Thomas

TAK 2.1.0 - Beta release 2

Reply #1 –
CPU: Core i7 720QM
Code: [Select]
Preset          V 2.0          V 2.1          Improvement
-p2            159.38         203.21              27.500%
-p3e            54.41          69.13              27.054%
-p4m            24.57          31.76              29.263%

27% more speed
Can't wait for multi-core support.

TAK 2.1.0 - Beta release 2

Reply #2 –
^+1

Excellent speedup on 32nm! (Core i3 2.93GHz)

-e -p4m -silent -ihs

2.0.0        - 27.53x realtime

2.1 beta 2 - 34.54x realtime - 20% speedup

🇺🇦 Glory to Ukraine!

TAK 2.1.0 - Beta release 2

Reply #3 –
I've tested -p3m which I often use lately, on a Touhou remix album (dBu - Eternal Nocturne):

2.0: Total encoding time: 0:39.765, 68.70x realtime

2.1b2: Total encoding time: 0:36.567, 74.71x realtime

8.7% faster on my 65nm core2 duo (4MB cache), 8*388MHz (3.1GHz, ddr2-776cl4).
Measured while converting from WAV to TAK, source and destination on the same SandForce-based Mushkin Callisto SSD (I used to convert using different HDDs for source/dest before). Using my HDD TAK copy as source (so needed to decode too) I got 0:43.447, 62.88x realtime with 2.1b2. Whatever. And SandForce compression can possibly lead to idiosyncracies.

TAK 2.1.0 - Beta release 2

Reply #4 –
Thank you all for testing!

Nice results!

Since i have just replaced my 65 nm Pentium Dual Core with a 45 nm Pentium Dual Core, i can now also confirm a speed advantage of the newer CPU. It's about 5 percent on my system.

Quote from: zombiewerewolf on
Can't wait for multi-core support.

Really?

I find it still a bit strange to see my not really fast Pentium Dual Core 2.5 GHz encoding p0 with 720* and p2 with 440* real time! 

Well, i think i will get used to the speed of the new multi core encoder...

TAK 2.1.0 - Beta release 2

Reply #5 –
Quoting myself...
Quote from: TBeck on
I find it still a bit strange to see my not really fast Pentium Dual Core 2.5 GHz encoding p0 with 720* and p2 with 440* real time!

Well, it's a bit shocking to experience an almost 100 % speed up after about only two days of work to implement the multi core encoder. It took much longer to improve the single core version's speed by 10 to 15 percent. Ok, it was to be expected, but to really experience those speed ups is somehow different.

But surely i like it! It's some kind of a paradigm shift for me as developer. Now multi core support has a very high priority. You may think "I could have told you!" But it took some time to move this in some respects a bit stagnant developer into another direction.

Maybe i will release a beta 3 with multi core support for the encoder. But there are still some bugs left. Multi threading bears it's own traps. I will only add it to TAK 2.1, if i am feeling really safe.

So much (blogging) from the excited but rather sleepless developer.

TAK 2.1.0 - Beta release 2

Reply #6 –
if Tak improves almost 100% on 2 cores, would I get ~300% speed up on 4 cores cpu?

TAK 2.1.0 - Beta release 2

Reply #7 –
I'd like to see how it compares to two single core encoders running in parallel

TAK 2.1.0 - Beta release 2

Reply #8 –
A quick test: I grabbed a bunch of albums of all kind of genres, converted them to wav and then to flac and tak with default and maximum compression. I ran twice each compression and took the best result, although these were similar.

All is done on Intel Core 2 Duo running at 3,02 GHz with reading from a SSD drive and writing to a normal HDD. Reading and writing from and to the same SSD produced significant worse results. No high consuming background processes were running and all values are taken from foobar2000.

Total wav size : 10.3GB (11 071 244 724 bytes)

Running both CPU cores:

Code: [Select]
FLACv121    FLACv121    TAKv200    TAKv200    TAKv210b2    TAKv210b2
-5          -8          -p2        -p4m       -p2          -p4m
4:19.866    11:38.979   3:39.541   21:09.147  3:29.915     18:24.128
241.51x     89.79x      285.87x    49.45x     298.98x      56.84x
899 kbps    896 kbps    873 kbps   862 kbps   873 kbps     862 kbps

Running one CPU core:

Code: [Select]
FLACv121    FLACv121    TAKv200    TAKv200    TAKv210b2    TAKv210b2
-5          -8          -p2        -p4m       -p2          -p4m
6:15.167    22:06.025   5:06.308   9:28.781   4:30.397     34:35.609
167.29x     47.33x      204.89x    26.49x     232.11x      30.23x

TAK 2.1.0 - Beta release 2

Reply #10 –
Thanks Porcus, I suppose I didn't copy & paste the entire time string and missed the first digit. Maybe an admin can correct this.

TAK 2.1.0 - Beta release 2

Reply #11 –
hello TBeck, first of all I want to thank you for creating such a good lossless format and know I'm using Tak almost daily !
It is FAR superior to Monkey's audio and ought to replace it completely. (Hear me you album rippers out there ? )

I mainly use it on the setting p4 because it offers few more percents of compression with reasonable speed tradeoff.
(I find p4e/m to be really overkill and unpracticable, those save 1-2.5 Mo on a 500 Mo audio disc and that at half the encoding speed)

one small thing though : In the frontend,  when going back to the main screen the file hande isn't closed thus locking the file until I exit the frontend
This is causing a lock on that file. (why not close the handle when on the "main screen" where you choose between encode and decode)

PS: has anyone noticed a problem with fooobar when encoding in Tak, using win7, when transcoding is complete the target file disappears suddenly and right then "An error occurred while finalizing the encoding process (Object not found)" from foobar error handling (commandline => -e p4 - %d)
There is no error when using a Temporary File ( -e p4 %s %d)

TAK 2.1.0 - Beta release 2

Reply #12 –
Quote from: zombiewerewolf on
if Tak improves almost 100% on 2 cores, would I get ~300% speed up on 4 cores cpu?

Even if disk io isn't limiting the performance, the advantage will grow a bit less with each additional core, because some processing has to be performed by the main thread.

Quote from: alvaro84 on
I'd like to see how it compares to two single core encoders running in parallel

The question...

and a baseline for an answer:
Quote from: Alexxander on
Running both CPU cores:
Code: [Select]
TAKv210b2    TAKv210b2
-p2          -p4m
298.98x      56.84x

Running one CPU core:
Code: [Select]
TAKv210b2    TAKv210b2
-p2          -p4m
232.11x      30.23x

Thank you very much for such a comprehensive Test!

Back to the question: Nearly twice the speed with two cores for -p4m. The now integrated multi core support will hardly do any better. But maybe it's different if a much slower conventional hard disk is beeing used for reading. We will see.

Quote from: eleria on
hello TBeck, first of all I want to thank you for creating such a good lossless format and know I'm using Tak almost daily !

Thank you! That's motivating!

Quote from: eleria on
one small thing though : In the frontend,  when going back to the main screen the file hande isn't closed thus locking the file until I exit the frontend
This is causing a lock on that file. (why not close the handle when on the "main screen" where you choose between encode and decode)

Well, i don't think the file stays locked, but the folder containing it. I close the file handles immediately, but the add files dialog may lock the folder until the main compression dialog is closed. Can you please verify this? Is it possible to delete files which already have been encoded?

If so i will try to manipulate the dialog's behaviour to unlock the folder earlier.

Quote from: eleria on
PS: has anyone noticed a problem with fooobar when encoding in Tak, using win7, when transcoding is complete the target file disappears suddenly and right then "An error occurred while finalizing the encoding process (Object not found)" from foobar error handling (commandline => -e p4 - %d)
There is no error when using a Temporary File ( -e p4 %s %d)

Huh, this would be bad...  Any other reports?

BTW: The multi core encoder now seems to work flawless. Unfortunately i couldn't carry out more tests today, because i had to deal with a strange error in my development environment. Many hours later i figured out that the latest update of my virus scanner was responsible...

TAK 2.1.0 - Beta release 2

Reply #13 –
My Laptop:
i3 350M 2.26GHz running


Tak 2.1.0 beta2 with SSSE3 by Application

----------------------------------------------------------------------------------------------

P4M + MD5

CYNTHIA HARRELL - I AM THE WIND.wav  60.81%  23*

Compression:    60.81 %
Duration:        11.86 sec
Speed:          23.42 * real time

----------------------------------------------------------------------------------------------

P2 only

CYNTHIA HARRELL - I AM THE WIND.wav  61.69%  181*

Compression:    61.69 %
Duration:        1.53 sec
Speed:          180.99 * real time

=====================================================

Tak 2.0.0 Final By Appication

----------------------------------------------------------------------------------------------

P4M + MD5

CYNTHIA HARRELL - I AM THE WIND.wav  60.81%  19*

Compression:    60.81 %
Duration:        14.57 sec
Speed:          19.06 * real time

----------------------------------------------------------------------------------------------

P2 only

CYNTHIA HARRELL - I AM THE WIND.wav  61.69%  150*

Compression:    61.69 %
Duration:        1.85 sec
Speed:          149.98 * real time

=====================================================


I get 22.8753% speed up @ preset P4M + MD5,and 20.6760% speed up @ preset P2
 

TAK 2.1.0 - Beta release 2

Reply #14 –
Quote from: eleria on
one small thing though : In the frontend,  when going back to the main screen the file hande isn't closed thus locking the file until I exit the frontend
This is causing a lock on that file. (why not close the handle when on the "main screen" where you choose between encode and decode)

Quote from: TBeck on
Well, i don't think the file stays locked, but the folder containing it. I close the file handles immediately, but the add files dialog may lock the folder until the main compression dialog is closed. Can you please verify this? Is it possible to delete files which already have been encoded?

If so i will try to manipulate the dialog's behaviour to unlock the folder earlier.

Done. Please test the Beta 3, which will be released today or tomorrow.

TAK 2.1.0 - Beta release 2

Reply #16 –
Edit: posted in wrong thread -> moved to beta 3 thread