Hydrogenaudio Forums

Lossless Audio Compression => Lossless / Other Codecs => Topic started by: TBeck on 2007-01-04 03:23:35

Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-04 03:23:35
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 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=51787&view=findpost&p=463517)
Title: TAK 1.0 - Beta testing
Post by: Gnerma on 2007-01-04 05:24:14
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.
Title: TAK 1.0 - Beta testing
Post by: Synthetic Soul on 2007-01-04 06:38:52
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 (http://www.synthetic-soul.co.uk/files/tag_2.0.49.zip) 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: [Select]
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 (http://wiki.hydrogenaudio.org/index.php?title=Wapet).  Take a look at the EAC and Monkey's Audio (http://wiki.hydrogenaudio.org/index.php?title=EAC_and_Monkeys_Audio) guide in the wiki for the general idea.

Remember to swap ".ape" with ".tak", and use a command line like:

Code: [Select]
%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
Title: TAK 1.0 - Beta testing
Post by: pest on 2007-01-04 10:04:03
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 (http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Samples/Perverse/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
Title: TAK 1.0 - Beta testing
Post by: foosion on 2007-01-04 12:12:00
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 (http://foosion.foobar2000.org/0.9/foo_input_tak-0.0_20070104.zip)
Source code (http://foosion.foobar2000.org/0.9/foo_input_tak-0.0_20070104-src.zip)

If the above links don't work, please check my components page (http://foosion.foobar2000.org/0.9/) or this thread (http://www.hydrogenaudio.org/forums/index.php?showtopic=51584).
Title: TAK 1.0 - Beta testing
Post by: fairway on 2007-01-04 12:35:26
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.
Title: TAK 1.0 - Beta testing
Post by: Synthetic Soul on 2007-01-04 12:58:58
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.
Title: TAK 1.0 - Beta testing
Post by: smack on 2007-01-04 13:09:39
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 (http://www.hydrogenaudio.org/forums/index.php?showforum=19). Just run a search for YALAC or TAK.
You'll also find lots of benchmark results and comparisons to other codecs there.
Title: TAK 1.0 - Beta testing
Post by: fairway on 2007-01-04 13:14:54
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
Title: TAK 1.0 - Beta testing
Post by: Synthetic Soul on 2007-01-04 13:52:49
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?

There are  several threads about the development of this new codec in the Lossless / Other Codecs forum (http://index.php?showforum=19). 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 (http://www.synthetic-soul.co.uk/comparison/lossless/), which includes TAK alpha 0.14, FLAC 1.1.3, WavPack 4.40, and Monkey's Audio 3.99.
Title: TAK 1.0 - Beta testing
Post by: Caroliano on 2007-01-04 16:05:30
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.
Title: TAK 1.0 - Beta testing
Post by: madorangepanda on 2007-01-04 17:08:58
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/
Title: TAK 1.0 - Beta testing
Post by: Synthetic Soul on 2007-01-04 17:39:24
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.
Title: TAK 1.0 - Beta testing
Post by: madorangepanda on 2007-01-04 17:47:02
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.

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.
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-04 18:04:36
...
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.

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 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=51590&view=findpost&p=461826)
Title: TAK 1.0 - Beta testing
Post by: Caroliano on 2007-01-04 19:45:40
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!
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-04 20:27:03
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.


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.



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!
Title: TAK 1.0 - Beta testing
Post by: Caroliano on 2007-01-04 20:43:05
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.

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.
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-04 20:59:15
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.

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

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.

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!
Title: TAK 1.0 - Beta testing
Post by: Caroliano on 2007-01-04 21:01:19
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...
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-04 21:13:56
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.

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

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.
Title: TAK 1.0 - Beta testing
Post by: Caroliano on 2007-01-04 21:41:08
E-mail sent. Probably the silence problem.
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-04 21:53:20
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... 
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-04 22:14:57
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...

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.
Title: TAK 1.0 - Beta testing
Post by: Caroliano on 2007-01-04 22:17:22
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... 

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.
Title: TAK 1.0 - Beta testing
Post by: Gnerma on 2007-01-04 22:26:39
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.

Code: [Select]
       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


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).
Title: TAK 1.0 - Beta testing
Post by: madorangepanda on 2007-01-04 22:40:23
Thank you for the Damage Tool and the explanation as to why removing the header/footer causes a problem with the current decoder.
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-04 22:58:15
...
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.

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!

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.
Title: TAK 1.0 - Beta testing
Post by: Caroliano on 2007-01-04 23:00:40
@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.   
Quote
Fixed!
[...]
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.
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-04 23:15:49
Quote
Fixed!
[...]
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.

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.
Title: TAK 1.0 - Beta testing
Post by: Caroliano on 2007-01-04 23:37:08
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.
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-05 12:30:02
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.
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-05 13:41:58
Edit:  I have updated Tag to recognise TAK files (so you don't have to specify --ape2 --nocheck).  Download 2.0.49 (http://www.synthetic-soul.co.uk/files/tag_2.0.49.zip) if you want to tag using Case's Tag.  NB: 2.0.48 was a "silent" release that updated to libFLAC 1.1.3.

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.

Thank you very much for making Tak more usable!

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.
Title: TAK 1.0 - Beta testing
Post by: shnutils on 2007-01-05 16:12:50
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?
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-05 16:28: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.
Title: TAK 1.0 - Beta testing
Post by: Synthetic Soul on 2007-01-05 16:37:15
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.php?showtopic=43160)
http://www.hydrogenaudio.org/forums/index....showtopic=41287 (http://www.hydrogenaudio.org/forums/index.php?showtopic=41287)

Definately worth taking the time to ensure that foobar can easily pipe to TAKC.EXE.
Title: TAK 1.0 - Beta testing
Post by: jido on 2007-01-05 16:45:54
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.
Title: TAK 1.0 - Beta testing
Post by: shnutils on 2007-01-05 17:21:59
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: [Select]
C:\shnutils>takc -d test.tak CON
test.tak                            .......... Error writing destination

1 files with read/write errors.


Code: [Select]
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.


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! 
Title: TAK 1.0 - Beta testing
Post by: Caroliano on 2007-01-05 18:45:11
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: [Select]
--- 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
Title: TAK 1.0 - Beta testing
Post by: johnsonlam on 2007-01-05 18:47:12
TAK 1.0 Beta 1

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.
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-05 19:17:05
Well, even reading the read-me I don't understand perfeclty this error log. Here it is:
Code: [Select]
--- 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

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...
Title: TAK 1.0 - Beta testing
Post by: Caroliano on 2007-01-05 20:58:33
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:

Code: [Select]
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.


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).
Title: TAK 1.0 - Beta testing
Post by: TrNSZ on 2007-01-06 03:49:38
[deleted]
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-06 04:52:23
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: [Select]
                    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


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...
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-06 05:10:30
And now some compression results:
...

Thank you! Seems to be a Tak-friendly test set. There may be more of them than i expected...

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...
Title: TAK 1.0 - Beta testing
Post by: TrNSZ on 2007-01-06 06:29:20
[deleted]
Title: TAK 1.0 - Beta testing
Post by: Caroliano on 2007-01-06 14:09:52
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.
Title: TAK 1.0 - Beta testing
Post by: Mark0 on 2007-01-06 15:02:21
I have just created a new def for TrID (http://mark0.net/onlinetrid.aspx) to recognize TAK compressed audio files!

Bye!
Title: TAK 1.0 - Beta testing
Post by: Caroliano on 2007-01-06 15:24:43
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:

Code: [Select]
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

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: [Select]
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 %

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 (http://www.hydrogenaudio.org/forums/index.php?showtopic=41248&st=0&p=363343�entry363343)
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-06 16:08:02
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.

TBeck, have you looked into FreePascal (http://www.freepascal.org/) 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.

Ok, tak doesn't suport unicode yet. I tried an music with japanese characters in it's name and it don't

Definitely not...

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!

I have just created a new def for TrID (http://mark0.net/onlinetrid.aspx) to recognize TAK compressed audio files!

Great!

You found the secret String "tBaK"... I have to hide it better the next time...
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-06 16:44:25
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:

Very interesting file! I have downloaded it and played with it.

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.

Usually there are 2 possible reasons for such a big delta:

1) The file likes the PreFilter.
2) The file likes many predictors.

This time the answer is 2).

Another thing intersting in this file is the "max" swich in TAK. Here the gains in compression with max for each preset:

Code: [Select]
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 %

It increases after "normal"! The High Max compress beter than extra simple!

You are right: Usually the "max" switch isn't doing much for presets higher than FAST, because starting with NORMAL most of the options "max" could add are already part of the presets default setting.

The option "Frame partition calculator - Validate" is slow and quite useless (on average less than 0.05 percent advantage) most of the time. But it can help some problem files (especially with high predictor orders) and this is one of them:

Extra + Max: 67.77
Extra + Max without Validate: 68.16
Difference: 0.39

There are some more hidden options in TAK, which can help rare problem files. Currently they are disabled, because they are very slow and on average have as little effect on compression as Validate.

Thanks for providing such an interesting sample for my test corpus! It can help me with further optimizations.
Title: TAK 1.0 - Beta testing
Post by: johnsonlam on 2007-01-06 16:50:41
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...


Thank you very much to keep this! The high speed and low CPU usage is very suitable for video capture.
Looking forward to TAK access via ACM or DirectShow!
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-06 17:07:51
There are some more hidden options in TAK, which can help rare problem files. Currently they are disabled, because they are very slow and on average have as little effect on compression as Validate.

Just tried some of the hidden options: About 0.20 percent better compression, but 2.5 times slower encoding.

Well, there is room for some more encoder optimizations (without breaking the current design and compatibility) in the future, but don't expect too much. Maybe 0.15 to 0.30 percent on average and only with a heavy speed penality for encoding.
Title: TAK 1.0 - Beta testing
Post by: SokilOff on 2007-01-06 17:28:08
Well, there is room for some more encoder optimizations (without breaking the current design and compatibility) in the future, but don't expect too much. Maybe 0.15 to 0.30 percent on average and only with a heavy speed penality for encoding.

Compression improvement from 0.2 to 0.3 percent is enough to beat MAC Extra high (or at least to be on par), so it sounds very promising anyway. Encoding speed penalty isn't a big problem in this case until decoding still much faster than MAC.
Title: TAK 1.0 - Beta testing
Post by: Caroliano on 2007-01-06 17:31:50
I found a file that benefits from prefilter, but only from "fast" and up. It is from an 448kbps AC3 track of a DVD. I'm omiting the normal and high modes as they behave in the same way as fast and extra in all the situations I tested.

Code: [Select]
prefilter-test.wav 

TAK and diferent presets and prefilters strenghts

Mode             Compression     Speed

Turbo + off        40.15 %        45x
Turbo + low        40.20 %        35x
Turbo + medium     40.31 %        35x
Turbo + high       40.38 %        35x

fast + off         39.95 %        35x
fast + low         37.83 %        26x
fast + medium      37.83 %        25x
fast + high        37.83 %        25x

extra + off        39.77 %        12x
extra + low        37.33 %        10x
extra + medium     37.33 %        10x
extra + high       37.33 %        10x

If I re-encode to vorbis q4, the benefits of pre-filter grows a little for all presets, except turbo, where the compression hurt is even higher.

If I re-encode to vorbis q-2 (~32kbps) turbo starts to get benefits, but not much, and in an strange patern:
Code: [Select]
Mode             Compression     

Turbo + off        37.45 %      
Turbo + low        37.28 %      
Turbo + medium     37.31 %      
Turbo + high       37.30 %      

fast + off         37.12 %      
fast + low         34.83 %        
fast + medium      34.83 %  
fast + high        34.83 %      

extra + off        36.12 %      
extra + low        34.15 %      
extra + medium     34.15 %      
extra + high       34.15 %

If I re-encode (it is geting a bit repetitive, isn't?) to Winamp's AACv2 32kbps, the figure is totaly diferent. Now Turbo gains a little with prefilter, and all other presets loose compression:
Code: [Select]
Mode             Compression     

Turbo + off        37.42 %      
Turbo + low        37.29 %      
Turbo + medium     37.30 %      
Turbo + high       37.33 %      

fast + off         36.83 %      
fast + low         37.16 %        
fast + medium      37.29 %  
fast + high        37.32 %      

extra + off        36.64 %      
extra + low        36.88 %      
extra + medium     37.00 %      
extra + high       37.00 %

Now we have an extra mode that compress by defaut worse than the fast mode.     

I can send it to you if you want. It is only 23 seconds long, and I'm keeping the vorbis and AAC compressed ones. May help you tune the prefilter, or even understand it better.
Title: TAK 1.0 - Beta testing
Post by: Caroliano on 2007-01-06 17:55:06
Quote
You found the secret String "tBaK"... I have to hide it better the next time...

I also saw this sometime ago, when cutting the files... it isn't very secret... what is the great deal?
Quote
2) The file likes many predictors.

This time the answer is 2).

Indeed. The ground breaking change from Flake -8 to Flake -12 shoud be the increased prediction order from 12 to 32. Maybe the same thing between the wavepack's hardware capable -h and the non hardware capable -hh. But that brings a question: is TAK turbo, fast and normal modes hardware capable, even with such high predictors number?
Quote
Well, there is room for some more encoder optimizations (without breaking the current design and compatibility) in the future, but don't expect too much. Maybe 0.15 to 0.30 percent on average and only with a heavy speed penality for encoding.

That is still good. When compressing those 30s samples for upload, or if you have an quad quad-core K8L system (AMD showed one of those one month ago...) with an future multithreaded version of TAK, encoding speed isn't a problem.

By the way, my feature request list, in the order of importance to me:

- Unicode Suport
- DirectShow filter
- GStreamer plugin
- Matroska embedding (I'm not sure if this is the correct word)
- Multitreading (for dualcores and quadcores at least)
- More compression!
- Native suport for TAK to TAK transcoding
- ACM filter

I don't know if all them are possible, and I know that some of them are very tricky, especialy the unicode... windows vs rest-of-the-world problems, developer system problems (you are in windows 98, isn't?), etc. So you can put it in your TODO list in any order you want. And I don't listed the other things that are even more important, but already are in your TODO list.
Title: TAK 1.0 - Beta testing
Post by: ...Just Elliott on 2007-01-06 18:01:00
I'll test with either a Mac binary (linux i guess is ok too) or source... but Windows = nope, can't, sorry
Title: TAK 1.0 - Beta testing
Post by: Mark0 on 2007-01-06 18:08:46
Quote
You found the secret String "tBaK"... I have to hide it better the next time...

I also saw this sometime ago, when cutting the files... it isn't very secret... what is the great deal?

I think he was just a bit ironic!
Not a big deal, indeed; I just tought it would have be nice to add TAK to the other various  filetypes that can be identified.

Bye!
Title: TAK 1.0 - Beta testing
Post by: Caroliano on 2007-01-06 18:20:38

Quote
You found the secret String "tBaK"... I have to hide it better the next time...

I also saw this sometime ago, when cutting the files... it isn't very secret... what is the great deal?

I think he was just a bit ironic!
Not a big deal, indeed; I just tought it would have be nice to add TAK to the other various  filetypes that can be identified.

Bye!

Yeah... I thought so... but curiosity was bigger. 
Title: TAK 1.0 - Beta testing
Post by: Caroliano on 2007-01-06 21:32:10
Here a file that benefits a lot from the prefilter. Up to 4.30% in turbo, down to 4.15% in extra. It is from an 192kbps MP2 layer II file.

No significant anomalities in this one. Only an loose of 0.01% in fast on "medium" and "high" settings.

Code: [Select]
prefilter friendly.wav

Mode             Compression    

Turbo + off        66.17 %      
Turbo + low        61.88 %      
Turbo + medium     61.88 %      
Turbo + high       61.87 %      
Turbo Max          65.25 %

fast + off         65.41 %      
fast + low         61.20 %        
fast + medium      61.21 %  
fast + high        61.21 %      
fast max           64.69 %

normal + off       65.11 %      
normal + low       60.90 %        
normal + medium    60.90 %  
normal + high      60.90 %      
normal max         64.53 %

high + off         64.96 %      
high + low         60.81 %        
high + medium      60.81 %  
high + high        60.81 %      
high max           60.46 %

extra + off        64.92 %      
extra + low        60.77 %      
extra + medium     60.77 %      
extra + high       60.77 %
extra max          60.44 %

MAC fast           70.60 %
MAC normal         63.87 %
MAC extra high     59.12 %

The Max also helps a lot. 0.93% in turbo, 0.88 in normal, 0.33 in extra.

When re-encoding to vorbis q2 (96kbps) no strange things also:
Code: [Select]
prefilter friendly vorbis q2.wav
Mode             Compression    

Turbo + off        64.08 %      
Turbo + low        62.27 %      
Turbo + medium     62.21 %      
Turbo + high       62.19 %      
Turbo Max          63.26 %

fast + off         63.79 %      
fast + low         60.31 %        
fast + medium      60.31 %  
fast + high        60.31 %      
fast max           62.97 %

normal + off       63.16 %      
normal + low       59.92 %        
normal + medium    59.92 %  
normal + high      59.92 %      
normal max         62.64 %

high + off         62.89 %      
high + low         59.77 %        
high + medium      59.77 %  
high + high        59.77 %      
high max           59.43 %

extra + off        62.79 %      
extra + low        59.69 %      
extra + medium     59.69 %      
extra + high       59.69 %
extra max          59.40 %

MAC fast           69.26 %
MAC normal         62.14 %
MAC extra high     56.88 %

The tread is about TAK, but the compression delta of MAC in this file is impressive. The compression level at extra high also is so. If weren't for the prefilter...

I didn't compressed at lower bitrates because anything under this sounds horrible. Probably because it is an relatively low bitrate transcoding...

The files are also avaliable on request.
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-06 22:22:40
Quote
You found the secret String "tBaK"... I have to hide it better the next time...

I also saw this sometime ago, when cutting the files... it isn't very secret... what is the great deal?
Quote
2) The file likes many predictors.

This time the answer is 2).

Indeed. The ground breaking change from Flake -8 to Flake -12 shoud be the increased prediction order from 12 to 32. Maybe the same thing between the wavepack's hardware capable -h and the non hardware capable -hh. But that brings a question: is TAK turbo, fast and normal modes hardware capable, even with such high predictors number?

Turbo is using up to 16, Fast up to 32 predictors (like flake -12). I don't know, how many hardware players are fast enough for this.

Prefilter

I found a file that benefits from prefilter, but only from "fast" and up. It is from an 448kbps AC3 track of a DVD. I'm omiting the normal and high modes as they behave in the same way as fast and extra in all the situations I tested.
...
If I re-encode to vorbis q4, the benefits of pre-filter grows a little for all presets, except turbo, where the compression hurt is even higher.
...
If I re-encode to vorbis q-2 (~32kbps) turbo starts to get benefits, but not much, and in an strange patern:
...
If I re-encode (it is geting a bit repetitive, isn't?) to Winamp's AACv2 32kbps, the figure is totaly diferent. Now Turbo gains a little with prefilter, and all other presets loose compression:
...
Now we have an extra mode that compress by defaut worse than the fast mode.     
...
I can send it to you if you want. It is only 23 seconds long, and I'm keeping the vorbis and AAC compressed ones. May help you tune the prefilter, or even understand it better.

Here a file that benefits a lot from the prefilter. Up to 4.30% in turbo, down to 4.15% in extra. It is from an 192kbps MP2 layer II file.
...


I really appreciate your work! But to be honest, for me it does not make much sense to check the (lossless) compressability of lossy encoded files.

A bit of the PreFilter history can be found in the Yalac evaluation thread. Summary:

1) The PreFilter sigificantly affects the decompression speed.
2) The PreFilter is usually more efficient on files which like higher predictor orders.
3) On average it's advantage lies in the range of 0.1 to 0.3 percent, sometimes up to 1 percent.
4) Lossy encoded files can benefit tremendously from the PreFilter. I have seen 2 to 6 percent better compression.
5) I could improve the PreFilter efficiency for lossy files further, but what is it worth?
6) Not all lossy compressed files are benefiting from the PreFilter, it depends on the encoder and it's parameters.

