IPB

Welcome Guest ( Log In | Register )

2 Pages V   1 2 >  
Closed TopicStart new topic
TAK 1.1.1 - Beta release
TBeck
post Feb 16 2009, 01:37
Post #1


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



Beta release of TAK 1.1.1 ((T)om's lossless (A)udio (K)ompressor)

It consists of:

- TAK Applications 1.1.1 Beta
- Winamp plugin 1.1.1 Beta
- Decoding library 1.1.1 Beta
- TAK Software Development Kit 1.1.1 Beta

The final release of the SDK will additionally contain some source code for the TAK container.

Download:

Attached File  TAK_1.1.1_Beta.zip ( 842.94K ) Number of downloads: 3205

After the beta test phase this archive will be removed.

What's new

New Features:

- In very rare cases the presets -p3 and -p4 could compress much worse than the lower presets. A new filter in the encoder will nearly eliminate this annoying effect. It can also increase the average compression by a tiny (<= 0.05 percent) amount. Because of the filter, encoding with -p3 and -p4 will be a bit slower.
- Creation and verification of MD5 checksums of the raw audio data. The file info command can show you the MD5.
- Option to lower the process priority. Nice for background processing.

Improvements:

- Up to 9 KB smaller binaries. Although i have removed a lot of the assembler optimizations, the speed is still very close to the previous version.
- Further clean up of the Code.

Modifications:

- Support for seek tables removed. The new version will neither add seek tables to newly encoded files nor use seek tables contained in files created with older program versions. Important: Seeking in files without seek table is only supported since V1.1.0. Please update the WinAmp plugin and/or the decoding library for full seeking support in media players.
- There is a new metadata object which contains position and size of the last frame in the stream. This info is useful for seeking and tag detection.

Known issues:

- If you use pipe decoding and the application reading the pipe is beeing terminated before the whole file has been read, TAKC may get into an endless loop and has to be manually killed with the task manager. I don't think this is a big issue but i will try to fix it in one of the next versions. BTW: Big thanks to shnutils for testing the pipe decoding!
- There seem to be some compatibility issues with pipe decoding to some other applications ("crc1632.exe" has been reported). I will try to fix it in the next release.

Beta testing

The beta version has already gone through extensive testing performed by my automatic scripts. But especially because of the many changes for 1.1.1 rare bugs are still possible (as always...). Please try the beta release and report any bugs in this thread.

I would also be happy about tests of compression efficiency and speed. Because the final release will have identical performance (there may be a speed variation of 1 to 2 percent because of different code alignment of another build), it does make sense to test the beta.

Thanks for testing and have fun

Thomas

Go to the top of the page
+Quote Post
ssjkakaroto
post Feb 16 2009, 01:48
Post #2





Group: Members
Posts: 203
Joined: 22-May 02
Member No.: 2096



Thanks Thomas!


--------------------
Allegari nihil et allegatum non probare, paria sunt.
Go to the top of the page
+Quote Post
Reinforce Genera...
post Feb 16 2009, 05:30
Post #3





Group: Members
Posts: 8
Joined: 14-December 07
Member No.: 49541



Thanks for your hardly work! laugh.gif
Could you change the low priority process function into that I could specific what level I want in the next version?
I find a little question in the 1.1.1beta version, the encoded file by 1.1.1beta version is be identified as 1.1.0 in foobar2000.I use foobar2000 0.9.6.3 beta1 and foo_input_tak.dll 0.4.2, maybe foo_input_tak.dll need to rebuild for this new version?

This post has been edited by Reinforce Generation: Feb 16 2009, 05:34
Go to the top of the page
+Quote Post
TBeck
post Feb 16 2009, 10:30
Post #4


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



QUOTE (Reinforce Generation @ Feb 16 2009, 05:30) *
Could you change the low priority process function into that I could specific what level I want in the next version?

I don't really like to. It would require more explainations in the documentation and i like to keep it as simple as possible. Furthermore the meaning of the levels is likely to be different between different operating systems.

But if you don't feel comfortable with my level-choice (it's IDLE_PRIORITY_CLASS), feel free to tell me.

QUOTE (Reinforce Generation @ Feb 16 2009, 05:30) *
I find a little question in the 1.1.1beta version, the encoded file by 1.1.1beta version is be identified as 1.1.0 in foobar2000.I use foobar2000 0.9.6.3 beta1 and foo_input_tak.dll 0.4.2, maybe foo_input_tak.dll need to rebuild for this new version?

