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 84992 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

TAK 1.0.4 - Development

Reply #75 –
Quote from: skamp on
It's not a question of decoding being a bottleneck. Decoding takes processing power, no matter what, and 5% of the CPU is better than 10%: it leaves 95% for the encoding process, vs. 90%.
Oh yes, I was wrong about this. 

TAK 1.0.4 - Development

Reply #76 –
Quote from: Reinforce Generation on
Personally i think a new preset p0 has faster decode speed and lower compression ratio is good idea,its mean that when system use CPU process power 99% (likely run transcoding or some error process blocked system) my music playback wouldn't be easier to delay especially with ASIO audio driver.


I think when we're talking about formats that can be decoded <1% of the CPU in your PC (probably <1% of one of the cores of the CPU) it's the the OS's fault: it could make good use of a better scheduler that gives a damn about priority... You can try to use longer buffer in the player as a workaround though

edit. umm, typo?

TAK 1.0.4 - Development

Reply #77 –
Quote from: TBeck on
Now and then i am thinking about dropping -p5... On big representative file sets the advantage over -p4 is usually less than 0.20 percent. But on the other hand some particular files gain up to 2 percent.
Quote from: TBeck on
More important: -p0 will compress much worse than before!
...
Welcome in the wonderful world of marketing...
...
I doubt, that anyone would use this weak preset, but if want to make TAK the fastest codec, it should also compete well at this low level.

What do you think?
Now that you have switched to solely using numbers rather than a single letter to denote the compression level I see no problem in introducing a few more presets.  Therefore, I would gladly see a faster preset that compressed less well, and would gladly keep -p5 (or -p6 or -p7, as it may now be).  The wider the range the better I think, to a degree*.

* OptimFROG's range of options are just too confusing IMHO, but I can't see how you can go wrong with a numeric scale (0 = fastest/worse compression, n = slowest/best compression) and the additional option of adding one of two evaluation levels.
I'm on a horse.

TAK 1.0.4 - Development

Reply #78 –
I'm dying to get the Linux port...

TAK 1.0.4 - Development

Reply #80 –
Quote from: Synthetic Soul on
Now that you have switched to solely using numbers rather than a single letter to denote the compression level I see no problem in introducing a few more presets.  Therefore, I would gladly see a faster preset that compressed less well, and would gladly keep -p5 (or -p6 or -p7, as it may now be).  The wider the range the better I think, to a degree*.

I have modified -p0 and -p1. New -p0 is currently encoding about 11 percent faster than old -p0. This widens the range at least a bit... I wasn't happy with old p0/p1 because they were so close performance wise.

Here a comparison of the current version with V1.0.3b:

Code: [Select]
      Compression %    | Enco Speed *     | Deco Speed *     |
       1.0.3b   1.0.4  |  1.0.3b   1.0.4  |  1.0.3b   1.0.4  |
-----------------------+------------------+------------------+
-p0    58.31    58.83  |  77.70    91.00* | 105.64   120.15  |
-p1    57.86    57.98  |  64.57    70.90  |  98.24   115.47  |
-p2    57.08      "    |  43.99    44.82  |  91.73   100.86  |
-p3    56.66      "    |  25.63    25.98  |  80.97    88.18  |
-p4    56.28      "    |  15.52    15.72  |  74.57    80.49  |
-p5    56.08      "    |  11.15    11.21  |  66.15    70.79  |
-----------------------+------------------+------------------+

Speed data expressed as multiple of real time on a Pentium 3 with 1000 MHz.

-p0 is now using 4 instead of 8 predictors, -p1 12 instead of 16.

Don't know if it really matters, but i feel better with this configuration. And i see a chance to speed up the -p0 encoding by 15 to 20 percent.

edit: Encoding with -p0 is now another 6 percent faster...

TAK 1.0.4 - Development

Reply #81 –
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.

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 fear TAK will become yet another Windows codec with the kitchen sink included, and that non-Windows OSes and music players will be 2nd-class citizens (again...). Pushing for WavPack support on unix is already hard as it is ("WakPak? Who the hell uses that thing?"), imagine how hard it's gonna be for TAK! 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. I was drawn to FLAC myself because I was able to implement FLAC metadata parsing in PHP, thanks to his very clear documentation. Later on, I was able to quickly implement the CD-TOC metadata block.

