IPB

Welcome Guest ( Log In | Register )

3 Pages V  < 1 2 3 >  
Reply to this topicStart new topic
TAK codec (Any news, seems silent for some time)
Porcus
post Sep 25 2012, 12:02
Post #26





Group: Members
Posts: 1842
Joined: 30-November 06
Member No.: 38207



QUOTE (Anakunda @ Sep 25 2012, 06:31) *
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.


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
IgorC
post Sep 25 2012, 14:11
Post #27





Group: Members
Posts: 1540
Joined: 3-January 05
From: ARG/RUS
Member No.: 18803



QUOTE (Destroid @ Sep 24 2012, 23:21) *
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 wink.gif

http://marketshare.hitslink.com/operating-...amp;qpcustomd=1
Go to the top of the page
+Quote Post
skamp
post Sep 29 2012, 15:53
Post #28





Group: Developer
Posts: 1412
Joined: 4-May 04
From: France
Member No.: 13875



QUOTE (johnsonlam @ Sep 13 2012, 12:33) *
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.


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
D404
post Oct 2 2012, 15:55
Post #29





Group: Members
Posts: 7
Joined: 30-July 08
Member No.: 56482



News!

http://ffmpeg.org/pipermail/ffmpeg-devel/2...ber/131785.html
Go to the top of the page
+Quote Post
saratoga
post Oct 2 2012, 17:19
Post #30





Group: Members
Posts: 4866
Joined: 2-September 02
Member No.: 3264



QUOTE (D404 @ Oct 2 2012, 10:55) *


Decoder looks quite clean. No idea about correctness, but assuming it works that should be pretty easy to use on portable devices or phones.
Go to the top of the page
+Quote Post
lvqcl
post Oct 2 2012, 17:21
Post #31





Group: Developer
Posts: 3339
Joined: 2-December 07
Member No.: 49183



QUOTE (D404 @ Oct 2 2012, 18:55) *

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

So TAK was reverse engineered. What does it mean to its development and "market share"?
Go to the top of the page
+Quote Post
Nick.C
post Oct 2 2012, 18:43
Post #32


lossyWAV Developer


Group: Developer
Posts: 1787
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



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


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
Dario
post Oct 3 2012, 00:56
Post #33





Group: Members
Posts: 158
Joined: 20-September 11
Member No.: 93842



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.
Go to the top of the page
+Quote Post
saratoga
post Oct 3 2012, 02:19
Post #34





Group: Members
Posts: 4866
Joined: 2-September 02
Member No.: 3264



QUOTE (Dario @ Oct 2 2012, 19:56) *
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.
Go to the top of the page
+Quote Post
TBeck
post Oct 3 2012, 02:20
Post #35


TAK Developer


Group: Developer
Posts: 1095
Joined: 1-April 06
Member No.: 29051



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

Go to the top of the page
+Quote Post
saratoga
post Oct 3 2012, 03:14
Post #36





Group: Members
Posts: 4866
Joined: 2-September 02
Member No.: 3264



You should post on the ffmpeg mailing list. They'll probably have questions.
Go to the top of the page
+Quote Post
TBeck
post Oct 3 2012, 03:51
Post #37


TAK Developer


Group: Developer
Posts: 1095
Joined: 1-April 06
Member No.: 29051



QUOTE (saratoga @ Oct 3 2012, 04:14) *
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....
Go to the top of the page
+Quote Post
Porcus
post Oct 3 2012, 08:11
Post #38





Group: Members
Posts: 1842
Joined: 30-November 06
Member No.: 38207



QUOTE (TBeck @ Oct 3 2012, 03:20) *
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 wink.gif


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
smok3
post Oct 3 2012, 08:53
Post #39


A/V Moderator


Group: Moderator
Posts: 1727
Joined: 30-April 02
From: Slovenia
Member No.: 1922



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

no force.

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


--------------------
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung
Go to the top of the page
+Quote Post
C.R.Helmrich
post Oct 3 2012, 11:00
Post #40





Group: Developer
Posts: 686
Joined: 6-December 08
From: Erlangen Germany
Member No.: 64012



QUOTE (Porcus @ Oct 3 2012, 09:11) *
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.
Go to the top of the page
+Quote Post
saratoga
post Oct 3 2012, 15:57
Post #41





Group: Members
Posts: 4866
Joined: 2-September 02
Member No.: 3264



QUOTE (TBeck @ Oct 2 2012, 22:51) *
QUOTE (saratoga @ Oct 3 2012, 04:14) *
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.
Go to the top of the page
+Quote Post
Porcus
post Oct 3 2012, 18:39
Post #42





Group: Members
Posts: 1842
Joined: 30-November 06
Member No.: 38207



QUOTE (C.R.Helmrich @ Oct 3 2012, 12:00) *
QUOTE (Porcus @ Oct 3 2012, 09:11) *
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” wink.gif


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
_m˛_
post Oct 4 2012, 21:00
Post #43





Group: Members
Posts: 231
Joined: 6-April 09
Member No.: 68706



Very interesting. TAK may not be lost for me after all...An encoder would still be needed though.

QUOTE (D404 @ Oct 2 2012, 16:55) *

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
Go to the top of the page
+Quote Post
TBeck
post Oct 4 2012, 21:33
Post #44


TAK Developer


Group: Developer
Posts: 1095
Joined: 1-April 06
Member No.: 29051



QUOTE (smok3 @ Oct 3 2012, 09:53) *
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 cool.gif

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.

QUOTE (smok3 @ Oct 3 2012, 09:53) *
- ffmpeg including the decoder will make it star for decades cool.gif

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

QUOTE (_m˛_ @ Oct 4 2012, 22:00) *
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
Go to the top of the page
+Quote Post
saratoga
post Oct 4 2012, 22:34
Post #45





Group: Members
Posts: 4866
Joined: 2-September 02
Member No.: 3264



QUOTE (TBeck @ Oct 4 2012, 16:33) *
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.

Go to the top of the page
+Quote Post
mudlord
post Oct 4 2012, 22:50
Post #46





Group: Developer (Donating)
Posts: 805
Joined: 1-December 07
Member No.: 49165



QUOTE (TBeck @ Oct 4 2012, 15:33) *
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.
Go to the top of the page
+Quote Post
Soap
post Oct 4 2012, 23:10
Post #47





Group: Members
Posts: 1013
Joined: 19-November 06
Member No.: 37767



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.
Go to the top of the page
+Quote Post
saratoga
post Oct 5 2012, 00:53
Post #48





Group: Members
Posts: 4866
Joined: 2-September 02
Member No.: 3264



QUOTE (Soap @ Oct 4 2012, 18:10) *
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.
Go to the top of the page
+Quote Post
Soap
post Oct 5 2012, 00:55
Post #49





Group: Members
Posts: 1013
Joined: 19-November 06
Member No.: 37767



QUOTE (saratoga @ Oct 4 2012, 19:53) *
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.
Go to the top of the page
+Quote Post
mudlord
post Oct 5 2012, 01:04
Post #50





Group: Developer (Donating)
Posts: 805
Joined: 1-December 07
Member No.: 49165



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

Superb RE work BTW.
Go to the top of the page
+Quote Post

3 Pages V  < 1 2 3 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 31st July 2014 - 01:17