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

TAK 2.3.0

Reply #75
Thanks, Thomas.

Good to hear you're doing well and plan to continue you work on TAK in the future.
It's is one of the most efficient lossless codecs and it would be really sad if it's development stuck completely for an indefinite time.

TAK 2.3.0

Reply #76
Great, the latest version of the SDK is missing the MD5 API from the C headers.

TAK 2.3.0

Reply #77
Sorry. I hope, this helps for now:

Code: [Select]
type
  Ttak_str_MD5 = Array[0..15] of Byte;

function tak_SSD_GetMD5 (    ADecoder : TtakSeekableStreamDecoder;
                         var AMD5     : Ttak_str_MD5) : TtakResult;
                         cdecl; external 'tak_deco_lib.dll';


Re: TAK 2.3.0

Reply #79
Thanks for this notice, I have retrieved the necessary files from an old copy of that archive, and added them to the repository.

Re: TAK 2.3.0

Reply #80
Is there a linux version so I can try it? :-D
- I abandoned this account since I didn't find a way to delete it -

Re: TAK 2.3.0

Reply #81
Maybe you noticed that I happened to reply to a 3 year old topic? The closest you'll get on Linux is FFmpeg, and that's decode-only.

Re: TAK 2.3.0

Reply #82
Quote
Maybe you noticed that I happened to reply to a 3 year old topic?

No, I didn't. :D
- I abandoned this account since I didn't find a way to delete it -

Re: TAK 2.3.0

Reply #83
wine tak.exe
seems to be working just fine, also mpv seems to have no problems with playback.
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

Re: TAK 2.3.0

Reply #84
People still using this? Thought support died long time ago. Latest version is 4,5 years old.

Differences in file size are really close with lossless compression. I've had my entire collection at WavPack once, but stumbled upon some compatibility issues. Went back to Flac for the moment.

Is you really need smaller file (at the expense of (to me) inaudible noise), you can gain a lot of space by using LossyWav. Be sure to not mix them up with you lossless collection though. Unless you don't care about that.

I myself are a bit of a purist in that. I experimented with LosseWav and hear no difference, but don't have the guts to delete the originals.

Re: TAK 2.3.0

Reply #85
People still using this? Thought support died long time ago. Latest version is 4,5 years old.

Specally regged to answer to. Yes, I do. No development but the codec still is working, isn't it? :)

Differences in file size are really close with lossless compression. I've had my entire collection at WavPack once, but stumbled upon some compatibility issues. Went back to Flac for the moment.

Playing Wavpack CPU load is too high and the navigation is too slow comparing to TAK. Fraction of seconds of course but these fractions are annoying while the TAK rewinding is smooth or at least very near to. Just FYI my CPU is Core 5 and I use the 4 max TAK profile. Also I personally like the Waveform Seekbar plugin and it counts the waveform on the first play and wavpacks make the foobar stuck while taks don't. So the differences are between these codecs.

Is you really need smaller file (at the expense of (to me) inaudible noise), you can gain a lot of space by using LossyWav. Be sure to not mix them up with you lossless collection though. Unless you don't care about that.

I myself are a bit of a purist in that. I experimented with LosseWav and hear no difference, but don't have the guts to delete the originals.

My personal lovely choise is LossyTAK i.e. LossyWAV + TAK. My whole library is LossyWAVed (mostly -q 8 ) and TAKed because I don't hear any difference between the original files and LossyWAV 8 and the TAK decoding is as fast as FLAC's or even faster but the files are less in size.

