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 1.0.4 - Development (Read 85028 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

TAK 1.0.4 - Development

Reply #100 –
Quote from: SebastianG on
Quote from: skamp on

I understand why Thomas would want to wait until the format is final,

I thought it was finalized.

Now and then i am working on a slightly modified codec:

- A bit faster en- and decoding without compression penality
- Slightly better compression
- Simplier code

If the advantages are big enough, i may add this new codec to TAK. Currently i don't know how much improvement i can achieve, i first have to try some new ideas.

Quote from: skamp on
Quote from: TBeck on
And nevertheless i have the impression [Monkey's Audio] is slowly dying... Source code availability is no guarantee for lasting success.

In the Free Software world at least (can't speak for Windows or MacOS), it seems the problem was with licensing. FOSS developers claim the license is too ambiguous (the author requires them to ask for permission) and thus refuse to engage work into supporting and including Monkey's Audio in apps and linux distros. I guess it's fundamentally incompatible with the main Free Software licenses (GPL, BSD...).

I know about those license issues, but i doubt this could prevent windows developers from improving the applications or writing plugins for other applications.


Quote from: greynol on
I don't really have a dog in this race, but it would seem to make sense to use a method that's compatible with at least two other codecs.  For those transcoding between formats, md5 would make for pretty easy verification.

Exactly!
 

TAK 1.0.4 - Development

Reply #101 –
If there will be more efficient  TAK 2.0 not backwards compatible with 1.x then  I won't mind to transcode my tak and flac files to it. Transcoding isn't big issue for lossless.
Anyway TAK is still new codec and probably its new users will move to new codec. It's different from FLAC 1.x. Users won't move to new generation because of hardware compatibility.

Just my thoughts.

TAK 1.0.4 - Development

Reply #102 –
Quote from: TBeck on
Quote from: skamp on

Quote from: Daniel Beaver on

Quote from: Bourne on

I'm dying to get the Linux port...

Me too. What kind of effort would that take?

It would take Thomas letting go of his baby and one or two enthusiastic developers who could contribute *their* free time. I fully understand that Thomas has other priorities in life (family (?), work), but refusing help for now makes the point moot. He's been developing his codec for over 10 years, made his first announcement here almost two years ago, and us non-Windows users keep drooling over it, waiting for a port. One year ago we were told to be patient. How much longer? David Bryant found people to port WavPack to linux and write a plugin for XMMS... Now it's even supported by other players.

For the priorities: Well, i don't think someone who has also to work a bit for money could spend more time on a project as i on TAK... If you have got the impression, my dedication to TAK has decreased: That's wrong. Possibly one can get this impression, because now there is less discussion about TAK (because i am no longer releasing evaluation versions to test new optimizations).

For the 10 years: It did take so long, because i did so much (several thousand hours), not because of a little priority. TAK contains a couple of very new technologies.

Quote from: skamp on
I'm worried that Thomas may miss the train again because of his reluctance to release the code in its current state, all these feature requests that he's considering, his plans to switch to C++ and Object Oriented Programming, etc... Hashing can be done by piping raw PCM output to a hashing utility. Tagging can be implemented by encoding software, tagging software, or even a wrapper shell script. Cue sheets can be used externally. Artwork is taken care of by APEv2, hence relates to tagging support. More to the point, all of these features have little to do with major format changes, and could easily be developed on a multi-platform codebase. Delaying a souce code release by however much time it would take for a single, already busy person, to implement those features sures sounds like a bad idea to me.

I am preparing a port from an object oriented to a procedural approach (not the other way round) to make an implementation in standard C possible.

I would love to hear the opinion of other developers on whether moving to procedural is the best way to approach the Delphi-to-C conversion problem.
Quote
For the other features: Users are asking for them and the other lossless compressors have them. Without them TAK will always look bad in feature comparisons and some people will get the feeling, TAK isn't mature.

Quote from: skamp on

Now that I think of it, I wonder if FLAC didn't get such good support on Free operating systems and playback software in part thanks to Josh's extensive work in documentation and portability.

Absolutely right and -i fear- a very good argument to support my position...

It doesn't make much sense to release source code which isn't clean and lacking a good documentation. Not if you want widespread support. I think there is quite a lot of developers who would be excited when i release the source code. I don't want them to be disappointed because of bad code or documentation. A bad release could kill their motivation and i don't think i would get a second chance to attract developers.

Also very important: I am working as a self employeed developer and if i release bad source code, this will hurt my reputation!

If that is your reason for not going open source, then I will not support you on this!

Messy and undocumented code means a high barrier of entry for developers. That does not mean it is not worth publishing it. Besides, if said developers can observe that the code is getting tidier and more annotated over time, that is a great boost for their confidence. They will know that it is worth getting used to the structure and style of coding, even maybe suggest some changes.

You can delegate tasks to them that do not require a high level of understanding of the code.

As for your public image, I do not see how being known as the developer of the new lossless codec everyone talks about is going to damage it.

Do you have no better reason for keeping the code to yourself?

TAK 1.0.4 - Development

Reply #103 –
As a developer I would go and replace extremely ugly code immediately for the sake of being able to further support my work.
As for the not-so-extremely-ugly code I wouldn't care much about it. Developers are always in a state where a code written is worth to be written more clearly.

Other than that it's worth to differentiate between the encoder and the decoder. For a wide support of TAK the source code availability of the decoder is most important. As the decoder is supposed to be easier to implement than the encoder may be it's not such a hard work to replace the extremely ugly code.
So I think the highest priority for going public should be given to the decoder.
Of course the encoder is vital for porting TAK to Linux etc. However this can be done in a second step.
lame3995o -Q1.7 --lowpass 17

TAK 1.0.4 - Development

Reply #104 –
Let me add that there are more than one type of coders: some are mathematicians who develop awesome algorithms, some are hardcore optimizers who will squeeze out every last drop of performance out of the most relevant parts, some are into portability, some like to come up with the most elegant organization of the code, etc...

TAK 1.0.4 - Development

Reply #105 –
Need help!

I want to release TAK 1.0.4 within the next hours.

With every release i am running into the same problem: I want to split my first post in the News submission section into 2 or 3 parts. But the board software will automatically concatenate the posts. The only solution i know of: i log out, clear the cookies, disconnect my internet connection, wait a bit and log in before posting the next part...

There must be an easier way to avoid the concatenation!???

TAK 1.0.4 - Development

Reply #106 –
Hey TBeck I recently asked for a x64 build of OptimFROG but that looks to have gone cold.
What are the chances of a x64 build of TAK

I have TAK decoding nicely in x86.

TAK 1.0.4 - Development

Reply #107 –
Quote from: twistedddx on
Hey TBeck I recently asked for a x64 build of OptimFROG but that looks to have gone cold.
What are the chances of a x64 build of TAK

This currently has a very low priority for me.

Because of the design of the codec (mostly 16 and 32 bit arithmetics) there would be no speed advantage for the decoder and only a quite small speed up of for the encoder.

TAK 1.0.4 - Development

Reply #108 –
My main reason is not for speed improvements but for 64bit applications loading the TAK lib, which currently is not possible. I am not so much looking for a rewrite of your work to get benefits from 64bit(but it would be nice), just a compile in 64bit so we can support TAK in 64bit.

Anyways thanks for your effort, TAK does seem rather nice.

TAK 1.0.4 - Development

Reply #109 –
Quote from: twistedddx on
My main reason is not for speed improvements but for 64bit applications loading the TAK lib, which currently is not possible. I am not so much looking for a rewrite of your work to get benefits from 64bit(but it would be nice), just a compile in 64bit so we can support TAK in 64bit.

Well, possibly i tried to understand your request wrong...

Unfortunately i currently own neither a 64-bit OS nor a 64-bit compiler. Therefore it's very unlikely i will provide 64-bit libs soon. Sorry...

  Thomas

TAK 1.0.4 - Development

Reply #110 –
Quote from: TBeck on
Unfortunately i currently own neither a 64-bit OS nor a 64-bit compiler. Therefore it's very unlikely i will provide 64-bit libs soon. Sorry...

Yet another reason for releasing the source code…

TAK 1.0.4 - Development

Reply #112 –
Quote from: TBeck on
Huh, i thought on saturday it would take a bit longer...

You're asking for it!  Do like everyone else, just ignore requests you can't/won't fulfill. And more importantly: don't apologize for it.

TAK 1.0.4 - Development

Reply #113 –
Quote from: TBeck on
Unfortunately i currently own neither a 64-bit OS nor a 64-bit compiler. Therefore it's very unlikely i will provide 64-bit libs soon. Sorry...


That is alright. Great work you are doing, if you ever get bored enough and do look into 64bit compiles of TAK do let us know, I would love to hear. So far 32bit is holding us back on otherwise supported features: OptimFROG, TAK and Sonique Visual Plugins due to 32bit binaries.

If you care the player is Tuniac: http://sourceforge.net/projects/tuniac/

Any suggestions in regards to improving/correcting our TAK support would be appreciated, noting we are close to a rather large change to Tuniac 2 soon.
You can find our TAK plugin here: http://tuniac.svn.sourceforge.net/viewvc/t...ac1/tak_Plugin/