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

TAK 1.1.0 Development

Reply #25 –
Resurrecting this thread to bring something to your attention, Tom...

I use MusicBrainz to tag all the albums I rip, and the current version of Picard does not support TAK (which is the main reason I'm not using it yet; I'm still using FLAC).

I posted a bug over at MusicBrainz (http://bugs.musicbrainz.org/ticket/3970) for adding support for TAK, and they did respond that support will be in the next release of the application.

However, the exact response is what prompted this post (emphasis added):
Quote
... the support is very limited due to the closed nature of the codec. It supports only adding APEv2 tags, the file length is not shown, scanning doesn't work.


Any chance I could convince you to work more closely with the team over at MusicBrainz to help improve their support for your fine codec? I realize the difference in compression between your codec and FLAC isn't very large, but since I plan on archiving my entire CD collection losslessly, I consider every byte precious.

TAK 1.1.0 Development

Reply #26 –
really?  a byte on a 500G hard drive costs about US$0.0000000003

TAK 1.1.0 Development

Reply #27 –
Depends on what kind of hard-drive.

TAK 1.1.0 Development

Reply #28 –
I'm anal

TAK 1.1.0 Development

Reply #29 –
Tbeck, would it be possible to add "low priority" switch into next version of Tak?

I'm planing to reencode all my FLAC collection (~400GB) to Tak. Since I've only one PC, I also need to do other tasks and prefer having Takc run in background.

Using statistic from Synthetic Soul's Lossless Codec Comparison, reencoding to Tak would save roughly around ~11G of hdd space.

edit: spelling

TAK 1.1.0 Development

Reply #30 –
You may be able to work around this yourself if you're running Windows.

Press Ctrl/Alt/Del and left-click on the appropriate exe on the Processes tab. Now right-click and move your mouse pointer down to Set Priority. You may be able to set it to "Low" in there.

Cheers, Slipstreem. 

TAK 1.1.0 Development

Reply #31 –
That would work for that instance of takc.exe, if you could catch it, but as soon as it closed the next instance would have Normal priority again.

I have seen a VBS script that watches for the name of an application and (re)sets its priority to a desired value.  I've used it for a PAR2 script I had.

If you used foobar, which would make retaining tags easy, IIRC you can set the priority of the Converter thread(s).  It's pretty low by default I think.
I'm on a horse.

TAK 1.1.0 Development

Reply #32 –
START /LOW takc.exe?

TAK 1.1.0 Development

Reply #33 –
A very good point.

I'm still wondering about tag transfer though.  Case's Tag could do it, using --fromfile, I think.

Also, I know decoding is faster, but does FLAC have such a switch?  IIRC WavPack does have a switch like this - both the encoder and decoder.
I'm on a horse.

TAK 1.1.0 Development

Reply #34 –
If I put a process on low priority in my taskmanager it's always handled that way. Have WinXP SP3

TAK 1.1.0 Development

Reply #35 –
Huh, sorry, i had little time to work on TAK in the past months (and to reply to posts and mails). It would take only about 2 days to finalize V1.1.0 and release a beta, but currently i don't have this time. But i still intend to release a new version this year.

Quote from: sundance on
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?

Oh yeah, i really want to do this! It may be the next thing to work on after the 1.1.0 release.

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

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

Quote from: Zarggg on
...
Any chance I could convince you to work more closely with the team over at MusicBrainz to help improve their support for your fine codec? I realize the difference in compression between your codec and FLAC isn't very large, but since I plan on archiving my entire CD collection losslessly, I consider every byte precious.

Thank you all for your interest (and warnings  )!

For now i can only repeat what i wrote above:
Quote from: TBeck on
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.

I really hope to have more time for TAK in the future!

Well, this doesn't mean i am not working on TAK at all. Always when i have a couple of hours left i am working on TAK 2.0.  The problem is, that currently my spare time is so fragmented. I need a a couple of days in a row to release a beta and to fix the quite possible bugs reported after the release.

Quote from: zombiewerewolf on
Tbeck, would it be possible to add "low priority" switch into next version of Tak?

I will look at it. If it's easy to do, i can implement it in V1.1.1.

BTW: I just changed my hosting plan to one with a bigger monthly transfer volume. Therefore i am now able to host the TAK files by myself. 

  Thomas

TAK 1.1.0 Development

Reply #36 –
Thomas, have you ever thought of 2 licences for TAK? You could open source now the decoder for Linux. I would be totally OK with Win32 closed. This could help TAK catch on Linux and help other applications to support it fully. In my vision, it would defeat one of the greatest TAK's shortcommings. Or at least start to defeat the lack of multi-platform support. TAK's Applications/Encoder/Decoder are already very well served for Win32, through your hands.

By the way many thanks for your HARD WORK on this.
PS: I miss TAK's devel posts!

TAK 1.1.0 Development

Reply #37 –
Quote from: Neasden on
Thomas, have you ever thought of 2 licences for TAK? You could open source now the decoder for Linux. I would be totally OK with Win32 closed. This could help TAK catch on Linux and help other applications to support it fully. In my vision, it would defeat one of the greatest TAK's shortcommings. Or at least start to defeat the lack of multi-platform support. TAK's Applications/Encoder/Decoder are already very well served for Win32, through your hands.

I will definitely first release the source of the decoder, this simply because it's much less code and far simplier to understand (and to document). But as i wrote above, the 2.0 codec will be a candidate for this.

Quote from: Neasden on
By the way many thanks for your HARD WORK on this.

Thank you! 

Quote from: Neasden on
PS: I miss TAK's devel posts!

Me too, primarily because of the motivation provided by the user responses. And they always made clear, that TAK development is very vivid.

And despite the missing devel post, TAK's development ist still vivid.

Currently i am working on the final coding step, the efficient storage of the residuals of TAK's filters. TAK 1.x is using 3 different methods for this and i want to reduce it to only 1. It will not help the speed and the code size will not be significantly smaller, but (following a source code release) it will be less work for other developers to port only one method to other platforms. And i will have to document only one...

I regard this as important for the future of TAK, but i doubt this would be very interesting for current users.

Ok, it will increase compression of 8-bit audio files -where TAK is already performing very well- by about 0,75 percent. And LossyWav-files may compress 0.05 to 0.10 percent better. That's nice but probably not very important for most users.

  Thomas

TAK 1.1.0 Development

Reply #38 –
Quote from: TBeck on
I will definitely first release the source of the decoder, this simply because it's much less code and far simplier to understand (and to document). But as i wrote above, the 2.0 codec will be a candidate for this.


Good to hear that moving towards open source is still on your list of priorities, but does this mean that you have no intention to release source or documentation for the 1.0.x format?

Quote
Currently i am working on the final coding step, the efficient storage of the residuals of TAK's filters. TAK 1.x is using 3 different methods for this and i want to reduce it to only 1. It will not help the speed and the code size will not be significantly smaller, but (following a source code release) it will be less work for other developers to port only one method to other platforms. And i will have to document only one...


Speaking as a developer waiting for your source code or documentation (in my case so I can implement TAK support for Rockbox), it would be a shame if any future open source implementation of TAK was to be unable to decode any files encoded by the 1.x encoders.  Personally, I would be happy to do the extra work needed to maintain full compatibility - users shouldn't have to worry about such things. 

I hate to repeat what has been suggested ad-nauseum on these forums, but I have to mention that simply releasing your existing Delphi source code today under an OSI-approved license would solve all compatibility issues.  It would be no work for you, and other people would have all the information they need to implement a decoder compatible with all TAK versions.  As a developer, I continue to not understand how a binary can be considered suitable for public use, if the source code isn't.  But I respect the fact that it's your work, and that you've decided you don't want to publish your current source.

I also have a question about your upcoming 1.1.0 seeking changes.  Is this an actual change to the stream format, or just a change in the decoder to allow it to seek in files without a seektable?

Thanks.

TAK 1.1.0 Development

Reply #39 –
I have to hurry...

because i want to release TAK 1.1.0 before christmas!

Possibly i am posting now to force myself to work a bit harder...

Here a list of new features and changes:

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

- Further clean up of the Code. Especially i want a clear separation of assembler and pascal code: Turn off a compiler switch to make it work without any assembler optimizations. The bad: I lost about 2 percent of speed for presets turbo to normal. The good: I discovered new possibilities for optimizations (sometimes it's good to pause the work and do something totally different...) and now those presets are about 3 to 5 percent faster on my systems (Pentium III - 1000 MHz and Pentium Dual Core 2000 MHz)! Not too much, but if you take into account that following the release of TAK 1.0.4 i thought there wasn't anything left to tune the codec... And TAK 2.0 will be even faster.

BTW: Because i now own a multi core, it's quite probable one of the next TAK versions will support multiple cores for encoding.

- I hope you don't mind but i always had the feeling 5 presets are enough. Therefore i dropped the appropriately 'Insane' named preset -p5 and instead made presets 3 and 4 stronger. Okay, new -p4 will nevertheless be slightly weaker than old -p5, because i have reduced the maximum predictor count from 256 to 160. Before doing this i performed a detailed analysis of predictor count * compression * speed. There are not many files which benefit from such high predictor orders. Two of my file sets contain many of such files, but even they will only loose about 0.10 percent compression. Not a big loss if in exchange you get nearly half the decoding (cpu power) requirements.

Probably it was a good thing that i had less time for TAK this year. I could rethink some things. Findings:

TAK's strongest point (the one that justifies it's existence) is it's efficiency, defined as compression * speed ratio.

It doesn't make any sense to try to compete at any cost with the compression wise strongest but much slower codecs like Optimfrog and LA. Currently i can't see how you can have both: maximum compression and highest speed. In the past i was tempted to sacrifice speed for more compression. But that's not the way to go for me.

This deceision makes some really hard choices easier, especially for the TAK 2.0 development. Modifications have to be:

- Easy to understand for other developers
- Fast

V 2.0 will be both faster and more efficient. But instead of adding more complexity to the now discarded 'Insane' preset i will make especially the presets turbo, fast and normal even more efficient.

  Thomas

TAK 1.1.0 Development

Reply #40 –
my experience is that you are right, speed is more important than compression ... because if your storage strategy is good you always recode your lossless collection sooner or later, so the only thing that matter is neither pure speed or pure compression but the compression/speed ration at the average setting ...

I have only an athlon xp 2Ghz & unless I buy a new CPU, I didn't plan to use TAK above -p3e so actually I don't care much for -p5.
Nice to hear about multi-core. How does the last changes affect lossytak ?

"i am posting now to force myself to work a bit harder" ... I think you are right !!! you don't work hard enough you lazy boy

As I already said I will not use TAK 1.1.0 if there is no code release ... so sadly  it is a useless christmas gift for me ;(
but Dear Father Christmas, do you think that I could have a 2.0 TAK release with a clean code for Christmas 2009-2010 ? I added this to my wishlist & I promise I will be a nice boy

thks for the update but for now I will stay with flac for the support even if I know tak is superior.

TAK 1.1.0 Development

Reply #41 –
You seem to be carrying the right choices Thomas. It's also good to hear that we'll have a great Christmas gift, TAK 1.1.0. And as I said before, I don't mind closed source.

TAK 1.1.0 Development

Reply #42 –
As there doesn't seem to be any info or source coming from Thomas, I thought I would share some information I've managed to deduce about the TAK file format:

http://linuxstb.cream.org/tak_format.html

Hopefully it's of use to someone.

TAK 1.1.0 Development

Reply #43 –
Quote from: davechapman on
As there doesn't seem to be any info or source coming from Thomas, I thought I would share some information I've managed to deduce about the TAK file format:

http://linuxstb.cream.org/tak_format.html

Hopefully it's of use to someone.

Sorry ... sorry ... and sorry!

I am ashamed 

You did what i really wanted to do for some time but hadn't enough time for. What makes me feel really bad is that it was much more effort for you without my knowledge about the format. Okay, for me it's always quite difficult to write a documentation in english and that's probably the main reason why i hesitated to start with it...

Really great work!

And it' arousing  some amazing feeling to see a written documentation about TAK! I didn't know that.

I would like to send you the module of my source code which encodes and decodes the container objects. If you are interested, i will translate it's comments into english and add some more info to it.

And another sorry. Can it be you sent me an email i have not replied to yet?

Here the problem is: In the past i was too careless when answering questions about the date of a possible source code release. I was to optimistic about my amount of spare time left to work on TAK. Now things take much longer than expected. I don't want to raise wrong expectations about the progress.

Again,

thank you very much! 

  Thomas

TAK 1.1.0 Development

Reply #44 –
Quote from: davechapman on
As there doesn't seem to be any info or source coming from Thomas, I thought I would share some information I've managed to deduce about the TAK file format:
...

Quote from: TBeck on
I would like to send you the module of my source code which encodes and decodes the container objects. If you are interested, i will translate it's comments into english and add some more info to it.

I have just begun this work. Please tell me, if and how (email) you would like to receive the source when i am ready.

  Thomas

TAK 1.1.0 Development

Reply #45 –
Quote from: TBeck on
Quote from: TBeck on

I would like to send you the module of my source code which encodes and decodes the container objects. If you are interested, i will translate it's comments into english and add some more info to it.

I have just begun this work. Please tell me, if and how (email) you would like to receive the source when i am ready.


Sure, I would be happy to see your container parsing code.  I assume you would like me to keep that source private, but use it to complete my document on the container format?  I'm happy to do that, but the decoder source would be even more helpful  (<--- very big smiley!)

And yes, I have sent an email to you which you haven't replied to yet

Email for the source is fine - my email address is on the webpage I linked to with my description of your format.

Regards,

Dave.

TAK 1.1.0 Development

Reply #46 –
Quote from: davechapman on
Sure, I would be happy to see your container parsing code.  I assume you would like me to keep that source private, but use it to complete my document on the container format?

Possibly i will send you a version, which isn't perfect. For instance i still have to standardize my naming conventions. This version should be kept private, but i don't have a problem to publish the final version, if someone finds it useful.

BTW: Athough this piece of code is hardly of any use besides of documentation purposes, i have to put some license into it. Currently i prefer BSD. Could be anything wrong with this? I definitely want to permit proprietary decoder implementations.

Quote from: davechapman on
I'm happy to do that, but the decoder source would be even more helpful  (<--- very big smiley!)

No more promises... ... but i am motivated.

Quote from: davechapman on
And yes, I have sent an email to you which you haven't replied to yet

 

  Thomas

TAK 1.1.0 Development

Reply #47 –
Quote from: TBeck on
BTW: Athough this piece of code is hardly of any use besides of documentation purposes, i have to put some license into it. Currently i prefer BSD. Could be anything wrong with this? I definitely want to permit proprietary decoder implementations.


If you are asking me to keep the source code you send me private, then there is no need for you to put any license text in it.  In fact, that will just confuse me - do I comply with your request to keep it private, or do I share it as the license text in the files allow?.  So in my opinion you shouldn't put any license info into it until you release it publically.  Without any license text, your intentions are clear - I have no right to share it.

But in reality, I would comply with your wishes - even if you put the BSD (or other) license in the code, I wouldn't share it if you didn't want me to.

As I'm sure you've seen from www.opensource.org, there are many open source licenses, and the choice really depends on what you want to allow other people to do with your work.  The BSD license means that people can take your code and incorporate it into proprietary (closed-source) software, without any requirements for them to share any improvements they may make to the source code.  Other licenses would prevent this, but they would probably have other problems - it's not easy...

But the BSD license seems to have worked well for FLAC - maybe some other codec authors reading this can give the benefit of their experience?


Thanks,

Dave.

TAK 1.1.0 Development

Reply #48 –
Quote from: davechapman on
As I'm sure you've seen from www.opensource.org, there are many open source licenses, and the choice really depends on what you want to allow other people to do with your work.  The BSD license means that people can take your code and incorporate it into proprietary (closed-source) software, without any requirements for them to share any improvements they may make to the source code.  Other licenses would prevent this, but they would probably have other problems - it's not easy...

Thanks for the comment.

BTW: You have mail...

  Thomas

TAK 1.1.0 Development

Reply #49 –
You could license the encoder under the LGPL, and the decoder under a BSD license.

This way, hardware manufacturers can use the decoding part without worries (BSD).

Licensing the encoder under LGPL, allows them to include it in closed source apps, but have to return any changes to the encoder itself.