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: Open Source TAK encoder (Read 20489 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Open Source TAK encoder

Reply #100
Triza if something is irrelevant why you bother? Just leave it alone. Aggressive attitude including yours is the most pathetic and cringey here.
TAK has one thing no other lossless codecs have - best efficiency. It's irrelevant as in obscurity that only a tiny community uses it. That also makes comparison to widespread, de-facto standard Word/DOC or MP3 pointless.
It's nobodys business whats on TBeck mind. Maybe he finds TAK incomplete, wants to finish it and then go FOSS? Or go commercial? He made it and its none of your business. If there's something you don't like, ask, or just don't bother and go with something relevant like FLAC. It's not perpetuum mobile that you have to give it to the world.
And if you find it relevant why call it irrelevant? Respect the author.


Re: Open Source TAK encoder

Reply #102
I identify as Porcus above. I am Porcus's alter ego.
Please remove my account from this forum.

Re: Open Source TAK encoder

Reply #103
And I'm Porcus' father!

Re: Open Source TAK encoder

Reply #104
This entire discussion is surreal.
Perhaps it is.
It is a major boon to any format to have two independent implementations, especially of the decoder. Having at least a mostly-working proof-of-concept second decoder implementation is often seen as a must before any kind of real adoption of a format.
That might be true and I'm not against having two independent implementations of something like TAK personally.
Attempting to write a second implementation of an existing format is not theft, it is not harassment, it is not abuse, it is not rude, it is not illegal, it is simply a reasonable technical goal for someone to set themselves.
This might be true, as long as it's done from scratch I guess?
There's no legal, moral, or even "social convention-al" reason why someone writing a second implementation would be required to prostrate themselves at the feet of the writer of the original implementation, contacting them repeatedly over the course of years to humbly beg for their pontifical blessing.
Might be true, too. I assume this is actually what these inconsistencies are all about?
Some kind of contact could be nice, to cultivate a sense of community, but not required. Sounds like mycroft made some kind of attempt at one point many years ago.
I agree to the first sentence. I wonder how many attempts? Just one attempt and then he gave up? What language did he use when communicating with TBeck for the first time do you think? Did he have any patience at all? Only Mycroft and TBeck know. If he used the same language as we've witnessed here then I understand why things have become so difficult.
Almost all of us rely daily on things that would not exist without reverse engineering. If you've ever run DOS or Windows on something that wasn't an IBM PC actually sold by IBM Corporation, you were only able to do so because people reverse engineered the PC BIOS. If you've ever opened a Microsoft .DOC in any program other than MS Word, or any other word processing, spreadsheet, or presentation file in any program besides the originator of the format, that worked due to reverse engineering. If you've ever used shared files on a network drive, at least one machine in the network was running Windows, and at least one wasn't, you almost certainly relied on the years of reverse engineering of the SMB protocol done by the SAMBA team.
I don't think anybody here is against reverse engineering as a concept.
None of those groups obtained permission from the originators before working on their clean-room implementations.
In many cases that's probably true.
If it weren't for people who reverse engineer relatively obscure media and document formats, a lot of content from the last seventy years would simply be lost.
Good point.
I appreciate TBeck's achievements. I understand he is going through a hard time and has legitimate fears about people abusing leaked versions of his copyrighted code. That doesn't seem like a sufficient reason for the histrionics on display here. Jeano and Porcus, I'm going to call you in particular out for unreasonable reactions here as well.
People were positive to Mycroft's announcement in this thread until TBeck told us he was shocked. He apparantly didn't know about Mycroft's plans. After that, things went out of control. In the meantime the moderators removed some of Mycroft's posts. The whole discussion got at one point heated up and then we reacted. Because these posts now are gone you and others are not able to get/to see the whole picture (unfortunately).
For all I know, it's possible that mycroft doesn't have the promised working implementation and was merely trolling, or that he does have one and it's illegally based on leaked code, or that there's some other reason this would never be the boon one would hope for from a second implementation.
Then he should tell us instead of playing silly games with us.
But the only thing there's any actual evidence of in this thread is this: someone came to HydrogenAudio with what he thought was good news about something he had to offer, immediately faced all kinds of unreasonable accusations about driving the poor author of TAK to suicide by his awful, horrible, inhuman, inexcusable deed of trying to write a piece of interoperable software, understandably got upset at the reaction he was getting, wrote a couple bad replies, and has decided that HydrogenAudio is a hostile community he should not contribute to.
It's not like that at all. I think Mycroft is welcome here like anybody else. We're not hostile. He must just show some moderation and calm down a little. There is no need to use harsh words and try to use force. If he's working on something cool then it's of course valuable and great. Everybody likes open source software, compatibility etc. This thread began with a "throw in the face" for TBeck. The name of the thread says it all. It might have turned out differently from the very beginning if the name of the thread was "Open Source TAK encoder - would that be possible/feasible?" or "I would like to contribute to create an Open Source TAK encoder". Like I said: People were positive from the start until TBeck expressed his concerns. I think everybody should respect what he feels about it and discuss the whole issue like adults. We should help him improve upon TAK. That has to happen on his terms - at least for now. Personally I think it's a good thing if Mycroft and TBeck could work together to get TAK to become more wide spread as a format. If TBeck could let Mycroft create an open source TAK encoder that would in my view be awesome, but at the same time I believe it's wrong to "force" TBeck to think it's a good idea. He must believe in this path forward himself.
This is not a moment for anyone here to be proud of.
Well, it doesn't have to be that bad if only Mycroft and TBeck could "sit down" and talk. :)

Re: Open Source TAK encoder

Reply #105
TAK has one thing no other lossless codecs have - best efficiency. It's irrelevant as in obscurity that only a tiny community uses it. That also makes comparison to widespread, de-facto standard Word/DOC or MP3 pointless.
I agree completely. TAK is uniqe in its own way and there are people who love it for what it is. I hope TBeck continues his work on improving it. 8)

