Stereo Tool

Exactly. You have previously stated that SSE3+ versions are showing no appreciable performance gain. My theory is that most of the performance increases you'll see moving up the processor generations are from improvements in L2 and L3 cache, along with memory bandwidth. With cores from both AMD and Intel having 2, 4, 6, or 8MB cache on-die, what you're likely seeing is the FFT running completely within the on-die cache and thus the CPU doesn't have to stall waiting on the I/O bus out to main memory. When it does have to go out to main memory, the newer architectures have faster main memory access.
Exactly. The difference in newer processors might not be as dramatically noticable as it is with mine, but eventually, it all adds up. If you just write everything as bloated as you can, adopting the policy of "so long as it works, I don't care about efficiency, because there's plenty of headroom", sooner or later that is going to catch up to you.
I understand that completely. I am looking at this from a different angle than you are, it would seem. It seems you're looking at only the raw change in CPU usage. I'm looking at that too, but weighted by the relative gain in audio fidelity. A doubling of load to get 5-10% increase in fidelity is not a good price-performance ratio.

Main problem is De-Clipper section for CPU usage.
De-Clipping itself is NEW tehnology, few weeks new tehnology. Old if you count "SeeDeClipp" software.. but there, even on my CPU (e8400@4,5GHz) i takes good time to convert just one track.
In ST processing even must be realtime. If you ask me this is REALLY big success of this filter! .. and it's unrealistic to expect to work on almost any single core CPU w/o glitch.

Even more CPU power will be needed in future for other filters, high/low-pass-filters, SSB, composite clippers .. etc..

"Dynamic booster" - After AGC. Or the possibility that there may be.

The issue is I wasn't talking about the declipping. I was talking about how the CPU load of the Dynamics Booster was way higher than what I felt it should've been. I guess I made the unforgivable mistake of mentioning the declipper along with the Dynamics Booster, talking about the CUMMULATIVE EFFECT of both of them...

Mea culpa... Can I pick my own sword to throw myself upon? Please? I'd really like that a lot...

Fortunately, Hans has stated that my observation about the increased load is likely to be temporary...and in any case, it's optional.

@Brian: Have a look at that: http://www.cpubenchmark.net/common_cpus.html

Now you can throw yourself into your sword. (just kidding).

I had initially typed up a response, but decided to go validate what I was thinking. My thought was my system would end up somewhere around the first two Pentium D entries. I downloaded the latest Performance Test from there, and, sure enough, the CPUMark score was 757.6. As I've said, I have one of the fastest single-core systems you'll find. Any faster, and they'd have to be liquid or phase-change cooled.

That said, all of you are COMPLETELY MISSING THE POINT!

You see this little smiley here:

It's called "Mr. Green".

You know what "being green" might entail?

Do you think it's a great thing for energy consumption to use as much power as possible to do a given task?

...or would you think it's a great thing to use only as much power as is necessary?

Just recently, the Advanced Extreme Highs Protection consumed way more CPU time than it needed. As such, my system, AND YOURS AS WELL consumed more power than it really needed to consume to complete the task.

If something can be done efficiently with the same results, then unless there is a significant burden of time and effort to make the process more efficient, then it should be done efficiently rather than non-efficiently.

So, my suggestion to you all is to look up "Wirth's Law". Here's a preview:

•Software is getting slower more rapidly than hardware becomes faster.

I really do understand that I can't have the best performance with full bells and whistles on older hardware. What you all are not understanding is that I'm talking about making sure that the code runs as efficiently as it can. The Advanced Extreme Highs filtering now uses a whole 1-3% more CPU than without it running. Previously, it used 40-50% more CPU. If every single piece of software out there in the world decided to be as inefficent, then we'd all need to be buying computers a lot more frequently. Not only that, but in this day and age when people are talking about reducing carbon footprints, then it would behoove software developers to make sure that their code is performing as efficiently as possible.

Now, I really dislike being a jerk, but I will not play nice if backed into a corner. I'd appreciate you all stop jumping on my case and look at what I'm saying. If you want to argue against efficiency, then I guess I will go ahead and be a jerk and say you're idiots.

About : True, and that's another very good reason to keep optimizing.

Still, for some users (for example those who operate a big FM station with hundreds of thousands of listeners), 5% increase in quality is A LOT, regardless of the costs. And to audiophiles too.
Based on that number, I'm actually surprised that you're having problems with the performance. My own Q9450 CPU is listed (I'll download the test to check) as about 4000, which is 1000 per core - so per core it's only 1/3rd faster than yours, and Stereo Tool does most of its processing on a single core.

(On the other hand, since Stereo Tool uses one core, on a multi-core system the effect of running Stereo Tool is almost unnoticeable because many applications also use only one core, and are hence not slowed down at all by Stereo Tool).
Try if you can still find Stereo Tool 1.0 somewhere... It used about 90% on my P4 at the time... And that was with only stereo image (no azimuth or stereo boost), 8-band multiband (without clippers, filtering the output and flat frequency response) and a singleband compressor.



By the way, about the FFT and multi-core: Intel itself says that FFT's of size 4096 and smaller are calculated on a single core because of the overhead of spreading the calculation over 2 cores. So that's why there's no gain in enabling the CoreDuo versions etc - the usage of SSE3 or SSE4 could have helped, but apparently it doesn't (The same is true if I compile Stereo Tool for SSE3/4, it's not faster than the SSE2 version. So I'll stick with that).

Ok, one last note from me to the cpu discussion, i´ll try to make it as understandable as i can with my broken english.

@Brian: You talking about inefficiency?
Here are my thoughts: I think Hans is optimize his code as well as he can, but code optimization which maybe could lasts several weeks - just to get at least 1% less cpu load (or something like that) - that is really inefficient, and i would say most of software developers thinking the same way. Sure, code optimization is important, but at some point it hits the border where it makes no sense anymore.

Hope you get it.

@Hans, what's the reason you place the dynamics booster before the AGC and not after it? It now depends a lot on the input level.

@eldoradofm: The reason for that is that if I place it after the AGC, it will strongly boost spikes that remain after the AGC. By putting it in front of the AGC, the AGC handles those spikes. And the behavior is constant though the entire track.

I know that setting it is a bit annoying, the thought behind this is:
1. For soft sounds, and older CD's, only little boost is needed.
2. For LOUD (recent) CD's, much more boost is needed. Which is automatically applied because they are louder.

In a previous version I kept track of the input level and changed the boost level dynamically - maybe that works better. I'm currently only trying some things out, most importantly I think the current 'boost shape' is not good. If that's fixed I can start trying other things.

I don't disagree with anything you've said. At the same time, this is also a good reason to get a new CPU. They *also* are doing the same thing much more efficiently. Especially in terms of power use.

One thing I will interject is that you're critiquing what's essentially ALPHA development versions of software. Some of the things that Hans is doing are simply to find out the audible viability of any additions and changes. For an audio processor, that's ALWAYS the first step. If something benefits the audio side and you want to keep it around, then you figure out how to make it work efficiently.