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 SDK - First release (Read 15448 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

TAK SDK - First release

The first version of the SDK version will only contain decoding functionality. It consists of a Windows DLL and Header files in Pascal and C.

Currently i am working on the documentation. Some days ago i switched from a simple text form to a hypertext reference with many many links (sigh...).

The reference is now nearly complete and i am working on some example code snippets.

But... it's all in german!

Therefore i am looking for someone who wants to help me with a translation into english. He (or she) should be familar with the basics of html code to avoid unintended destruction of my html formatting. The reference will be about 50 to 60 KB large, but much of it are code examples and declarations which have not to be translated. The work may start within the next days.

Please send me an email, if you want to help.

When the translation is done i would be happy to find some developers, who want to test the SDK. Possibly there is someone who wants to integrate TAK support into his application? This would be the best test!

If you are interested, send me an email and tell me, what you would like to do with the SDK. But please no beginners! I don't have the time to explain programming fundamentals!

  Thomas

TAK SDK - First release

Reply #1 –
why not just make this an open project so people can help easier?

TAK SDK - First release

Reply #2 –
Quote from: xmixahlx on
why not just make this an open project so people can help easier?

Hm, is it possible, that this question (a real evergreen...) has not been asked the last 2 weeks? Possibly it's again time for an answer (sorry to the members who already know what i usually say...).

1) Preparation of an open source release would take 'just' about 3 to 6 months if i spent my whole free time on it. Please forgive me, that i want to have some private living with a bit of fun...

2) I doubt, that open source automatically means many competent helpers or results of high quality.

3) I doubt, that a TAK open source project would work very well without me taking care for it. Currently i prefer to work on my compression technology instead of spending my time on administration and politics.

Other people will think different, but the above is what my experiences and my feelings are telling me.

And fortunately it's still my choice....

  Thomas

TAK SDK - First release

Reply #3 –
[deleted]

TAK SDK - First release

Reply #5 –
Quote from: kjoonlee on
I think xmixahlx just means making the documentation public & editable by anyone. Not necc. the code...

Huh, if so, then sorry to xmixahlx! 

My first year at hydrogen somehow made me very sensitive regarding never ending open source requests. Funny: It even changed my earlier very positive attitude towards open source... Although the concept itself isn't responsible for some crusaders.

I doubt, that it would be advantegous, if the documentation would be editable by anyone. What about consistency? And it seems to be very much work for me to check it anytime someone has changed a bit.

Hey, it's only some pages! Probably someone who is good in both languages can translate it in about three or four hours.

  Thomas

TAK SDK - First release

Reply #6 –
yeah i was talking specifically about the documentation - sorry for the ambiguity...

i do, however, have a similar opinion about code but i wasn't imposing that on you at that time


later

TAK SDK - First release

Reply #7 –
I also misunderstood. I get mad at people who say "open source the project" when they're talking about the code. I think about MA, which has been really stagnant despite when the code was open sourced and the incompatible license did not help it.

Anyway, back OT

Good to hear that an SDK is coming along. Being a Windows thing (for now) means some people might get their favorite player to use TAK soon (this is my hunch at least).
"Something bothering you, Mister Spock?"

TAK SDK - First release

Reply #8 –
Making it open source would not limit the users of TAK to Windows users.

TAK SDK - First release

Reply #9 –
Quote from: caligae on
Making it open source would not limit the users of TAK to Windows users.


Not here again!

Please.

That's been discussed way too long already.
Nothing is impossible if you don't need to do it yourself.

TAK SDK - First release

Reply #10 –
Quote from: xmixahlx on
why not just make this an open project so people can help easier?
Or make it available for non-Windows users, while he still keep the source closed.
So we can give it a try, and provide useful (hopefully) feedback as well!

TAK SDK - First release

Reply #12 –
Quote from: TBeck on
I doubt, that it would be advantegous, if the documentation would be editable by anyone. What about consistency? And it seems to be very much work for me to check it anytime someone has changed a bit.

Well, I think the open source part of documentation would be similar to code, where people can submit changes to you, and you can look over it and either approve it or not.  OR if you can find a volunteer to take charge of the documentation, you don't have to worry about it.  This is probably the goal that people want when they encourage you to open up the project.  You can ask other people to be in charge of the work you're not interested in doing.  Making it an "open" project gives you the option of not personally knowing the person working on it.

I do sympathize though, because documentation has got to be the least fun and most annoying thing to do when it comes to sharing a library.  At the same time, I'm happy that you're releasing a library for the codec.  I would encourage you to "share the load" onto other people who are excited to work on the parts that you're not as interested in working on.  This is an exciting codec and a lot of people would love to see more things happening, and some folks may love it enough to help you out.

