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

TAK 1.0.1 Development

TAK 1.0.1 Development

Some information about the next TAK version and some future plans.

SDK

I rewrote considerable parts of TAK to make interfacing to external Application via my new SDK easier. The first SDK version will probably only contain decoding functionality. It consists of a Windows DLL and Header files in Pascal and C.

TAK 1.0.1 will use the modified code, which also contains some improvements, for instance even better handling of damaged files.

Speed

Although the code of TAK 1.0 already was highly optimized, i could squeeze a bit more speed out of it. Encoding may be up to 5, Decoding up to 8 percent faster in V1.0.1 (CPU dependend). I doubt, that i can make decoding even faster without breaking the format compatibility. But future improvements of the encoding speed are possible.

Winamp plugin

As soon as my SDK is done, i will recompile the Winamp plugin (which is using the SDK code) and release it as beta version.

Plugins for other players...

may follow. My SDK already seems to work very well with some other popular player... But that's confidential for now.

Release date

As soon as possible. But currently i have to work on some other things, therefore it may take some weeks.


Future plans

More speed

Earlier i wanted to develop a dedicated Turbo codec with considerably higher decoding speed. It should only be used for preset Turbo.

But after some evaluation i found out, that the speed oriented modifications have so little effect on the compression efficiency (less than 0.02 percent), that it is appropriate to apply them to any preset! Therefore i prefer to build a new all-in-one codec with higher decoding speeds for any preset.

Better compression

I have some new ideas for compression improvements and first evaluations are looking promising. It seems possible to achieve about 0.2 to 0.3 percent better compression for preset Extra.

More exciting are possible improvements of preset Turbo, Fast and Normal. Some files really like the PreFilter option, which is beeing applied in presets High and Extra. Unfortunately this option slows down both encoding and decoding.

But i have found a way to achieve about 60 percent of the PreFilter efficiency without any impact on encoding or decoding speed! Hence the faster presets will compress better without loosing any speed.

And there is another idea to improve the channel decorrelation of preset Turbo. If it works, it will increase the compression efficiency with no effect on decoding speed but at the price of a bit slower encoding.

When will the new codec be available?

When it is done! It needs much time to evaluate my new ideas and to check interactions with the existing methods of the current codec.

  Thomas

TAK 1.0.1 Development

Reply #1 –
Try releasing the code and a Foobar plugin. I think a lot of interest has waned by your lack of followthrough.

TAK 1.0.1 Development

Reply #2 –
I agree with Night Rain. I've adopted TAK and recompressed all my lossless to TAK @ 4 (saving anywhere from 3 to 25 mb per album), but now i have a bunch of lossless files that i need to use an entirely different player to playback! Not a nice situation.

Please give the foobar playback plugin atleast as much priority as the winamp one. Please.

Could you also elaborate on the Replaygain support?

Thanks for your work on tak.

TAK 1.0.1 Development

Reply #3 –
Quote from: Night Rain on
Try releasing the code and a Foobar plugin. I think a lot of interest has waned by your lack of followthrough.


I would love to have this. It's a great lossless codec.

TAK 1.0.1 Development

Reply #4 –
Quote from: Night Rain on
Try releasing the code and a Foobar plugin. I think a lot of interest has waned by your lack of followthrough.

Quote from: kanak on
Please give the foobar playback plugin atleast as much priority as the winamp one. Please.

Quote from: Paws on
Quote from: Night Rain on

Try releasing the code and a Foobar plugin. I think a lot of interest has waned by your lack of followthrough.

I would love to have this. It's a great lossless codec.

Probably i wasn't clear enough: Plugins for other players have a very high priority for me! That's the primary reason why i am working on my SDK. It's close to an release, but it needs some more testing performed by other developers and i have to write some documentation. I simply can't do this immediately because i currently have to work for money...

TAK 1.0.1 Development

Reply #5 –
Quote from: TBeck on
Probably i wasn't clear enough: Plugins for other players have a very high priority for me! That's the primary reason why i am working on my SDK. It's close to an release, but it needs some more testing performed by other developers and i have to write some documentation. I simply can't do this immediately because i currently have to work for money...


Why not release it as a pre-alpha or something so we can tool around? 

TAK 1.0.1 Development

Reply #6 –
Quote from: TBeck on
Quote from: Night Rain on

Try releasing the code and a Foobar plugin. I think a lot of interest has waned by your lack of followthrough.

Quote from: kanak on
Please give the foobar playback plugin atleast as much priority as the winamp one. Please.

Quote from: Paws on
Quote from: Night Rain on

