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

[Porcus]

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.

[IgorC]

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

[skamp]

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 of the TAK component works with the HDCD component.

[D404]

News!

http://ffmpeg.org/pipermail/ffmpeg-devel/2...ber/131785.html

[saratoga]

News!

http://ffmpeg.org/pipermail/ffmpeg-devel/2...ber/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.

[lvqcl]

http://ffmpeg.org/pipermail/ffmpeg-devel/2...ber/131785.html

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

So TAK was reverse engineered. What does it mean to its development and "market share"?

[Nick.C]

Hopefully, quite a lot if it ends up on Rockbox in the first instance.

[Dario]

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.

[saratoga]

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.

[TBeck]

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

[saratoga]

You should post on the ffmpeg mailing list. They'll probably have questions.

[TBeck]

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

[Porcus]

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

[smok3]

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.

This post has been edited by smok3: Oct 3 2012, 08:57

[C.R.Helmrich]

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 is likely the best example.

I guess you mean the old encoder. From 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

[saratoga]

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.

[Porcus]

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 is likely the best example.

I guess you mean the old encoder

I meant “has shipped”, I meant nothing about “does still”

[_m²_]

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

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.

This post has been edited by _m²_: Oct 4 2012, 21:03

[TBeck]

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

[saratoga]

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.

[mudlord]

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.

[Soap]

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.

[saratoga]

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.

[Soap]

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

[mudlord]

now all they needs to do is RE a TAK encoder.

Superb RE work BTW.