Hi,

I happened to have time to test this Optimized TTA encoder.

"Multiple Read and Write Buffer Solution (Intel Compiler Executable)"
http://softlab.technion.ac.il/project/opti...source_code.htm

Apologies if this was already mentioned before.

First off, apparently this optimized versioin doesn't work on a Non-HT/single-CPU machine. I got a broken file testing it on Win2K, non HT. The following result was obtained on WinXP SP2, HT, Prescott 3.4G, where I tested again and again that decoded WAV is identical to the Original WAV and I belive this tweaked ttaenc is working properly at least for this sample.



In my test, Optimized TTAenc is significantly faster than Normal TTAenc. And it is a little faster now than WavPack default, in encoding, with better compression. WavPack def is still faster in decoding.
On the other hand, WavPack -h gives me much better compression; it's slower, but I'd think 60~70 sec per CD is enough fast.

Anyway, if you use TTA for some reason, and you are on a HT or Dual-CPU machine, you might want to test this optimized TTAenc.

That´s very interesting. Too bad it will only work on HT or dual machines (I have neither)

Makes me wonder if running two wavpack instances on the HT machine wouldn´t speed it up somewhat, at least to get standard speed closer to the optimized TTA.

I have a HT machine and also access to several dual core machines - will do some tests at weekend.

Edit: Spelling.

@ Sebastian Mares
Thanks very much. I'd really like other people to check if they can reproduce my result, as the way I checked the time cost is by no means professional (I just copid the time cost reported by the app itself, which might be inaccurate). Actually that's why I couldn't include FLAC data. (flac.exe doesn't report the time cost.)

I'm wondering why encoding cost by normal ttaenc varies greatly each time I try it too.

http://www.microsoft.com/windows2000/techi.../timethis-o.asp

Enjoy!

Crapola, and I already coded something in VB using QueryPerformanceCounter...

@rjamorim
Thanks, I'll try it.

@Sebastian Mares
Yeah... That may be a good diea, altho, CreateProcess overhead is quite big compared to QueryPerformanceCounter accuracy, perhaps we can get at least ms accracy. maybe I'll code that later when I have an hour to kill

OK, this time I timed the cost down to microseconds, including FLAC.



The conclusion is about the same.

I performed a fast test session on that matter.

On a PIV with HT I got bit identical files, a 16% improvement in encoding speed and a 20% improvement in decoding speed.

On a PIII I got corrupted files.

I think that is more or less a confirmation for your results.

Thank you very much.



This part is really annoying. Probably this optimized encoder shouldn't be recommended to general users, as some of them would use it on PCs that are not supported and get broken files.

For the record I'm going to time encoding/decoding speed of optimized FLAC.exe vs optimized TTAenc.exe, as it is somehow unfair to compare this ttaenc with the normal FLAC.exe. I didn't have time to do that so far, but I alraedy made an accurate timing tool which will correct the time cost needed for timing itself. (I mean, "Timing" itself needs some CPU time)