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

TAK 1.1.0 Development

Purpose of this thread

- I will post news about the development of the next TAK version.
- I may ask you questions regarding new features.
- You may comment my work, ask for features and help me to do it right.

What i did until 2008-08-31

Hey, i hope you didn't think i wasn't working on TAK anymore?!

The bigger part of my spare time goes into TAK 2.0 development, therefore new TAK 1.x releases will take a bit longer than earlier.

The next version will contain at least these improvements:

- Support for 192 Khz Audio.
- Seeking without seek table. Some users seem to need it, especially when using pipe encoding.
- Fixed a bug in the encoder that resulted in suboptimal compression of some loud files and especially high resolution audio. Some files may gain about 0.05 percent of compression. Not much, but it comes without any speed penality.

The next version will be named TAK 1.1.0 instead of 1.0.5.

That's because earlier decoders will not decode files with more than 96 KHz, which can be generated with the next version. They also will not support seeking in new files generated witout a seektable.

TAK 1.1.0 Development

Reply #1
Although I don't use TAK, I've heard nothing but great things from it.  Keep up the good work, maybe I'll compress a few things with TAK to give it a whirl. (Currently my audio collection is iTunes AAC, MP3, FLAC, and WavPack.

TAK 1.1.0 Development

Reply #2
TAK V1.1.0 is nice but TAK V2.0 looks so much more promising that I am already looking forward for TAK V2.0 ... IMHO V1.1.0 is a useless update because the biggest problem of TAK is not its performance as it already beats all other lossless codecs ... but the problem is its lack of support which is due to only one thing IMHO the fact that is is not yet open source ... I am pretty sure that third party developers (F2K, Mr ?man, Cuetools ...) are waiting for TAK to be open sourced before they support it ... & end-users like me are waiting for it to be better supported (via open source) in order to leave flac ... make a clear open source release & TAK will instantly become N°1 ... keep doing ultra performant but closed source release & TAK will always stay N°2.

For exemple if TAK is still not open sourced when lossywav V1.2.0 comes out (which is likely) ... I will use flac for my own use no matter how much more performant TAK is.

I like TAK as it is very impressive, I love FLAC as it is future-safe.

TAK 1.1.0 Development

Reply #3
I am pretty sure that third party developers (F2K, Mr ?man, Cuetools ...) are waiting for TAK to be open sourced before they support it ...


Code: [Select]
foo_input_tak.dll

Decodes and tags TAK files.

Built for TAK library version 1.0.1
Using TAK library version 1.0.7 (compatible with versions down to 1.0.0)

Copyright © 2007-2008 Holger Stenger
TAK icon by Florian Trendelenburg (used with permission)