One notice: LossyWAV is not too good for 16bit files so I use the conversion to 24bit. And also the TAK or LossyWAV (can't recall) can not process the 32bit files. And, again, the 24bit conversion is the remedy.

Also I convert the DSD to LossyTAK. For this I use the FIR filter (the second version in the bottom of the page) from Nazar Shtybel: http://s-audio.systems/catalog/dsd-filter
The page is on Russian so use the google translate if you can't read. The filter itself is written on strong math so the google translator won't help :D

Though my DAC plays DSD natively but waveforms are preferrable in some aspects. At least the foobar DSPs work with them. Well, and the file size matters.
Listening to pure sine 220V 50Hz...

Re: TAK 2.3.0

Reply #86
The reports of TAK's death have been greatly exaggerated...

Initially i didn't want to post before the next release, but while i am working on it i am also regularly reading the posts at hydrogen and somehow they made me feel it's a good time to make a (small) statement.

TAK 2.3.1 (I like to call it the "Back to work"-release...) will again be faster. Currently the strongest mode -p4m encodes more than 20 percent faster on my (Haswell-) system. And this with good old SSE2 and SSSE3 instruction sets. AVX2 would be even faster but currently i am not too satisfied with it's advantage. Possibly it's faster on newer CPUs.

If the release would only consist of speed improvements, i could publish it within the next 3 days.

But i am also preparing an open source release of the decoder. I would definitely prefer a release in the C-language, but this would take a lot of time, probably more than i can invest now.  Therefore i will try the second best approach and migrate the Delphi-Code to Lazarus.

It's more work than one might expect. I am refactoring and tidying the code and i have to extract or sometimes replace small inline assembler sections. I may sacrifice some percent of speed for better readability and portability.

Hopefully most of this work will be done when i release 2.3.1.

The next version 2.4.0 should contain a decoder-library compiled with Lazarus. If this works well, i will release it's source code.

While the time i have to spend on Tak is a lot less than earlier (and also less calculable) i hope to release 2.3.1 in 2 to 4 weeks. With some luck 2.4.0 may take less than 3 additional months. No guarantee, but i am quite confident.

Next big step then could be the work on an open source Lazarus encoder library.

Interim releases to add other features are likely.

When the open source decoder has been published i may also reintroduce the dedicated LossyWav-Codec, which was part of an earlier beta release. It worked very well but seemed to be quite useless without an open source decoder implementation.

I know there is a lot more to do, but for now i will focus on the next 2 versions as outlined above.

Thank you for your interest - and patience

  Thomas

Re: TAK 2.3.0

Reply #87
Great news. Thanks, Thomas, for post. It is important to have any feedback from the developer.
“We are not stuff that abides, but patterns that perpetuate themselves.” – Norbert Wiener


Re: TAK 2.3.0

Reply #89
Nice to see Thomas is still there. Makes me curious to go and test and do some comparisons.

At this moment I have no idea how much software is compatible. I mainly use Foobar (which has support) but also Kodi and Volumio support would be great (haven't searched yet). Also curious to see which compression levels there are.

Re: TAK 2.3.0

Reply #90
Thanks for the info/news Thomas. :)

Re: TAK 2.3.0

Reply #91
Out of curiosity:

Planned features in order of current priority:

1. Unicode support


At the top of the source of your quote i had written:

"While i intended to port TAK to C, this looks unrealistic at the moment. Therefore the next version still has to be written in Delphi. Since my Delphi 6 ist lacking a lot required for the planned features, i finally bought an upgrade to Delphi XE 7 (There was a time limited offer for users of very old versions)."

Delphi XE 7 has built in unicode support. But unfortunately now (3 years later) it does not seem to be a good option for future TAK development. Embarcadero just wrote me, that they will no longer provide upgrade options for older versions. You have to subscribe to a permanent and costly update. For my purposes that's a killer... Last time i looked for a free version, it did not support 64 bit.

Therefore the planned step-wise switch to Lazarus. I wanted to start this as soon as possible to avoid the feeling of wasting time on an inadequate (because too costly) development tool. This obviously changed priorities.

But Unicode support still has a top priority.

BTW: My english skills did not benefit from the long absence. I hardly train them outside of hydrogen. When writing the text above, i had the feeling of beeing a bit unclear and omitting at least some nuances.

Re: TAK 2.3.0

Reply #92
Open source decoder would be great (and encoder as well. :) )

Not sure whether it was discussed.
According to http://www.audiograaf.nl/losslesstest/Lossless%20audio%20codec%20comparison%20-%20revision%204.pdf
p1 is better or equal to p0e/m by all parameters: decompression/compression speed and compression ratio.

Does it make p0e/m pretty irrelevant?

Re: TAK 2.3.0

Reply #93
No. Hidden in TAK's ReadMe:

"Each preset selects a set of internal encoder options. Some of them affect only the encoding speed, the others also the decoding speed.

Slower decoding usually means higher hardware requirements (memory size and/or cpu power) for a playback device. Some devices may be too weak to support the more demanding internal encoder options. But any option, which only affects the encoding speed and complexity, is always applicable.