Re: Open Source TAK encoder

Reply #106
I think it's mostly about respect. Thomas had the unfortunate thing about YALAC being a beta (or alpha) release on April 1st, and members dismissed it as a joke.

But it delivered- MAC compression with FLAC decompression qualities.

When I got PM's to share the beta binaries, I just ignored them. It was out of respect for Thomas's work.

Now all this drama isn't helping.

All the dissertation of what defines this and that- it isn't helping.

Please give Thomas credit and let him continue to do something he obviously likes doing and had the courage to share. Personally, I'm honored he let me be involved in the early public releases.

As for me, I continue to support TAK as an obscure but considerably formidable lossless codec, much like the lossy codec MPC. (That means Musepack just in case of new members.)
"Something bothering you, Mister Spock?"

Re: Open Source TAK encoder

Reply #107
Thanks for Thomas good feedback I will not release TAK encoder at all.

I wish this codec remain obscure and unpopular forever ever.
Also wishes that circle jerk around TAK remain obscure as it really is and should be always just that - circle jerk.
Please remove my account from this forum.

Re: Open Source TAK encoder

Reply #108
In the meantime the moderators removed some of Mycroft's posts. The whole discussion got at one point heated up and then we reacted. Because these posts now are gone you and others are not able to get/to see the whole picture (unfortunately).
Indeed they did, and as you say - someone reading the thread now cannot see the entirety of the discussion as some of it was moderated. I saw two of the OP's posts that were removed and am in no way surprised that they were removed, especially given the claim and threat contained in the later of the two.

[edit] ... and I've just noticed that the posts I thought were deleted are still there, apart from one of the posts which is in the Recycle Bin forum.[/edit]

Re: Open Source TAK encoder

Reply #109
Also wishes that circle jerk around TAK remain obscure as it really is and should be always just that - circle jerk.
And that's a fantastic hardcore punk band, still kicking butt on stage more than 40 years down the road so thank you!

BTW, I still didn't get if the code you claim to have comes from a leak of TBeck's or from reverse engineering, but I'm too busy circling and jerking so I might've missed that piece of crucial information.
WavPack 5.7.0 -b384hx6cmv / qaac64 2.80 -V 100

Re: Open Source TAK encoder

Reply #110
I actually take Reply #107 to mean that @mycroft is indeed willing to think twice, something that is - unironically! - a good thing.
(Throwing some insults on the way - taking care of his evil image I guess - but still.)
Spoiler (click to show/hide)

Awaiting a TAK3 with impossible performance figures, release date set for 2024-04-01.

Re: Open Source TAK encoder

Reply #111
Thanks for Thomas good feedback I will not release TAK encoder at all.
You really know how to surprise someone. I rarely meet someone I find so hard to judge. That's not meant in a negative way, but it makes it so hard to trust.

I think some things would have gone very differently if you had emailed me first. Even if I -as you write- have not answered a mail 7 years ago. Maybe I was sick again, sometimes I can hardly read more than one line for days or weeks. Ok, I didn't make this public in the past, so you couldn't know that maybe that's why there was no answer.

Ironically, I had already planned to contact you later to ask for cooperation on the decoder for TAK 3.0. I am glad that you wrote a decoder for TAK 1/2 (even if I saw it differently many years ago...) and would not want to release V3.0 without an open source decoder being available. I wanted to at least provide you with the source code of the new elements as well as some test files.

I would be happy if this possibility would still exist.

But the work on TAK 3 will take quite a while. For this I will open a separate thread to discuss some features. Maybe I should split the work into two steps.

To make a first step, maybe I could send you the source code of the TAK 1 decoder, which is different from V2. I got some messages that your decoder is not working completely correct there. But maybe it is already fixed.