I understand why Thomas would want to wait until the format is final, but then again, people could port the codec as it is now, and with all that work done, subsequent modifications would probably take less time. Also, different people might be interested in working on different things in parallel: one guy might volunteer to port the whole thing, while another might be interested in various modern CPU optimizations, for instance. Look at Vorbis: one guy wanted to make it sound better, and another wanted to make it faster. The result? A faster and better sounding version. Working alone and refusing any outside help is the worst way to go when you are unable to fully dedicate your time and resources (IMO, anyway).

Note that I wouldn't rant about this if Thomas hadn't asked for feedback from the get go. Well, here it is: after a couple of years of waiting, I'm growing impatient.

TAK 1.0.4 - Development

Reply #82 –
Quote from: buktore on
On the another hand.. Sometime (Once.. maybe.. I can't remember), There are another type of "particular files" that made TAK -p3 have better compression rate than -p5  weird eh? And I'm not talking about white noise & some weird stuff too.

Often -p5e can cure this.

Quote from: TBeck on
Don't know if it really matters, but i feel better with this configuration. And i see a chance to speed up the -p0 encoding by 15 to 20 percent.

edit: Encoding with -p0 is now another 6 percent faster...

Ok, only 6 percent more for now. Nevertheless -p0 is now a super fast encoding preset with still very good compression.

Quote from: skamp on
...
Note that I wouldn't rant about this if Thomas hadn't asked for feedback from the get go. Well, here it is: after a couple of years of waiting, I'm growing impatient.

Thanks for the input! I will reply when i have a bit more time...

BTW: TAK 1.0.4 is now quite complete. Most important changes:

1) Depending on the preset up to 13 percent faster decoding.
2) New super fast turbo preset.
3) Decoding to StdOut (piping).
4) Most delphi specific libraries replaced with own code.

Probably we will see a release in about 1 to 2 weeks.

  Thomas

TAK 1.0.4 - Development

Reply #83 –
TAK is going to be a very big monster in terms of being a competitive codec... Thomas work is being amazing... so much implemented in little time... soon his TODO list will be done and then it's just destiny...

TAK 1.0.4 - Development

Reply #85 –
Quote
As brought up before, beware of preset bloat. The general public does not seem to be waiting for yet faster encoding at the expense of compression ratio: http://www.hydrogenaudio.org/forums/index....showtopic=58731


It's not exactly the same thing. Since FLAC decode rate almost if not all are the same no matter what compression level you use. It's more attractive to use FLAC -8 because... well.. why not?

Another codec are different from this.

TAK 1.0.4 - Development

Reply #86 –
Yes, TAK's decoding speed is also affected by different -p settings, but luckily there is no strong increase in decoding effort when using higher -p values.

Anyway the people with compression ratio in focus will use -p 2+. And for the speed folks the new -p 0 and -p 1 settings are welcome. So IMO things are alright for everybody's needs.
lame3995o -Q1.7 --lowpass 17

TAK 1.0.4 - Development

Reply #87 –
I wonder how extra and maximum levels of evaluations will be affected in a new modified -p0 preset.
If new -p0m will  have the compression ratio on par with FLAC -8 probably I will stay with it. Or move to p1.
Anyway encode and decode speeds  will be more than enough high in a new version.

TAK 1.0.4 - Development

Reply #88 –
Quote from: Bourne on
TAK is going to be a very big monster in terms of being a competitive codec... Thomas work is being amazing... so much implemented in little time... soon his TODO list will be done and then it's just destiny...

Thank you!

But i don't think my TODO list will ever get empty...

Quote from: halb27 on
Anyway the people with compression ratio in focus will use -p 2+. And for the speed folks the new -p 0 and -p 1 settings are welcome. So IMO things are alright for everybody's needs.

That's exactly my valuation.

Quote from: IgorC on
I wonder how extra and maximum levels of evaluations will be affected in a new modified -p0 preset.
If new -p0m will  have the compression ratio on par with FLAC -8 probably I will stay with it. Or move to p1.
Anyway encode and decode speeds  will be more than enough high in a new version.


Here the results for my primary test corpus:

Code: [Select]
      Compression %    | Enco Speed *     | Deco Speed *     |
       1.0.3b   1.0.4  |  1.0.3b   1.0.4  |  1.0.3b   1.0.4  |
