HydrogenAudio

Lossless Audio Compression => Lossless / Other Codecs => Topic started by: johnsonlam on 2012-09-13 05:06:29

Title: TAK codec (Any news, seems silent for some time)
Post by: johnsonlam on 2012-09-13 05:06:29
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.

Title: TAK codec (Any news, seems silent for some time)
Post by: Destroid on 2012-09-13 07:00:47
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.
Title: TAK codec (Any news, seems silent for some time)
Post by: skamp on 2012-09-13 09:05:59
Try foobar2000 (http://www.foobar2000.org/) with the TAK decoder component (http://www.foobar2000.org/components/view/foo_input_tak) and the HDCD decoder component (http://www.foobar2000.org/components/view/foo_hdcd).
Title: TAK codec (Any news, seems silent for some time)
Post by: johnsonlam on 2012-09-13 11:33:06
Try foobar2000 (http://www.foobar2000.org/) with the TAK decoder component (http://www.foobar2000.org/components/view/foo_input_tak) and the HDCD decoder component (http://www.foobar2000.org/components/view/foo_hdcd).


I'm using Foobar2000 already, but for some strange reason (I'm no programming guy).
TAK encoded HDCD can play but lost the HDCD decoding ability.
Title: TAK codec (Any news, seems silent for some time)
Post by: johnsonlam on 2012-09-13 11:50:12
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:

(http://dl.dropbox.com/u/15785527/tak_drop.png)
Title: TAK codec (Any news, seems silent for some time)
Post by: Dario on 2012-09-13 13:20:52
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.
Title: TAK codec (Any news, seems silent for some time)
Post by: johnsonlam on 2012-09-14 03:41:02
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.


Title: TAK codec (Any news, seems silent for some time)
Post by: Destroid on 2012-09-16 11:23:57
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).
Title: TAK codec (Any news, seems silent for some time)
Post by: johnsonlam on 2012-09-16 16:06:03
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.
Title: TAK codec (Any news, seems silent for some time)
Post by: itisljar on 2012-09-16 16:15:01
For me, choice is obvious - open source, with multi-platform compatibility.
Title: TAK codec (Any news, seems silent for some time)
Post by: johnsonlam on 2012-09-18 12:39:27
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.
Title: TAK codec (Any news, seems silent for some time)
Post by: itisljar on 2012-09-18 13:57:06
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
Title: TAK codec (Any news, seems silent for some time)
Post by: Destroid on 2012-09-19 11:14:28
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.
Title: TAK codec (Any news, seems silent for some time)
Post by: itisljar on 2012-09-19 17:34:33
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.
Title: TAK codec (Any news, seems silent for some time)
Post by: Destroid on 2012-09-19 18:27:23
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.
Title: TAK codec (Any news, seems silent for some time)
Post by: TBeck on 2012-09-21 20:59:08
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
Title: TAK codec (Any news, seems silent for some time)
Post by: Porcus on 2012-09-23 15:02:38
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 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=95670&view=findpost&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)
Title: TAK codec (Any news, seems silent for some time)
Post by: quackalist on 2012-09-23 19:23:54
...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.
Title: TAK codec (Any news, seems silent for some time)
Post by: Destroid on 2012-09-23 22:34:57
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
Title: TAK codec (Any news, seems silent for some time)
Post by: saratoga on 2012-09-23 23:07:31
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
Title: TAK codec (Any news, seems silent for some time)
Post by: mudlord on 2012-09-24 02:25:27
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.
Title: TAK codec (Any news, seems silent for some time)
Post by: saratoga on 2012-09-24 02:44:31
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.
Title: TAK codec (Any news, seems silent for some time)
Post by: Destroid on 2012-09-25 02:21:54
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
Title: TAK codec (Any news, seems silent for some time)
Post by: Anakunda on 2012-09-25 05:31:31
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.
Title: TAK codec (Any news, seems silent for some time)
Post by: greynol on 2012-09-25 05:35:38
Please give it a rest.
Title: TAK codec (Any news, seems silent for some time)
Post by: Porcus on 2012-09-25 12:02:10
loses chances to move closer to become acceptable standard for wide range music interchange and direct playability


