Stereo Tool

@bojcha: Ok, I understand what you mean by 2 bands now... Very low freqs (say upto about 150 Hz or so) and the rest. And then first clip that bass (hm, actually I already do that - should be easy to adapt) and then clip the total.

You have unique tehnique to do all this. But what i 'learned' so far this should be much less complicated.
Also this gives chance to set amount of clipping for bass and rest of sound separately.

hmm yes.. If you clip bass first then all rest and if you set 'static clip' to e.g. -0.5dB, this lows will never reach next clipper.

@bojcha: Yeah. Currently I treat all frequencies equally. So I don't treat bass sounds different from highs. Now the ears are FAR more sensitive to harmonics at higher frequencies than to harmonics of very low frequencies. So it is possible to treat lower frequencies differently from higher frequencies (actually that's also what Bass Boost does). I currently don't do that.

And before I redesigned my clipper protection it would have been pretty hard to add it, but with the new design it should actually be pretty easy. Because lows, mids and highs are currently much better protected against each other, I could just add an extra step just before the clipper that clips the bass below a certain threshold.

Actually this would mean a redesign not so much of 'Advanced Bass Distortion Protection', but of the 2 filters on the left side of the Loudness panel - they are supposed to keep the bass level under control. Although doing this would also make the 'strictness' setting for the bass clipper useless.

I had the IPP and compiler reversed. You're using a version of IPP that doesn't have dispatching issues with a compiler that does have dispatching issues, not the other way around as I was thinking...

So, according to things I'm reading, if you are not using the automatic dispatcher, then there is supposedly not a problem. If the dispatcher gets used, then there are a variety of situations which could cause 386 code, per:

http://www.agner.org/optimize/blog/read.php?i=49

You have to scroll down a way until you find:

"Overview of CPU dispatching in Intel software"

Could you either post or PM me the compiler flags you use to create the DSP version, just to cross-check and make sure that it doesn't enable the dispatcher?

@Brian: The relevant settings are /QaxW /QxW

Which should mean that there's no dispatching - the required and used settings are identical. And /QaxW differs from /QaxN because the N version checks (according to Intel anyway) that you're running on an actual Intel CPU, while /QaxW supposedly also accepts compatible CPU's. But since there should be no dispatching there in the first place this should not make any difference.

I've also never noticed CPU dispatching code when browsing through the generated Assembly files or when running performance analysis programs.

O, and before I used these settings and generated separate code paths (generic and SSE2, or SSE and SSE2), the performance was a lot worse because in some cases the compiler somehow didn't "see" that the SSE2 version would be faster and didn't generate it. That behavior is also gone now, which also seems to indicate that the dispatching is gone.

According to what I'm reading, you have to use BOTH of those switches. The /QaxW alone would generate SSE2 and a default code path that was 386. Per Intel's documentation here http://software.intel.com/en-us/article ... -overview/ under "Recommendations", the /QxW in combination forces the default switch path to be SSE2 rather than 386 (the default for version 10.1 of the compiler for 32-bit compilation).

Edit: Re-reading the Intel documentation that's on that page, the wording is phrased from the point of view of compiler version 11 or higher. Version 11 is when the /Qax option began to generate the default path as SSE2. If you upgraded to version 11 or 12 of the compiler, you wouldn't need to force the default to SSE2.

I'll check a little more after I put supper in the oven, but if that holds true, then there shouldn't be an AMD penalty.

Edit 2: (Both edits made after supper, but anyway)

If it isn't too much trouble, could you compile a DSP version with /QaxN /QxN and let me see if it 1) Runs and 2) might be better on Athlon64? From what I recall with SETI@Home, the N option did work better.

R I P Steve Jobs..!

_________________
Sexy Girls in your city

Really?! As far as I understood the N is for Pentium, W is for any SSE2-capable CPU. (I am using both options by the way).

I'll build an N version now for testing.

About newer compiler versions: I've tried 11.1, and the CPU load went up by over 20%. So I rapidly went back to 10.1. I am using 11.1 for Leif's declipper though, because he's still using Visual Studio 6 from 1998 with the default compiler that's shipping with that .

@brian:
http://www.stereotool.com/download/dsp_ ... B127-N.dll


Edit: Here I see no difference - the N version might even be slightly slower.

The link for the N-compiled version is broken though... You're listing it as a very different filename format, and as a DLL

You use what you have, I suppose. I own a copy of VS 6 Enterprise, bought when I was a student. It came complete with NT Server 4 with a 10-seat develop and test license, meaning, at least from what I remember from back then without digging out the paperwork to confirm, that you could not directly make money from what you did with it. If you wanted to make money / use things in production, you had to get a regular, non-student license. I think it also came with a 1-year MSDN Universal subscription, meaning I got copies of the beta stuff from that time period.

Edit:

Telling the story of how Microsoft was extremely helpful to me when I had used a non-Microsoft "Registry Cleaner" product that toasted the Enterprise edition all the way back to the Learning edition (I think that was what it was called - whatever it was, I lost ADO, and the VB course required ADO), earned me lots of hatred from some anti-Microsoft people. Microsoft responded to my email with the registry key to restore the functionality in less than a day. I think it may have been in less than 12 hours, but that was 1998, and this far out I'm fuzzy on the exact details. Anyway, the sharing of my experience did not go over well with them and their "Microsoft is Evil. They don't help you." perspectives...