-----------------------+------------------+------------------+
-p0    58.31    58.83  |  77.70    91.00  | 105.64   120.15  |
-p0e   58.10    58.67  |  56.00    69.67  | 104.66   118.40  |
-p0m   57.97    58.54  |  29.29    34.06  | 104.96   118.82  |
-p1    57.86    57.98  |  64.57    70.90  |  98.24   115.47  |
-p1e   57.74    57.87  |  51.28    54.83  |  98.33   115.64  |
-p1m   57.61    57.75  |  26.55    28.13  |  98.29   115.59  |
-----------------------+------------------+------------------+
FLAC            1.2.1  |                  |                  |
-5              59.03  |                  |                  |
-8              58.74  |                  |                  |
-----------------------+------------------+------------------+

Speed data expressed as multiple of real time on a Pentium 3 with 1000 MHz.

TAK 1.0.4 - Development

Reply #89 –
Quote from: TBeck on
Quote from: IgorC on

I wonder how extra and maximum levels of evaluations will be affected in a new modified -p0 preset.
If new -p0m will  have the compression ratio on par with FLAC -8 probably I will stay with it. Or move to p1.
Anyway encode and decode speeds  will be more than enough high in a new version.

Here the results for my primary test corpus:

or try it yourself: TAK 1.0.4 - Beta release 1

TAK 1.0.4 - Development

Reply #90 –
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.

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!

Quote from: skamp on
I understand why Thomas would want to wait until the format is final, but then again, people could port the codec as it is now, and with all that work done, subsequent modifications would probably take less time. Also, different people might be interested in working on different things in parallel: one guy might volunteer to port the whole thing, while another might be interested in various modern CPU optimizations, for instance. Look at Vorbis: one guy wanted to make it sound better, and another wanted to make it faster. The result? A faster and better sounding version. Working alone and refusing any outside help is the worst way to go when you are unable to fully dedicate your time and resources (IMO, anyway).

I am convinced a project of some complexity needs some authority (or a heart) to coordinate the actions, at least in the beginning. This task would leave less time for my development work.

Summary:

I a am trying to do what i thinks is the best for TAK's future and also fun for me.

If you look at the latest release (V1.0.4), you find a a good mixture of new features which take into account different demands:

1) Speed optimizations = Much fun for me and important for TAK's reputation as possibly the most efficient (speed * compression) codec.

2) Pipe decoding = Make the users happy 

3) Replacement of delphi specific libraries with own code = preparation of the translation into standard C.

That's the way i will do it: A good balance of having fun and considering user demands.

I also have to care more for marketing. BTW: TAK still needs a logo!

I have also raised the priority of "Applications for other operating systems than Windows" on my todo list:

  * Tag writing functions for the TAK applications.
  * Fast seeking without seektable.
  * Raw audio data files as input for the encoder.
  * Option to decode only a specific part of a file.
  * Unicode support.
  * Even more speed and better compression.
  * Applications for other operating systems than Windows.
  * MD5 audio checksums for verification and identification.
  * TAK files as input for the encoder for transcoding purposes.
  * Multi channel audio.
  * A german version.

This list is dynamic.

Quote from: skamp on
Note that I wouldn't rant about this if Thomas hadn't asked for feedback from the get go. Well, here it is: after a couple of years of waiting, I'm growing impatient.

Thanks for the feedback! 

I have tried my best to explain my position. Because of my quite limited english, my explaination is less detailed and clear than i would like it to be.

  Thomas

TAK 1.0.4 - Development

Reply #91 –
Tbeck, I TOTALLY agree with your stance, and feel that you should NOT release the source code until you're sure the code is clean, well documented and upto your standards. Furthermore, I think you should not release the source code until you're confident that you will not have to make ANY changes which might break the standard.

I see TAK's current status as an advantage; unlike other "more established" codecs, you have the complete freedom to make changes which might break backwards compatibility but result in a very improved codec.

Please keep up the good work.

TAK 1.0.4 - Development

Reply #92 –
Quote from: TBeck on
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.

I'm not questioning your dedication at all, just pointing out the realities of life: you're not making a living with TAK, hence you cannot spend all of your time on it. Nothing wrong with that. What bugs me, is that things would go much faster if you let other people spend their free time on TAK.

Quote from: TBeck on
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.

Well, right now it looks bad to me, because there's no unix support (not even MacOS support). Besides, maturity is something that one acquires over *time*. Why can't TAK acquire that maturity while being multi-platform from the start? Why does it need to have everything before you'll let non-Windows users run it?

Quote from: TBeck on
It doesn't make much sense to release source code which isn't clean and lacking a good documentation.

Alright, but there's a large gap between cleaning up code and writing documentation, and waiting for a full set of features to be developed before even considering releasing the source code. Besides, do you really want to build all these features on your current, I assume messy code, and *then* clean the whole thing up? You've got it backwards!