Sorry, my fault. I hadn't changed the codec version constant in the applications. Thanks for the report!

I don't think it's neccessary to release a fixed beta now?

Thomas

This post has been edited by TBeck: Feb 16 2009, 10:32
Go to the top of the page
+Quote Post
wortels
post Feb 16 2009, 12:58
Post #5





Group: Banned
Posts: 170
Joined: 8-July 04
Member No.: 15154



TBeck I am really impressed with TAK but I am reluctant to use it because of it being closed source. I read some time ago that you were planning to license the source under a permissive license once the code was cleaned. Is there any progress regarding that?
Go to the top of the page
+Quote Post
sauvage78
post Feb 16 2009, 13:14
Post #6





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



aliumalik +1

I still follow tak development, but I will use flac as long as tak is closed.
For pure compression/storage, I prefer to buy a new HDD than using a closed codec.
I only wish I could enjoy tak's speed/compression improvement over flac.

Try again.


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
ssjkakaroto
post Feb 16 2009, 13:23
Post #7





Group: Members
Posts: 203
Joined: 22-May 02
Member No.: 2096



Sigh... sleep.gif
Every time there's a new TAK topic, someone has to bring this up...
Thomas will release the source when he thinks it's the right time, this was discussed in EVERY single TAK topic.
This is getting a little old don't you think?


--------------------
Allegari nihil et allegatum non probare, paria sunt.
Go to the top of the page
+Quote Post
sauvage78
post Feb 16 2009, 13:40
Post #8





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



... and everytime there is a new release it is not the right time ... sorry I have been following tak since the time it was called yalac so I have been waiting a long time ... I have been more than patient ... I recall a time when monkey audio developper was telling that he would maybe release the code ... specially as third party software developpers were asking him to do so ... it never happened ... (the source is available but the license is ... weird)

always telling: "later" is a clue that tak doesn't share the way of thinking of free software ... who care if it's bugged as long as it is instantly fixed ... free software developpers release opensourced code specially to find bugs ... the more eyes see the code, the less buggy is the code ...

years ago Tom had an excuse ... he was not releasing the code because he wanted to write a research/scientific article about his new technology & be the first to publish...
at time this was a very valid excuse to me ...

I never saw the article, I never saw the code ...

I am not crying for the code, I am only pointing the lack of honesty ... if Tak is closed source software, so be it, but plz tell it openly ... so that I don't long for more & that I can pass my way when I see a new Tak release.

This post has been edited by sauvage78: Feb 16 2009, 14:01


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
ssjkakaroto
post Feb 16 2009, 13:53
Post #9





Group: Members
Posts: 203
Joined: 22-May 02
Member No.: 2096



Besides porting to other platforms, I doubt there will be much more improvements aside from Thomas himself. You can see that the main development of both WavPack and FLAC are still from the original authors.
OSS is good, but it's not like there's a ton of people that have the knowledge/interest in audio encoding just waiting to get their hands on a new code.


--------------------
Allegari nihil et allegatum non probare, paria sunt.
Go to the top of the page
+Quote Post
zombiewerewolf
post Feb 16 2009, 14:00
Post #10





Group: Members
Posts: 119
Joined: 27-January 03
From: Perth, AU
Member No.: 4755



Thank you for adding Low Priority option, TBack smile.gif
Now, I'm waiting patiently for 1.1.1 to be finalized, and then I'm going to migrate to TAK.
Go to the top of the page
+Quote Post
GHammer
post Feb 16 2009, 19:07
Post #11





Group: Members
Posts: 224
Joined: 11-May 03
From: China
Member No.: 6546



QUOTE (aliumalik @ Feb 16 2009, 06:58) *
TBeck I am really impressed with TAK but I am reluctant to use it because of it being closed source. I read some time ago that you were planning to license the source under a permissive license once the code was cleaned. Is there any progress regarding that?


Educate me. Why are you reluctant to use TAK in its current form/release?
Are there people waiting in the wings wanting to improve it? Should I worry about some backdoor/malware? Some other reason?

Just curious, because personally, I can't read code well enough for it to matter to me.
Go to the top of the page
+Quote Post
Brent
post Feb 16 2009, 19:59
Post #12





Group: Members
Posts: 156
Joined: 27-August 07
Member No.: 46544