Because of the decoding speed penality i earlier thought about dropping the PreFilter. One reason why i haven't:

Mpeg4Als - 7 is quite efficient in compressing this lossy encoded kind of files. Here it can be up to 2 percent better than Tak, while it usually isn't more than about 0.3 percent better.

It's possible, that someone publishes comparisons of lossless compressors based on evaluations of lossy encoded file! This shouldn't happen but it does. I simply don't want Tak to look bad in such (quite useless) evaluations. One important reason for keeping the PreFilter.
Title: TAK 1.0 - Beta testing
Post by: Caroliano on 2007-01-06 23:44:51
Quote
I really appreciate your work! But to be honest, for me it does not make much sense to check the (lossless) compressability of lossy encoded files.

I've read in the read-me that the prefilter is good for lossy files, so I selected some to test. It realy isn't very meaningfull. I've only losslessly compressed an lossy file one time before, and wasn't for archieve purposes...

Some reasons for losslessly recompress lossy files:
1)  You want to convert an rare or proprietary format without loss of quality in something you can use. May be because you can't hear it in another OS (ie: Linux, FreeBSD...) or in an hardware player.
2) You want all your colection in only one format.
3) You don't know it was lossy compressed before.
4) You decoded it to wave for whatever reason and deleted the source by accident (prefilter testing anyone? =P). Don't want to loose quality again because of this.
5) You is crazy, or don't understand audio compression.   

