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 codec (Any news, seems silent for some time) (Read 61896 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

TAK codec (Any news, seems silent for some time)

Hi Guys,

Thomas seems going silent for a period of time, any news or other developers working on TAK related GUI or something like "TAK drop"?

Also want to ask, any media player can DIRECT decode the HDCD signal inside TAK yet?

Thanks.

Hong Kong - International Joke Center (after 1997-06-30)

TAK codec (Any news, seems silent for some time)

Reply #1
I also have not heard much lately. Is there anything to suggest about window interface of TAK.EXE that is of interest?

I also do not know of the direct decoding of HDCD signal, would that be up to the media player rather than TAK? I am guessing the DShow filter also would not help with a media player that can not interpret a HDCD input. Maybe a good starting place would be to identify audio players that can accept HDCD input from a file that also are aware of DShow filters.
"Something bothering you, Mister Spock?"



TAK codec (Any news, seems silent for some time)

Reply #4
I also have not heard much lately. Is there anything to suggest about window interface of TAK.EXE that is of interest?

I also do not know of the direct decoding of HDCD signal, would that be up to the media player rather than TAK? I am guessing the DShow filter also would not help with a media player that can not interpret a HDCD input. Maybe a good starting place would be to identify audio players that can accept HDCD input from a file that also are aware of DShow filters.


Just wonder the latest AMD CPU have a lot of new commands, maybe can help speed up encoding ...

For GUI, I'm no designer but what I can think of is ... I've an ugly picture below:


Hong Kong - International Joke Center (after 1997-06-30)

TAK codec (Any news, seems silent for some time)

Reply #5
Cross-platform TAK binaries would be like a dream come true for me. The codec is pretty mature as it is, though, and so long as I use Windows it will remain my primary choice.

TAK codec (Any news, seems silent for some time)

Reply #6
Cross-platform TAK binaries would be like a dream come true for me. The codec is pretty mature as it is, though, and so long as I use Windows it will remain my primary choice.

TAK need a real cross-platform support so Linux and OSX can implement it easily, if TAK can successfully widespread,  there're one less headache in the digital world.

I'm a little bit worry about Thomas, he disappear for quite a long time.


Hong Kong - International Joke Center (after 1997-06-30)

TAK codec (Any news, seems silent for some time)

Reply #7
I think it is safe to say Thomas is still around and that he is still interested in continuing TAK.

My (unofficial) deductions of TAK development are:
- Cross-platform TAK support is interwoven with its user base, Windows still chief in that regard;
- Lack of lossless audio standard/adoption is seen with the stagnation of nearly all lossless codecs' development;
- Breaking TAK 2.x compatibility is a hindrance on further designs (my deduction, flame me if I am wrong).

On the last note, I do not see most current TAK users having issue with an updated TAK codec that would be backward compatible with versions 2.x and prior but required the newest decoder to work with files created with the newest encoder. Again, I am speculating and would rather rely on the discussion of the developer(s) and other users on this. I also speculate that other platforms might have to be patient for TAK support (for now).
"Something bothering you, Mister Spock?"

TAK codec (Any news, seems silent for some time)

Reply #8
I think it is safe to say Thomas is still around and that he is still interested in continuing TAK.

I guess so, since TAK is too charming, it's hard to bear ... without news, even only a new GUI that simply use it's library to encode.

Quote
On the last note, I do not see most current TAK users having issue with an updated TAK codec that would be backward compatible with versions 2.x and prior but required the newest decoder to work with files created with the newest encoder. Again, I am speculating and would rather rely on the discussion of the developer(s) and other users on this. I also speculate that other platforms might have to be patient for TAK support (for now).

TAK did a great job, it's excellent and I'm hesitating to get enough reasons for me, to change my whole FLAC collection.
FLAC is great also, this is a major problem for choose between one of them.
Hong Kong - International Joke Center (after 1997-06-30)

TAK codec (Any news, seems silent for some time)

Reply #9
For me, choice is obvious - open source, with multi-platform compatibility.
Error 404; signature server not available.

TAK codec (Any news, seems silent for some time)

Reply #10
For me, choice is obvious - open source, with multi-platform compatibility.


That's a reason I still kept most of my collection FLAC, but the compression ratio and efficiency of TAK really promising, so eyeballs keep waiting for good news from Thomas, he say TAK will be Open Source sometimes later, trust him.
Hong Kong - International Joke Center (after 1997-06-30)

TAK codec (Any news, seems silent for some time)

Reply #11
Well, yeah, TAK has it's strengths, but I live in NOW, not in 10 years THEN. Thomas might, or he might not, release it's codec as Open Source, or port it to linux and OS X.
And I'm old enough to be tired of will be's, could be's, should be's. I use what I have available now
Error 404; signature server not available.

TAK codec (Any news, seems silent for some time)

Reply #12
Pardon my saying, but I never understood the attitude that open-source is instantly future-proof, nor the argument saying a program is doomed if it does not release a new version X times a year. Sounds like FUD.

In yet another thread on this board was all sorts of doom and gloom over the idea the "leader" in lossless formats is doomed for all sorts of reasons. Again, mostly speculation and barely any confirmed news.

TAK is a "10 years ago" format? Hardly. The first public version was released in 2006 and the latest version released in 2011. In a quick glance I counted over 12 non-beta public releases.

As other persons suggest to critics: why not make a new and better lossless codec and make it open-source and see how it feels to be demanded for licensing obligations and release schedules without a team of full-time software developers?

But enough of this old, tired train of thought...

I asked earlier (although obscurely) in this thread: would existing TAK users care if compatibility was changed again for future expansion? (Backwards-compatibility would still be supported, of course.) Maybe a fresh direction for development would be welcome rather than boxing the codec into a corner with ultimatums like, "Make it open-source, or else be criticized."

edit: I correct myself- 10 public non-beta TAK releases starting in 2007.
"Something bothering you, Mister Spock?"

TAK codec (Any news, seems silent for some time)

Reply #13
You misunderstood what I've been saying. I work in different environments - Windows at home, at work it's windows, linux and a little bit of OS X. I have most of my music in FLAC format on two machines, and I access it form two different OSes. FLAC is working natively on both of them, and it's open source - for me, as an end user, it means it's totally free to use it however I see fit. I can freely encode and decode files with it, on any OS I use. Ah, and it's decodeable on WDTV Live which I use at home.

That is not the case with TAK. It exists only as windows binary, it hasn't been ported to linux or OS X, so I can't use it natively, and I refuse to use it through some kind of wrapper. Thomas could make (or give someone to make) native linux and OS X applications, that could happen tomorrow, in 10 years, or never. And I don't want to wait or to be limited to only one platform. I'm a user, not fanatic about encoding format.

And why do you think I criticise Thomas about not opening his codec as Open Source? I don't give rat's ass about if he's ever going to do that or not, it's his decision, not mine. It's his codec and his work, and he can do with it whatever he wants, for what I care. I just won't be using it until there is encoding-decoding support for all platforms - in open source format or just regular freeware. And that is my own decision, based on my own preferences.
Error 404; signature server not available.

TAK codec (Any news, seems silent for some time)

Reply #14
My comment regarded the licensing issue having already been beaten to death. Open-source does not equate to future-proof and multi-platform. I personally use many lossless codecs for different tasks, each for their individual strengths (I designated TAK for my audio CD images). Cross platform TAK is not something I would hold my breath for. The only cross-platform lossless format I find useful (in an active project) is PCM WAV/AIFF, arguably the one and only true industry standard.

As to the topic...

I do not think I am am the only user willing to be flexible with TAK breaking existing 2.x compatibility if it means the author has a better experience with development. Who knows? Maybe a format change is necessary for other possibilities already requested.
"Something bothering you, Mister Spock?"

TAK codec (Any news, seems silent for some time)

Reply #15
Yes, it became a bit silent. Sometimes i am missing those early days, when i released many test versions and was impatiently waiting for results to see, if the latest optimizations worked well. This was exciting for me and for many testers. Yeah, this was some kind of entertainment!

BTW: I am reading the hydrogen posts on a daily base, but i usually don't have time to answer immideately. Well, there are also a lot of unanswered mails too... Sorry.

As a result of the extensive tuning before the first stable release, there was not much opportunity left to tune the codec further. At some point it's getting more and more difficult to optimize. New processors with new instructions sets can provide opportunities to improve the speed, but the (in some post) mentioned new AMD cpus can't help TAK. I always had possible hardware implementations in mind, and this usually means fast integer implementations, to my knowledge the new AMD cpus only provide improvements for floating point optimizations. But when Intel releaseses their new cpus with AVX-256-Bit integer instructions, i will jump on the train...

So, what was left to do:

V 2.0 (which required a format change) provided relatively small improvements, but the effort to achieve them was quite large. And it would be even more (time wise) expensive to achieve more improvements. It's getting harder and harder. Another point: I am still looking for opportunities to improve the compression ratio, but all i have tried had a very significant effect on the encoding speed (10 to 50 times slower). That's not a good thing, if you want your codec to be associated with speed. Notice: I am still trying a lot, but because nothing worked very well, i don't post about it.

Conclusion: Currently little chance to improve the CD-Audio-compression performance.

Therefore i worked on other things:

V 2.1 initially included a specialized codec for LossyWav-compressed files. But there was very little interest (understandable, if you want to use such files to replace conventionally lossy compressed ones, you usually need hardware playback capabilities, which TAK is lacking).

V2.2 brought the probably most efficient (if you also take speed into account) compression for multi-channel-audio. But that's also only relevant for a small group of users. Possibly more for the video guys, but they would need an open source version of TAK integrated into their video tools.

Currently i have very liitle time i could invest into TAK. To do so, the task has to be attractive. Well, if i get a new exciting idea...

But i still love TAK (developers are allowed to say something like this about their work, i hope) and i definitely want it to have a great future. I am thinking about strategies to spread it. I have some plans, but i don't want to talk about them, this because of bad experiences in the past, when i was to enthusiastic and made promises i couldn't keep. You will hear about it, when i'ts done. And i hope, it will get a bit better than the latest Duke Nukem game... 

  Thomas

TAK codec (Any news, seems silent for some time)

Reply #16
Another point: I am still looking for opportunities to improve the compression ratio, but all i have tried had a very significant effect on the encoding speed (10 to 50 times slower). That's not a good thing, if you want your codec to be associated with speed. Notice: I am still trying a lot, but because nothing worked very well, i don't post about it.


If you still after these years see the fun in finding room for improvement, then ... did you use much noise music in development? I checked my least-FLACable album and it turned out to be even less TAK-able: http://www.hydrogenaudio.org/forums/index....st&p=800823 .  Of course it is only one album, and that's not much of a statistic. Anyway, some figures for the least compressible track (#3, now playing):

1307 for WavPack extra high (not holding my breath)
1395 for FLAC -8
1399 for FLAC -0
1400 for WavPack fast
1402 for WavPack normal (!)
100.04 % for TAK -p4m, reported by Tak.exe (2.2.0) -- indeed, file sizes are 58 178 123 bytes for .wav and 58 198 718 for .tak.
100.96 % for TAK -p0


Cheers from YALAuwivibusoC #666
(Yet Another Lossless Audio user who is very impressed but uses some other Codec)

TAK codec (Any news, seems silent for some time)

Reply #17
...And why do you think I criticise Thomas about not opening his codec as Open Source? I don't give rat's ass about if he's ever going to do that or not, it's his decision, not mine. It's his codec and his work, and he can do with it whatever he wants, for what I care. I just won't be using it until there is encoding-decoding support for all platforms - in open source format or just regular freeware. And that is my own decision, based on my own preferences.


World and dog, minus a 'couple of dozen' users, TAK no notice...an irrelevance, a hobby and nothing wrong in that but it's going nowhere and never will.

TAK codec (Any news, seems silent for some time)

Reply #18
All lossless formats are going nowhere when considering they all succeeded in outputting identical audio data. In my experience from the beginning, all lossless formats were neck-in-neck. I elaborate on this by mentioning the main aspects to handle are: compression ratio, speed(encoding/decoding) and efficiency(encoding/decoding). Usually gains of either of the first two usually sacrificed the latter. TAK proved to be an exception to what previously existed and its merits are largely indisputable. Naturally, people want more and request* their specific needs to be catered to.

In the world of digital audio, lossless audio compression is a niche at best. Just the same, I do not find using any lossless audio compressor risky. So, if ALAC takes over the world it just means I have to spend two minutes to learn its command line (for decoding  ).

The next breakthrough for lossless audio compression will likely take advantage of powerful processor functions as well as multi-processor capabilities. This has already begun. Another area might be mobile, but I think it would be better to have one's music library encoded with Opus in cloud storage for on-the-air streaming (I think of mobile devices with limited memory and lack of a microSD slot).

I believe it has been well known for years the theoretical limitations of the ratio expected with lossless audio- particularly CD's. It seems obvious the next step forward for lossless compressors are ways to better compress heavily dynamically compressed music, since most lossless audio compressors already do well on regular organic music. Nowadays with the loud modern recordings (in addition to louder reissues of older albums) this could be an area to raise the bar. It may also involve a completely different technology that in its infant stages would run very slow. This is not how TAK works. My understanding is TAK does not employ exhaustive, brute-force methods on audio compression, but rather uses a much more elegant method by utilizing a sub-set of filters that have been well-tested and proven. (100% of the thanks goes to the author for that.  )

I have many 32-bit float files that can not be negotiated by the existing version of TAK, but being I use it for all my CD images hardly makes TAK useless, irrelevant and going nowhere unless CD's stop being pressed.


* euphemism
"Something bothering you, Mister Spock?"

TAK codec (Any news, seems silent for some time)

Reply #19
Pardon my saying, but I never understood the attitude that open-source is instantly future-proof, nor the argument saying a program is doomed if it does not release a new version X times a year. Sounds like FUD.


Well from my point of view it makes perfect sense, since if I have the source code I can just add support for the format to rockbox and use it on my hardware + phone

TAK codec (Any news, seems silent for some time)

Reply #20
Pardon my saying, but I never understood the attitude that open-source is instantly future-proof, nor the argument saying a program is doomed if it does not release a new version X times a year. Sounds like FUD.


Well from my point of view it makes perfect sense, since if I have the source code I can just add support for the format to rockbox and use it on my hardware + phone



WRONG.

TAK is Delphi, so unless you can get it working under FreePascal, good luck.

TAK codec (Any news, seems silent for some time)

Reply #21
WRONG.

TAK is Delphi, so unless you can get it working under FreePascal, good luck.


Two things:

1)  I didn't say anything about TAK, since there is no decoder source available (AFAIK).

2)  Lossless decoders are fairly simple.  I don't really care about TAK, but given Delphi source code, it wouldn't be that hard to port a decoder to any given platform if someone wanted to.  I've certainly ported worse.

TAK codec (Any news, seems silent for some time)

Reply #22
Sidenote: even though I said that lossless on mobile devices seemed unnecessary (as being overkill for casual listening) I am interested in seeing Windows 8 mobile devices will running x86 programs. I am not a paid advocate of the OS but I have an interest in a PDA that handles existing Windows apps. With good x86 compatibility I think TAK would perform well on upcoming Windows mobiles (I imagine more of an ARM issue than an Intel one). And FB2K on a handheld mobile device? I think few HA users would like that
"Something bothering you, Mister Spock?"

TAK codec (Any news, seems silent for some time)

Reply #23
Yep please make the takdecolib component opensource, or atleast provide other platforms counterparts, whatever dll or static lib counts. I understand making the code in Delphi introduces significant holdback for the question of  possible future portability without which this otherwise awesome codec loses chances to move closer to become acceptable standard for wide range music interchange and direct playability.