Code being free generally ensures longevity, because although you (and me) don't write code, almost certainly someone who can, can pick it up, keep it up to date, port it to other, newer systems, etc. In 20 years from now it's quite possible Thomas will have lost interest and we no longer use Windows on x86 machines. If the source is open, anyone who can code and has an interest can port it to whatever system he choses so that you can keep decoding your music (and encoding).
Go to the top of the page
+Quote Post
alvaro84
post Feb 16 2009, 20:27
Post #13





Group: Members
Posts: 128
Joined: 9-August 06
Member No.: 33830



QUOTE (Brent @ Feb 16 2009, 19:59) *
Code being free generally ensures longevity, because although you (and me) don't write code, almost certainly someone who can, can pick it up, keep it up to date, port it to other, newer systems, etc. In 20 years from now it's quite possible Thomas will have lost interest and we no longer use Windows on x86 machines. If the source is open, anyone who can code and has an interest can port it to whatever system he choses so that you can keep decoding your music (and encoding).


Indeed, it's very useful to have the source in the collective subconscious, and I'd be a bit happier to if it was open (and I hope that it will be in the not too far future). But fortunately TAK is a lossless codec, so its demise and the need to convert music encoded with it won't cause data loss like it would in case of a lossy one smile.gif So it's pretty safe, even if it's closed at the moment.
So I'm waiting patiently.
Go to the top of the page
+Quote Post
TBeck
post Feb 16 2009, 20:30
Post #14


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



QUOTE (aliumalik @ Feb 16 2009, 12:58) *
TBeck I am really impressed with TAK but I am reluctant to use it because of it being closed source. I read some time ago that you were planning to license the source under a permissive license once the code was cleaned. Is there any progress regarding that?

QUOTE (sauvage78 @ Feb 16 2009, 13:14) *
aliumalik +1

I still follow tak development, but I will use flac as long as tak is closed.
For pure compression/storage, I prefer to buy a new HDD than using a closed codec.
I only wish I could enjoy tak's speed/compression improvement over flac.

QUOTE (ssjkakaroto @ Feb 16 2009, 13:23) *
Sigh... sleep.gif
Every time there's a new TAK topic, someone has to bring this up...
Thomas will release the source when he thinks it's the right time, this was discussed in EVERY single TAK topic.
This is getting a little old don't you think?

Thank you for supporting me. But i think, it's totally ok to ask those questions, if someone is really interested into using TAK. It's different, if they are only beeing asked for some general ideological reasons.

While i don't want to criticize personal subjective preferences (it's a matter of taste i am also affected by in different fields...), there have been some statements i have to comment:
QUOTE (sauvage78 @ Feb 16 2009, 13:40) *
... and everytime there is a new release it is not the right time ... sorry I have been following tak since the time it was called yalac so I have been waiting a long time ... I have been more than patient ... I recall a time when monkey audio developper was telling that he would maybe release the code ... specially as third party software developpers were asking him to do so ... it never happened ... (the source is available but the license is ... weird)

Despite beeing a bit harsh, this is useful for me. I think you are right, that it's time for me to make a definite statement about an open source release of TAK. I will do this in a separate post within the next days.

QUOTE (sauvage78 @ Feb 16 2009, 13:40) *
always telling: "later" is a clue that tak doesn't share the way of thinking of free software ... who care if it's bugged as long as it is instantly fixed ... free software developpers release opensourced code specially to find bugs ... the more eyes see the code, the less buggy is the code ...

I don't think there have been many bugs in TAK releases. There can be minor issues with the beta releases, but please take into account, that i don't have any testers outside of hydrogen. At the time i release a beta, nobody else has tried the new version.

I am sure even the most prominent open source projects are obtaining bug reports following a beta release.

I can't empirically deceide, if open source projects are suffering from less bugs than commercial projects (for instance Internet Explorer vs. Firefox). I have the feeling, it's true for some of them. But i think, there are of other important reasons to be taken into account:

- Because open source developers are working on the things they like, they will be far more motivated and feel much more responsible (identification) for the results of their work.
- Open source releases are not subjected to the same time constraints as many commercial projects, where the software often has to be released at any price.

And the same is usually true for the developers of Freeware...

QUOTE (sauvage78 @ Feb 16 2009, 13:40) *
years ago Tom had an excuse ... he was not releasing the code because he wanted to write a research/scientific article about his new technology & be the first to publish...
at time this was a very valid excuse to me ...

I never saw the article, I never saw the code ...

I am not crying for the code, I am only pointing the lack of honesty ... if Tak is closed source software, so be it, but plz tell it openly ... so that I don't long for more & that I can pass my way when I see a new Tak release.

