Content
This thread should be used to discuss the first public beta release of my lossless audio compressor TAK (formerly known as YALAC):
1) Bug reports
That's the most important purpose of this beta testing!
Please try to provide as many details as possible about the conditions which created the error. And please keep the affected files. I may ask you for them.
2) Ideas for improvements and feature requests
I am aware, that the first release is missing many important features, especially tagging and plugin support for media players. No need to tell me about this...
I will collect your ideas and requests and try to implement them into later releases.
The ReadMe of the beta archive contains a list of features i am planning to implement into future versions.
3) Compression results
are always welcome.
Download
The beta can be downloaded from the Upload section:
TAK 1.0 Beta 2
Full Version: TAK 1.0 - Beta testing
First of all... Congratulations on the first public build!
Also, I'd like to be the first to thank you for all the work you've done on your labor of love up to this point Thomas. We all know how much time you've spent on this "little" project of yours in the past years and you can be sure we all appreciate it greatly.
Also, I'd like to be the first to thank you for all the work you've done on your labor of love up to this point Thomas. We all know how much time you've spent on this "little" project of yours in the past years and you can be sure we all appreciate it greatly.
Well said.
Congratulations Thomas. The results posted for TAK from the alpha testing seem to have caused a real buzz on this board. It will be interesting to see what happens in 2007.
Edit: I have updated Tag to recognise TAK files (so you don't have to specify --ape2 --nocheck). Download 2.0.49 if you want to tag using Case's Tag. NB: 2.0.48 was a "silent" release that updated to libFLAC 1.1.3.
You can then easily tag using:
If you want to rip to TAK using EAC I suggest that you use Wapet. Take a look at the EAC and Monkey's Audio guide in the wiki for the general idea.
Remember to swap ".ape" with ".tak", and use a command line like:
Congratulations Thomas. The results posted for TAK from the alpha testing seem to have caused a real buzz on this board. It will be interesting to see what happens in 2007.
Edit: I have updated Tag to recognise TAK files (so you don't have to specify --ape2 --nocheck). Download 2.0.49 if you want to tag using Case's Tag. NB: 2.0.48 was a "silent" release that updated to libFLAC 1.1.3.
You can then easily tag using:
CODE
TAG.EXE --artist "My Artist" --album "My Album" --genre Rock --year 2006 --track 1 --title "My Title" myfile.tak
If you want to rip to TAK using EAC I suggest that you use Wapet. Take a look at the EAC and Monkey's Audio guide in the wiki for the general idea.
Remember to swap ".ape" with ".tak", and use a command line like:
CODE
%d -t "Artist=%a" -t "Title=%t" -t "Album=%g" -t "Year=%y" -t "Track=%n" -t "Genre=%m" "C:\Program Files\TAK\TAKC.EXE" -e -pN -v %s %d
Congratulations! 
I just played around a bit
Not a big thing but i found a file with invalid RIFF-Header that TAK refuses to process
http://www-mmsp.ece.mcgill.ca/Documents/Au...verse/GLASS.WAV
the file is 8000Hz,16-Bit,1 Channel,40200 Samples
edit:
Sadly WAVE_FORMAT_EXTENSIBLE files are not supported, or are they?
Would be nice if you could add that feature
I just played around a bit
Not a big thing but i found a file with invalid RIFF-Header that TAK refuses to process
http://www-mmsp.ece.mcgill.ca/Documents/Au...verse/GLASS.WAV
the file is 8000Hz,16-Bit,1 Channel,40200 Samples
edit:
Sadly WAVE_FORMAT_EXTENSIBLE files are not supported, or are they?
Would be nice if you could add that feature
TAK Decoder Stub for foobar2000
I've made a simple component for foobar2000 that will allow you to use foobar2000 to tag your TAK files. It doesn't support playback for obvious reasons. Perhaps some people will find it useful to manage their TAK files.
Download
Source code
If the above links don't work, please check my components page or this thread.
I've made a simple component for foobar2000 that will allow you to use foobar2000 to tag your TAK files. It doesn't support playback for obvious reasons.
Perhaps some people will find it useful to manage their TAK files.Download
Source code
If the above links don't work, please check my components page or this thread.
Sorry I may seem new to TAK but what's the big fuss all about it? I just ran a test with -e -p4m and the files were still a bit larger than APE -c4000 (extra high) files. The encoding time was about the same.
TAK's advantage is more with encoding and decoding speed than compression. It compresses very well, while still being fast. Monkey's Audio, OptimFROG and LA will compress better, but tend to be slower.
If you compare TAK Normal with Monkey's Audio Normal they compress about the same, and encode at the same rate, but TAK decodes twice as fast. If you compare TAK Normal with FLAC -5 they encode and decode at around the same rate, but TAK shaves off around 2% compression.
If you look at the poll, and the type of codec being used by most people, you have the answer to your question.
If you compare TAK Normal with Monkey's Audio Normal they compress about the same, and encode at the same rate, but TAK decodes twice as fast. If you compare TAK Normal with FLAC -5 they encode and decode at around the same rate, but TAK shaves off around 2% compression.
If you look at the poll, and the type of codec being used by most people, you have the answer to your question.
QUOTE (fairway @ Jan 4 2007, 13:35) 
Sorry I may seem new to TAK but what's the big fuss all about it? I just ran a test with -e -p4m and the files were still a bit larger than APE -c4000 (extra high) files. The encoding time was about the same.
The section About in Tak's Readme.html gives you this answer:
QUOTE
My goal was to develop a compressor which combines strong compression with highest decompression speeds. On average the current implementation should match the compression efficiency of Monkey's Audio High and achieve decompression speeds similar to FLAC.
There are several threads about the development of this new codec in the Lossless / Other Codecs forum. Just run a search for YALAC or TAK.
You'll also find lots of benchmark results and comparisons to other codecs there.
My testing results:
02.01.2007 19:51 107.467.628 original.wav
02.01.2007 19:51 64.151.240 flac8.flac
04.01.2007 14:05 60.495.029 p2m.tak
04.01.2007 14:06 59.833.424 p3m.tak
04.01.2007 14:04 59.743.460 p4m.tak
Decoding time for p4m.tak: 8.67 sec
Monkey's Audio Extra High:
04.01.2007 14:11 58.977.820 extrahigh.ape
Decoding time for extrahigh.ape: 44.6 sec
02.01.2007 19:51 107.467.628 original.wav
02.01.2007 19:51 64.151.240 flac8.flac
04.01.2007 14:05 60.495.029 p2m.tak
04.01.2007 14:06 59.833.424 p3m.tak
04.01.2007 14:04 59.743.460 p4m.tak
Decoding time for p4m.tak: 8.67 sec
Monkey's Audio Extra High:
04.01.2007 14:11 58.977.820 extrahigh.ape
Decoding time for extrahigh.ape: 44.6 sec
QUOTE (fairway @ Jan 4 2007, 13:14)
Decoding time for p4m.tak: 8.67 sec
...
Decoding time for extrahigh.ape: 44.6 sec
I assume that you've just answered your own question? ...
Decoding time for extrahigh.ape: 44.6 sec
QUOTE (smack @ Jan 4 2007, 13:09)
There are several threads about the development of this new codec in the Lossless / Other Codecs forum. Just run a search for YALAC or TAK.
You'll also find lots of benchmark results and comparisons to other codecs there.
Here is my comparison, which includes TAK alpha 0.14, FLAC 1.1.3, WavPack 4.40, and Monkey's Audio 3.99.
You'll also find lots of benchmark results and comparisons to other codecs there.
Congratulations! I was watching the development and finaly I can test it my self. It is realy fast! I can't wait for an final version lauched in an GPL-compatible license, for I play in my linux also.
Not exaclty a bug report, but the "Tak_Enco_Proto.txt" have the "yes" and "no" as "nein" and "ja". I think it is better translate it to english. Maybe leave the possibility of multilanguage versions... but that shoud be much more complex.
Not exaclty a bug report, but the "Tak_Enco_Proto.txt" have the "yes" and "no" as "nein" and "ja". I think it is better translate it to english. Maybe leave the possibility of multilanguage versions... but that shoud be much more complex.
Seeing as everyone else is doing speed/compression tests and I'm on a slow pc at the moment I think ill do some damage testing, see if I can choke the decoder.
I can run my own tests easily enough but does anyone have the damage tool that was created with this in mind available/
I can run my own tests easily enough but does anyone have the damage tool that was created with this in mind available/
I do, but I'm not sure about the ethics of passing out an application that was given to me as an alpha tester. I think Thomas needs to authorise this.
I'm probably being anal, but I'd rather not break his confidence. Sorry.
I'm probably being anal, but I'd rather not break his confidence. Sorry.
QUOTE (Synthetic Soul @ Jan 4 2007, 17:39)
I do, but I'm not sure about the ethics of passing out an application that was given to me as an alpha tester. I think Thomas needs to authorise this.
I'm probably being anal, but I'd rather not break his confidence. Sorry.
I'm probably being anal, but I'd rather not break his confidence. Sorry.
Don't worry I can wait.
I seem to be able to produce an undecodable file by cutting off the first 8 lines in notepad++, might just be saving it in a different format(utf-8, uncode etc) by mistake though so I shall investigate further.
QUOTE (madorangepanda @ Jan 4 2007, 18:08)
...
I can run my own tests easily enough but does anyone have the damage tool that was created with this in mind available/
I can run my own tests easily enough but does anyone have the damage tool that was created with this in mind available/
QUOTE (Synthetic Soul @ Jan 4 2007, 18:39)
I do, but I'm not sure about the ethics of passing out an application that was given to me as an alpha tester. I think Thomas needs to authorise this.
I'm probably being anal, but I'd rather not break his confidence. Sorry.
I'm probably being anal, but I'd rather not break his confidence. Sorry.
Again, thanks for beeing anal! I really appreciate this.
I could put the Damage tool (V1.02) into the upload section. It's only about 85 K big and i doubt, that many people are interested, hence i suppose it is ok to use the upload section for this without asking the admins (Hope so).
Could take 1 hour.
BTW: This thread is real fun for me! I will respond to some other posts later.
Edit: Here it is: Damage 1.02
Chopping a big chunk from head and feet (~120KiB in total of a file with 6.54MiB) makes the file undecodable. That is normal? Where you posted about errors that are know to not been decodable?
EDIT: Even an not so big chunk (10K in total) turn the file undecodable.
EDIT2: I've found no problem cutting the entire first half or the entire last half of the file. The remaining data decodes perfectly!
EDIT: Even an not so big chunk (10K in total) turn the file undecodable.
EDIT2: I've found no problem cutting the entire first half or the entire last half of the file. The remaining data decodes perfectly!
QUOTE (Caroliano @ Jan 4 2007, 20:45)
Chopping a big chunk from head and feet (~120KiB in total of a file with 6.54MiB) makes the file undecodable. That is normal? Where you posted about errors that are know to not been decodable?
It's normal for the current decoder implementation. The decoder has to read a stream info structure which contains all general parameters needed for decoding (audio format, frame size...). This can be found in the meta data structure at the beginning of the file and it is also beeing inserted every 2 seconds into the audio data stream itself. Therefore the file format can survive even very heavy damage. Theoretically...
While the stream info is available in many places of the file, the current decoder implemation checks only 3 positions:
1) The meta data.
2) If the meta data is damaged, it searches for the first frame header (this always contains another stream info).
3) If both above are damaged the decoder searches for the last frame header (with a flag set, indicating that this is the last frame) within the last 1 MByte of the file.
If all this fails, the decoder stops. Obviously this can be improved: The decoder could go through the whole stream.
But all this is beeing performed by the open function of the decoder. I don't want to let it scan through the whole file (imagine a 4 GB file), at least not without asking the user.
I suppose, that damage of head and feet is a rare case, therfore this limitation should not hurt too much.
To make it clear: another decoder implementation can solve this.
QUOTE (Caroliano @ Jan 4 2007, 20:45)
EDIT: Even an not so big chunk (10K in total) turn the file undecodable.
If this is not the head-and-feet issue: It is sometimes necessary to deactivate the restore wave file meta data option to decode damaged files. This is always the case, if the damage changes the file size. Then the decoder has to modify the audio data size entries in the wave file header. But if you are using the restore wave file meta data option, the decoder handles the previously stored header as a black box, which it will not touch.
QUOTE (Caroliano @ Jan 4 2007, 20:45)
EDIT2: I've found no problem cutting the entire first half or the entire last half of the file. The remaining data decodes perfectly!
Well, this supports my explaination above.
Nice testing!
QUOTE
If all this fails, the decoder stops. Obviously this can be improved: The decoder could go through the whole stream.
But all this is beeing performed by the open function of the decoder. I don't want to let it scan through the whole file (imagine a 4 GB file), at least not without asking the user.
I suppose, that damage of head and feet is a rare case, therfore this limitation should not hurt too much.
To make it clear: another decoder implementation can solve this.
But all this is beeing performed by the open function of the decoder. I don't want to let it scan through the whole file (imagine a 4 GB file), at least not without asking the user.
I suppose, that damage of head and feet is a rare case, therfore this limitation should not hurt too much.
To make it clear: another decoder implementation can solve this.
OK. Glad to hear that. I supose that is possible add this "scan the whole file" as an switch in the decoder, and in case of an undecodable file, ask the user if he want to make this in depth scan.
QUOTE
If this is not the head-and-feet issue: It is sometimes necessary to deactivate the restore wave file meta data option to decode damaged files.
I don't know where the head or feet start or end, I was just making some dumb cuts by an hex-editor. If head an foot in an 5.64MB file shoud have more than ~10KB togheter, then it may be a problem. I deactivated the restore meta data option since the begin, so that is not the problem.
As an side note, every time that I change a preset, the "verify" option is disabled, and I have to re-check it. As I want to leave it enabled for catch any possible encoder/decoder errors in this beta, this is anoying. Just my opinion, as the defaut may be better for other people...
PS: How I enable SSE optimizations? In the log has a mention that it is disabled, but I've only found the enable/disable MMX option. I have an P4 based Celeron, that shoud suport up to SSE2.
QUOTE (Caroliano @ Jan 4 2007, 21:43)
QUOTE
If all this fails, the decoder stops. Obviously this can be improved: The decoder could go through the whole stream.
But all this is beeing performed by the open function of the decoder. I don't want to let it scan through the whole file (imagine a 4 GB file), at least not without asking the user.
I suppose, that damage of head and feet is a rare case, therfore this limitation should not hurt too much.
To make it clear: another decoder implementation can solve this.
But all this is beeing performed by the open function of the decoder. I don't want to let it scan through the whole file (imagine a 4 GB file), at least not without asking the user.
I suppose, that damage of head and feet is a rare case, therfore this limitation should not hurt too much.
To make it clear: another decoder implementation can solve this.
OK. Glad to hear that. I supose that is possible add this "scan the whole file" as an switch in the decoder, and in case of an undecodable file, ask the user if he want to make this in depth scan.
Good idea!
Probably i will build a separate repair function with such an option.
The decoder itself should be simple without too many options and without user interaction. Otherwise it would be more difficult to build media player plugins (i suppose, i am not yet an expert in this).
QUOTE (Caroliano @ Jan 4 2007, 21:43)
QUOTE
If this is not the head-and-feet issue: It is sometimes necessary to deactivate the restore wave file meta data option to decode damaged files.
I don't know where the head or feet start or end, I was just making some dumb cuts by an hex-editor. If head an foot in an 5.64MB file shoud have more than ~10KB togheter, then it may be a problem. I deactivated the restore meta data option since the begin, so that is not the problem.
I too don't know. It depends on frame size, audio format, file size and compressability.
But with for instance 5 to 10 kB cut from the beginning and the end there is a fair chance to have damaged all 3 possible stream info positions.
QUOTE (Caroliano @ Jan 4 2007, 21:43)
As an side note, every time that I change a preset, the "verify" option is disabled, and I have to re-check it. As I want to leave it enabled for catch any possible encoder/decoder errors in this beta, this is anoying. Just my opinion, as the defaut may be better for other people...
This shouldn't be! Thanks! I will change this.
QUOTE (Caroliano @ Jan 4 2007, 21:43)
PS: How I enable SSE optimizations? In the log has a mention that it is disabled, but I've only found the enable/disable MMX option. I have an P4 based Celeron, that shoud suport up to SSE2.
Well, i have removed the SSE optimizations, because they brought absolutely nothing (evaluated by different testers). Obviously i forgot to remove the corresponding protocol entry.
Thanks for your thorough testing!
Some news (I think a new post is better than editing):
If I cut only 30bytes from the start and 30bytes from the end, the decoder still tell that it is undecodable. If I cut only the first and the last byte, the decoder tries to decode the file, but at 98% (as the GUI shows, but may be more) it stop with an error:
"Assertion failure (D:\VocComp\Win\yaaFileDecomp.pas, line 484)"
I click OK and the program close...
If I cut only 30bytes from the start and 30bytes from the end, the decoder still tell that it is undecodable. If I cut only the first and the last byte, the decoder tries to decode the file, but at 98% (as the GUI shows, but may be more) it stop with an error:
"Assertion failure (D:\VocComp\Win\yaaFileDecomp.pas, line 484)"
I click OK and the program close...
QUOTE (Caroliano @ Jan 4 2007, 22:01)
If I cut only 30bytes from the start and 30bytes from the end, the decoder still tell that it is undecodable. If I
Even with only 30 bytes it is possible to damage the headers of the first and the last frame, if the file begins and ends with silence, which can be compressed into very small frames.
QUOTE (Caroliano @ Jan 4 2007, 22:01)
If I cut only the first and the last byte, the decoder tries to decode the file, but at 98% (as the GUI shows, but may be more) it stop with an error:
"Assertion failure (D:\VocComp\Win\yaaFileDecomp.pas, line 484)"
I click OK and the program close...
"Assertion failure (D:\VocComp\Win\yaaFileDecomp.pas, line 484)"
I click OK and the program close...
Since the morning i am sitting here and waiting for something like this to happen...
But it's very nice to know the code line.
Would it be possible to send me the damaged file which generates this error?
I assume, that the last frame is very small and that this causes the error.
E-mail sent. Probably the silence problem.
QUOTE (Caroliano @ Jan 4 2007, 22:41)
E-mail sent. Probably the silence problem.
Thank you! I've got it.
Now i will look for the error...
Well, if you don't try to make your codec error tolerant and simply stop decoding (or skip the data) instead of trying to restore the data, it's simplier. Then you have not to deal with some quite complicated error correction code, which itself can contain errors...
Now Tak looks less stable because of it's attempts to restore as much data as possible...
QUOTE (Caroliano @ Jan 4 2007, 22:01)
If I cut only 30bytes from the start and 30bytes from the end, the decoder still tell that it is undecodable. If I cut only the first and the last byte, the decoder tries to decode the file, but at 98% (as the GUI shows, but may be more) it stop with an error:
"Assertion failure (D:\VocComp\Win\yaaFileDecomp.pas, line 484)"
I click OK and the program close...
"Assertion failure (D:\VocComp\Win\yaaFileDecomp.pas, line 484)"
I click OK and the program close...
Fixed!
Sweating...
The compressed audio data of a frame is beeing followed by a CRC. I forgot to check, if there were enough bytes left in my buffer for the CRC. After removal of the last byte (same is true for 2 or 3 bytes) it wasn't enough (This could only happen with the last frame).
The fix was so simple, that this alone is no reason for a second beta. But let's see what comes next.
QUOTE (TBeck @ Jan 4 2007, 19:53)
Thank you! I've got it.
Now i will look for the error...
Well, if you don't try to make your codec error tolerant and simply stop decoding (or skip the data) instead of trying to restore the data, it's simplier. Then you have not to deal with some quite complicated error correction code, which itself can contain errors...
Now Tak looks less stable because of it's attempts to restore as much data as possible...
Now i will look for the error...
Well, if you don't try to make your codec error tolerant and simply stop decoding (or skip the data) instead of trying to restore the data, it's simplier. Then you have not to deal with some quite complicated error correction code, which itself can contain errors...
Now Tak looks less stable because of it's attempts to restore as much data as possible...
Don't worry about this so much! It is a beta, that isn't suposed to be totaly stable and "production ready"! No one in future will judje your codec based in an early beta release.
And on top of all this the error is with an corrupted file, that as you said could be ignored. And this even isn't an error that will make you loose some data, as it will be recoverable with the next version, or, in the worst case, with an specialized tool in future.
Lets find all the possible hiden bugs to release an clean stable version!
Edit: "No one in future will judje your codec based in an early beta release" ... but will see with good eyes an developer that is so concerned with the problems in his codec and quicky in bug-fixes! That was fast! Thank you.
I thought I'd post some compression results I found interesting. From my tests, it seems that the higher the compressibility of a sample the more TAK outstrips other encoders. To demonstrate this, here are some results from the most compressible album in my collection. It's Autechre & The Halfer Trio's "æo³ & ³hæ" album. Lots of silence, near silence, static and such on this one.
My CPU is an Opteron 165 overclocked to 2900 mhz. A lot of the numbers are there but notice how neither flac or wavpack can come anywhere close to even Turbo. Another thing you might notice is that Turbo mode is much too fast for my storage subsystem (enct is encode test mode).
CODE
enc enct dec size
Turbo 209.9 274.1 294.73 240,020,885
Fast 172.7 187.5 277.82 237,073,503
Normal 107.2 112.2 266.09 234,668,207
High 66.40 68.38 206.81 232,370,112
Extra 39.54 40.23 186.40 229,728,913
ExtraM 12.54 xxxxx 187.28 229,502,965
flac8 18.55 xxxxx 316.43 256,086,154
WVh 104.8 xxxxx 141.73 267,167,826
WVhhx3 9.590 xxxxx 108.22 255,402,312
Turbo 209.9 274.1 294.73 240,020,885
Fast 172.7 187.5 277.82 237,073,503
Normal 107.2 112.2 266.09 234,668,207
High 66.40 68.38 206.81 232,370,112
Extra 39.54 40.23 186.40 229,728,913
ExtraM 12.54 xxxxx 187.28 229,502,965
flac8 18.55 xxxxx 316.43 256,086,154
WVh 104.8 xxxxx 141.73 267,167,826
WVhhx3 9.590 xxxxx 108.22 255,402,312
My CPU is an Opteron 165 overclocked to 2900 mhz. A lot of the numbers are there but notice how neither flac or wavpack can come anywhere close to even Turbo. Another thing you might notice is that Turbo mode is much too fast for my storage subsystem (enct is encode test mode).
Thank you for the Damage Tool and the explanation as to why removing the header/footer causes a problem with the current decoder.
QUOTE (Caroliano @ Jan 4 2007, 23:17)
...
Edit: "No one in future will judje your codec based in an early beta release" ... but will see with good eyes an developer that is so concerned with the problems in his codec and quicky in bug-fixes! That was fast! Thank you.
Edit: "No one in future will judje your codec based in an early beta release" ... but will see with good eyes an developer that is so concerned with the problems in his codec and quicky in bug-fixes! That was fast! Thank you.
Thank you! A very nice point of view.
QUOTE (Gnerma @ Jan 4 2007, 23:26)
I thought I'd post some compression results I found interesting. From my tests, it seems that the higher the compressibility of a sample the more TAK outstrips other encoders. To demonstrate this, here are some results from the most compressible album in my collection. It's Autechre & The Halfer Trio's "æo³ & ³hæ" album. Lots of silence, near silence, static and such on this one.
...
...
Fine. Tak is quite well optimized for very low amplitudes (within the possible limits of non arithmetic coding), because in it's early days i only had 8 Bit sample files.
And thanks for the kind words in your first post of this thread! And thanks for the congratualations of the other posters!
QUOTE (madorangepanda @ Jan 4 2007, 23:40)
Thank you for the Damage Tool and the explanation as to why removing the header/footer causes a problem with the current decoder.
I hope, the documentation of the tool is sufficient.
And i hope, i could make it clear, that the header/feet problem should only be a problem, if both are beeing removed simultaneously. Otherwise the file should be decodable.
@Gnerma: What was the total filesize? Only to have a idea about the compressibility. MAC comparison would also be nice to see the high compresion side.
This may not be, but the anoying "verify" option could be.
Anyways, I will try to use the comand-line for batch encode from now. There this problem will not apear. Too many beta releases can overload the file server and the beta-testers.
And about the undecodable files? I tested now cuting the first byte and the last 4 bytes. It tries to decode but when it finish it says that the file is undecodable. This behavior is slight diferent than when I cut 30 bytes from each end. In that case it stops imediatly and say that it is undecodable. Don't even try to decode the whole file.
QUOTE
Fixed!
[...]
The fix was so simple, that this alone is no reason for a second beta. But let's see what comes next.
[...]
The fix was so simple, that this alone is no reason for a second beta. But let's see what comes next.
This may not be, but the anoying "verify" option could be.
Anyways, I will try to use the comand-line for batch encode from now. There this problem will not apear. Too many beta releases can overload the file server and the beta-testers.
And about the undecodable files? I tested now cuting the first byte and the last 4 bytes. It tries to decode but when it finish it says that the file is undecodable. This behavior is slight diferent than when I cut 30 bytes from each end. In that case it stops imediatly and say that it is undecodable. Don't even try to decode the whole file.
QUOTE (Caroliano @ Jan 5 2007, 00:00)
QUOTE
Fixed!
[...]
The fix was so simple, that this alone is no reason for a second beta. But let's see what comes next.
[...]
The fix was so simple, that this alone is no reason for a second beta. But let's see what comes next.
This may not be, but the anoying "verify" option could be.
Both are easy fixes without the possibility of unpredictable side effects. Therefore i would risk to apply the patches to the final version without further beta testing.
I don't want to stress the testers too much and there already have been the two alpha versions. All this can get boaring for the testers and the audience... I assume, we are also here for some entertainment!
But maybe we will see a second beta.
For your great and dangerous (huh, what will this guy do next... i really appreciate your work!) testing it would be better to soon have a second beta with the fixes. But i want to wait some days for more bug reports before thinking about a second beta.
QUOTE (Caroliano @ Jan 5 2007, 00:00)
And about the undecodable files? I tested now cuting the first byte and the last 4 bytes. It tries to decode but when it finish it says that the file is undecodable. This behavior is slight diferent than when I cut 30 bytes from each end. In that case it stops imediatly and say that it is undecodable. Don't even try to decode the whole file.
If the error message comes at the end of the file, i suppose that you have not disabled the restore wave file meta data option. Otherwise i would be surprised.
QUOTE
For your great and dangerous (huh, what will this guy do next... i really appreciate your work!) testing it would be better to soon have a second beta with the fixes. But i want to wait some days for more bug reports before thinking about a second beta.
No problems.
QUOTE
If the error message comes at the end of the file, i suppose that you have not disabled the restore wave file meta data option. Otherwise i would be surprised.
Ooops. I forgot to re-enable after the crashes.
It decodes correctly and only the last sample is missed (if I understod correcly the log...). Great! But an more precise error message when the "restore wave file meta data" is enabled would be good... not every one will read the whole read-me file, or may forget it enabled, as me.
QUOTE (Caroliano @ Jan 5 2007, 00:37)
QUOTE
If the error message comes at the end of the file, i suppose that you have not disabled the restore wave file meta data option. Otherwise i would be surprised.
Ooops. I forgot to re-enable after the crashes.
It decodes correctly and only the last sample is missed (if I understod correcly the log...). Great! But an more precise error message when the "restore wave file meta data" is enabled would be good... not every one will read the whole read-me file, or may forget it enabled, as me.
Improved:
- If one file was undecodable, Tak shows the hint "Try disabling "Restore wave file meta data" (-wm0)."
- The state of the Verify-option is beeing preserved when changing presets in the GUI version.
EDIT: Probably there will be more then 1 lost sample at the end of your damaged file. An error in a frame will always make the whole (small) frame undecodable. Unfortunately the error log will always say 0 lost samples for the last frame, because earlier only the last frame itself contained info about it's sample count. If the last frame was damaged, the decoder could not tell how many samples it contained. This only regards to the last frame. And it could be done better now, because after the last modification of the stream format any stream info structure contains data from which the size of the last frame can be calculated. Sorry, i forgot to use this.
QUOTE (Synthetic Soul @ Jan 4 2007, 07:38)
Edit: I have updated Tag to recognise TAK files (so you don't have to specify --ape2 --nocheck). Download 2.0.49 if you want to tag using Case's Tag. NB: 2.0.48 was a "silent" release that updated to libFLAC 1.1.3.
QUOTE (foosion @ Jan 4 2007, 13:12)
TAK Decoder Stub for foobar2000
I've made a simple component for foobar2000 that will allow you to use foobar2000 to tag your TAK files. It doesn't support playback for obvious reasons. Perhaps some people will find it useful to manage their TAK files.
I've made a simple component for foobar2000 that will allow you to use foobar2000 to tag your TAK files. It doesn't support playback for obvious reasons.
Perhaps some people will find it useful to manage their TAK files.Thank you very much for making Tak more usable!
QUOTE (pest @ Jan 4 2007, 11:04)
Sadly WAVE_FORMAT_EXTENSIBLE files are not supported, or are they?
They are not supported. Probably i will wait with this until i am implementing multi channel support.
I would love to support TAK in shntool. Are there plans to have TAKC read WAVE data from standard input when encoding and/or write WAVE data to standard output when decoding?
QUOTE (shnutils @ Jan 5 2007, 17:12)
I would love to support TAK in shntool. Are there plans to have TAKC read WAVE data from standard input when encoding and/or write WAVE data to standard output when decoding?
Great!
It's among the items on my to do list, but has no top priority for me. Well, your post has just raised the priority... But first comes tagging and media player support.
A very good point.
Being able to read from STDIN and write to STDOUT is very useful for those of us wishing to convert from our lossless source to lossy files.
It's also worth noting that some apps like FLAC and OptimFROG have issue with the way that foobar pipes to STDIN. WavePack gets around it with the -i switch.
http://www.hydrogenaudio.org/forums/index....showtopic=43160
http://www.hydrogenaudio.org/forums/index....showtopic=41287
Definately worth taking the time to ensure that foobar can easily pipe to TAKC.EXE.
Being able to read from STDIN and write to STDOUT is very useful for those of us wishing to convert from our lossless source to lossy files.
It's also worth noting that some apps like FLAC and OptimFROG have issue with the way that foobar pipes to STDIN. WavePack gets around it with the -i switch.
http://www.hydrogenaudio.org/forums/index....showtopic=43160
http://www.hydrogenaudio.org/forums/index....showtopic=41287
Definately worth taking the time to ensure that foobar can easily pipe to TAKC.EXE.
QUOTE (shnutils @ Jan 5 2007, 08:12)
I would love to support TAK in shntool. Are there plans to have TAKC read WAVE data from standard input when encoding and/or write WAVE data to standard output when decoding?
Have you tried to set the filename to "CON" yet? May just work.
QUOTE (jido @ Jan 5 2007, 11:45)
Have you tried to set the filename to "CON" yet? May just work.
Thanks for the suggestion. I actually use that trick for other formats, but hadn't tried it for TAK. Unfortunately, it doesn't seem to work:
CODE
C:\shnutils>takc -d test.tak CON
test.tak .......... Error writing destination
1 files with read/write errors.
test.tak .......... Error writing destination
1 files with read/write errors.
CODE
C:\shnutils>type test.wav | takc -e CON test.tak
CON.wav .......... Allready exists
1 files allready existed.
The process tried to write to a nonexistent pipe.
CON.wav .......... Allready exists
1 files allready existed.
The process tried to write to a nonexistent pipe.
I will wait patiently, as this is not a top priority for me either. In the meantime, thank you Thomas for all of your hard work!
QUOTE (TBeck @ Jan 5 2007, 10:30)
EDIT: Probably there will be more then 1 lost sample at the end of your damaged file. An error in a frame will always make the whole (small) frame undecodable. Unfortunately the error log will always say 0 lost samples for the last frame, because earlier only the last frame itself contained info about it's sample count. If the last frame was damaged, the decoder could not tell how many samples it contained. This only regards to the last frame. And it could be done better now, because after the last modification of the stream format any stream info structure contains data from which the size of the last frame can be calculated. Sorry, i forgot to use this.
Well, even reading the read-me I don't understand perfeclty this error log. Here it is:
CODE
--- 4.tak ---
Result: Frame(s) damaged
File-ID: damaged
StreamInfo: damaged
Meta data: damaged
Header frames: 369
Valid frames: 368
Skipped blocks: 0
Skipped end: 1
Skipped data blocks
No Source pos Size Sample pos Count
1 6861140 29 4057200 0
Result: Frame(s) damaged
File-ID: damaged
StreamInfo: damaged
Meta data: damaged
Header frames: 369
Valid frames: 368
Skipped blocks: 0
Skipped end: 1
Skipped data blocks
No Source pos Size Sample pos Count
1 6861140 29 4057200 0
QUOTE (TBeck @ Jan 4 2007, 11:34)
TAK 1.0 Beta 1
Have fun and thanks for testing!
Thomas
Have fun and thanks for testing!
Thomas
Hi Thomas,
Thank you very much for the codec!
I pick a few digitized 48KHz vinyl WAV to test, the speed and compression rate was VERY impressive, also the GUI is clean and simple.
I think Foobar2000 can be helpful for the GUI, you can concentrate on the codec core and let Foobar2000 handles common operations.
Test sample:
---
a03-just the way you are.wav (56,217,644 bytes)
19 sec - FLAC -7 - 23,517,400 bytes (with Foobar2000 plugin 1.1.3, estimate)
7.4 sec - TAK -3 (high) - 22,404,252 bytes (with TAK 1.0 beta1, builtin counter)
---
b03-she's always a woman.wav (38,592,044 bytes)
13 sec - FLAC -7 - 16,248,229 bytes (with Foobar2000 plugin 1.1.3, estimate)
5.03 sec - TAK -3 (high) - 15,424,111 bytes (with TAK 1.0 beta1, builtin counter)
---
Of course, Josh did a great work, but without competition there won't be any fun and improvement, maybe TAK can also have FLAC features like "picture block", or even standize some common "must have" between codecs ... I can wait for your great work, too.
QUOTE (Caroliano @ Jan 5 2007, 19:45)
Well, even reading the read-me I don't understand perfeclty this error log. Here it is:
CODE
--- 4.tak ---
Result: Frame(s) damaged
File-ID: damaged
StreamInfo: damaged
Meta data: damaged
Header frames: 369
Valid frames: 368
Skipped blocks: 0
Skipped end: 1
Skipped data blocks
No Source pos Size Sample pos Count
1 6861140 29 4057200 0
Result: Frame(s) damaged
File-ID: damaged
StreamInfo: damaged
Meta data: damaged
Header frames: 369
Valid frames: 368
Skipped blocks: 0
Skipped end: 1
Skipped data blocks
No Source pos Size Sample pos Count
1 6861140 29 4057200 0
The stream info (header) tells, that the file contains 369 frames. 368 frames were valid and could be decoded. Skipped block counts undecodable frames except the last one at the file end. Skipped end is 1, if the last frame could not be decoded, otherwise 0.
Skipped data blocks is a list of file parts containing frames which could not be decoded.
Most interesting maybe the value of SamplePos: You can open the decoded file with a wave editor and jump to this position to look at the damage. Count usually tells you, how many samples have been affected. But for the last frame this value is always 0 (i will change this later).
While damaged frames are usually beeing replaced with zeros (muted), a damaged last frame is simply beeing cut off.
I hope, this helps...
Yes, it helped very much. You can improve the "Skiped End" and the "count" explanation in the readme, in the same way as you explaned here for me.
And now some compression results:
From the total of 20 files compressed by TAK extra max, 7 were very compressible (35.20% ~ 49.68%), 11 not very compressible (60.42% ~ 71.79%) and only two were in the 50 ~ 60 range, only to show how averages can be misleading.
The "turbo" and "fast" modes from TAK doesn't have any competition! Flake slowest mode didn't compressed better than TAK's turbo, and WV hhx3 barely out performed it in compression, but coudn't reach the fast mode. MAC's fast is better, but not in TAK's level.
In normal and high MAC came closer, but not quite there yet. Finally, TAK can't compete with the compression of MAC's Extra high, nor Insane. But, on the other hand, the same is true for MAC when you compare the decoding speed, that I didn't mesured.
Overal, very impressive! Don't drop Turbo mode, as it is faster than fast any way, and can help with slower processors or when you want the minimum system usage (live video capture with audio, for example).
And now some compression results:
CODE
Tsubasa Chronicle - Original Sound Track - Future Soundscape 1
Original Size: 581.838.640 bytes
Total playing time: 54:58 min
Codec Avg. Compression Enc Time
Flac -0 : (62,73%) 1:29 min
Flac -5 : (59,76%) 2:39 min
Flac -8 : (59,54%) ~9:20 min
Flake -5 : (58,72%) 2:28 min*
Flake -8 : (58,42%) 5:12 min*
Flake -12 : (57,77%) 31:40 min*
WV -fm: (60,11%) 2:12 min*
WV -hm: (58,06%) 3:18 min*
WV -hhx3m: (57,38%) 22:39 min*
MAC fast: (58,31%) 1:46 min
MAC normal: (56,83%) 2:32 min
MAC high: (56,09%) 3:00 min
MAC Extra high: (54,98%) ~5:30 min
MAC Insane: (54,57%) 18:17 min
TAK turbo: (57.46 %) 1:29 min
TAK fast: (56.75 %) 1:50 min
TAK normal: (56.19 %) 2:24 min
TAK normal max: (56.08 %) 4:13 min
TAK high: (55.48 %) 3:38 min
TAK extra: (55.18 %) 5:15 min
TAK extra max: (55.14 %) 12:03 min
Hardware: Celeron 1.7GHz (L2 cache of 128KB)
512mb DDR-133
Seagate 7200.7 80GB IDE
* the times marked this way may be wrong, encoding made by foobar.
Original Size: 581.838.640 bytes
Total playing time: 54:58 min
Codec Avg. Compression Enc Time
Flac -0 : (62,73%) 1:29 min
Flac -5 : (59,76%) 2:39 min
Flac -8 : (59,54%) ~9:20 min
Flake -5 : (58,72%) 2:28 min*
Flake -8 : (58,42%) 5:12 min*
Flake -12 : (57,77%) 31:40 min*
WV -fm: (60,11%) 2:12 min*
WV -hm: (58,06%) 3:18 min*
WV -hhx3m: (57,38%) 22:39 min*
MAC fast: (58,31%) 1:46 min
MAC normal: (56,83%) 2:32 min
MAC high: (56,09%) 3:00 min
MAC Extra high: (54,98%) ~5:30 min
MAC Insane: (54,57%) 18:17 min
TAK turbo: (57.46 %) 1:29 min
TAK fast: (56.75 %) 1:50 min
TAK normal: (56.19 %) 2:24 min
TAK normal max: (56.08 %) 4:13 min
TAK high: (55.48 %) 3:38 min
TAK extra: (55.18 %) 5:15 min
TAK extra max: (55.14 %) 12:03 min
Hardware: Celeron 1.7GHz (L2 cache of 128KB)
512mb DDR-133
Seagate 7200.7 80GB IDE
* the times marked this way may be wrong, encoding made by foobar.
From the total of 20 files compressed by TAK extra max, 7 were very compressible (35.20% ~ 49.68%), 11 not very compressible (60.42% ~ 71.79%) and only two were in the 50 ~ 60 range, only to show how averages can be misleading.
The "turbo" and "fast" modes from TAK doesn't have any competition! Flake slowest mode didn't compressed better than TAK's turbo, and WV hhx3 barely out performed it in compression, but coudn't reach the fast mode. MAC's fast is better, but not in TAK's level.
In normal and high MAC came closer, but not quite there yet. Finally, TAK can't compete with the compression of MAC's Extra high, nor Insane. But, on the other hand, the same is true for MAC when you compare the decoding speed, that I didn't mesured.
Overal, very impressive! Don't drop Turbo mode, as it is faster than fast any way, and can help with slower processors or when you want the minimum system usage (live video capture with audio, for example).
Here is the results of the mega-test, and the decoding speed for most codecs, however I didn't get to update the TAK results yet for the latest info or make this in any better format (I've been working 12+hrs a day). Hopefully this is a nice start:
QUOTE (TrNSZ @ Jan 6 2007, 04:49)
Here is the results of the mega-test, and the decoding speed for most codecs, however I didn't get to update the TAK results yet for the latest info or make this in any better format (I've been working 12+hrs a day). Hopefully this is a nice start:
Absolutely! Thank you very much!
Again i took the freedom to put some (it's really much!) of the data into another form:
CODE
Size (MB) Ratio Diff Best Diff Tak 4m
Original 1307.29 100.00 -47.94 -46.47
MLP 885.81 67.76 -15.70 -14.23
FLAC-0 785.29 60.07 -8.01 -6.54
WavPack-fast 748.42 57.25 -5.19 -3.72
FLAC-5 735.93 56.29 -4.23 -2.76
FLAC-8 731.44 55.95 -3.89 -2.42
WavPack-normal 729.37 55.79 -3.73 -2.26
Flake-12 725.01 55.46 -3.40 -1.93
WavPack-normal-x3 724.56 55.43 -3.36 -1.89
ALS 723.40 55.34 -3.27 -1.80
APE-fast 722.21 55.24 -3.18 -1.71
WavPack-high 721.94 55.22 -3.16 -1.69
WavPack-normal-x6 721.37 55.18 -3.12 -1.65
TAK-0 719.65 55.05 -2.99 -1.52
WavPack-high-x3 718.27 54.94 -2.88 -1.41
WavPack-hh 717.48 54.88 -2.82 -1.35
WavPack-high-x6 716.01 54.77 -2.71 -1.24
WavPack-hhx3 715.16 54.71 -2.64 -1.17
TAK-0m 715.05 54.70 -2.63 -1.16
WavPack-hhx6 713.96 54.61 -2.55 -1.08
TAK-1 713.50 54.58 -2.52 -1.05
OptimFROG-fast 709.74 54.29 -2.23 -0.76
APE-normal 709.58 54.28 -2.22 -0.75
TAK-2 708.31 54.18 -2.12 -0.65
APE-high 704.69 53.90 -1.84 -0.37
TAK-3 703.73 53.83 -1.77 -0.30
OptimFROG-normal 702.40 53.73 -1.67 -0.20
TAK-4 700.61 53.59 -1.53 -0.06
TAK-4m 699.84 53.53 -1.47 0.00
OptimFROG-high 699.60 53.52 -1.45 0.02
APE-extra 696.66 53.29 -1.23 0.24
ALS -7 696.46 53.27 -1.21 0.26
ALS-7-LTP 696.16 53.25 -1.19 0.28
APE-insane 693.59 53.06 -0.99 0.48
La-high 681.64 52.14 -0.08 1.39
OptimFROG-maximum-exp 680.62 52.06 0.00 1.47
Original 1307.29 100.00 -47.94 -46.47
MLP 885.81 67.76 -15.70 -14.23
FLAC-0 785.29 60.07 -8.01 -6.54
WavPack-fast 748.42 57.25 -5.19 -3.72
FLAC-5 735.93 56.29 -4.23 -2.76
FLAC-8 731.44 55.95 -3.89 -2.42
WavPack-normal 729.37 55.79 -3.73 -2.26
Flake-12 725.01 55.46 -3.40 -1.93
WavPack-normal-x3 724.56 55.43 -3.36 -1.89
ALS 723.40 55.34 -3.27 -1.80
APE-fast 722.21 55.24 -3.18 -1.71
WavPack-high 721.94 55.22 -3.16 -1.69
WavPack-normal-x6 721.37 55.18 -3.12 -1.65
TAK-0 719.65 55.05 -2.99 -1.52
WavPack-high-x3 718.27 54.94 -2.88 -1.41
WavPack-hh 717.48 54.88 -2.82 -1.35
WavPack-high-x6 716.01 54.77 -2.71 -1.24
WavPack-hhx3 715.16 54.71 -2.64 -1.17
TAK-0m 715.05 54.70 -2.63 -1.16
WavPack-hhx6 713.96 54.61 -2.55 -1.08
TAK-1 713.50 54.58 -2.52 -1.05
OptimFROG-fast 709.74 54.29 -2.23 -0.76
APE-normal 709.58 54.28 -2.22 -0.75
TAK-2 708.31 54.18 -2.12 -0.65
APE-high 704.69 53.90 -1.84 -0.37
TAK-3 703.73 53.83 -1.77 -0.30
OptimFROG-normal 702.40 53.73 -1.67 -0.20
TAK-4 700.61 53.59 -1.53 -0.06
TAK-4m 699.84 53.53 -1.47 0.00
OptimFROG-high 699.60 53.52 -1.45 0.02
APE-extra 696.66 53.29 -1.23 0.24
ALS -7 696.46 53.27 -1.21 0.26
ALS-7-LTP 696.16 53.25 -1.19 0.28
APE-insane 693.59 53.06 -0.99 0.48
La-high 681.64 52.14 -0.08 1.39
OptimFROG-maximum-exp 680.62 52.06 0.00 1.47
Sorted by compression ratio.
"Diff Best" is the difference of the best result and the row.
"Diff Tak 4m" is the difference of Tak's strongest mode and the row.
First time i see results for MLP. Is it really so weak?
Again, many thanks for this comprehensive testing! The table shows only a tiny part of the whole data...
QUOTE (Caroliano @ Jan 5 2007, 21:58)
And now some compression results:
...
...
Thank you! Seems to be a Tak-friendly test set. There may be more of them than i expected...
QUOTE (Caroliano @ Jan 5 2007, 21:58)
Overal, very impressive! Don't drop Turbo mode, as it is faster than fast any way, and can help with slower processors or when you want the minimum system usage (live video capture with audio, for example).
Fine!
And no, i don't intend to drop the Turbo mode, exactly for the same reasons as you!
Maybe i will try to make it a bit faster sometime...
It makes me wonder if MLP would perform better on multichannel data, or if the whole purpose of it is really just a modest savings in space combined with watermarking and DRM....
On the other hand, comparison to wavpack hhx6 is impressive.
A hybrid mode in the future would be quite a feat.
TBeck, have you looked into FreePascal to see about producing a DLL that might be able to be wrapped up with a foobar2000 decoder component?
On the other hand, comparison to wavpack hhx6 is impressive.
A hybrid mode in the future would be quite a feat.
TBeck, have you looked into FreePascal to see about producing a DLL that might be able to be wrapped up with a foobar2000 decoder component?
Ok, tak doesn't suport unicode yet. I tried an music with japanese characters in it's name and it don't worked. It loads the file, with ??? in the name, but in test mode the error message was: "Error reading source". In the compress mode the error is "Allready exists", if a file with an name close to the source name exist, even if the diference is made by normal characters. If the name is very diferent, or there is no .tak file in the folder, the error is the same as in test mode.
Note the typo in the "Allready exists". It shoud have only one L.
Note the typo in the "Allready exists". It shoud have only one L.
I found an very interesting file, that answers in an almost linear way to the increase of compression time, in case of TAK and MAC, and in others it is an jump in compression in the very high setings:
The compression delta for TAK is 4.65 %, wich seems very high for TAK. And the compression delta between Flac -0 and this extreme mode in OptimFrog is 12.04 %. Flac is the "left zero", with an delta of only 2.55, but Flake got the trick somewere beteween -8 and -12.
Another thing intersting in this file is the "max" swich in TAK. Here the gains in compression with max for each preset:
It increases after "normal"! The High Max compress beter than extra simple!
I've upload this file sometime ago, as an SBR killer. You can get it here: http://www.hydrogenaudio.org/forums/index....533;entry363343
CODE
Flyin' to Fly (source).wav
Mode Compression Speed
Turbo 72.42 % 55x
Turbo Max 71.78 % 21x
Fast 70.96 % 38x
Fast Max 70.41 % 16x
Normal 69.39 % 24x
Normal Max 69.19 % 11x
High 68.53 % 15x
High Max 68.18 % 7x
Extra 68.23 % 10x
Extra Max 67.77 % 4x
MAC fast 73.57 % --
MAC normal 71.54 % --
MAC high 69.59 % --
MAC extra h. 66.79 % --
MAC insane 65.83 % --
LA normal 65,24 % --
LA high 64.97 % --
OptimFrog 64.53 % --
(--maximumcompression --experimental --seek min)
WV -f 75.10 % --
WV 74.31 % --
WV -h 74.43 % --
WV -hh 72.59 % --
WV -hhx3 72.50 % --
Flac -0 76.57 % --
Flac -3 75.52 % --
Flac -5 74.70 % --
Flac -8 74.02 % --
Flake -5 74.69 % --
Flake -8 74.10 % --
Flake -12 72.51 % --
Hardware: Celeron 1.7GHz (L2 cache of 128KB)
512mb DDR-133
Seagate 7200.7 80GB IDE
Mode Compression Speed
Turbo 72.42 % 55x
Turbo Max 71.78 % 21x
Fast 70.96 % 38x
Fast Max 70.41 % 16x
Normal 69.39 % 24x
Normal Max 69.19 % 11x
High 68.53 % 15x
High Max 68.18 % 7x
Extra 68.23 % 10x
Extra Max 67.77 % 4x
MAC fast 73.57 % --
MAC normal 71.54 % --
MAC high 69.59 % --
MAC extra h. 66.79 % --
MAC insane 65.83 % --
LA normal 65,24 % --
LA high 64.97 % --
OptimFrog 64.53 % --
(--maximumcompression --experimental --seek min)
WV -f 75.10 % --
WV 74.31 % --
WV -h 74.43 % --
WV -hh 72.59 % --
WV -hhx3 72.50 % --
Flac -0 76.57 % --
Flac -3 75.52 % --
Flac -5 74.70 % --
Flac -8 74.02 % --
Flake -5 74.69 % --
Flake -8 74.10 % --
Flake -12 72.51 % --
Hardware: Celeron 1.7GHz (L2 cache of 128KB)
512mb DDR-133
Seagate 7200.7 80GB IDE
The compression delta for TAK is 4.65 %, wich seems very high for TAK. And the compression delta between Flac -0 and this extreme mode in OptimFrog is 12.04 %. Flac is the "left zero", with an delta of only 2.55, but Flake got the trick somewere beteween -8 and -12.
Another thing intersting in this file is the "max" swich in TAK. Here the gains in compression with max for each preset:
CODE
Turbo Max over Turbo 0.64 %
Fast Max over Fast 0.55 %
Normal Max over Normal 0.20 %
High Max over High 0.35 %
Extra Max over Extra 0.46 %
Fast Max over Fast 0.55 %
Normal Max over Normal 0.20 %
High Max over High 0.35 %
Extra Max over Extra 0.46 %
It increases after "normal"! The High Max compress beter than extra simple!
I've upload this file sometime ago, as an SBR killer. You can get it here: http://www.hydrogenaudio.org/forums/index....533;entry363343
QUOTE (TrNSZ @ Jan 6 2007, 07:29)
A hybrid mode in the future would be quite a feat.
I am not sure, if this will happen... Very early versions contained something similar, but i wasn't too interested into it.
QUOTE (TrNSZ @ Jan 6 2007, 07:29)
TBeck, have you looked into FreePascal to see about producing a DLL that might be able to be wrapped up with a foobar2000 decoder component?
Thank you, but it's no problem to create DLL's with my current Delphi compiler.
QUOTE (Caroliano @ Jan 6 2007, 15:09)
Ok, tak doesn't suport unicode yet. I tried an music with japanese characters in it's name and it don't
Definitely not...
QUOTE (Caroliano @ Jan 6 2007, 15:09)
Note the typo in the "Allready exists". It shoud have only one L.
Oh, it wasn't a typo... I thought, it was right. About a week ago one tester told me about my misconception, but i forgot to correct the source. Thanks for reminding me!
QUOTE (Mark0 @ Jan 6 2007, 16:02)
I have just created a new def for TrID to recognize TAK compressed audio files!
Great!
You found the secret String "tBaK"... I have to hide it better the next time...
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.