TAK SDK - First release

Reply #13 –
Quote from: xmixahlx on
i do, however, have a similar opinion about code but i wasn't imposing that on you at that time

later

"Later" is ok...

Quote from: krmathis on
Quote from: xmixahlx on
why not just make this an open project so people can help easier?
Or make it available for non-Windows users, while he still keep the source closed.
So we can give it a try, and provide useful (hopefully) feedback as well!

Don't you think i myself would like to have a TAK for as many platforms as possible? I simply don't have the time to do all at once! I am already spending an insane amount of time on TAK.

Quote from: sthayashi on
Quote from: TBeck on
I doubt, that it would be advantegous, if the documentation would be editable by anyone. What about consistency? And it seems to be very much work for me to check it anytime someone has changed a bit.

Well, I think the open source part of documentation would be similar to code, where people can submit changes to you, and you can look over it and either approve it or not.  OR if you can find a volunteer to take charge of the documentation, you don't have to worry about it.  This is probably the goal that people want when they encourage you to open up the project.  You can ask other people to be in charge of the work you're not interested in doing.  Making it an "open" project gives you the option of not personally knowing the person working on it.

"and you can look over it and either approve it or not" is critical for me. Looking for errors in something as detailed as an Sdk documentation possibly is more work than doing it by myself.

And i think, TAK needs a solid base before making it or parts of it open source. There has to be one trustable reference to check future changes against.

Quote from: sthayashi on
I do sympathize though, because documentation has got to be the least fun and most annoying thing to do when it comes to sharing a library.  At the same time, I'm happy that you're releasing a library for the codec.  I would encourage you to "share the load" onto other people who are excited to work on the parts that you're not as interested in working on.  This is an exciting codec and a lot of people would love to see more things happening, and some folks may love it enough to help you out.

Thank you!

Fotunately i just found a volunteer for the translation. Now i have to work a bit faster...

  Thomas

TAK SDK - First release

Reply #14 –
hey TBeck, you have to understand that there are *NIX users (including myself) that just want to be in the loop.

so screaming "open source" is really just asking for support sometimes. a lot of the times we are willing to do the work (a good example is wavpack porting from kuniklo & co. and the mac-port by supermmx)