Try releasing the code and a Foobar plugin. I think a lot of interest has waned by your lack of followthrough.

I would love to have this. It's a great lossless codec.

Probably i wasn't clear enough: Plugins for other players have a very high priority for me! That's the primary reason why i am working on my SDK. It's close to an release, but it needs some more testing performed by other developers and i have to write some documentation. I simply can't do this immediately because i currently have to work for money...


Perhaps version 1 should not have been released until more was ready. I see a steady decline in interest in TAK.

TAK 1.0.1 Development

Reply #7 –
Quote from: Night Rain on
Perhaps version 1 should not have been released until more was ready. I see a steady decline in interest in TAK.

Why that?

Because there are a bit less posts regarding TAK at hydrogen? (Except about logo or wiki...) What should people post? Before the release i have frequently asked for testing or feedback and the members responded. It would be easy to increase the frequency of TAK posts by asking for some pre release tests. Would this mean, that TAK is more alive?

Oh, i am not sure, if i have seen a post in the WavPack forum today. Is this a bad sign for WavPacks future?

Until now i myself have not performed any serious promotion work for TAK (outside of hydrogen). Therefore TAK 1.0 possibly has been some kind of a secret release...

  Thomas

TAK 1.0.1 Development

Reply #8 –
Quote from: TBeck on
Speed

Although the code of TAK 1.0 already was highly optimized, i could squeeze a bit more speed out of it. Encoding may be up to 5, Decoding up to 8 percent faster in V1.0.1 (CPU dependend). I doubt, that i can make decoding even faster without breaking the format compatibility. But future improvements of the encoding speed are possible.



Better compression

I have some new ideas for compression improvements and first evaluations are looking promising. It seems possible to achieve about 0.2 to 0.3 percent better compression for preset Extra.

More exciting are possible improvements of preset Turbo, Fast and Normal. Some files really like the PreFilter option, which is beeing applied in presets High and Extra. Unfortunately this option slows down both encoding and decoding.


If you have ways to significantly improve speed and/or compression I think you should go ahead and use all of the tricks NOW, even if it breaks current compatibility. TAK looks to be a very promising Lossless codec in the FUTURE. There should be very few if any people with a significant number of tracks in the TAK format. If you really want the format to compete it needs to be as good as possible. It seems to perform a bit better then FLAC (dont know vs 1.1.4), but for people to really want to change from a heavily supported, well documented, opensource format you need to really blow the old codec out of the water.

TAK 1.0.1 Development

Reply #9 –
I agree that any format-compatibility breakage should happen rather soon if it is worth it. TAK as well as lossless-codecs in general are just at the beginning of their journey. If it is worth it, then better break now instead of later.

- Lyx
I am arrogant and I can afford it because I deliver.

TAK 1.0.1 Development

Reply #10 –
Quote from: Eli on
If you have ways to significantly improve speed and/or compression I think you should go ahead and use all of the tricks NOW, even if it breaks current compatibility. TAK looks to be a very promising Lossless codec in the FUTURE. There should be very few if any people with a significant number of tracks in the TAK format. If you really want the format to compete it needs to be as good as possible. It seems to perform a bit better then FLAC (dont know vs 1.1.4), but for people to really want to change from a heavily supported, well documented, opensource format you need to really blow the old codec out of the water.


Quote from: Lyx on
I agree that any format-compatibility breakage should happen rather soon if it is worth it. TAK as well as lossless-codecs in general are just at the beginning of their journey. If it is worth it, then better break now instead of later.

Much easier said than done!

As i wrote earlier, it took me years to develop the current version of TAK! It can take up to a year to build a new codec with implementations of all the ideas i have. This involves evaluations, optimizations and very much testing and verification.

Maybe i will release an intermediate version. But if i do this, i will also include a function to use Tak files as encoder input for an easy upgrade to the new codec.

TAK 1.0.1 Development

Reply #11 –
I wanted to be one of first to say, "Thanks for the good news about TAK!"

For what it's worth, I don't see a plethora of users outside HA that use Foobar, so I don't care about the lack of a Foobar plugin, the Winamp plugin is a better start.

I await for the person clever enough to use the upcoming SDK to make a TAK_flt.dll (a.k.a. Cooledit filter)
"Something bothering you, Mister Spock?"

TAK 1.0.1 Development

Reply #12 –
Quote from: TBeck on
As i wrote earlier, it took me years to develop the current version of TAK! It can take up to a year to build a new codec with implementations of all the ideas i have. This involves evaluations, optimizations and very much testing and verification.

Maybe i will release an intermediate version. But if i do this, i will also include a function to use Tak files as encoder input for an easy upgrade to the new codec.