This is all that I can think. It don't need much atention... there are many more important things to do. May be in future when you are bored...   
Title: TAK 1.0 - Beta testing
Post by: gib on 2007-01-07 01:20:43
Though more compression results aren't super important, I decided to do a few myself.  I wanted to compare flac -6 (what I currently use) against tak -p3 for a few different albums.  I did not bother to list decoding speeds since both flac -6 and tak -p3 were blazing fast to decode - about 90x.  For reference, this test was done on an Athlon64 3400+ running Win2000. 
Code: [Select]
Album:  Sarah McLachlan - Solace
Style of music:  Quieter stuff, and it's a bit older so it's mastered much lower than albums today.
       Mode        Size       Encoding Rate
Original Image:   486 MB          n/a
Flac -6:          262 MB          50x
Tak -p3:          246 MB          34x


Album:  Green Day - American Idiot
Style of music:  Harder rock, mastered very loudly and compressed.
       Mode        Size       Encoding Rate
Original Image:   578 MB          n/a
Flac -6:          415 MB          41x
Tak -p3:          407 MB          34.5x


Album:  Techmaster P.E.B. - Bass Computer
Sytle of music:  Bass music.  Virtually no vocals, all electronic with LOTS of low frequency content.  Well mastered.
       Mode        Size       Encoding Rate