Somehow I had the feeling that I'd better answer quickly here. As if it's a moment when you can still give everything a positive twist.

I didn't think it all through and trusted DeepL 100 percent...

Re: Open Source TAK encoder

Reply #112
You can send me decoder for 1.X version if you want. Real specifications are much better. So I do not need to reverse Pascal code.
Although it is just codec with FIR coefficients for LPC with custom entropy coder and decorrelation for stereo.
Please remove my account from this forum.

Re: Open Source TAK encoder

Reply #113
I waited to see others' replies, and felt like communicating that these latest posts are positive for all involved :)

"Something bothering you, Mister Spock?"

Re: Open Source TAK encoder

Reply #114
This entire discussion is surreal.

It is a major boon to any format to have two independent implementations, especially of the decoder. Having at least a mostly-working proof-of-concept second decoder implementation is often seen as a must before any kind of real adoption of a format.

Attempting to write a second implementation of an existing format is not theft, it is not harassment, it is not abuse, it is not rude, it is not illegal, it is simply a reasonable technical goal for someone to set themselves.

There's no legal, moral, or even "social convention-al" reason why someone writing a second implementation would be required to prostrate themselves at the feet of the writer of the original implementation, contacting them repeatedly over the course of years to humbly beg for their pontifical blessing.

Some kind of contact could be nice, to cultivate a sense of community, but not required. Sounds like mycroft made some kind of attempt at one point many years ago.

Almost all of us rely daily on things that would not exist without reverse engineering. If you've ever run DOS or Windows on something that wasn't an IBM PC actually sold by IBM Corporation, you were only able to do so because people reverse engineered the PC BIOS. If you've ever opened a Microsoft .DOC in any program other than MS Word, or any other word processing, spreadsheet, or presentation file in any program besides the originator of the format, that worked due to reverse engineering. If you've ever used shared files on a network drive, at least one machine in the network was running Windows, and at least one wasn't, you almost certainly relied on the years of reverse engineering of the SMB protocol done by the SAMBA team.

None of those groups obtained permission from the originators before working on their clean-room implementations.

If it weren't for people who reverse engineer relatively obscure media and document formats, a lot of content from the last seventy years would simply be lost.

I appreciate TBeck's achievements. I understand he is going through a hard time and has legitimate fears about people abusing leaked versions of his copyrighted code. That doesn't seem like a sufficient reason for the histrionics on display here. Jeano and Porcus, I'm going to call you in particular out for unreasonable reactions here as well.

For all I know, it's possible that mycroft doesn't have the promised working implementation and was merely trolling, or that he does have one and it's illegally based on leaked code, or that there's some other reason this would never be the boon one would hope for from a second implementation.

But the only thing there's any actual evidence of in this thread is this: someone came to HydrogenAudio with what he thought was good news about something he had to offer, immediately faced all kinds of unreasonable accusations about driving the poor author of TAK to suicide by his awful, horrible, inhuman, inexcusable deed of trying to write a piece of interoperable software, understandably got upset at the reaction he was getting, wrote a couple bad replies, and has decided that HydrogenAudio is a hostile community he should not contribute to.

This is not a moment for anyone here to be proud of.

Could not be said better.
Creature of habit.

Re: Open Source TAK encoder

Reply #115
True enough, there is always the calculated risk of going public and backfiring. I was personally grateful to be involved, and, I suppose fortunate to be running that platform. I think Thomas is better at English than myself, too.
"Something bothering you, Mister Spock?"

Re: Open Source TAK encoder

Reply #116
Ironically, I had already planned to contact you later to ask for cooperation on the decoder for TAK 3.0. I am glad that you wrote a decoder for TAK 1/2 (even if I saw it differently many years ago...) and would not want to release V3.0 without an open source decoder being available. I wanted to at least provide you with the source code of the new elements as well as some test files.

I would be happy if this possibility would still exist.

You can send me decoder for 1.X version if you want. Real specifications are much better. So I do not need to reverse Pascal code.
Although it is just codec with FIR coefficients for LPC with custom entropy coder and decorrelation for stereo.

So nice that both could leave your differences and start working on TAK.

Although I use mostly Windows, I never migrated to it because of the lack of an open source decoder, so this will be great if it happens.

In this world at war, is always good to see the good in people.

Re: Open Source TAK encoder

Reply #117
In this world at war, is always good to see the good in people.
Quite the best comment I've seen in many a long day. The current situation is way beyond sad!

Re: Open Source TAK encoder

Reply #118
So, honest question: why not release TAK as open-source/source-available?

Going back to a comment I made way, way earlier in the thread - none of us live forever. Most of us don't make great plans around that basic fact, so software tends to die with the author and is lost forever.

Unless there's a business component to all this that I'm missing (selling support contracts, etc), TAK is freeware, no? Going open-source/source-available makes it easier to get volunteers to assist with things like, porting to other platforms, adding features, and so forth.