T - does the TAK file/storage format include a dataformat versioning field somewhere in the header or stream, to ensure that future decoders will be able to route the data to the older vs. newer engines?

-brendan

TAK 1.0.1 Development

Reply #13 –
you take care of your music-collection, you are using lossless-codecs for backing up, you are willing to invest some time for your collection, you are able to work with new codecs to get any benefits and you decided to for some reasons, you are able to cope with encode-decode...

..then I don't get the clue - you are aware of using an really interesting and promising new codec, for ree, encoding & decoding is possible, playback needs time (with foobar) as - said more than 10 times - the SDK has to be finished, with winamp it's possible (you can use 1by1 for light-weighting), and..

no no, I am not argueing, but still wondering why someone has to answer and comment all the questions and comments spent again and again.
And if it's brought too early for you, don't use it, it's not adressed to you..

TAK 1.0.1 Development

Reply #14 –
Quote
Could you also elaborate on the Replaygain support?

Maybe I missed something, but I always thought that replaygain support isn't a codec's feature but a player's. If e.g. TAK is going to use APEv2 tags and corresponding replaygain tags are stored, I'm pretty sure that foobar (and other players reading that tags) will be able to use it...

TAK 1.0.1 Development

Reply #15 –
Nice progress with TAK, I didn't expect performance improvements so soon after 1.0.
Good news about the SDK l guess that means more plugins coming soonish.

Interest for TAK waning? Hello, when has it taken off anyway? Afaik it is still a ha.org private affair at the moment.

TAK does blow FLAC (which is not an old codec) out of the water by compressing more at comparable speed. But if that is not something that matters to me, I will keep using FLAC which is the best choice in my case. People will keep using different lossless codecs and that is good.

TAK 1.0.1 Development

Reply #16 –
Quote from: Destroid on
I wanted to be one of first to say, "Thanks for the good news about TAK!"

Hi Destroid, thank you!

Quote from: bhoar on
T - does the TAK file/storage format include a dataformat versioning field somewhere in the header or stream, to ensure that future decoders will be able to route the data to the older vs. newer engines?

Surely! Both the header and the stream itself (which is also decodable without the header available) contain info about the codec version and the decoding requirements (calculation complexity).

Quote from: sPeziFisH on
..then I don't get the clue - you are aware of using an really interesting and promising new codec, for ree, encoding & decoding is possible, playback needs time (with foobar) as - said more than 10 times - the SDK has to be finished, with winamp it's possible (you can use 1by1 for light-weighting), and..

no no, I am not argueing, but still wondering why someone has to answer and comment all the questions and comments spent again and again.
And if it's brought too early for you, don't use it, it's not adressed to you..

Thank you for those words...

Quote from: jido on
Nice progress with TAK, I didn't expect performance improvements so soon after 1.0.

I had not planned to work on improvements, but while cleaning up my source code for the SDK i found some opportunities for optimizations and couldn't resist...

The same was true for the new ideas for compression improvements for future versions. I haven't worked on this for some time and this break possibly was useful for building up some new connections in my mind...

Quote from: jido on
Interest for TAK waning? Hello, when has it taken off anyway? Afaik it is still a ha.org private affair at the moment.

I agree. And that's intentional...

TAK 1.0.1 Development

Reply #17 –
This is a great list of improvements.  Looks like TAK is coming along great for being so new.  The ability to use tagging is the only really great thing that is missing.  Keep up the great work!!

TAK 1.0.1 Development

Reply #18 –
Current progress

yes, there is progress!

The work on the SDK documentation has taken much time. The code is complete and currently beeing tested by some other developer.

I added a new meta data structure to the format, which contains the encoder version, the preset and the evaluation level. No, i haven't forgotten it in TAK 1.0, but it would have been quite useless with all the encoder options available. The main purpose of this info is the possibility to define conditions for transcoding purposes, for instance: Transcode any file to preset HIGH / Evaluation MAX if it has been compressed with weaker settings. Such rules would have been far too complicated if you had to deal with all the encoder options of TAK 1.0. But since TAK 1.0.1 will remove these options and instead add a new evaluation level EXTRA, it's now practicable.

Evaluation EXTRA is especially interesting if applied to Presets TURBO or FAST, because it significantly increases compresion (up to 0.30 percent) with a speed penality of only 25 to 30 percent.

Because i anyhow had to write some code to check the new meta data structure, i added a new feature: TAK 1.0.1 can show you some information about the internals of TAK files. It looks like this:

