Stereo Tool

Smitten by the unprecedented transparent sound of Armin Van Buuren's webcast, I have, since then, poured huge effort and time to make something that comes close - if not surpass the very source of inspiration!

Posted here is the draft of a very high fidelity preset for HD Radio and Webcasting (which I am in the process of finalizing).
Loudness is decent too.
Distinction would be clear once you compare with other good presets in StereoTool's arsenal like Neodymium and Lucidity FX5.

Refer to the screenshot for a comparison between the posted preset and ASOT webcast playing 'Fragile vs. Green and Falkner - Inertia vs. Ceylan'.
The green spikes depict the preset output (AGC + MB enabled only) for center frequencies and interpolated crossovers(might not be very accurate).




Important
1. The original ASOT webcast does not 'seem' to use any kind of Stereo Panning. I have, nonetheless, added subtle amount of Stereo Boost. Thanks to Achez for that bit of setting.
2. I have not done any coloration to the signature by using equalization. In case, you really need to add bass or excite the highs - you are at your own.
3. For streaming, I realize the need for attenuating the final level and using subtle pre-emphasis(for spike protection). I would rather urge to delegate these tasks to Edcast latest version.



4. Perceptible sound, needless to say, would differ across hardware. However, using the same hardware we can also percieve difference in playback quality across various players and the API used to transfer the audio samples. The preset I created was on J River Media Center 17 using ASIO/ WASAPI. So, comparison with other sources/presets are also based on my perception using the mentioned player and APIs.
5. I am yet to tinker and come up with more convincing clipping thresholds in MB. So, far the default settings seem to be doing a decent job

_________________
visit website

After intensive testing of many different CF modifications I have finally to agree that the centers should be as linear as possible.
Especially (at least) bass frequencies up to 1K !

If you would ask me again if I now also agree that Stereo Tool has too many bands, I would say:
Yes !
And no !
It has definetly too many bass/low mid bands (using a plain linear CF concept).
Most problems (instabilities) are based on this frequency range.
For higher frequencies more bands are less problematic IMO.

So it could make sense to try CF mods with a split point.
That way you can somehow "virtually" reduce the number of bass bands.
Instead of plain x2 you could try to use something like x2.5 for bass up to 1K and x1.5 for the higher frequency range.
Then you have even one band more for higher frequencies.
And IMO this could help to better control especially too aggressive percussion sounds (hihat, cymbals) without the need to use that kind of extreme limiting and up and down speed orgies I have used with my BASE presets.

Of course you have to tinker a little bit to match some important center frequencies and it could be better to use two (!) split points.
I just try a constellation with 1K and 1.7K as those two split points.

Anyway!
Have you tried to use higher latency settings ?
Almost every preset I have tested sounds much better with 8192 samples latency !
The only problem is that you cannot save 8192 samples latency with the GUI.
When you load a STS with 8192 and save it with the GUI (even without any change) you always get 4096.
Though other "hidden" parameter values beyond the GUI standards (e.g. 300 % for steepness and vocals protection) still remain after saving as long as you do not touch any slider of its corresponding sub-GUI module !

But 8192 samples latency must be manually rewritten to STS after every GUI based saving.

Precisely. We don't need too many bands for higher end of the spectrum. A max of 6-7 bands across the entire audible range is enough.
We need more bands towards the bass and mid ranges. So somethings like:
a band for sub-bass, one for the bass, one for lower mids, another for higher mids and remaining for the highs would sound optimum.
What's really relevant is that we need to have defined cross-over points.
Well the reason we use x2 is simple. Harmonics always occur as integral multiples of the fundamental frequency. So for a fundamental frequency of say 31Hz, it makes sense to have subsequent controls at 62, 124, 248 and so on.
Now we could have used x3 or x4. But that would not optimally utilise the 10 bands covering entire audible range.
I was always aware of the leverage that the underlying validation framework(if there exists one) between the UI and the audio processing core provides. Software architecture wise, this is not a good design, but in case of Stereo Tool, one might say this is a blessing if used the right way.
However I NEVER expected the latency setting to be in the same league. Because the implication of this is HUGE if you are aware of its relationship with the loudness section. I'd rather like to pull Hans in the loop to gather his consent. Nonetheless, the effect of using higher latencies like 16384~524288 is pleasing if not astounding. I mean my preset sounds like top notch Omnia 6 unit!

_________________
visit website

Wooh, I didn't even know that that was possible! (Actually it would have caused crashes in many previous versions, and it will probably still crash if you enable oversampling or FM output). And even the the biggest possible value would be 16384, because no memory has been allocated to handle bigger chunks of data.