Original Image:   624 MB          n/a
Flac -6:          351 MB          46x
Tak -p3:          331 MB          35.5x


Fun results.  Flac -6 has tak -p3 beat in encoding speed, though encoding at 35x like Tak -p3 does on my computer is still very fast.  But in terms of compression, tak -p3 absolutely destroys flac -6, and tak seems to do especially well on material that has not been mastered super loudly.  Cutting 16 MB off the Sarah McLachlan album is outstanding!

Lastly, I really want to say thank you to TBeck and all the alpha testers for working on this codec.  I remember long ago when TBeck first posted about his lossless codec and I was excited that I was going to be able to follow along as it developed.  This first public release is certainly a major milestone.  Congratulations, and thanks.
Title: TAK 1.0 - Beta testing
Post by: Synthetic Soul on 2007-01-07 08:24:41
According to my comparison TAK Normal only compresses 0.2% less than High, but encodes faster than FLAC -6 - about the same speed as FLAC -5.

Code: [Select]
Encoder Setting    Compression    Encode Rate    Decode Rate
============================================================
TAK Normal             63.875%            40x            83x
FLAC -5                65.926%            38x            79x
TAK Turbo Max          64.520%            36x            83x
FLAC -6                65.881%            34x            79x
TAK High               63.684%            27x            76x
Title: TAK 1.0 - Beta testing
Post by: madorangepanda on 2007-01-07 15:07:05
Is there an easy way I can locate the frame headers within a TAK file using a hex editor or such? More importantly is there an easy way I can locate the checksums within the headers(and at the start of the file) I'm going to try and get a bit more crafty with my damage tests as so far every error gets reported correctly.
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-07 16:02:29
Some reasons for losslessly recompress lossy files:
...