Support is always relative. There is a decoder SDK, which has already been used to expand its reach (as shown by the example above).  The real problem has been, probably, the lack of support for other platforms than windows, but that can be understandable in some cases too (if you don't have such a platform, you cannot be sure if that works).

Anyway, he should probably be able to build the library for other platforms (linux at least, there's a delphi/pascal compiler).

TAK 1.1.0 Development

Reply #4
make a clear open source release & TAK will instantly become N°1

That's wishful thinking… There are still lots of people who think "Lossless = FLAC" and ask "why would anyone want to use any other lossless codec". FLAC is the lossless MP3. Ogg Vorbis is Free Software and well supported, has been around for years, yet it remains a distant second.

TAK 1.1.0 Development

Reply #5
The biggest problem with Vorbis is Christopher Montgomery & his close minded way of thinking ("Leave me alone, I am the best"). Vorbis is strictly superior to mp3 but Monty alone is strictly inferior to any open minded mpeg developer ... I'd rather have to deal with patents than having to deal with Monty ... I have learned one thing from my vorbis experience ... before using a codec, learn about who is doing it. Monty never developped any audio codec, he is doing hit & run technology demonstration to prove to the world how clever he is ... I hope Tom is not as bully minded as a Debian developper ... I have been waiting for TAK to be open sourced for nearly a year now ...

TAK 1.1.0 Development

Reply #6
cool! nice to see you're still developing TAK!

now that you mentioned it, i can't resist to ask: what's version 2 going to bring?

TAK is great! thank you for your work

@sauvage78: don't call 1.1 a useless update. there are new features and fixes, even if you won't use them. i'm sure you didn't mean it, but it sounded rude.

TAK 1.1.0 Development

Reply #7
@sauvage78: don't call 1.1 a useless update. there are new features and fixes, even if you won't use them. i'm sure you didn't mean it, but it sounded rude.

...as did his off-topic rant about ogg.  Keep it up sauvage78 and you'll find your posts in the recycle bin.

TAK 1.1.0 Development

Reply #8
1.1.0 seems like a good step closer towards 2.0 and is adding features that will be needed in 2.0.  Keep up the good work, TBeck.

I have been using Lossy WAV and TAK as of late for my Desktop computer music library that gets accessed by my notebook through the home WiFi.

Since TAK is supported by foobar2000 and my DAP does not support lossless of any sort at the moment, I have to use Lame 3.98 mp3, I am one of those people in the position to care less about support for the codec being everywhere.  Even FLAC did not have all that support a few years back.

All great codecs have to start somewhere.
Zune 80, Tak -p4 audio library, Lossless=Choice

TAK 1.1.0 Development

Reply #9
Not to sound like a FOSS fanboy, but it'll be interesting when this is ported and opened up (or at least opened up).

I know Josh does a lot of work to get OEMs to support FLAC on portable and embedded devices, and that's with a BSD(-style?) license.

I'm interested to see not only where TAK will lead technically, but also how the adoption curve will develop over the next few years. Best of luck to you  (and thanks for putting some new life into the lossless codec arena).

TAK 1.1.0 Development

Reply #10
Great news, Thomas. Happy to see TAK improving.

One question then: what about a hybrid-mode+correction-file for TAK? Is it technically feasible or desirable?
ATM that's a feature of Wavpack I rely intensively on - the last gap that prevents me from switching to tak.

Keep it up! MfG,

TAK 1.1.0 Development

Reply #11
I moved recently from FLAC to TAK.
Using TAK with LossyWAV and looking forward to the LossyTAK enhancements.
TAK and fb2k work for me. 

Keep up the excellent work.

C.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

TAK 1.1.0 Development

Reply #12
Hey, i hope you didn't think i wasn't working on TAK anymore?!

No, we knew that from your previous posts, but we try not to ask all the time 
I hope that by default the next TAK will make files that are compatible with the 1.0 series (with seektables). Even the small updates give some exposure to the fact that TAK is being worked on.
In theory, there is no difference between theory and practice. In practice there is.

TAK 1.1.0 Development

Reply #13
Good to hear Thomas!

I've been using TAK for awhile now and have been following it extensively since you announced it that one April day.

Keep up the excellent work! Can't wait to see what the future of TAK will be.

TAK 1.1.0 Development

Reply #14
This is great news! Once MusicBrainz adds support for TAK in Picard, I might finally switch from FLAC to TAK for my lossless needs.

TAK 1.1.0 Development

Reply #15
First: Thanks for the encouragement! It's always appreciated!!!

now that you mentioned it, i can't resist to ask: what's version 2 going to bring?

Copied from another thread:

1) The work on TAK 1.x.x will focus on the addition of new usability features and stream improvements (for instance seeking without seek table). The codec will remain unchanged.

2) Simultaneously i am working on a new slightly modified codec with the following features:

- Even more speed. Decoding is already about 7 percent faster than in 1.0.4.
- Shorter and simplier source code which is easier to document and understand.
- Hopefully slightly better compression (0.10 to 0.15 %) for many files.
- A dedicated compression mode for LossyWav that will hopefully save another 20 to 25 kbps.

It will not be a revolution but an evolution. I still want to create the most efficient (compression/speed ratio) codec and provide you the most bang for the buck.

And this codec (which will be introduced with TAK 2.0) will most probably be the last significant format change. Later work may improve the encoder, but without breaking the format.

Important: I can't tell you a release date for V 2.0! When it comes, it will be backwards compatible with TAK 1.x. The work on V 1.x will go on until a 2.0 release.

One question then: what about a hybrid-mode+correction-file for TAK? Is it technically feasible or desirable?
ATM that's a feature of Wavpack I rely intensively on - the last gap that prevents me from switching to tak.

I don't intend to reinvent the wheel...

"Nick.C" is doing a very good job with LossyWav! Could this be an option for you?

TAK 2.0 or 2.1 will add an dedicated compression mode for LossyWav, that hopefully will significantly improve the compression of LossyWav files.


Hey, i hope you didn't think i wasn't working on TAK anymore?!

No, we knew that from your previous posts, but we try not to ask all the time 

Very considerate 