Code: [Select]
=== BeautySlept.tak ===========================================

  File size:                     1.64 MB
  Header size:                   0.18 KB
  Compression:                  62.44 %
  Samples per channel:         689262
  File duration:                16.00 sec
  Frame duration:                  94 ms
  Seek point interval:            937 ms
  Audio format:            PCM, 44100 Hz, 16 Bits, 2 Channels
  Encoder:                 V 1.0.1, Preset Turbo, Evaluation Standard
  Wave file meta data:     Header 46, Footer 0 Bytes
  Status:                  Ok


As usual this info can also be collected from a set of files and be written to a log file.

  Thomas

TAK 1.0.1 Development

Reply #19 –
Current progress

Well, it will take a bit longer to finalize my SDK. I have deceided to add support for reading APEv2 tags, which is the recommended tagging standard for TAK. This means more testing, documentation and translation.

When it's done i will also release a new WinAmp plugin with APEv2 support.

  Thomas

TAK 1.0.1 Development

Reply #20 –
Hi Thomas.

I'm confused.  Reading?  I know plugins will need to read tags, but I would have thought TAK only need be concerned about writing tags.

Not that I know diddly of course, just an opportunity to say hi and maybe squeeze you for a little more info...
I'm on a horse.

TAK 1.0.1 Development

Reply #21 –
Quote from: Synthetic Soul on
Hi Thomas.

Hi Neil  .
Quote from: Synthetic Soul on
I'm confused.  Reading?  I know plugins will need to read tags, but I would have thought TAK only need be concerned about writing tags.

Not that I know diddly of course, just an opportunity to say hi and maybe squeeze you for a little more info...

Hm, maybe you are right. The reason why i wanted to add support for reading tags:

1) The wavpack sdk and other sdks support it. Me too!

2) The winamp playback plugin interface contains functions to request tag info. I want to provide it.

3) Writing code to read the tags is a good starting point for me to learn a bit more about APEv2 tags. It's less dangerous than writing them (if there are bugs in the code).

4) Probably i will later add an option to move the APEv2 tag into TAK's meta data structure located at the beginning of the file. Then you will need TAK's functions to access it.

I used the TAG tool from your homepage to add tags to my test files. Thank you! When i looked at the header and footer it generated, i was a bit surprised.

You know that there are two flags in both the APEv2 header and footer, indicating if there is also a footer respectively header.

This is the result from tags created with TAG.EXE (appended to the file end):
Code: [Select]
Header
  ContainsHeader = False
  ContainsFooter = False
Footer
  ContainsHeader = True
  ContainsFooter = False


I would have expected this (if header and footer are present):

Code: [Select]
Header
  ContainsHeader = True
  ContainsFooter = True
Footer
  ContainsHeader = True
  ContainsFooter = True


Ok, the most important information is there: if you read the footer at the file end, you indeed only need to know if there is also a header. But i was surprised.

Another question about the format: Items (or Keys) can contain multiple values seperated by NULL. Is this option really used?

  Thomas

TAK 1.0.1 Development

Reply #22 –
Well, seems like you do have good reason.  I should have known.

Thanks for the info RE: Tag.  Tag was written by Case and I have merely made a few mods and updated the libraries.  I am aware that there are headers and footers but I have no idea what Tag is doing in this area.  I may have to read up on the spec as well!

foobar has functionality for multiple values in one tag.  I think it may be used more so with tagging classical music.  In essence, I would say "yes" - but I hope that someone with more tagging experience sees this and responds with more clarity.

Thanks for the info, and good luck with the continuing work.  Whether I respond or not I do always read your updates with interest.
I'm on a horse.

TAK 1.0.1 Development

Reply #23 –
On checking I think Tag is fine.

The header says "Tag contains a header, tag contain a footer, this is the header" (31 = 1, 30 = 0, 29 = 1) while the footer says "Tag contains a header, tag contain a footer, this is the footer" (31 = 1, 30 = 0, 29 = 0).

Do you agree?

I was confused for a while, until I realised that bit 30 as 0 meant there was a footer.
I'm on a horse.

TAK 1.0.1 Development

Reply #24 –
Quote from: Synthetic Soul on
On checking I think Tag is fine.

The header says "Tag contains a header, tag contain a footer, this is the header" (31 = 1, 30 = 0, 29 = 1) while the footer says "Tag contains a header, tag contain a footer, this is the footer" (31 = 1, 30 = 0, 29 = 0).

Do you agree?

Totally!

Quote from: Synthetic Soul on
I was confused for a while, until I realised that bit 30 as 0 meant there was a footer.

Me too! Painful... Well, things may get better soon, because i just ordered some new glasses. Now i know, how urgent this was...

Thank you!

  Thomas