Very creative! I agree, there can be reasons for compressing lossy files.

Fun results.  Flac -6 has tak -p3 beat in encoding speed, though encoding at 35x like Tak -p3 does on my computer is still very fast.  But in terms of compression, tak -p3 absolutely destroys flac -6, and tak seems to do especially well on material that has not been mastered super loudly.  Cutting 16 MB off the Sarah McLachlan album is outstanding!
...
Lastly, I really want to say thank you to TBeck and all the alpha testers for working on this codec.  I remember long ago when TBeck first posted about his lossless codec and I was excited that I was going to be able to follow along as it developed.  This first public release is certainly a major milestone.  Congratulations, and thanks.

Thank you! Indeed Tak isn't as good in compressing loud and (dynamic wise) compressed material.

Is there an easy way I can locate the frame headers within a TAK file using a hex editor or such? More importantly is there an easy way I can locate the checksums within the headers(and at the start of the file) I'm going to try and get a bit more crafty with my damage tests as so far every error gets reported correctly.

Each frame header starts with a 16 bit sync code (byte aligned):

0A0FFh =  41215 (decimal)  = 10100000.11111111 (bits)

I wrote a littel tool to find the pattern with the lowest probability (1 to about 80,000) and this came out.

Nevertheless this pattern is also likely to be found in the audio data.

For the checksums: There are two per frame: One 24 bit CRC following the frame header to protect the header and to make the identification of headers (avoid false alarm caused by sync code only) more safe.

Next comes the compressed audio data and then (byte aligned) another 24 bit CRC to protect the audio data.

Illustration:
Code: [Select]
[Frame header]  [Frame data]  [Frame header]  [Frame data]

Frame header is:

[Sync code - Header data - CRC]

Frame data is:

[Audio data - CRC]


Hope this helps.
Title: TAK 1.0 - Beta testing
Post by: gib on 2007-01-07 23:07:11
According to my comparison TAK Normal only compresses 0.2% less than High, but encodes faster than FLAC -6 - about the same speed as FLAC -5.

Good point, Synthetic Soul.  Personally I like as much compression as possible while mantaining good speeds.  That's why I use flac -6 rather than -7 or -8.  At this point, with tak -p3 going at about 35x on my computer, I'd be more than happy with that speed, I think. 

