IPB

Welcome Guest ( Log In | Register )

2 Pages V   1 2 >  
Reply to this topicStart new topic
TAK 1.1.0
TBeck
post Jan 5 2009, 05:28
Post #1


TAK Developer


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



Final release of TAK 1.1.0 ((T)om's lossless (A)udio (K)ompressor)

This version brings support for 192 Khz Audio, seeking without seek table and some tiny speed improvements.

It consists of:

- TAK Applications 1.1.0.
- TAK Winamp plugin 1.1.0.
- TAK SDK 1.1.0.
- TAK Decoding library 1.1.0.

Download

Download the archive in the upload section: TAK 1.1.0 Final

What's new

New Features:

- Support for 192 Khz Audio.
- Seeking without seek table.

Improvements:

- Encoding and decoding speed improvements of about 3 percent for presets p0 and p1 on my system. Also some decoding speedup for p2.
- 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.

Modifications:

-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.
- Removed option to modify the Prefilter sensitivity.

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.

More information

You may find some useful information in the beta thread.

Plans for V1.1.1

I will soon open a thread for the TAK 1.1.1 development.

Have fun...

Thomas

This post has been edited by TBeck: Jan 6 2009, 14:53
Go to the top of the page
+Quote Post
twistedddx
post Jan 5 2009, 10:06
Post #2





Group: Members
Posts: 37
Joined: 27-October 05
Member No.: 25383



SDK works fine for me smile.gif
Go to the top of the page
+Quote Post
gottkaiser
post Jan 5 2009, 18:41
Post #3





Group: Members
Posts: 171
Joined: 7-January 05
From: Germany
Member No.: 18891



Great work Thomas.
Thanks!
QUOTE (TBeck @ Jan 5 2009, 06:28) *
New Features:

- Support for 192 Khz Audio.
- Seeking without seek table.

Is there any speed penalty in seeking, if I'll won't use a seek table?

greetings
Go to the top of the page
+Quote Post
Destroid
post Jan 5 2009, 21:36
Post #4





Group: Members
Posts: 544
Joined: 4-June 02
Member No.: 2220



Using -sts0 (seek table size = zero) has no noticeable delay whenever I randomly seek within a file.

Using P3 733 with FB2k.

edit: "noticeable delay" meaning comparatively to other audio formats, all seeking on system has small lag

This post has been edited by Destroid: Jan 5 2009, 21:49


--------------------
"Something bothering you, Mister Spock?"
Go to the top of the page
+Quote Post
TBeck
post Jan 6 2009, 15:21
Post #5


TAK Developer


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



QUOTE (twistedddx @ Jan 5 2009, 10:06) *
SDK works fine for me smile.gif

Nice to hear that someone is using it. smile.gif

QUOTE (gottkaiser @ Jan 5 2009, 18:41) *
...
Is there any speed penalty in seeking, if I'll won't use a seek table?

QUOTE (Destroid @ Jan 5 2009, 21:36) *
Using -sts0 (seek table size = zero) has no noticeable delay whenever I randomly seek within a file.

Using P3 733 with FB2k.

edit: "noticeable delay" meaning comparatively to other audio formats, all seeking on system has small lag

And so shall it be...

Seeking without seek table requires some more seek and read operations from the storage device and some very fast check sum caclculations which have to be performed by the CPU. The latter is very unlikely to have a significant effect even on quite slow cpus.

The additional io-requests can be noticeable if your storage device is very slow, for instance a cd-rom drive with slow random seek and/or untypically low data transfer rates. Possibly a very slow usb-stick could also cause a noticeable delay.

Hard disk based playback should be equally fast with and without see table.

The decoder wil also build an internal seek table while you are playing the file. Seeks to audio parts that alreday have been played can use this table.

The worst case with the highest seek times is defined as follows:

- The storage medium is slow.
- The file isn't in the os file cache.
- You start the playback and immediately jump to a position in the second half or close to the end of the file.

Thomas

This post has been edited by TBeck: Jan 6 2009, 15:26
Go to the top of the page
+Quote Post
jido
post Jan 8 2009, 22:11
Post #6





Group: Members
Posts: 246
Joined: 10-February 04
From: London
Member No.: 11923



Congratulations for this release!

Any words of a decoder for non-Windows platforms?
Go to the top of the page
+Quote Post
gottkaiser
post Jan 9 2009, 21:41
Post #7





Group: Members
Posts: 171
Joined: 7-January 05
From: Germany
Member No.: 18891



@Thomas
It is already possible to add cover art to the APE tags in the TAK files with Mp3tag. Would it be a big effort to add support to read them with the winamp plugin?
then here wouldn't be any disadvantage over the other formats in Winamp.

greetings

This post has been edited by gottkaiser: Jan 9 2009, 21:42
Go to the top of the page
+Quote Post
hamasaki
post Jan 10 2009, 16:14
Post #8





Group: Members
Posts: 1
Joined: 21-February 08
Member No.: 51472



wow.really nice update.30% of my music CDz are backed up in tak format.
so,how could I get my foobar component update for those new feature? smile.gif
Go to the top of the page
+Quote Post
lvqcl
post Jan 10 2009, 17:17
Post #9





Group: Developer
Posts: 3219
Joined: 2-December 07
Member No.: 49183



QUOTE (hamasaki @ Jan 10 2009, 18:14) *
wow.really nice update.30% of my music CDz are backed up in tak format.
so,how could I get my foobar component update for those new feature? smile.gif

Current plugin should work. Just update tak_deco_lib.dll in foobar2000 folder.
Go to the top of the page
+Quote Post
Neasden
post Jan 11 2009, 00:31
Post #10





Group: Banned
Posts: 185
Joined: 1-July 08
Member No.: 55148



Silly question...

Can TAK re-encode itself off previous TAK version?
Something like takc.exe -e file.tak
Go to the top of the page
+Quote Post
fillip
post Jan 13 2009, 12:47
Post #11





Group: Members
Posts: 19
Joined: 17-August 07
Member No.: 46287



I just transcoded 3.84GB (774kbps TAK 1.0.3/1.0.4 -pMax) to 3.84GB (774kbps TAK 1.1.0 -pMax) and saved 1047KB! This sentence may seem sarcastic, but the fact given, that it's actually a weaker setting it's quite impressive, isn't it? I have to try to keep track of the other transcodings, still more than 400GB to go
Go to the top of the page
+Quote Post
Synthetic Soul
post Jan 13 2009, 14:50
Post #12





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



QUOTE (Neasden @ Jan 10 2009, 23:31) *
Silly question...

Can TAK re-encode itself off previous TAK version?
Something like takc.exe -e file.tak
I think it's a good question, but it is easy to test, and therefore a lazy question.

I get "Command line error: invalid file extension" when trying to encode a .tak file.

I think this would be a welcome addition. As takc.exe can decode as well as encode I presume it would not be a mammoth task to include.


--------------------
I'm on a horse.
Go to the top of the page
+Quote Post
Neasden
post Jan 13 2009, 15:32
Post #13





Group: Banned
Posts: 185
Joined: 1-July 08
Member No.: 55148



QUOTE
I think it's a good question, but it is easy to test, and therefore a lazy question.


You got it right! Call that lazy... ohmy.gif
Go to the top of the page
+Quote Post
Antonski
post Jan 13 2009, 18:04
Post #14





Group: Members
Posts: 202
Joined: 8-October 01
From: Sofia, Bulgaria
Member No.: 250



QUOTE (Synthetic Soul @ Jan 13 2009, 15:50) *
I think this would be a welcome addition. As takc.exe can decode as well as encode I presume it would not be a mammoth task to include.


Isn't it possible to pipe the takc output to another instance of takc? It should be possible to run multiple instances?
~
Go to the top of the page
+Quote Post
Synthetic Soul
post Jan 13 2009, 20:22
Post #15





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



True. Once takc.exe supports writing tags though it would be nice if tag data was just copied across. If you decode one file and pipe it to takc.exe all tags will be lost.

Of course, you could use Case's Tag to copy the tags from one to the other.


--------------------
I'm on a horse.
Go to the top of the page
+Quote Post
TBeck
post Jan 13 2009, 20:31
Post #16


TAK Developer


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



QUOTE (jido @ Jan 8 2009, 22:11) *
Any words of a decoder for non-Windows platforms?

For now only the hint, that TAK is known to work with wine...

QUOTE (gottkaiser @ Jan 9 2009, 21:41) *
It is already possible to add cover art to the APE tags in the TAK files with Mp3tag. Would it be a big effort to add support to read them with the winamp plugin?

I think i would have to to use the new winamp plugin interface to provide access to binary data, but i am not really sure. If so, it would be a considerable amount of work. But at some point i will do it. BTW: A developer could use my decoder library to write a winamp plugin.

QUOTE (fillip @ Jan 13 2009, 12:47) *
I just transcoded 3.84GB (774kbps TAK 1.0.3/1.0.4 -pMax) to 3.84GB (774kbps TAK 1.1.0 -pMax) and saved 1047KB! This sentence may seem sarcastic, but the fact given, that it's actually a weaker setting it's quite impressive, isn't it? I have to try to keep track of the other transcodings, still more than 400GB to go

That's nice!

QUOTE (Synthetic Soul @ Jan 13 2009, 14:50) *
QUOTE (Neasden @ Jan 10 2009, 23:31) *
Silly question...

Can TAK re-encode itself off previous TAK version?
Something like takc.exe -e file.tak
I think it's a good question, but it is easy to test, and therefore a lazy question.

I get "Command line error: invalid file extension" when trying to encode a .tak file.

I think this would be a welcome addition. As takc.exe can decode as well as encode I presume it would not be a mammoth task to include.

QUOTE (Antonski @ Jan 13 2009, 18:04) *
QUOTE (Synthetic Soul @ Jan 13 2009, 15:50) *

I think this would be a welcome addition. As takc.exe can decode as well as encode I presume it would not be a mammoth task to include.


Isn't it possible to pipe the takc output to another instance of takc? It should be possible to run multiple instances?
~

I am not really sure if an internal transcoding mode in TAK would be advantegous. It won't be faster than the foobar approach.

Please tell me, why i should add a transcoding mode. Is it because of the tags? Wouldn't foobar copy them?

To be honest, i myself am not performing a lot of audio processing, therefore i don't know much about those issues...

Thomas
Go to the top of the page
+Quote Post
Synthetic Soul
post Jan 13 2009, 22:08
Post #17





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



Foobar could do the job.

For my part, I thought that having this ability inbuilt to the TAK encoder would mean that command line users could easily upgrade their TAK collection to the latest version, as and when major versions bring major benefits. It's almost like TAK taking care of its own. FLAC 1.1.3 introduced this feature, and it just seemed to make sense to me: that an encoder can understand its own format, and save time for existing users to move their files from an older version to the latest, possibly helping resolve backward-compatibility issues with major releases.

Not a major issue for me though, by any means.


--------------------
I'm on a horse.
Go to the top of the page
+Quote Post
Neasden
post Jan 13 2009, 22:12
Post #18





Group: Banned
Posts: 185
Joined: 1-July 08
Member No.: 55148



Sythetic Soul said everything... I really like this ability to upgrade a huge collection with one command line through a script... It becomes painful if you need to convert to WAV before, and lose the tags.
Go to the top of the page
+Quote Post
Neasden
post Jan 16 2009, 00:12
Post #19





Group: Banned
Posts: 185
Joined: 1-July 08
Member No.: 55148



QUOTE (gottkaiser @ Jan 9 2009, 18:41) *
It is already possible to add cover art to the APE tags in the TAK files with Mp3tag. Would it be a big effort to add support to read them with the winamp plugin?
then here wouldn't be any disadvantage over the other formats in Winamp.

greetings


If you don't mind switching, foobar2000 already displays TAK+APEv2+Cover

To let you know... I am dropping FLAC today, doing a mass conversion of files to new TAK!
Let the future come...

Some of TAK highlights at the moment for me:
- FB2k transcoding TAK/2 to TAK/2 is dead fast on my machine, and that not using pipe encoding.
- Adding album art does not re-write the entire TAK file because I assume it places the metadata at the end of the file. With FLAC, if there's not enough padding, the entire file gets re-written on disc (spending up to 3 seconds to get written on a SATAII/7.200rpm disc and probably more time on slower hard drives.) Removing art also cleanses the space occupied, whereas FLAC file will remain the same size because padding space won't go away automatically.

I tested that when FB2k transcodes TAK to TAK, it will transfer tags but won't transfer embedded cover art and replaygain values.
Is there any way to keep all metadata by using FB2k???

This post has been edited by Neasden: Jan 16 2009, 02:02
Go to the top of the page
+Quote Post
Dologan
post Jan 16 2009, 00:52
Post #20





Group: Members (Donating)
Posts: 478
Joined: 22-November 01
From: United Kingdom
Member No.: 519



Wow, great news! Thanks a lot, Thomas! emot-toot.gif
Go to the top of the page
+Quote Post
DOS386
post Jan 16 2009, 15:21
Post #21





Group: Members
Posts: 64
Joined: 16-June 07
Member No.: 44412



QUOTE
Final release of TAK 1.1.0 ((T)om's lossless (A)udio (K)ompressor)


smile.gif Very good, faster and better compression (minimal test so far)

Sadly there are files giving much worse compression with -pmax than default ... problem exists in 1.0.4 already:

CODE
01/15/2009  03:21  31,705,004 p.wav

>t -e p.wav
p.wav                               ..........  20.85%   21*

Compression:     20.85 %
Duration:         8.72 sec
Speed:           20.61 * real time

>t -e -pmax p.wav
p.wav                               ..........  22.73%    4*

Compression:     22.73 %
Duration:        42.64 sec
Speed:            4.22 * real time

>t -d p.tak
p.tak                               ..........   51* Ok

Duration:        3.52 sec
Speed:          51.03 * real time

01/15/2009  03:23  6,609,076 pdef.tak
01/15/2009  03:24  7,207,262 p.tak

>t4 -e p.wav  
p.wav                               ..........  20.85%   30*

Compression:     20.85 %
Duration:         5.92 sec
Speed:           30.36 * real time

>t4 -e -pmax p.wav
p.wav                               ..........  22.74%    3*

Compression:     22.74 %
Duration:        68.05 sec
Speed:            2.64 * real time

>t4 -d p.tak
p.tak                               ..........   29* Ok

Duration:        6.11 sec
Speed:          29.44 * real time

01/15/2009  03:24   6,610,883 pdef.tak
01/15/2009  03:25   7,209,408 p.tak


T is 1.0.10 and T4 is 1.0.4
pdef.tak is default and p.tak is -pmax


A few minor things:

- is expired
- Screenshots are bloated, could be 3 times smaller (this is about very best compression, isn't ?)
- Package is bloated, could be 2 times smaller (still, one package onlyis good, add decoder source one day also? wink.gif )

This post has been edited by DOS386: Jan 16 2009, 15:44


--------------------
/\/\/\/\/\/\
Go to the top of the page
+Quote Post
gottkaiser
post Jan 16 2009, 18:53
Post #22





Group: Members
Posts: 171
Joined: 7-January 05
From: Germany
Member No.: 18891



QUOTE (Neasden @ Jan 16 2009, 00:12) *
I tested that when FB2k transcodes TAK to TAK, it will transfer tags but won't transfer embedded cover art and replaygain values.
Is there any way to keep all metadata by using FB2k???

Thats what I was asking in the foobar2000 forum. right here.
But no developer replied. :-/

greatings
Go to the top of the page
+Quote Post
TBeck
post Jan 17 2009, 00:26
Post #23


TAK Developer


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



QUOTE (DOS386 @ Jan 16 2009, 15:21) *
Sadly there are files giving much worse compression with -pmax than default ... problem exists in 1.0.4 already:

Good timing! I am just working on a new encoder option in TAK 1.1.1 to minimize such (usually rare) problems...

Could you please send me 2 to 3 second snippets (which show the misbehaviour) of one or more of your problem files? I would be happy to use them to test the new method!

Thomas
Go to the top of the page
+Quote Post
DOS386
post Jan 17 2009, 12:23
Post #24





Group: Members
Posts: 64
Joined: 16-June 07
Member No.: 44412



> new encoder option in TAK 1.1.1 to minimize such (usually rare) problems...

IMHO SEVERE problem ... the "very best" compression is much worse sad.gif

> Could you please send

Done !


--------------------
/\/\/\/\/\/\
Go to the top of the page
+Quote Post
Synthetic Soul
post Jan 17 2009, 20:00
Post #25





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



Surely a "severe problem" would be near-zero percent compression, lossy encoding, or a complete lack of error tolerance?

A few more MiB in your collection... "severe"? I suppose it depends on how rare "rare" is.

Edit: FYI I Just checked my comparison and none of the fifty files suffer from this. Obviously this doesn't prove a whole lot, but it does indicate to me that the issue is not normal.

QUOTE
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.
Thomas, is this issue related to the above, or is it something totally unrelated? Apologies if this has been done a thousand times before.

This post has been edited by Synthetic Soul: Jan 17 2009, 20:18


--------------------
I'm on a horse.
Go to the top of the page
+Quote Post

2 Pages V   1 2 >
Reply to this 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: 24th April 2014 - 01:54