I hope that by default the next TAK will make files that are compatible with the 1.0 series (with seektables).

Yes. I may change this later, when the new decoder has been spread.

Even the small updates give some exposure to the fact that TAK is being worked on.

Oh yes!

BTW: Seeking without seek table is now working very well. For harddisk based playback it's hardly slower than seeking with seektable. On my system the average seek time is about 25 ms. TAK doesn't have to decode a frame to perform a seek. Therefore the seeking speed is nearly only dependent on access times and transfer rates of your storage system.

TAK 1.1.0 Development

Reply #16
You always come with great news! Keep up the great work Thomas!
Allegari nihil et allegatum non probare, paria sunt.

TAK 1.1.0 Development

Reply #17
very cool!
can't wait for TAK 2!
7% more speed sounds great!
so is version 2 the one you plan to opensource?

how much space is saved by encoding without a seektable? what are the advantages? is it worth it?

TAK 1.1.0 Development

Reply #18
You always come with great news! Keep up the great work Thomas!

Thank you! 

so is version 2 the one you plan to opensource?

It doesn't make much sense to go open source before i am really happy with the codec. The 2.x-line will be a candidate for it.

how much space is saved by encoding without a seektable? what are the advantages? is it worth it?

Very little space if you don't use pipe encoding: about 0.002 percent for CD-Audio. Up to maybe 0.03 percent with pipe encoding if the parameter for the seek table size isn't appropriate.

Not really much, but:

1) Some users were complaining about the lack of this option when i introduced pipe encoding.

2) Josh Coalson more often than once pointed out that FLAC can seek without seek table and i don't want  TAK to look worse...

3) Possibly the most complicated part of the TAK documentation is the one dealing with the appropriate parameter choice for the seek table size when using pipe encoding with foobar. It's much easier if you don't have to deal with it at all, because no seek table is required.

Well, the reason for the addition of this option is merely psychological... But it was also an interesting task to implement it. And it was also a pleasure to confirm, that it can be done more efficiently with TAK than with FLAC, because TAK can perform a seek without the need to decode a frame.

TAK 1.1.0 Development

Reply #19
Tom here are some logos I designed for TAK if you like any of these designs or have any question please contact via the HA personal message.  I think TAK has great potential and hope you will release an Apple Mac version soon.  Good luck with the development of TAK!


TAK 1.1.0 Development

Reply #20
TBeck, could you add checking method of md5-hash like FLAK and WavPack 

EDIT:
woops, I don't read Readme.html...
TAK already has added a 24-bit checksum. very sorry.

Quote
Error detection. Each single frame is protected by a 24-bit checksum (CRC).
<name>madoka</name>

TAK 1.1.0 Development

Reply #21
And it was also a pleasure to confirm, that it can be done more efficiently with TAK than with FLAC, because TAK can perform a seek without the need to decode a frame.

it's not necessary for FLAC, that's just the way the decoder does it now.  the current way is fast enough to not be an issue.

TAK 1.1.0 Development

Reply #22
It doesn't make much sense to go open source before i am really happy with the codec. The 2.x-line will be a candidate for it.

TAK is more and more likely to take the path of Monkey's Audio, which is now pegged as a "mostly Windows-oriented codec" (I read that recently), even though there's some support on Unix platforms (including MacOS X). Your world-domination plan is flawed

Since the FFmpeg project has implemented closed-source codecs such as MLP/TrueHD, ALAC, E-AC3, maybe you could at least do some PR and interest them in implementing TAK as well.

TAK 1.1.0 Development

Reply #23
Quote
The bigger part of my spare time goes into TAK 2.0 development, therefore new TAK 1.x releases will take a bit longer than earlier
Is there still no chance to have some kind of (draft or even uncomplete) documentation for TAK's container format?

TAK 1.1.0 Development

Reply #24
It doesn't make much sense to go open source before i am really happy with the codec. The 2.x-line will be a candidate for it.

Since the FFmpeg project has implemented closed-source codecs such as MLP/TrueHD, ALAC, E-AC3, maybe you could at least do some PR and interest them in implementing TAK as well.

I am an FFmpeg developer, and I am definitely interested in TAK.  Having the source opened up once it reaches 2.0 would certainly be nice, but personally I think a good format specification would be even more valuable.  Of the above mentioned codecs, MLP and ALAC had to be reverse-engineered because there is no public specification, which has been very frustrating. E-AC-3 has an open, free specification, so the development has been much easier.