Stereo Tool

Thanks Hans. I did a little more testing listening to pre-limiter Difference and observed that as the number of bands gets lower, the amount of difference audio goes up. By 128 it is almost completely gone. At 2048, it is completely absent.

Your answer makes sense with that. As I raise the number of bands, less is being caught by the pre-lilmiter, and therefore the difference audio is less and less. So I assume less is better, if you want the pre-limiter to actually do anything, right?

Less bands you mean I suppose? Well, yes, but if it does too much it might sound bad. I thought 128 was a good compromise (and it matches some other internal settings) but Bojcha is usually never wrong.... So I don't know.

Yeah, I juxtaposed my sentence a little bit. As the number of bands goes up, the pre-limiter does less and less. Therefore (presumably) the final clipper is doing more and more of the work the pre-limiter can't catch. That was proven in both the audible difference signal and in the Output display window.

I'm messing with 16 at the moment. That's still a ton of bands. Hopefully, I'm not over-driving the pre-limiter, but I don't think I am.

Hello Hans,
A good feature would be to add a possibility to setup dedicated Band couplings in the MB section.
Of course this is a bit difficult because the number of bands is adjustable. Perhaps it could be done in this way, that you insert let´s say 8 equal rows with fields where you can set the source band, the destination band and the coupling intensity.
There are 3 ways to realize the couplings:
1. To put a portion of the source band´s control value to the destination band´s control value. Dest.BandGR = Dest.BandGR + SourceBandGR * x/100. The value of x is then %.
2. To limit the minimum gain reduction of the Destination Band to a source-band dependent value: Dest.Band_minGR = SourceBand_GR - x. The value of x is then dB.
3. To limit the minimum gain reduction of the Destination Band based on a portion of the source-band´s Gain reduction: Dest.Band_minGR = SourceBand_GR * x/100. The value of x is then %.
I would prefer the third version. How do you think about his?
Regards,
Robert Sack

I think I'm coming up with a tuning procedure for the pre-limiter setting. I have a hunch that what we want is the lowest number of bands for which no artifacts appear in the human sensitive range of the spectrum for most material. More bands just mean the pre-limiter is doing less, so more distortion will be present in the final limiter. Too few bands, means the pre-limiter itself may actually cause audible distortion. So the balancing act is to find the range where the pre-limiter difference is usually in audible except for occasional pieces.

I've actually found 64 to be the sweet spot, not 32. But I'm sure that would change depending on other settings in the processor, notably clipper drive.

i wait new stereo tool vercion come on hans

Whereas even small changes in the advanced clipper drive does change the sound significantly (especially with pre Limiter + ABDP engaged), i would prefer the the BS.412 Limiter does reduce the gain after the clipper stages. Instead of the BS.412 input amplification it shoult be a control to insert a static loss, a kind of buffer, cuase some of the louder presets can create MPX power as much as +8dB and more. So with this control you prevent the BS.412 fom producing such high amounts of gain reduction without reducing the clipper drive.
Regards,
Robert Sack

Wooha. I just looked at the latest IPP library benchmarks... turns out that IPP7 with AVX is about twice as fast as the version that I'm using (on pc's that support AVX, of course). I'm now downloading the latest compiler and IPP version to run some tests... The bad news is that older CPU's (before Pentium 4) won't really be supported anymore and older OS's (before Win7 SP1) don't do AVX anyway. So to benefit from this you would need at least Win7 SP1.

Btw: Stereo Tool currently spends about half of its time in the IPP function which' performance should have been doubled. So, if this is correct, the CPU load should drop by 25% when I switch to this new version. Unfortunately, every attempt I have done in the past to upgrade in fact showed a decline in speed instead of an improvement. But... it's been a while. So I really need to try again now.

Which means NO more running on XP ?

For now I just want to test it. And it should run on XP, but without the performance improvement... In fact, 64 bit should also be a lot faster than 32 bit if this all works. (It kinda already is - but only a few percent at the moment).

So far I've been busy installing software all day and if this works out I have to buy about $2000 in software licenses just to make everything run using these new versions. I'm starting with trial versions...

Edit: Hm... 20% gain in performance for this Intel library (so not 50%), 25% when using 64 bit. But I see some big differences in some other parts of the code as well if I switch to 64 bit. This might get very interesting...

Edit #2: 17% performance gain over the whole program. A bit more for the 64 bit versions. No change when running in XP - which might indicate that the Intel compiler is *finally* back at the performance it had in version 10.1. Not bad for one day of work... Will check tomorrow if there are also things that have gotten worse.