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

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

Reply #25
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.

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

Reply #26
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

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

Reply #27
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.




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

Reply #31
Hopefully, quite a lot if it ends up on Rockbox in the first instance.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

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

Reply #32
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.

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

Reply #33
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. 

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

Reply #34
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


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

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

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

Reply #36
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....

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

Reply #37
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

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

Reply #38
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.
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

 

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

Reply #39
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
If I don't reply to your reply, it means I agree with you.


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

Reply #41
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” 

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

Reply #42
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.

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

Reply #43
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

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

Reply #44
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.


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

Reply #45
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.

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

Reply #46
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.

Creature of habit.

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

Reply #47
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.

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

Reply #48
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...
Creature of habit.

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

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

Superb RE work BTW.