I guess it is too late for that anyway. Well, if developers of a major format would want so much of an update that they are willing to sacrifice forward compatibility, then they could do far worse than sending TBeck an e-mail.  (Breaking compatibility would likely be 'far worse' than anything. Unless your format e.g. needs to be updated for multichannel.) So until the bigger fish (/fruits) cast their eyes on TAK (and that is not very likely, and it is even less likely to be up to TBeck's choice of release format), it is unlikely to achieve world domination.

Then there are other success criteria, of course. There are a lot of researchers who work their asses off in narrow niches just to be recognized and respected as one of the absolutely baddest guns in town.
Title: TAK codec (Any news, seems silent for some time)
Post by: IgorC on 2012-09-25 14:11:02
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

http://marketshare.hitslink.com/operating-...amp;qpcustomd=1 (http://marketshare.hitslink.com/operating-system-market-share.aspx?qprid=8&qpcustomd=1)
Title: TAK codec (Any news, seems silent for some time)
Post by: skamp on 2012-09-29 15:53:24
I'm using Foobar2000 already, but for some strange reason (I'm no programming guy).
TAK encoded HDCD can play but lost the HDCD decoding ability.


The latest version (http://www.foobar2000.org/components/view/foo_input_tak) of the TAK component works with the HDCD component.
Title: TAK codec (Any news, seems silent for some time)
Post by: D404 on 2012-10-02 15:55:10
News!

http://ffmpeg.org/pipermail/ffmpeg-devel/2...ber/131785.html (http://ffmpeg.org/pipermail/ffmpeg-devel/2012-September/131785.html)
Title: TAK codec (Any news, seems silent for some time)
Post by: saratoga on 2012-10-02 17:19:35
News!

http://ffmpeg.org/pipermail/ffmpeg-devel/2...ber/131785.html (http://ffmpeg.org/pipermail/ffmpeg-devel/2012-September/131785.html)


Decoder looks quite clean.  No idea about correctness, but assuming it works that should be pretty easy to use on portable devices or phones.
Title: TAK codec (Any news, seems silent for some time)
Post by: lvqcl on 2012-10-02 17:21:48
http://ffmpeg.org/pipermail/ffmpeg-devel/2...ber/131785.html (http://ffmpeg.org/pipermail/ffmpeg-devel/2012-September/131785.html)

And https://github.com/richardpl/FFmpeg/tree/TAK (https://github.com/richardpl/FFmpeg/tree/TAK)

So TAK was reverse engineered. What does it mean to its development and "market share"?
Title: TAK codec (Any news, seems silent for some time)
Post by: Nick.C on 2012-10-02 18:43:55
Hopefully, quite a lot if it ends up on Rockbox in the first instance.
Title: TAK codec (Any news, seems silent for some time)
Post by: Dario on 2012-10-03 00:56:39
Hold on a sec. I'm pretty familiar with reverse-engineering, but how do such decoders cope with the ‘originals’? Would the reverse-engineered one, for example, be slower and more error-prone than the tak_deco_lib.dll?

Please enlighten me, this matter is quite interesting to me.
Title: TAK codec (Any news, seems silent for some time)
Post by: saratoga on 2012-10-03 02:19:43
Hold on a sec. I'm pretty familiar with reverse-engineering, but how do such decoders cope with the ‘originals’? Would the reverse-engineered one, for example, be slower and more error-prone than the tak_deco_lib.dll?


Depends on how good the implementation is. 
Title: TAK codec (Any news, seems silent for some time)
Post by: TBeck on 2012-10-03 02:20:15
Well, mixed feelings here...

First reaction was a bit shocked and somehow relieved, quite ambivalent overall. Some brainstorming (first thoughts, unfiltered):

It feels a bit strange to see source code implementing my ideas with a foreign copyright notice not even mentioning me. Would i be allowed to use it?

On the other hand there is quite a lot of respect for the work of the reverse engineer. And probably someone has to have good reasons to invest so much time. I take it as a compliment for TAK's performance.

I said, i am feeling a bit relieved. That, because it was anyhow my plan to release the source code of the decoder, but given my current time constraints it was quite uncertain when this could happen. If this reverse engineered version is making users happy, i am happy too.

I haven't investigated the source code for compliance, no time for it now. But i am interested into a reliebale and fast implementation. Therefore i *will* (do i really like to feel forced?) have to contact the developer and send him my decoder source code (as soon as i have tidied it up).

What does this mean for future developments?

Well, possibly less freedom for me to implement new ideas breaking backwards compatibility. But this only, if we can't establish a good contact between me and the decoder developer.

  Thomas

Title: TAK codec (Any news, seems silent for some time)
Post by: saratoga on 2012-10-03 03:14:04
You should post on the ffmpeg mailing list.  They'll probably have questions.
Title: TAK codec (Any news, seems silent for some time)
Post by: TBeck on 2012-10-03 03:51:41
You should post on the ffmpeg mailing list.  They'll probably have questions.

I did.

Well, i hope so. I am not familar with such mailing lists....
Title: TAK codec (Any news, seems silent for some time)
Post by: Porcus on 2012-10-03 08:11:02
I haven't investigated the source code for compliance, no time for it now. But i am interested into a reliebale and fast implementation. Therefore i *will* (do i really like to feel forced?) have to contact the developer and send him my decoder source code (as soon as i have tidied it up).


If you don't like the thought of 'being forced to', then you might consider as an argument the fact that ffmpeg has shipped with tools that should certainly not be considered state-of-the-art. The AAC encoder (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=89208&view=findpost&p=761235) is likely the best example.
If your best guess is that users who encounter issues with ffmpeg will blame ffmpeg and not TAK, you might just wait and see. If your best guess is that TAK will get the blame, then ... well, you would feel 'forced' to contribute a repair.

I still think that a compression format without source code should be considered undocumented though
Title: TAK codec (Any news, seems silent for some time)
Post by: smok3 on 2012-10-03 08:53:41
Quote
Well, possibly less freedom for me to implement new ideas breaking backwards compatibility. But this only, if we can't establish a good contact between me and the decoder developer.


Why is that? (just curiousness)

- if reversed decoder in not-compliant, make a note on your download page
- if it is compliant, then when you break the compatibility just make-up a new name, like TAK2
- ffmpeg including the decoder will make it star for decades 

no force.
Title: TAK codec (Any news, seems silent for some time)
Post by: C.R.Helmrich on 2012-10-03 11:00:48
If you don't like the thought of 'being forced to', then you might consider as an argument the fact that ffmpeg has shipped with tools that should certainly not be considered state-of-the-art. The AAC encoder (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=89208&view=findpost&p=761235) is likely the best example.

I guess you mean the old encoder. From http://ffmpeg.org/ (http://ffmpeg.org/): "September, 28, 2012, FFmpeg 1.0, ... AAC encoding via libfdk-aac"

Looking forward to a verified open-source decoder implementation of TAK. Seems like a good piece of engineering.

Chris
Title: TAK codec (Any news, seems silent for some time)
Post by: saratoga on 2012-10-03 15:57:32
You should post on the ffmpeg mailing list.  They'll probably have questions.

I did.

Well, i hope so. I am not familar with such mailing lists....


Got it now, thanks.  Sorry to miss it before.
Title: TAK codec (Any news, seems silent for some time)
Post by: Porcus on 2012-10-03 18:39:37
If you don't like the thought of 'being forced to', then you might consider as an argument the fact that ffmpeg has shipped with tools that should certainly not be considered state-of-the-art. The AAC encoder (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=89208&view=findpost&p=761235) is likely the best example.

I guess you mean the old encoder


I meant “has shipped”, I meant nothing about “does still” 
Title: TAK codec (Any news, seems silent for some time)
Post by: _m²_ on 2012-10-04 21:00:39
Very interesting. TAK may not be lost for me after all...An encoder would still be needed though.

News!

http://ffmpeg.org/pipermail/ffmpeg-devel/2...ber/131785.html (http://ffmpeg.org/pipermail/ffmpeg-devel/2012-September/131785.html)

Tom, as to copyright, it doesn't cover ideas, only their expression. Therefore it's perfectly legal to claim full copyright on self-coded piece regardless of others' efforts in the field.
Title: TAK codec (Any news, seems silent for some time)
Post by: TBeck on 2012-10-04 21:33:01
Quote
Well, possibly less freedom for me to implement new ideas breaking backwards compatibility. But this only, if we can't establish a good contact between me and the decoder developer.


Why is that? (just curiousness)

- if reversed decoder in not-compliant, make a note on your download page
- if it is compliant, then when you break the compatibility just make-up a new name, like TAK2
- ffmpeg including the decoder will make it star for decades 

no force.

I don't want users to get into trouble with not-compliant implementations. I know myself: There are a lot of applications where i am the I-simply-want-it-to-work-guy... Therefore i feel forced to do anything to facilitate compliant implementations.

For not-backwards-compatible new codec features: Now there is at least one other implementations which has to be updated, what always implies the chance of bugs. I have to think twice if the possibly small improvements are worth the hassle.

- ffmpeg including the decoder will make it star for decades 

I have to admit: This indeed sounds cool... 

Tom, as to copyright, it doesn't cover ideas, only their expression. Therefore it's perfectly legal to claim full copyright on self-coded piece regardless of others' efforts in the field.

You are right. As i wrote, i expressed my first reactions brainstorming wise. On second thought this became clear.

I am still excitited and a bit confused beacuse of those new developments. Ok, bad timing, because i have so little time because i am involved into other projects.

Currently my preference is what i actually didn't want to do: To release the source code of the tak_deco_lib.dll as Delphi/Pascal and probably without a chance/enough time to bring it to a shape i regard as really acceptable.

  Thomas
Title: TAK codec (Any news, seems silent for some time)
Post by: saratoga on 2012-10-04 22:34:47
Currently my preference is what i actually didn't want to do: To release the source code of the tak_deco_lib.dll as Delphi/Pascal and probably without a chance/enough time to bring it to a shape i regard as really acceptable.


You could also privately release the code to the ffmpeg developer and then let them figure it out.

Title: TAK codec (Any news, seems silent for some time)
Post by: mudlord on 2012-10-04 22:50:35
Currently my preference is what i actually didn't want to do: To release the source code of the tak_deco_lib.dll as Delphi/Pascal and probably without a chance/enough time to bring it to a shape i regard as really acceptable.


Not really a excuse. I seen source released that was messy as hell. "Making it clean" is a common excuse for people not releasing source. And Pascal makes no difference either.
Title: TAK codec (Any news, seems silent for some time)
Post by: Soap on 2012-10-04 23:10:11
TBeck, something to think about:  (Note I'm attempting not to argue either way on releasing your code, after all it's yours)

IIRC (do I?) you expressed a bit of shock when Saratoga published here his quick-and-dirty reverse engineerign of the TAK bitstream, similar to the surprise at an (apparently) functional decoder @ ffmpeg.

My only point being that many of the people who enjoy reversing are disturbingly good at doing it - without code.  Much less with - regardless of condition.

You mentioned your other time consuming projects as well as your desire to clean up your existing code before publishing.  If I understand correctly a strong motivator in your eyes at this point for publishing would be to ensure a fully compliant decoder.

Might I propose that handing off the source code (if that is your true desire) and answering any arising questions from the ffmpeg developer via email would take much less of your time than actually cleaning the pascal code itself.

Title: TAK codec (Any news, seems silent for some time)
Post by: saratoga on 2012-10-05 00:53:49
IIRC (do I?) you expressed a bit of shock when Saratoga published here his quick-and-dirty reverse engineerign of the TAK bitstream, similar to the surprise at an (apparently) functional decoder @ ffmpeg.


FWIW, i didn't look into reverse engineering TAK, I just said that eventually someone would do it for ffmpeg, since eventually nearly all undocumented formats are reverse engineered.
Title: TAK codec (Any news, seems silent for some time)
Post by: Soap on 2012-10-05 00:55:18
FWIW, i didn't look into reverse engineering TAK, I just said that eventually someone would do it for ffmpeg, since eventually nearly all undocumented formats are reverse engineered.


Right, I didn't think you (?) had tried to RE TAK, but published a quick outline of how the bitstream was constructed.  Perhaps my memory is failing me...
Title: TAK codec (Any news, seems silent for some time)
Post by: mudlord on 2012-10-05 01:04:08
now all they needs to do is RE a TAK encoder.

Superb RE work BTW.
Title: TAK codec (Any news, seems silent for some time)
Post by: jido on 2012-10-05 17:52:39
The code of the decoder looks tidy. I can't wait to give it a try...
Title: TAK codec (Any news, seems silent for some time)
Post by: skamp on 2012-10-05 18:17:17
Nice! A few quirks though:
Title: TAK codec (Any news, seems silent for some time)
Post by: mycroft on 2012-10-06 01:33:04
First two issues should be resolved in latest version - available on github - until merged with FFmpeg. Please report any issues found with this version.
Last issue is probably because deadbeef(and bunch of other lavc users) does not support/recognize planar sample formats - this one have nothing to do with this decoder.
Title: TAK codec (Any news, seems silent for some time)
Post by: skamp on 2012-10-11 10:37:18
First two issues should be resolved in latest version - available on github - until merged with FFmpeg.


I see it has been merged into ffmpeg. Those issues are indeed solved

Last issue is probably because deadbeef(and bunch of other lavc users) does not support/recognize planar sample formats - this one have nothing to do with this decoder.


What are planar sample formats? How does the TAK decoder differ from, say, the ALAC decoder (which works with deadbeef's ffmpeg plugin)?
Title: TAK codec (Any news, seems silent for some time)
Post by: bandpass on 2012-10-11 11:01:05
What are planar sample formats?

I also came across this recently. AFAICT, it's a term used by (invented by?) ffmpeg to describe when multi-channel data is stored/transported one channel per buffer/stream, as opposed to being interleaved in a single buffer/stream.
Title: TAK codec (Any news, seems silent for some time)
Post by: Zergen on 2013-01-07 21:57:17
New version of ffmpeg (1.1) officially supports TAK decoding. I checked on a couple of files - don't see any problems in decoding.
Title: TAK codec (Any news, seems silent for some time)
Post by: skamp on 2013-01-08 08:18:22
There's one major problem though: as far as I can tell, ffmpeg only outputs 16 bit audio.
Title: TAK codec (Any news, seems silent for some time)
Post by: mycroft on 2013-01-08 12:29:05
That is just untrue.
Title: TAK codec (Any news, seems silent for some time)
Post by: skamp on 2013-01-08 13:08:57
Decoding a 24 bit TAK file with ffmpeg git:

Code: [Select]
ffmpeg -i foo.tak bar.wav
ffmpeg version git-2013-01-08-ff6b340 Copyright © 2000-2013 the FFmpeg developers
  built on Jan  8 2013 14:04:24 with gcc 4.7.2 (GCC)
  configuration: --prefix=/usr --enable-gpl --enable-libass --enable-libfaac --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-nonfree --enable-x11grab
  libavutil      52. 13.100 / 52. 13.100
  libavcodec    54. 86.100 / 54. 86.100
  libavformat    54. 59.106 / 54. 59.106
  libavdevice    54.  3.102 / 54.  3.102
  libavfilter    3. 32.100 /  3. 32.100
  libswscale      2.  1.103 /  2.  1.103
  libswresample  0. 17.102 /  0. 17.102
  libpostproc    52.  2.100 / 52.  2.100
[tak @ 0x1807740] max_analyze_duration 5000000 reached at 5124535
Guessed Channel Layout for  Input Stream #0.0 : stereo
Input #0, tak, from 'foo.tak':
  Duration: 00:00:28.33, start: 0.000000, bitrate: 891 kb/s
    Stream #0:0: Audio: tak, 44100 Hz, stereo, s32p
Output #0, wav, to 'bar.wav':
  Metadata:
    ISFT            : Lavf54.59.106
    Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, stereo, s16, 1411 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (tak -> pcm_s16le)
Press [q] to stop, [?] for help
size=    4881kB time=00:00:28.33 bitrate=1411.2kbits/s   
video:0kB audio:4881kB subtitle:0 global headers:0kB muxing overhead 0.001601%

The result is a 16 bit WAV file. The same used to be true with their FLAC decoder in ffmpeg version 1.0. (https://ffmpeg.org/trac/ffmpeg/ticket/210)
Title: TAK codec (Any news, seems silent for some time)
Post by: mycroft on 2013-01-08 14:37:18
Yes and that is normal, default codec for wav is 16 bit pcm. You need to add -acodec pcm_s24le.

The link you mentioned have nothing with this "issue", because flac encoder in FFmpeg got 24 bit support recently, and decoder supported 24 bit for ages.

Title: TAK codec (Any news, seems silent for some time)
Post by: skamp on 2013-01-08 14:44:49
I see. One shouldn't need to manually select the output format though, the default here is just wrong.
Title: TAK codec (Any news, seems silent for some time)
Post by: DOS386 on 2013-02-04 14:00:20

Quote
http://ffmpeg.org/pipermail/ffmpeg-devel/2...ber/131785.html (http://ffmpeg.org/pipermail/ffmpeg-devel/2012-September/131785.html)


Is this all (sufficient to decode all TAK files) ?

Quote
It feels a bit strange to see source code implementing my ideas with a foreign copyright notice not even mentioning me.


Indeed. Can't they add "This implements a decoder of the TAK audio codec by Thomas Becker" ??? They don't even write what the code is supposed to do :-\

Quote
don't want users to get into trouble with not-compliant implementations. I know myself: There are a lot of applications where i am the I-simply-want-it-to-work-guy... Therefore i feel forced to do anything to facilitate compliant implementations.
Quote


Did a short test: encode with TAK 1.1.1, decode with FFMPEG 1.1.1 - Result:

(http://jafile.com/uploads/dos386/takffm.png)

Red uncomprehensive complains 1'000'000'000'000 times :-(
Title: TAK codec (Any news, seems silent for some time)
Post by: DOS386 on 2013-02-04 15:17:08
Quote
Did a short test: encode with TAK 1.1.1, decode with FFMPEG 1.1.1 - Result:

Red uncomprehensive complains 1'000'000'000'000 times


Retest with TAK 2.2.0:

FFMPEG is able to decode it :-) But size is bad ... extra junk in the WAV header ... removing it ... audio PCM data is identical :-) Conclusion: FFMPEG is a not-compliant implementation as it fails to decode TAK 1.1.1 and fails to brew a useful message ... and the limitations are nowhere documented (should say "only TAK 2.xx").
Title: TAK codec (Any news, seems silent for some time)
Post by: mzso on 2013-06-23 22:18:50
I think in the worst case you would have to transcode your files from TAK to another format. If i would quit the work on TAK and new operating systems would  drop support for the latest release (for instance if windows would no longer support 32-bit-applications), you probably would have years left to perform the transition. But ok, this would mean a lot of work.

This might sound a bit harsh, but if you have traced the TAK development threads a couple of years ago, you possibly will understand.
aa
I made promisese regarding an open source release, which i first could not and -at some point- did not want to keep. My biggest fault. I surely deserved critic, but there have also been a lot of inappropriate insults. And some members seemed to jump at any chance to attack me over and over again.

I don't want to make the same mistakes again. Therefore no promisese. I only can tell you my current attitude:

I would like to release an open source decoder. If i could snap with the fingers and it was there, i would do it. But unless someone donates me a magic wand, a lot of (not very exciting) work is required. And i don't know, when i will able to do it.

That's all i can say. Nothing more to add.

Not sure how these things work, but meanwhile wouldn't a format specification suffice? With that people could make decoders or encoders if they desire.
Title: TAK codec (Any news, seems silent for some time)
Post by: TBeck on 2013-06-25 11:14:04
Not sure how these things work, but meanwhile wouldn't a format specification suffice? With that people could make decoders or encoders if they desire.

That's a lot of work too. Given my limited time, i will first concentrate on an open source decoder.
Title: TAK codec (Any news, seems silent for some time)
Post by: saratoga on 2013-06-25 19:16:14
Not sure how these things work, but meanwhile wouldn't a format specification suffice? With that people could make decoders or encoders if they desire.

That's a lot of work too. Given my limited time, i will first concentrate on an open source decoder.


People tend to underestimate just how hard writing a decoder specification is.  I've seen a certain major software company release a specification that covered 2/3s of the format and then ended with 'for the rest look at the decoder source'

Were you planning to write a new decoder, or to work on the ffmpeg one?  FWIW, the ffmpeg one seemed to be of fairly high quality although maybe you had other opinions.
Title: TAK codec (Any news, seems silent for some time)
Post by: skamp on 2013-06-26 13:06:54
Thomas, just FYI, I can't link to your official web page because it's in german only. So for now, I'm going to link to the HA wiki entry: http://wiki.hydrogenaudio.org/index.php?title=TAK (http://wiki.hydrogenaudio.org/index.php?title=TAK)
Title: TAK codec (Any news, seems silent for some time)
Post by: TBeck on 2013-06-27 11:05:06
People tend to underestimate just how hard writing a decoder specification is.  I've seen a certain major software company release a specification that covered 2/3s of the format and then ended with 'for the rest look at the decoder source'

Yeah. And there will nearly always be ambiguities in the specification which make you want to look at the source code.

Were you planning to write a new decoder, or to work on the ffmpeg one?  FWIW, the ffmpeg one seemed to be of fairly high quality although maybe you had other opinions.

I haven't examined the ffmpeg decoder, but i am sure the ffmpeg people are very talented and i have little doubt that their decoder is of high quality. And BTW: Finally i really have to thank them for pushing me in the right direction (regarding an open source decoder release)... 

But i think, i will take the easiest and most safe way and base the decoder on my implementation. Even if it's probably a less suitable base for portability.

Thomas, just FYI, I can't link to your official web page because it's in german only. So for now, I'm going to link to the HA wiki entry: http://wiki.hydrogenaudio.org/index.php?title=TAK (http://wiki.hydrogenaudio.org/index.php?title=TAK)

Thank you!
Title: TAK codec (Any news, seems silent for some time)
Post by: boombaard on 2013-06-27 20:32:00
Thomas, I've recently found a few classical recordings that, compared to what I'm used to (a maximum difference of about 1% compression between p4m and monkey's audio extra high), compress quite badly with tak. (30kbps higher bitrate where the difference is usually between 1-4kbps.)
Would you like me to send you one or more of these files so you can have a look at why? The performances are of Brahms's first piano concerto and variations on a theme by Haydn, both orchestral works. Some hiss in the recording because of it being older (1955), and probably recorded live, or sub-par recording equipment, but I've seen recordings with much more hiss compress much better.
Title: TAK codec (Any news, seems silent for some time)
Post by: TBeck on 2013-06-30 21:47:45
Thank you for providing the test file.

Some hiss in the recording because of it being older (1955), and probably recorded live, or sub-par recording equipment, but I've seen recordings with much more hiss compress much better.

I will look at it, but i can't promise that i will be able to improve the compression. Anyhow a nice addition to my pool of special files, that i use to test new ideas for improvements.
Title: Re: TAK codec (Any news, seems silent for some time)
Post by: Supermansaga on 2022-09-30 07:45:31
Try foobar2000 (http://www.foobar2000.org/) with the TAK decoder component (http://www.foobar2000.org/components/view/foo_input_tak) and the HDCD decoder component (http://www.foobar2000.org/components/view/foo_hdcd).

HDCD component no longer works Foobar2000 v2.0 beta 10
Title: Re: TAK codec (Any news, seems silent for some time)
Post by: Porcus on 2022-09-30 07:52:15
That is completely unrelated to TAK, it is about 64-bit foobar2000 breaking compatibility with old components.
(64-bit compile here: https://hydrogenaud.io/index.php/topic,79427.msg1015635.html#msg1015635 )