also, there are a lot of examples where licensing has not helped support issues (monkey's audio, optimfrog) and good examples (flac, wavpack, lame) that we sometimes disuade the *NIX community with new upcoming projects. (yeah, i realize there are examples for the opposite situation...)

i'm not a GPL advocate. i just want to be able to use software (and with rarewares/debian i also want to be able to provide software) and can't do that unless i have something to work with

sorry if that tirade wasn't helpful...


later

TAK SDK - First release

Reply #15 –
Would openly editable documentation be good or bad?

I cannot say. Wikipedia is more successful than Hydrogenaudio Knowledgebase, for example.

Will it be easy or difficult?

I'd say it's easy if you use version control. For example, Wikipedia is miles and miles better if you use "recent changes" and "my watchlist". I don't know how I used to live without those features...

TAK SDK - First release

Reply #16 –
Quote from: TBeck on
Don't you think i myself would like to have a TAK for as many platforms as possible? I simply don't have the time to do all at once! I am already spending an insane amount of time on TAK.
I don't question that you would like to have TAK for as many platforms as possible, and  that you already spend high amount of hours on it.

I simply replied to 'xmixahlx's posts, mentioning that you could release binaries for us non-Windows users (example GNU/Linux and Mac OS X), while you still keep the sources closed as of today. Cause opening the source don't have to be the best way to go...
 

TAK SDK - First release

Reply #17 –
Quote from: TBeck on
Quote from: xmixahlx on

i do, however, have a similar opinion about code but i wasn't imposing that on you at that time

later

"Later" is ok...

Sorry xmixahlx, i didn't notice that 'later' is your name. I understood: "I will later talk about going open source...".


Quote from: xmixahlx on
sorry if that tirade wasn't helpful...

No need to say sorry! You provided arguments...

Quote from: krmathis on
Quote from: TBeck on
Don't you think i myself would like to have a TAK for as many platforms as possible? I simply don't have the time to do all at once! I am already spending an insane amount of time on TAK.
I don't question that you would like to have TAK for as many platforms as possible, and  that you already spend high amount of hours on it.

I simply replied to 'xmixahlx's posts, mentioning that you could release binaries for us non-Windows users (example GNU/Linux and Mac OS X), while you still keep the sources closed as of today. Cause opening the source don't have to be the best way to go...

Unfortunately even the generation of a binary for *nix means much work for me:

- I have to install at least Linux on my second PC. Unfortunately my 40 GB harddisk is already filled up with test sound files.
- I doubt that i can simply compile my code with for instance Free Pascal without some adaptions.
- I have to port my testing suite to Linux.
- Testing of the binaries is much work and a significant portion of it has to be performed by myself.

Well, it's on my internal to do list but no promises yet...

  Thomas

TAK SDK - First release

Reply #18 –
Quote from: TBeck on
Quote from: TBeck on

Quote from: xmixahlx on

i do, however, have a similar opinion about code but i wasn't imposing that on you at that time

later

"Later" is ok...

Sorry xmixahlx, i didn't notice that 'later' is your name. I understood: "I will later talk about going open source...".

Actually your first guess was closer to the meaning. "Later" is used as a informal parting salutation meaning "see you later" or "talk to you later".

And, yes, porting to Linux can be non-trivial especially if your code is full of win32isms like WavPack was. Stuff like getting the time, setting file attributes, wildcards, user aborts, etc. can all be trouble. I don't know Delphi at all, so maybe some of these are wrapped up in native Delphi stuff, but if you're calling native win32 functions for file I/O then you're in for some editing. 

later 

TAK SDK - First release

Reply #19 –
Release of the SDK commits TAK to the current technology I guess. If you really have some neat tricks left up your sleeve I would much rather wait another year, or longer, and have something that clearly and decisively  outperforms current lossless codecs.

TAK SDK - First release

Reply #20 –
Quote from: Eli on
Release of the SDK commits TAK to the current technology I guess. If you really have some neat tricks left up your sleeve I would much rather wait another year, or longer, and have something that clearly and decisively  outperforms current lossless codecs.


From TAK's Readme:

"My goal was to develop a compressor which combines good compression with optimal decoding speeds. On average, the current implementation should match the compression efficiency of Monkey's Audio High, while achieving decompression speeds similar to FLAC."

TAK is high compression with very high encoding (if you use the fast presets) and decoding speed. It's often several times faster than other codecs with the same (or better) compression rate.

If you are only interested into maximum compression without caring for speed, use LA or Optimfrog. But if speed does matter,  TAK is a powerful new option.

TAK SDK - First release

Reply #21 –
Quote from: TBeck on
Unfortunately even the generation of a binary for *nix means much work for me:

- I have to install at least Linux on my second PC. Unfortunately my 40 GB harddisk is already filled up with test sound files.
- I doubt that i can simply compile my code with for instance Free Pascal without some adaptions.
- I have to port my testing suite to Linux.
- Testing of the binaries is much work and a significant portion of it has to be performed by myself.

Well, it's on my internal to do list but no promises yet...

  Thomas

Ok, I get it.
At least it has now made its way into your (internal) to do list...

TAK SDK - First release

Reply #22 –
TBeck, believe me, I dont mean to belittle your great work. TAK seems like a great codec. I currently use FLAC because of its significantly faster speeds with compression that doesnt differer to much from APE. You seemed to hint that you had ways in which you could improve both speed and compression. I dont know how much more compression you think you could get but its just MHO that its worth waiting longer to really take a leap forward instead of just a small step. Anyway, its your codec and your choice, just my $0.02.

TAK SDK - First release

Reply #23 –
Quote from: Eli on
TBeck, believe me, I dont mean to belittle your great work. TAK seems like a great codec. I currently use FLAC because of its significantly faster speeds with compression that doesnt differer to much from APE. You seemed

Are you comparing ("significantly faster") the speed of FLAC with MAC or with TAK? If the latter, then i am a bit surprised...

Sorry for being anal, but i have to take care for TAK's image: Speed is probably it's most important feature.

Quote from: Eli on
to hint that you had ways in which you could improve both speed and compression. I dont know how much more compression you think you could get but its just MHO that its worth waiting longer to really take a leap forward instead of just a small step. Anyway, its your codec and your choice, just my $0.02.

I have to perform many evaluations before i can provide accurate data for possible compression improvements. My current estimation can be found here: TAK 1.0.1 Development

  Thomas

TAK SDK - First release

Reply #24 –
I was of course referring to FLAC vs APE. TAK's reputation and image are intact ;-)

As for speed and compression improvements you said:

Quote
I doubt, that i can make decoding even faster without breaking the format compatibility.


Im saying, go ahead and break compatibility now, to make the format as good as possible, especially if compression could be improved at the same time.