Stereo Tool

Just had a quick check on the Stokkemask. Had a bit of an issue with the antenna probe (sorry neighbourhood) going in to the analyser.
Made a 5 min test. You can clearly see the bandwidth being limited within specs.
Seems to work very nicely Hans.

@Brian: Will be switchable (of course! A CPU load doubling is really a lot so it has to be!). Please keep in mind that these BETA's are always work in progress, usually I start looking at the performance just before I get ready to release a new version - and I usually try to keep the CPU usage as close as possible to the previous version. But that's a final step, first I need to know if I'm moving in the right direction - if I spend all my time on performance optimizations immediately it may be wasted if the improvement turns out not to be an improvement after all.

@DJ_DOGGY: Only Loudness is now done with pre-emphasis, all the other processing steps are before adding pre-emphasis. Clipping without pre-emphasis is useless, since adding pre-emphasis later will cause huge spikes. In fact, it would be better to clip the total MPX signal (which I intend to add soon).

@chris: This beta should be identical to 022 except for the AGC issue. I'll do a measurement - the CPU load should *not* be higher!

@Luke: Do you have a way to accurately measure if a signal is within Stokkemask limits? Because it could very well be that my current Stokkemask clipper is set too conservative, and that really hurts the stereo separation. If you can do an accurate measurement I could send you some samples with what I think is the most extreme sound possible (a 100% DC offset in L+R moving toward a 100% DC offset in L-R). (Actually I guess I should try to understand what's happening instead, so I can calculate the exact limitations based on the Stokkemask specs. I *think* I understand them now. In a few days I'll take a piece of paper and I'll try if I can find a formula to calculate the precise levels.)

Need to check what I can do since the transmitter that I have at the moment is not the best one there is. It's my own selfmade stuff that dates from the 80's and has alot of phase-noise from the PLL.
You also need to take into calculation that if you are using the full stuff, like audiocard to transmitter and then back to the analyser is not the best combo to make precise measurements. Well actually thinking of it that is how the official instances will measure it so it will have to be within limits.
I would rather keep it fully digital to test and comfirm if it works like it should and afterwards check it out on the transmitter. This way you can rule out stuff like non lineair outputs, phase shifts etc.

As far as I can see it now is that the filter seriously lowers the bandwidth on the skirts (as we call them). Unfortunately I still have to look into this old analyser on how to set it up properly but I need to return it soon.

It remains my opinion that if it were not for people voicing that there was no audible reason for non-broadcast use, you may have considered the "hole-punching" issue one that did not need to have any sort of toggle.

My concern is that changes might be being proposed that do not impact everyone, but yet are in the execution path for everyone. Making changes that impact everyone, whether or not you consider this a beta, violates principles of modular code.

@Luke, what for spectrum analyzer do you use? Brand / Type.

An anritsu ms2601b for the moment.

Story so far:
1. FM Processing : Check
2. De-clipper : Check
3. Clipper[Loudness] : Check
4. Natural Dynamics : Check
5. Suppression of hole-punching by highs: Check

But this is where it all comes to an end

_________________
visit website

@Phoenix: I know... I don't think that I'll be able to run it on my own system either - until I make some big changes. But at least the idea is there now...

If you do make the change, then before you publish the change, please consult with all of the preset creators that you can get in touch with so that we can resupply you with new versions so that people don't misattribute the load increase to be the fault of the preset(s).

Thanks...

@BGrumpy

^^ That's my fake Twitter account

Did some further cleanups: Moved the built-in preset handling and Final Limiter to a separate class. Also found about 10 filters that were being initialized but never used - removed them. The huge file that was over 1 MB when I started with the cleanups is now under 350 kB! (but I'm not finished yet).

I found 2 bugs in *all* the previous versions that had (some) effect on the audio: The de-esser and "Improved Loudness Distortion Protection" levels were multiplied by the Final Limiter level. This is only a problem when Final Limiter and Loudness are used simultaneously. Some time ago I changed the behavior in that situation by bypassing Final Limiter and (internally) multiplying the Loudness value by the volume set for Final Limiter. The de-esser and ILDP were already looking at the internal (multiplied) Loudness volume, but they were also still being adjusted for the Final Limiter volume. That's now gone.

So to get exactly the same behavior as before, you now need to divide the ILDP and de-esser maximum levels by the value set in Final Limiter. (I have not yet updated the built-in presets for this!).

Winamp: http://www.stereotool.com/download/dsp_ ... 22-024.exe
Stand alone: http://www.stereotool.com/download/ster ... 22-024.exe
VST: http://www.stereotool.com/download/vst_ ... 22-024.dll
Command line: http://www.stereotool.com/download/ster ... 22-024.exe

I have tested all 4 versions and they seem to work fine.


TODO: Update built-in presets
Bug found: When the sound card gets a RESET, the BS412 black line drops to 0! It should not do this!
Attempt to reduce hole protection CPU load (maybe skipping upsampling is an option). Maybe I can also skip the short-term processing
Find more efficient upsampling method