Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Optimized TTA Encoder (Read 9474 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Optimized TTA Encoder

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.

Optimized TTA Encoder

Reply #1
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.


Optimized TTA Encoder

Reply #3
@ 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.


 

Optimized TTA Encoder

Reply #6
@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

Optimized TTA Encoder

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



The conclusion is about the same.

Optimized TTA Encoder

Reply #8
I'd really like other people to check if they can reproduce my result...


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.

Optimized TTA Encoder

Reply #9

I'd really like other people to check if they can reproduce my result...


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.


Thank you very much.

Quote
On a PIII I got corrupted files.


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)