- Depending on preset and cpu up to 10 percent faster encoding and decoding compared with V1.1.1. - Slightly faster encoding and decoding of LossyWav files. - Slightly faster encoding and decoding if MMX is disabled and the pure pascal code is beeing used. - Removed some more assembler routines and simplified a lot of code. The binaries are again smaller now.

Fixes:

- The new filter introduced in V1.1.1 revealed a bug in the encoder, which resulted in suboptimal performance especially when compressing LossyWav-files with the presets -p3 or -p4 (BTW: It doesn't make sense to go higher than -p2m when compressing LossyWav-files...).

Known issues:

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

v1.1.1 seemed to max out at 213x when encoding and 1.1.2 seemed to max out at around 111x or so. This was on a collection of 57 songs

I'm running Windows Vists Ultimate 64bit with an Intel i7 920 (@3.2GhZ) (if you need to know more i can tell you)

One thing i noticed was that was weird was while encoding some songs the encode rate would drop down to 50 to 70x then shoot back up on the next song. I don't know if this is normal or not, so i just wanted to mention it. Also, it wasn't the song that caused it, as one test it would encode at it's max speed then in another test it would slow down to 50x..

TAK 1.1.2

I did some tests out of curiosity.. and it seems like 1.1.2 is slower on my computer than 1.1.1 is!

Which settings did you use?

Quote

One thing i noticed was that was weird was while encoding some songs the encode rate would drop down to 50 to 70x then shoot back up on the next song. I don't know if this is normal or not, so i just wanted to mention it. Also, it wasn't the song that caused it, as one test it would encode at it's max speed then in another test it would slow down to 50x..

That sounds more like something in the background eating cycles, is my guess. I can't imagine that being normal behavior, usually the opposite. There's a few friend's machines I fixed where that was infested with malware, so it might be a good idea to check that since slow encoding is the least worrisome in that scenario.

v1.1.1 seemed to max out at 213x when encoding and 1.1.2 seemed to max out at around 111x or so. This was on a collection of 57 songs

I'm running Windows Vists Ultimate 64bit with an Intel i7 920 (@3.2GhZ) (if you need to know more i can tell you)

One thing i noticed was that was weird was while encoding some songs the encode rate would drop down to 50 to 70x then shoot back up on the next song. I don't know if this is normal or not, so i just wanted to mention it. Also, it wasn't the song that caused it, as one test it would encode at it's max speed then in another test it would slow down to 50x..

I did some tests out of curiosity.. and it seems like 1.1.2 is slower on my computer than 1.1.1 is!

Which settings did you use?

Quote

One thing i noticed was that was weird was while encoding some songs the encode rate would drop down to 50 to 70x then shoot back up on the next song. I don't know if this is normal or not, so i just wanted to mention it. Also, it wasn't the song that caused it, as one test it would encode at it's max speed then in another test it would slow down to 50x..

That sounds more like something in the background eating cycles, is my guess. I can't imagine that being normal behavior, usually the opposite. There's a few friend's machines I fixed where that was infested with malware, so it might be a good idea to check that since slow encoding is the least worrisome in that scenario.

A really good reply!

I want to add another possible explaination: TAK is using extremely optimized code in the filters, which may drive CPU's into areas, where the cooling isn't sufficient and they use clock-throttling.

It's on my todo list... But no promises: I am also working hard on the TAK 2.0 codec, and i am progressing faster than expected... I am not sure, if there will be a 1.1.3 release (with new functionality) before the 2.0 release. Possibly you will have to wait for 2.0.1...

TAK 1.1.2

I thought a few major players here in HA were affluent in your language, I'm trying to remember them by alias since they would be able to translate your technical terms correctly. And you are correct, people visiting your home page should have the professional prose that equates to the the professional program, if I must say.

Also, thanks for the excellent news about upcoming TAK releases. I, for one, will be eagerly awaiting.

TAK 1.1.2

I have been using TAK since its first final release (having switched to it from Monkey's Audio) and I must say that, while there are many other great (some even awesome) lossless codecs, I love TAK for its rich set of excellent features.

Alas, I must woefully confess that I have had to use WavPack lately. The trouble is TAK doesn't support multichannel audio so far. WavPack is a truly awesome codec, and I respect its developer as much as I do Thomas. Yet I prefer TAK for its speed/compression ratio, and since I always try to get the highest compression a codec offers, I do the same with WavPack using the following options: wavpack.exe -hh -m -x6 *.wav. Space is something always worth saving, and hi-rez multichannel audio certainly calls for that. It is, however, almost intolerable to wait for a file to take five to eight times longer to get compressed than its own length. (I say "almost" because I still tolerate this.)

Indeed, the WavPack help warns that using the -x[4-6] option is very slow, and it is my own choice to do so. Yet from the fact that TAK offers even better compression within a fraction of that time when tested on some 24-bit stereo files I infer (and truly hope) that the speed/compression ratio will be the same for multichannel audio when support for that is implemented.

TAK 1.1.2

Hi TBeck.It appears that tak_SSD_Create_FromFile can not handle unicode names. It would be nice if multibyte filenames could be used or a function that can accept widechar filenames was created.Thanks.