Therefore each preset consists of two components:

  * The profile selects internal encoder options which affect both encoding and decoding speed. Profiles are declared as a number from 0 to 4 (fastest to strongest).

  * The evaluation level selects only internal encoder options, which have no effect on the decoding speed. The evaluation levels are named Standard, Extra and Max and abbreviated as s, e and m (fastest to strongest).

Presets are beeing declared as a combination of the profile and the abbreviated evaluation level (if not specified Standard is beeing used): 0 is the fastest, 4m the strongest setting.

A hardware manufacturer supporting TAK has only to specify the strongest profile it's hardware can decode, because the evaluation level does not affect the hardware requirements.

Hint: If you want higher compression and fast encoding, and are able to accept some decrease in decoding speed, it is usually preferable to select a higher profile instead of increasing the evaluation level."

 

Re: TAK 2.3.0

Reply #94

At the top of the source of your quote i had written:

"While i intended to port TAK to C, this looks unrealistic at the moment. Therefore the next version still has to be written in Delphi.

Hi TBeck,

I am the author of ImgDrive which could mount Cue sheets files of APE/FLAC/M4A/TTA/WAV/WV/BIN as AUDIO CD.
http://yubsoft.com/imgdrive/index.htm

i try to add support for TAK, which need DecodeTakFrame function implement in C and run in Ring 0 as kernel device driver. I have good skill of C/C++, if has some documentation or source code, i will help to port to C.

sorry for my bad english.

Re: TAK 2.3.0

Reply #95
Does it make p0e/m pretty irrelevant?
No. Hidden in TAK's ReadMe:
I hope you didn't mistake my brevity (caused by my bad english). It definitely wasn't meant as (R)ead (T)he (F)...ing (M)anual!

i try to add support for TAK, which need DecodeTakFrame function implement in C and run in Ring 0 as kernel device driver. I have good skill of C/C++, if has some documentation or source code, i will help to port to C.
sorry for my bad english.
You are very welcome! Even if you will not help me to improve my english...

TAK 2.3.1 (I like to call it the "Back to work"-release...) will again be faster. Currently the strongest mode -p4m encodes more than 20 percent faster on my (Haswell-) system. And this with good old SSE2 and SSSE3 instruction sets.
Well, now -p4m is about 30 percent faster. Time to prepare the beta release.

Re: TAK 2.3.0

Reply #96
I hope you didn't mistake my brevity (caused by my bad english). It definitely wasn't meant as (R)ead (T)he (F)...ing (M)anual!
Nah, it's not that.  :)
I've just assumed that there is [very old and/or slow] hardware where those presets (p0m/p0e) makes sense.
But still  p1 is better (or approx. equal in worst case) than p0m/p0e in all aspects (decoding/encoding speed, compression) even for  5-7+ years old CPU.

Good luck with a new release!

Re: TAK 2.3.0

Reply #97
I've just assumed that there is [very old and/or slow] hardware where those presets (p0m/p0e) makes sense.
But still  p1 is better (or approx. equal in worst case) than p0m/p0e in all aspects (decoding/encoding speed, compression) even for  5-7+ years old CPU.
IMHO it's the fastest possible setting that does make sense. Anything faster would compress significantly worse. It's using 4 predictors per sample, the minimum TAK permits. P1 is using 12 predictors like FLAC -8. One reason for these choices was to show what TAK can do when beeing restricted to similar cpu complexity as FLAC. Historical reasons...

Good luck with a new release!
Thank you  ::)

For other historical reasons i would have loved to publish my back-to-work release at April 1st. It was april fools day when i first posted about TAK (named YALAC then) and not many readers believed me. Nostalgia...

Well, if nothing unexpected happens i will perform the release one day too late.

Re: TAK 2.3.0

Reply #98
Given that ffmpeg people already made an open source decoder, and if you don't plan to change bitstream in a backward incompatible way, maybe it'd be better to focus solely on the encoder?
a fan of AutoEq + Meier Crossfeed

Re: TAK 2.3.0

Reply #99
Does this decoder support multi-channel-audio? I don't think so, but i may be wrong. And this would be sad, because TAK's multi-channel-encoder is really strong. I also put a lot of work into the decoders error robustness; hydrogenaudio's users helped a lot in testing this.

I would estimate the effort to prepare the encoder release as at least 3 times more than the decoder release (bad english..). Therefore omitting the decoder would not save so much time. And i prefer to start with something smaller.

And i also thought about the reintroduction of the dedicated LossyWav-codec which was part of an earlier beta release.

But maybe things will change when i start the work.