Anyway, I have looked at your website and the extensive lossless tests you've done.  While tak was in alpha, it was a key source of information for me.  But now that tak is in public beta, I couldn't resist doing a few quick tests of my own. 
Title: TAK 1.0 - Beta testing
Post by: GeSomeone on 2007-01-08 17:18:06
Some reasons for losslessly recompress lossy files:
...
Very creative! I agree, there can be reasons for compressing lossy files.

But of course none of them are a valid reason to optimize lossless compression for it.
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-08 17:44:48
Last chance to report bugs in Beta 1

I want to release the second (and hopefully final) beta soon. Please tell me, if you have found any bugs in beta 1 not contained in the list below:

Fixed:

- If the last 1 to 3 bytes of a (damaged) file had been cut off, the automatic repair function of the decoder crashed.

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.
- Now i know that i have to write "already exists" instead of "allready exists"...

  Thomas
Title: TAK 1.0 - Beta testing
Post by: madorangepanda on 2007-01-08 19:30:22
Other than the issue you have fixed I've been unable to make any unreported or undecodable errors.
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-11 02:54:29
Last chance to report bugs in Beta 1

I have found one by myself...

The Tak stream contains a seek table for fast random access to play positions. Because the seek table has not to be accessed for continuous decoding, it's integrity could not be checked. Therefore i implemented a new operation mode "Info" (-i), which outputs many details about the stream (Audio format, codec version, preset, meta data structures...) and additionally performs an exhaustive check of the seek table (it jumps to any file position contained in the seek table, decodes the frame header at this position and checks if it is the right one).

Unfortunately this new check revealed one small error which is now fixed. Files encoded with beta 1 are still decodable without any problems, but later player plugins will have trouble to use their seek table. Sorry, but that's beta testing.

The new info option will not be part of the first final release, because i don't want to apply bigger modifications to the allready well tested beta code. It will be included into the next public version.
Title: TAK 1.0 - Beta testing
Post by: Brydenn33 on 2007-01-11 07:48:49
Maybe I'm missing something but where is the decoder so I can actually play the files in Foobar2000?
Title: TAK 1.0 - Beta testing
Post by: Synthetic Soul on 2007-01-11 08:08:41
There is none, you cannot play TAK files at the moment.

This is beta1, simply for testing encoding and decoding to WAVE.
Title: TAK 1.0 - Beta testing
Post by: fairway on 2007-01-11 11:07:17
Last chance to report bugs in Beta 1

Perhaps you could include Tagging as well?
Title: TAK 1.0 - Beta testing
Post by: TrNSZ on 2007-01-11 17:11:57
[deleted]
Title: TAK 1.0 - Beta testing
Post by: Synthetic Soul on 2007-01-11 21:21:56
I've just downloaded Beta 2.

I've read the readme, but just wanted to clarify:  I assume that there is no point in running my timed comparison on this version?  I.e.: we are looking for bugs only.
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-11 21:28:35
V1.0 Beta 2 / 7-01-11

Fixed:

- If the last 1 to 3 bytes of a (damaged) file had been cut off, the automatic repair function of the decoder crashed.
- The seek table structure contained a small error. Files created with Beta 1 can still be decoded without any problems, but later media player plugins will not be able to perform (fast) seeking on files created with Beta 1.

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.
- Now i know that i have to write "already exists" instead of "allready exists"...

Download...

...from the Upload section: TAK 1.0 Beta 2 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=51787&view=findpost&p=463517)

What should be tested?

Please try it and report any bugs you encounter.

I am confident, that this version is quite bug free and stable. If i am right, we will see the final release in 1 or 2 weeks.

Again, thanks for testing!


Could one of the Mod's please remove the beta 1 post from the Upload section?





I've just downloaded Beta 2.

I've read the readme, but just wanted to clarify:  I assume that there is no point in running my timed comparison on this version?  I.e.: we are looking for bugs only.

You are right. There were only bug fixes.

  Thomas
Title: TAK 1.0 - Beta testing
Post by: fairway on 2007-01-11 21:38:31

I've just downloaded Beta 2.

I've read the readme, but just wanted to clarify:  I assume that there is no point in running my timed comparison on this version?  I.e.: we are looking for bugs only.

You are right. There were only bug fixes.

  Thomas