Quote from: TBeck on
I also have to care more for marketing. BTW: TAK still needs a logo!

You have got to be jocking...

Quote from: TBeck on
* Tag writing functions for the TAK applications.
  * Fast seeking without seektable.
  * Raw audio data files as input for the encoder.
  * Option to decode only a specific part of a file.
  * Unicode support.
  * Even more speed and better compression.
  * Applications for other operating systems than Windows.
  * MD5 audio checksums for verification and identification.
  * TAK files as input for the encoder for transcoding purposes.
  * Multi channel audio.

Is that it? That's my main gripe about it all: you want TAK to have all of the features other projects added over several years, before you're going to consider other platforms. And you want to do it all by yourself. Will you delay things further if a user comes along and requests, say, a plug-in for Adobe Audition? Oh, and what are you going to say when users bitch about the lack of support for adding cover art directly from TAK.exe? It took years for FLAC to get all that! Did FLAC have a bad reputation before? If TAK had any reputation in the Free Software world, it would be the kind of rep that, hum, closed-source, windows-only software gets. Reminds you of anything? Foobar2000? EAC?

Quote from: TBeck on
* A german version.

What about chinese? There's literally a billion of them! And what about hindi? That's another billion people!

Look at Monkey's Audio: Windows-centric software, no multichannel support, no piping, no Replay Gain, no inline-tagging, and the list goes on... Yet it's a somewhat popular codec because of its excellent performance. And guess what? It got ported to linux. People wrote plugins for it. Piping support was added through a simple patch. Tagging is supported by third-party software.

Like I said, you want the kitchen sink to be ready before you move to a source code release. I bet I won't see encoding + decoding + playback support under linux before at *least* a[nother] year.
Edit: while we're at it, let me throw in another feature request: multi-threaded encoding. By the time you're finished, we should all have 8-core CPUs (I'm getting a quad-core tomorrow)...

Quote from: kanak on
I see TAK's current status as an advantage; unlike other "more established" codecs, you have the complete freedom to make changes which might break backwards compatibility but result in a very improved codec.

Except he does NOT want to take advantage of that freedom (see his earlier response regarding the ubiquity of MD5).

TAK 1.0.4 - Development

Reply #93 –
Quote from: skamp on
I understand why Thomas would want to wait until the format is final,

I thought it was finalized.

Quote from: skamp on
Working alone and refusing any outside help is the worst way to go when you are unable to fully dedicate your time and resources (IMO, anyway).

This also applies to format specifications and it's a pretty serious issue because you usually can't fix a spec without breaking decoders. Wouldn't it be cool if the smart guys joined forces to actually design something like a new codec? IMHO this makes sense since creating something which is able to outperform existing solutions significantly is very hard to achieve if you're all by yourself.

Cheers,
SG

TAK 1.0.4 - Development

Reply #94 –
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.

Well, for instance, he wants to add MD5 hashing support. With FLAC, it's a fixed field in the streaminfo metadata block. I would consider that to be part of the format specification. So, unless he plans on making the MD5 hash a mandatory APEv2 field entry, the TAK format isn't finalized. He also plans on adding multichannel support, which might require some changes.

TAK 1.0.4 - Development

Reply #95 –
Quote from: skamp on
Quote from: TBeck on
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.

I'm not questioning your dedication at all, just pointing out the realities of life: you're not making a living with TAK, hence you cannot spend all of your time on it. Nothing wrong with that.

My reply was rather directed towards other readers who could misinterpret this and get a wrong impression.

Quote from: skamp on
Quote from: TBeck on
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.

Well, right now it looks bad to me, because there's no unix support (not even MacOS support). Besides, maturity is something that one acquires over *time*. Why can't TAK acquire that maturity while being multi-platform from the start? Why does it need to have everything before you'll let non-Windows users run it?

Maturity may lie in the eye of the beholder. A software can be rock-stable and feature-rich but nevertheless be percepted as immature. Some example: Earlier i initiated far more discussions about TAK's features, often asking for details on how to do something right. At some point i got the impression this behaviour made some readers doubt, i did know what i was doing and that TAK had already achieved a stable (mature) state. That's one reason why i am now a bit more reluctant.

Quote from: skamp on
Quote from: TBeck on
It doesn't make much sense to release source code which isn't clean and lacking a good documentation.

Alright, but there's a large gap between cleaning up code and writing documentation, and waiting for a full set of features to be developed before even considering releasing the source code. Besides, do you really want to build all these features on your current, I assume messy code, and *then* clean the whole thing up? You've got it backwards!

My code isn't messy and it never was. But long time it was designed to make my many evaluations of new compression methods possible. It served this purpose very well but was unneccessary complex for a production or end user release.

I will definitely only release source code i am feeling comfortable with. Maybe i am a bit too much of a perfectionist, but on the other hand it was exactly this trait of mine that made TAK as strong as it is. I think, you have to live with this as i have to do...

It's still much work to prepare a source code release. Indeed i could speed up the process if i did nothing else. But this would get very annoying for me. Therefore i am trying to balance this work and the fun part.

Quote from: skamp on
Quote from: TBeck on

  * Tag writing functions for the TAK applications.
  * Fast seeking without seektable.
  * Raw audio data files as input for the encoder.
  * Option to decode only a specific part of a file.
  * Unicode support.
  * Even more speed and better compression.
  * Applications for other operating systems than Windows.
  * MD5 audio checksums for verification and identification.
  * TAK files as input for the encoder for transcoding purposes.
  * Multi channel audio.

Is that it? That's my main gripe about it all: you want TAK to have all of the features other projects added over several years, before you're going to consider other platforms.

As i wrote above, i am doing several things simultaneously: a) Adding new features and b) working on a source code release in bearable portions. At some point b) will be finished and this has not to be at the end of the feature list.