I already said, that i see the need for a general statement about an open source release of TAK. Therefore i understand your demand for a definite answer. Where i can't follow you is the harshness... Did i do you any harm because i haven't released the source code yet? Did it affect your live in an important way?

There simply is something you would like to have, but not in it's current form. I think, that's live...

QUOTE (GHammer @ Feb 16 2009, 19:07) *
Educate me. Why are you reluctant to use TAK in its current form/release?
Are there people waiting in the wings wanting to improve it? Should I worry about some backdoor/malware? Some other reason?

Thank you. Just one thing to add: My internet page about TAK is part of my presentation as self-employeed software developer. What do you think would happen, if i published malware???

Thomas
Go to the top of the page
+Quote Post
wortels
post Feb 17 2009, 03:35
Post #15





Group: Banned
Posts: 170
Joined: 8-July 04
Member No.: 15154



QUOTE (GHammer @ Feb 16 2009, 23:07) *
QUOTE (aliumalik @ Feb 16 2009, 06:58) *
TBeck I am really impressed with TAK but I am reluctant to use it because of it being closed source. I read some time ago that you were planning to license the source under a permissive license once the code was cleaned. Is there any progress regarding that?


Educate me. Why are you reluctant to use TAK in its current form/release?
Are there people waiting in the wings wanting to improve it? Should I worry about some backdoor/malware? Some other reason?

Just curious, because personally, I can't read code well enough for it to matter to me.

I think people have given most of the reasons why I want it to be OSS. For me personally
1) Cross platform usability. I use both linux and windows and most of my music is stored externally so I need for it to be playable on both platforms. Most linux players cant/won't include support for for such formats because a) they have a conflicting license or b) they are shipped as a binary blob which causes other problems. In such a scenario you have to resort to reverse engineered decoders which might not be legal and considering that the TAK community is so small someone might not even care to reverse engineer it.
2) Future development. In the (improbable) scenario that TBeck stops development on TAK someone will be able to provide at least playback support on new platforms. I know that not many developers would get involved in the development process but at least someone would be able to provide playback support/small fixes etc in the future IF development on TAK is stopped.
3) Market adoption. I know this is a far fetched idea but if TAK is kept closed source it might not even see the small hardware adoption FLAC has right now. I would like to at least have a possibility of it getting implemented in some hardware.

There are other small details which make users like me reluctant. Don't get me wrong TAK is a great codec and the reason so many people are nagging regarding this issue is because they want to use it without any apprehensions. Most of the people here continually shift between file formats and it might not seem a big deal to them but for the "encode and forget" user base such little things can be problematic. In the end while TAK compresses better than FLAC and it is indeed an excellent product it does not offer the peace of mind FLAC does.

PS: If TBeck decides to license it under an OSS license I would suggest dual licensing under GPL/LGPL. Thanks for all your work and contribution to the lossless community TBeck whichever way you decide to go.

This post has been edited by aliumalik: Feb 17 2009, 03:38
Go to the top of the page
+Quote Post
TBeck
post Feb 18 2009, 07:50
Post #16


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



QUOTE (zombiewerewolf @ Feb 16 2009, 14:00) *
Thank you for adding Low Priority option, TBack smile.gif
Now, I'm waiting patiently for 1.1.1 to be finalized, and then I'm going to migrate to TAK.

Could you please try, if the low priority setting fits your needs?

QUOTE (aliumalik @ Feb 17 2009, 03:35) *
I think people have given most of the reasons why I want it to be OSS. For me personally
...

Thank you, that's very clear and thoughtful. rolleyes.gif

And there is no contradiction from me.

But i have to take some other factors into account, when thinking about an open source release. I will post about it as soon as i find some time to write it down.

Thomas
Go to the top of the page
+Quote Post
zombiewerewolf
post Feb 18 2009, 09:00
Post #17





Group: Members
Posts: 119
Joined: 27-January 03
From: Perth, AU
Member No.: 4755



QUOTE (TBeck @ Feb 18 2009, 13:50) *
Could you please try, if the low priority setting fits your needs?

I already tried this beta, and it's exactly what I need smile.gif Thank you again.

By the way, I wonder whether TAK will report if there's decoding errors, like, decoded files are not the same as original files (MD5 mismatch)?
For instance WAVPACK, it will show decoded file's MD5 and original file's MD5 when decode. FLAC will tell if there's MD5 mismatch and will not decode those files. Since I've never have corrupted TAK files before I wouldn't know how TAK will report in such situation.

