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

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

At this point, trying to convert TAK+SDK to an "opened"* project would kill any interest by most sensible people, at least at the current stage, IMHO.

* goatse-style.

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

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

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

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.

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!

People, please don't hijack yet another thread with pointless open source discussion.


http://www.hydrogenaudio.org/forums/index....showtopic=51511
This is what you might be looking for.

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.

"Later" is ok...


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.


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


Thank you!

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

Thomas

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

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

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

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



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


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

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

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.

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

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.

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.


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

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

As for speed and compression improvements you said:



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.

Fine! Somehow it was easier for me when i silently worked on TAK: No need to care for public relations...



If users want to benefit from compression improvements, they have to reencode their files with the new version. The effort is the same if the new version is backwards compatible or not.

An upgrade is easy: Download the new Version. If necessary replace the Tak Sdk library with the new version and other applications using the library will immediately be able to decode files created with the new version.

That's possible because the addition of a new improved codec changes neither TAK's container format nor the interface of the Sdk.

Yes, its a lossless format, so there is always the possibility to transcode. Hopefully you are willing, at least for awhile, to break backward compatability to move TAK forward.

Definitely yes!

I have been working on TAK's technology for many years without thinking about a public release. I did it, because the invention of new compression methods was the most fun for me. I am happy if i can continue this work!

And as i wrote above, it's easy for me to add new improved codecs, because TAK is prepared for this.