- I've just checked the code and it would still cause crashes, or at the very least overwrites of audio data of different processing steps which would cause major artifacts. But, looking at how a setting is loaded, it cannot use these higher values:

        ReadPrivateProfileFloat            (STCONF, "Latency (samples)", &latency_smp_f, file);
        int latency_smp = (int)latency_smp_f;
        switch (latency_smp)
        {
        case 512:
            qualitylatency_blocksize = 9;
            break;
        case 1024:
            qualitylatency_blocksize = 10;
            break;
        case 2048:
            qualitylatency_blocksize = 11;
            break;
        case 4096:
        default:
            qualitylatency_blocksize = 12;
            break;
        }

So for unknown values it defaults to 2^12 = 4096 samples. The VST interface also has protection.

So I don't think you even *can* select a higher latency.

How are you forcing the latency to be higher? And if you do and compare the 2 .WAV files, is the resulting latency actually bigger?

I just did a quick check (changed the value in the INI file from 4096 to 16384), the output file is 100% identical to the output when set to 4096. Am I missing something?

I use modified STS files (and I guess phoenix too).
Well, but why do we hear this obviously improved sound quality ?
Though for me 8192 in STS is enough and I don`t hear any relevant extra quality with 16384.
But this might be based on the fact that most presets I have tried do not use loudness at all.
It could also make a difference that phoenix uses the VST version (or not ?) and J.River Media Center and its advanced hosting/processing architecture (-> ask phoenix for the details) and I use the DSP version hosted with Breakaway Live trial.
We just replace the latency setting in STS and save it (to a new file like xyz 8192.sts).
And when I load (switch) from the original (4096) presets to the 8192 STS files back and forth there is a noticeable quality improvement.
And obvious this higher latency persists switching the bypass (and I can hear this higher latency => an extra delay).
When I save one of these 8192 presets with the GUI (without touching anything) and reload that, then the sound quality is reduced to the normal standard (and reopening the STS with an editor we see that 4096 is back).

So whatever (and it is not possible to use higher latency), something positive happens to the sound quality
I have not done that yet (writing WAV files).
I have only used my ears while listening and trying the modified STS files.

My question:
But these other settings (300 % for steepness and vocals protection or Bass Boost strength higher than 100 %) should be possible in theory, Hans ?
I can hear these and I can read these non-standard settings in the corresponding sub-GUI (get lost when I touch a slider of the specific sub-GUI).

I also can see this higher latency.
When I watch TV with the DVBViewer there is an extra delay (lost of lip synchronicity) when I use the modified 8192 or 16384 STS files.

In addition:
At least with my old Athlon X2 6000+ CPU disabling the multicore support in the GUI improves also the sound quality slightly.


Whatever (spiritistic ?) effect that might be ?
I like it.

One person can err (especially me).
But phoenix hears it obviously too.
I don`t believe that we both hear the grass grow based on unconscious simultaneous consumption of LSD.

Neither did I! I would assume any parameter in StereoTool that has radio button based selections would eventually translate to some pre-defined conditional statements or switch cases. Slider based controls would probably associate with some float variable.
Also, I am yet to encounter a crash due to loading of such values or perceive any audible artifacts.
Importantly, I can't dismiss the difference that I hear as some placebo effect
As Michi guessed, I am using VST plugin hosted on J River Media Center. I am unsure of other versions or how different it would when VST plugin is hosted on Winamp VST bridge as the latter deals only in 16 bits.
Not much that I can infer from the snippet that you posted. However assuming 'qualitylatency_blocksize' is the only decisive variable and that 'latency_smp' has not been used elsewhere without any validation, I pretty much convinced with the point you're trying to make despite my experience going against it.
Just curious to know, when you say no more that 2^15 bits have been allocated, which variable you're referring to in the snippet? From the snippet all I can infer is that:
'qualitylatency_blocksize' can have a max value of 4096 whereas 'latency_smp' can have a max value of 2147483648.

Unsure if I can answer this objectively except for saying that I alter the value of the key "Latency (samples)" to say 16384 and load the preset in the plugin.
Now here's an observation that probably could go in your favour -
Let's say I allocate just enough buffer to the application so that it can play the processed sound at a latency of 512 samples. Later if I change the latency to anything higher I begin to get jitters.
However I don't hear any jitter when I think I have allocated just enough buffer to play at 4096 samples latency and than reloading the preset with a higher latency as 16384 samples.

Don't bother too much! Better sound or not, as a developer of this app you can be rest assured the plugin does not crash

_________________
visit website

Can you post 2 records. One with 4096 and one with 16384.