No person is an island. If you want to go fast: go alone. If you wanna go far: go together.

Not that it's impossible to get assistance in a closed-source project. I'll put my money where my mouth is, and volunteer right now to help port TAK to Linux, regardless of license. It's just easier since somebody could find the code and send back fixes without you having to seek them out first.

Also it's not like going to an open-source model means you have to say, use Github or GitLab, provide an online git repo, issue tracking, and so forth. Could be as simple as uploading the source code alongside the binary releases on your existing website. Plenty of open-source projects operate that way.

So, just throwing that out there. Food for thought, hopefully.

Re: Open Source TAK encoder

Reply #119
So, honest question: why not release TAK as open-source/source-available?

Going back to a comment I made way, way earlier in the thread - none of us live forever. Most of us don't make great plans around that basic fact, so software tends to die with the author and is lost forever.

Unless there's a business component to all this that I'm missing (selling support contracts, etc), TAK is freeware, no? Going open-source/source-available makes it easier to get volunteers to assist with things like, porting to other platforms, adding features, and so forth.

No person is an island. If you want to go fast: go alone. If you wanna go far: go together.

Not that it's impossible to get assistance in a closed-source project. I'll put my money where my mouth is, and volunteer right now to help port TAK to Linux, regardless of license. It's just easier since somebody could find the code and send back fixes without you having to seek them out first.

Also it's not like going to an open-source model means you have to say, use Github or GitLab, provide an online git repo, issue tracking, and so forth. Could be as simple as uploading the source code alongside the binary releases on your existing website. Plenty of open-source projects operate that way.

So, just throwing that out there. Food for thought, hopefully.

I think you got a point here. In this thread, we have observed that we can be very persnickety about something, while the world is on the verge of breaking down with wars. Could it be possible for TBeck to release part of the code that is "sufficient" to surpass all codecs, but still hold the pieces for a proprietary implementation? I guess users would have best of both worlds, and this coming from the right source (not a "nobody" from the internet that has some ace upon his sleeve that gets to threaten with ridiculous posts I've seen here). Doing such thing, would deem this ridiculous "suspect" developer to ostracism for eternity. So, I thought this now.

For example, TBeck could release part of the code that does sufficient efficiency and help other projects to incorporate TAK as a growing project to reach mainstream attention over the years. TBeck would be recognized for that. We all know this. But also, TBeck could "hold the golden eggs", some secret part of TAK, that would prevent the open source release to reach the full potential of TAK and maintain it as it's main proprietary code with SDKs for decoding, etc. If I were TBeck, I would think about this strategy, it would drop many naysayers. So, this is something to consider. TBeck can still be motivated and implement the improvements only on the proprietary part, in a SDK. I don't know if I am talking with no understanding of these consequences - just an idea. I know that if some part of the code gets indeed released, one could work it up even better. But I don't see it as a problem... It's just a thought. Don't know whether this would work or not. But, perhaps... this could end this whole speculation and people could use more TAK.

I hope these sayings complement what the @jprjr just said. No one will live forever, and we die, we will be remembered for our deeds - not the guy who is threatening and holding some code he could overcrow or get credits for it.

Just my two cents and I hope everything is sorted out. We don't want TAK to be "obscure" and abandoned. It's a great project, excellent codec, and hell, it's really damn good.

Cheers.

 

Re: Open Source TAK encoder

Reply #120
Depending on circumstance, that "release parts of TAK as open source and keep other parts proprietary" may be overcomplicating it.

The current release is freeware, with some usage restrictions (no commercial use, for example). So, it could be TBeck has sold custom licenses to commercial entities, and that would certainly complicate releasing TAK source code. That's a case where I would totally understand wanting to keep some parts (or even the whole thing) proprietary.

If there aren't any existing contracts that would restrict a license change - it could be as straightforward as taking the existing code, changing the license document, and releasing it as-is. No need to keep some parts private - that would likely require more work - because then you have to go through and figure out what's private, what's not, probably reorganize some code and refactor things. I'm not sure what the real benefit of all that work would be.

Going open-source usually means removing any and all usage restrictions, I've tried to be careful and use the term "source available" as well - it's possible to release code and place restrictions on usage. Though, once you're releasing code I'd recommend going with one of the well-known, standard licenses. It makes it easier for projects to evaluate whether they can integrate the code, easier for Linux distros to determine if they can distribute the app, and so on. Those standard licenses usually allow using the code for any purpose - personally, I've always figured if I'm OK with putting code/apps online and not profiting off of them myself, I don't really care if a business decides to use it (just don't expect any support from me to be free). I understand not everybody has this same view, though.

The only person with the full, complete picture is TBeck. I just hope this provides things to think about from a longevity/pragmatic point of view.