how far are we from a TAK DLL to use in winamp, foobar2000 to playback files?
Title: TAK 1.0 - Beta testing
Post by: Synthetic Soul on 2007-01-11 22:07:24
Could one of the Mod's please remove the beta 1 post from the Upload section?
I have kept the thread (http://www.hydrogenaudio.org/forums/index.php?showtopic=51566), but closed it, and removed the link.

You are right. There were only bug fixes.
Thanks Thomas.
Title: TAK 1.0 - Beta testing
Post by: _io_ on 2007-01-12 18:56:47
OK, took me a while to dig out the username pw for this site as i'm usually just a lurker...

First of all i'd like to thank you for the sterling work your doing here. I can easily see tak becoming my new lossless codec of choice upon final release.

Seconding, and the main reason for the post, I thought I should post a bug in the command line program I just found....


Starting from the point of a single tak encoded file in a directory with no other tak or wav files.
If you issue the command:

================
Takc -d *
================

you get the following output:

================
01_Tubthumping.tak                  .......... Already exists

1 files already existed.
================

Which is obviously incorrect. (Note the wildcard command works fine if there is more than 1 file)

Of itself this is but a bug that is an annoyance, however when issuing the following command:


================
Takc -d -overwrite *
================

You get the same text output as above but the tak file is deleted which is most definately not what should happen....

Hope this will be of help.

{lurker mode engaged}

io
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-12 19:24:52
First of all i'd like to thank you for the sterling work your doing here. I can easily see tak becoming my new lossless codec of choice upon final release.

Fine!

Starting from the point of a single tak encoded file in a directory with no other tak or wav files.
If you issue the command:

================
Takc -d *
================

you get the following output:

================
01_Tubthumping.tak                  .......... Already exists

1 files already existed.
================

Too bad...

Of itself this is but a bug that is an annoyance, however when issuing the following command:


================
Takc -d -overwrite *
================

You get the same text output as above but the tak file is deleted which is most definately not what should happen....

Fatal!

I could reproduce the bug and it is fixed now.

You are right, this bug will only show up if decoding with wildcards and if the source directory contains only one matching file. Sorry.

When writing the file decompression management functions i used some code of the compressor as template for the decompressor, but unfortunately forgot to replace a destination file extension constant '.tak' with '.wav'...

Thank you very much!

  Thomas
Title: TAK 1.0 - Beta testing
Post by: A_Man_Eating_Duck on 2007-01-13 23:14:30
The compression of TAK is outstanding

Here is a list of full albums i encoded with all the presets of TAK and FLAC which roughly equals around 16gig s in wave files
Code: [Select]
 A - Hi-Fi Serious
 Bad Religion - Tested
 Ben Folds - Ben Folds Live
 Bic Runga - Birds
 Billy Talent - II
 Bob Mould - Bob Mould
 Breaking Benjamin - We Are Not Alone
 Cake - Comfort Eagle
 Chicago - Heart Of Chicago 1967 - 1997
 Counting Crows - August And Everything After
 Dave Dobbyn - The Islander
 Elliott Smith - XO
 Eminem - The Eminem Show
 Evanescence - Fallen
 Faith No More - Angel Dust
 Fatboy Slim - You've Come A Long Way, Baby
 Finger Eleven - Finger Eleven
 Foo Fighters - There Is Nothing Left To Lose
 Fun Lovin' Criminals - Come Find Yourself
 Gary Moore - Still Got The Blues
 Green Day - American Idiot
 Groove Armada - Lovebox
 Hoobastank - The Reason
 Husker Du - The Living End
 Iron Maiden - Rock In Rio Disc 1
 Jeff Wayne - The War Of The Worlds Disc 1
 Joe Satriani - The Extremist
 John Lennon - Imagine
 Lagwagon - Let's Talk About Feelings
 Linkin Park - Meteora
 Living Colour - Time's Up

And here are the overall results
(http://www.imagehosting.com/out.php/i125705_TAKvsFLAC.png)

So the Hard drive space savings is
(http://www.imagehosting.com/out.php/i125733_TAKvsFLACSize.png)
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-14 02:21:59
how far are we from a TAK DLL to use in winamp, foobar2000 to playback files?

I just started the work on a WinAmp playback plugin. But it will definitely not be part of V1.0 final.

A foobar plugin will have to wait until i have translated at least some high level functions of my code from delphi to C. Or alternatively until i have built a codec library (DLL), which other developers can use to build plugins.

The compression of TAK is outstanding

Here is a list of full albums i encoded with all the presets of TAK and FLAC which roughly equals around 16gig s in wave files
...
And here are the overall results
...

Thank you! It's also a great presentation!

Off topic: Nice to see this oldie: "Jeff Wayne - The War Of The Worlds Disc 1". I really liked it (i have always been a big fan of H.G. Well's story.).

  Thomas
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-15 08:28:33

how far are we from a TAK DLL to use in winamp, foobar2000 to playback files?

I just started the work on a WinAmp playback plugin. But it will definitely not be part of V1.0 final.

Well, not much sleep last night... But finally i was able to play Tak files with WinAmp! And as expected, it needs very very little cpu time.

But the plugin is only a quick and dirty approach to see, how easily it can be done with Delphi.

Because i currently have to spend more time on other things, it may take 4 to 6 weeks, until the plugin will be released.
Title: TAK 1.0 - Beta testing
Post by: $char(9836) on 2007-01-15 20:39:49
So long time, I can't wait to be able to use tak for my music  Though I need a fb2k plug-in
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-17 06:54:13
Well, not much sleep last night... But finally i was able to play Tak files with WinAmp! And as expected, it needs very very little cpu time.

Now the plugin can seek. On my Pentium 3 / 866 Mhz i can hardly notice any delay, even with the strongest compression settings!

I am quite happy, because fast seeking was always very important for me. I expected it to be fast, but you will not really know before you tried it.
Title: TAK 1.0 - Beta testing
Post by: fairway on 2007-01-17 20:57:19
Is there a chance to see TAK ever going open source?
Title: TAK 1.0 - Beta testing
Post by: Caroliano on 2007-01-17 22:13:06
Is there a chance to see TAK ever going open source?

See: TAK - Source code release and conversion (http://www.hydrogenaudio.org/forums/index.php?showtopic=51511)
Title: TAK 1.0 - Beta testing
Post by: foosion on 2007-01-17 23:17:50
I just started the work on a WinAmp playback plugin. But it will definitely not be part of V1.0 final.

A foobar plugin will have to wait until i have translated at least some high level functions of my code from delphi to C. Or alternatively until i have built a codec library (DLL), which other developers can use to build plugins.
Since you seem to know Delphi better than C, I guess it would be easier for you to build a DLL first (also faster and less error-prone probably). If you use that DLL in your Winamp plugin, you can get some first-hand experience how hard (or easy) it is to use.

Anyway, if you want any help to create a foobar2000 component or a decoder DLL that can be used (also) in a foobar2000 component, just ask.
Title: TAK 1.0 - Beta testing
Post by: audiofreak on 2007-01-18 02:05:43
Everything is working nice in this beta, great job! 

I wonder if you are considering writing a Rockbox plugin for sometime in the future, because I am sure that a lot of people would appreciate it, considering that it is the ideal portable lossless codec.

Keep it up,
audiofreak
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-18 02:22:39
Everything is working nice in this beta, great job! 

Thank you!
I wonder if you are considering writing a Rockbox plugin for sometime in the future, because I am sure that a lot of people would appreciate it, considering that it is the ideal portable lossless codec.

There is very much i would like to do with TAK and hardware support is very interesting. But unfortunately my time is limited. Therefore no promises...

Coming out with a new lossless codec now isn't easy. The allready existing codecs have been developed over years. Very much work if you want to have comparable feature sets. And TAK's development history is different from most other codecs: First came the exhaustive evaluation of possible speed and compression efficiency optimizations and then the work on usability features.
Title: TAK 1.0 - Beta testing
Post by: spockep on 2007-01-18 03:03:01
I just downloaded Beta2...and all I can say is awesome!!!!! 

Here are my first results using my old AMD 1.3ghz Thunderbird system: 


Code: [Select]
Marvin Hamlisch - The Spy Who Loved Me - 03 - Ride To Atlantis

Flac -8            45.7% Compression   41 Seconds  16.2mb
Tak Extra (p4)     42.85% Compression  23 Seconds  15.2mb



I am simply blown away!!  Thanks for the great work!!
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-18 04:29:01
I just started the work on a WinAmp playback plugin. But it will definitely not be part of V1.0 final.

A foobar plugin will have to wait until i have translated at least some high level functions of my code from delphi to C. Or alternatively until i have built a codec library (DLL), which other developers can use to build plugins.
Since you seem to know Delphi better than C, I guess it would be easier for you to build a DLL first (also faster and less error-prone probably). If you use that DLL in your Winamp plugin, you can get some first-hand experience how hard (or easy) it is to use.

I agree, a library is on the top of my to do list.

Anyway, if you want any help to create a foobar2000 component or a decoder DLL that can be used (also) in a foobar2000 component, just ask.

That's a great offer! Thank you.

For now i have only one question: Is the interface of the WavPack library a good example for how to do it (especially if you want to use it for foobar)? I like it and probably would build something similar.
Title: TAK 1.0 - Beta testing
Post by: foosion on 2007-01-18 14:02:25
I have never worked with the WavPack library, so I cannot judge that. About four years ago when I was writing a Shorten plugin for foobar2000 with a friend, the Monkey's Audio SDK was recommend to us as a good example for a library interface. We had decided to build our own Shorten decoding library as basis for this plugin, instead of going the usual way of twisting the Shorten command line decoder into an audio player plugin. (Everyone else seemed to have done that back then; at least everyone that had released source code. It was quite ugly.) So we modelled the interface of that library after the decoder part of the Monkey's audio library, and we haven't regretted that decision since.

While the Monkey's Audio SDK is written in C++, the key points still apply:
Hm, I thought that list would get longer. It probably would, if I added more details, but I'll refrain from that for now. As you might have noticed, my perspective is that of a foobar2000 component author, which means I only really care about the decoding interface. I hope it still provides some useful clues.
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-23 22:40:19
Last chance to report bugs in Beta 2

I want to release Tak 1.0 final soon. Please tell me, if you have found any bugs in beta 2 not contained in the list below:

Fixed:

- Decoding with the command line version: If you specified wildcards for the file selection and the source directory contained only 1 Tak file, the decoder always threw the message 'File already exists'. Even worse: Using the owerwrite option in this situation led to deletion of the compressed source file!

- Usually the decoder ignores any data appended to the file end of the compressed file (for instance APEv2 tags). But it failed, if the file size was an integer multiple of the frame size (in samples).

Both bugs affected only the decoder, therefore no need to reencode Tak files created with beta 2.

Thomas
Title: TAK 1.0 - Beta testing
Post by: Caroliano on 2007-01-24 19:42:50
I didn't found any new bugs so far. The "cut last byte" error was corrected.

But you didn't corrected the minor problems in the Tak_Enco_Proto: translation of the "nein" and "ja" to english, and erase the "SSE" report.
Title: TAK 1.0 - Beta testing
Post by: TBeck on 2007-01-24 23:10:59
But you didn't corrected the minor problems in the Tak_Enco_Proto: translation of the "nein" and "ja" to english, and erase the "SSE" report.

Guilty. I forgot the translations... The german words are included in one of my general purpose modules, which i did not want to touch, but instead replace with some new, more portable code. Not done yet...

I kept the SSE option, because i possibly will try some more SSE optimizations in the future.

Thank you!

  Thomas
Title: TAK 1.0 - Beta testing
Post by: Squeller on 2007-01-29 12:36:23
Does it support pipes or will I have to use "%s %d" in fb2k?
Title: TAK 1.0 - Beta testing
Post by: Synthetic Soul on 2007-01-29 12:41:40
No pipe support as yet, but planned.  Check the "Missing features" section of the readme.
SimplePortal 1.0.0 RC1 © 2008-2019