And.. how about files that I encoded before MD5 option was implemented (TAK 1.0.4 and earlier)... if in the future, my files become corrupted, can TAK tell me whether those files are corrupted or should I re-encode using newer versions?
Go to the top of the page
+Quote Post
greynol
post Feb 18 2009, 09:16
Post #18





Group: Super Moderator
Posts: 10339
Joined: 1-April 04
From: San Francisco
Member No.: 13167



TAK already stores a 24-bit checksum for each and every frame, so this should not serve as a reason to re-encode.


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
zombiewerewolf
post Feb 18 2009, 09:24
Post #19





Group: Members
Posts: 119
Joined: 27-January 03
From: Perth, AU
Member No.: 4755



QUOTE (greynol @ Feb 18 2009, 16:16) *
TAK already stores a 24-bit checksum for each and every frame, so this should not serve as a reason to re-encode.

Thanks, I just need a confirmation for peace of mind.
Go to the top of the page
+Quote Post
greynol
post Feb 18 2009, 09:28
Post #20





Group: Super Moderator
Posts: 10339
Joined: 1-April 04
From: San Francisco
Member No.: 13167



I understand. I went through a bit of paranoia over transcoding lossless formats in the past, which is why I remember this.


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
alvaro84
post Feb 19 2009, 16:55
Post #21





Group: Members
Posts: 128
Joined: 9-August 06
Member No.: 33830



At last, I'm back home! I tried your new decoding library with foobar, and its speed seems to be pretty much the same level as 1.1.0, in spite of the removed asm routines. Tested on a Prescott P4 (workplace) and a Conroe Core2 (home). We've got a Brisbane X2 too, but it's just another K8 what you've already tested anyway smile.gif
Go to the top of the page
+Quote Post
bwat47
post Feb 19 2009, 17:31
Post #22





Group: Members
Posts: 37
Joined: 10-February 09
Member No.: 66822



So how does this compare to lossless formats like flac? does it encode smaller files?
Go to the top of the page
+Quote Post
zombiewerewolf
post Feb 19 2009, 17:41
Post #23





Group: Members
Posts: 119
Joined: 27-January 03
From: Perth, AU
Member No.: 4755



QUOTE (bwat47 @ Feb 19 2009, 23:31) *
So how does this compare to lossless formats like flac? does it encode smaller files?

Yes, it does and with even less encoding time than FLAC.
See this comparison page for more details.

This post has been edited by zombiewerewolf: Feb 19 2009, 17:41
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Feb 21 2009, 04:33
Post #24





Group: Developer
Posts: 712
Joined: 2-October 08
From: Ottawa
Member No.: 59035



QUOTE (TBeck @ Feb 16 2009, 03:37) *
If you use pipe decoding and the application reading the pipe is beeing terminated before the whole file has been read, TAKC may get into an endless loop and has to be manually killed with the task manager.

This is actually quite dissapointing. I tried to add TAK support to CUETools using pipe encoding/decoding, but encountered this problem too.
As container format is still a mystery, i have to start the decoder just to find out the basic information about the file, such as sample rate and length.
I abort decoding after reading the wave header, but takc.exe often stays running, and consuming CPU resources.
Would be nice if 1.1.1 didn't have this problem. Also would be nice to know enough about TAK container format at least to be able to determine
basic audio stream properties without starting a decoder. I saw a RIFF header in the files, is it always present? How do i find out where it starts?
One more request, could the decoder be enhanced to work from pipe to pipe, i.e. "takc.exe - -"? This is required to be able to play/transcode TAK
streams directly from a zip archive or network stream without creating (large) temporary files on disc.
Using .dll library is not an option for me, because 1) it only provides decoding, but i also need an encoder. 2) i need an x64 version, but sdk only contains x86.

This post has been edited by Gregory S. Chudov: Feb 21 2009, 05:17


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Feb 21 2009, 04:54
Post #25





Group: Developer
Posts: 712
Joined: 2-October 08
From: Ottawa
Member No.: 59035



By the way, did you ever think about using some existing well-documented and well-implemented container format, like ogg(flac)?
I really don't understand why each and every codec tends to have a new container for it.
Reusing a well-known format would make it a lot easier for developers to support a new codec in their applications.


This post has been edited by Gregory S. Chudov: Feb 21 2009, 05:03


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post

2 Pages V   1 2 >
Closed TopicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 25th December 2014 - 14:57