Quote from: skamp on
Quote from: TBeck on
  * A german version.

What about chinese? There's literally a billion of them! And what about hindi? That's another billion people!

Well, i am german... I would like to have a much better documentation for the applications. Since i am not good in writing english, i will do it in german and than ask someone to translate it. The same applies to my homepage.


Hm...

Is there a limit for the quotes per post? Seems i have to split it. To be continued.

TAK 1.0.4 - Development

Reply #96 –
Quote from: skamp on
Look at Monkey's Audio: Windows-centric software, no multichannel support, no piping, no Replay Gain, no inline-tagging, and the list goes on... Yet it's a somewhat popular codec because of its excellent performance. And guess what? It got ported to linux. People wrote plugins for it. Piping support was added through a simple patch. Tagging is supported by third-party software.

And nevertheless i have the impression it is slowly dying... Source code availability is no guarantee for lasting success.

Don't take me wrong: I really like Monkey's audio and it was my codec of choice until the release of TAK 1.0.

Quote from: skamp on
Quote from: kanak on
I see TAK's current status as an advantage; unlike other "more established" codecs, you have the complete freedom to make changes which might break backwards compatibility but result in a very improved codec.

Except he does NOT want to take advantage of that freedom (see his earlier response regarding the ubiquity of MD5).

Why not ask Josh Coalson to add a stronger hash to FLAC? A new additional meta data structure wouldn't break compatibility. He is possibly be in the position to establish a new standard. I am not.


Given my limited english skills, this reply was much work for me. 

I am aware, that more arguments exist - both supporting and against my position.

I don't think anyone can really predict, if it is better to release the source code now in it's current state or later when it meets my demands. I think i have to let my intuition deceide...

  Thomas

TAK 1.0.4 - Development

Reply #97 –
Quote from: TBeck on
Is there a limit for the quotes per post?
Ten, IIRC.  Annoying, ain't it?

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.
Reasons for using it are quickly going away (IMO), that's for sure.

Quote from: TBeck on
...it  was my codec of choice until the release of TAK 1.0.
Somehow this doesn't come as a surprise.

I don't care what people say, to me encoding efficiency is important and you've made a lot of progress in that direction.  Thanks Thomas!

TAK 1.0.4 - Development

Reply #98 –
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...).

Quote from: TBeck on
Don't take me wrong: I really like Monkey's audio and it was my codec of choice until the release of TAK 1.0.

It used to be too slow for my taste on my old hardware (Athlon XP), but now (Athlon 64 X2) it smokes all other codecs in terms of speed/compression ratio. That was a nice surprise.

Quote from: TBeck on
Why not ask Josh Coalson to add a stronger hash to FLAC? A new additional meta data structure wouldn't break compatibility. He is possibly be in the position to establish a new standard. I am not.

FLAC doesn't need a stronger hash. I was merely pointing out your reluctance to break free from what you see as "standards".
 

TAK 1.0.4 - Development

Reply #99 –
Quote from: skamp on
FLAC doesn't need a stronger hash.
If flac doesn't need a stronger hash why would TAK need something stronger than what flac uses?

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.