Stereo Tool

Yes, but my minimum and your minimum are likely vastly different. You also may not be aware of the admitted (by Hans) ineffeciencies in the code.

An example of this is that the classic multiband is one of the places that has those additional iterations that aren't needed, and are thus waste. I've begged and pleaded for those to be removed, only to be told:

- It would take too long.
- The new multiband, if you set it to 5 bands, will require less than the 10-band classic multiband.

Well, the reality, thus far, is that with your "80s" preset, even if I get rid of the oversampling, scale the quality slider back to 60% @ 4096 latency, scale back strictness (CPU) in advanced clipper from 13 to a more appropriate 6 (values beyond 6-8 yield diminishing returns)... even if I do all of that:

Your preset with its' default of 9 bands weighs in at 70-80. Reducing your preset to 5 bands makes little or no difference. Bumping up to 100% @ 4096 results in a complete inability to do anything else on my computer while a track is playing, meaning I have to wait for the track to fully play before I can do anything else, including getting Task Manager open by pressing CTRL-ALT-DEL. Oh, and the really cool part about that is that the audio is stuttering, so 1 second of track time is no longer 1 second of wall clock time, but more like 1.5-2 seconds. Fortunately the track I chose to just test with was only normally 4m 20s, rather than, say, "Echoes" by Pink Floyd...which is over 23 minutes long.

My preset, using the classic multiband, even with its' known inefficiences weighs in at 45-50 with 60% @ 4096. Raising to 100% with declipper off puts it at 65-80. Only throwing on the declipper makes things stutter, and even then I can wiggle out of it in a couple of seconds vs. having to wait for the track to finish.

What's been promised is not being delivered.

Now, when something is "deprecated", it is generally on the way to being totally removed. He might not remove the functionality, but if he does, then that will cease my ability to use future versions of his product as it is too demanding. Odds are though that it wouldn't be too demanding if the inefficiencies were removed.

Even if you ignore me and my situation completely, treating me as a "statistical outlier", in a period of global economic recession and/or depression, it is an extremely unwise business strategy to demand people upgrade. The far better approach is to stagger the introduction of the new features so that there is not a huge spike in the hardware requirements, but is spread out over a longer period of time.

viewtopic.php?f=10&t=4667
It's finished. Just call it "vmp94 - Gentle Slope 0.5". Make it a little louder (more clipper drive) if appropriate.

Well i see your point, and i am not a computer expert, so i realy can not tell you if you are right or wrong.
Hans is the only one who knows if the code can be more efficent, but i can only imagine that audio calculations and especialy stereo and RDS gereration at low latency must be hard for any CPU. It has to generate an complete wide band audio spectrum and this HAS to be done at the lowest possible latency.

HAS ?? YES HAS !! because of onair presentation the lowest possible latency HAS to be accomplished.
I assume if the latency would not be an issue life would be far more easy, and maybe you don't need a near realtime system, but lots of other people do.

So maybe a different version (like breakaway live) might be a possibility.
I assume (correct me if i am wrong here) when latency is of less importance, the CPU load will be a lot lower.

_________________
----------------------------------------------------------------------------
AIRCHAIN-GURU professional independant airchain consultancy.
Orban/Omnia/Vorsis/DSPX/Aphex/Inovonics
----------------------------------------------------------------------------

This is exactly what I meant earlier about software being "nebulous" and people giving the developer the benefit of the doubt, with the exception of any Microsoft-employed developer, as it is widely known that all Microsoft developers are actually spawns of Satan...
I may be incorrect, but 4096 samples is the slowest processing, and thus the highest latency, where 512 samples is the fastest processing and thus the least latency. If that is indeed the case, then perhaps what you're asking for is for significantly higher quality (higher number of samples) at the same latency as the lower quality setting.

My impression, and again I could be incorrect, but my impression was that for non-broadcasting situations, meaning home / hobbyist music listening like what I'm doing, 4096 was preferred and 2048 OK.

When I load your preset that you posted in the preset section, it imports in at 1024 latency. As I've reported, but not sure if my report has been accepted, 1024 latency seems to give the new multiband and declipper some problems.

At any rate, when I load your preset through the preset menu in the latest version, it loads up at 4096 latency.

I could be totally off-base, as I'm routinely told that I'm wrong, so you can take this with the usual boulder of salt, but I'd say that something is amiss with the preset value for the built-in setting, and that perhaps you're not on the same page as me with respect to the latency levels.
As I previously mentioned, the higher number of samples is a higher "latency". I think you're attempting to combine latency and quality together. I use 4096 "latency", which is the slowest, and has more audio delay, but is of higher audio fidelity. Now, when I do lower the latency, yeah, I get a lower CPU load, and so do you. That lower CPU load is what enables you to crank up the oversampling and the strictness setting, run the FM stuff, and the declipper. However, if you were to actually compare audio fidelity, my settings at 4096 latency would be of higher fidelity than yours at 1024.

Well I will leave the discussion about the code because it's not relevant what we think, we all depend on the developer.
He's the boss and if he is not willing to solve your or my problem, i can't blame him, because he is leading in this.
I am just glad he's building something verry nice at reasonable (low) price.

My presets are indeed intended for broadcast use, as a mather affect i use it on air at this verry moment.
So i set latency at 1024 in order to get lowest possible delay and acceptable fidelity.
If hans sets the latency to 4096 in the build in user preset section, again thats up to him, he probably choses fidelity over latency.
Personaly i don't care.

_________________
----------------------------------------------------------------------------
AIRCHAIN-GURU professional independant airchain consultancy.
Orban/Omnia/Vorsis/DSPX/Aphex/Inovonics
----------------------------------------------------------------------------

I actually missed that setting when I converted the preset - I chose to save 'Audio & FM' settings, latency is not part of those (neither is quality, and of course loading a standard preset should never change that setting).

Rest of the performance discussion has been moved to another thread so I'll reply a bit there.

Hm, I wonder if this is what I'm hearing now in 'Spider Murphy Gang - Skandal im Sperrbezirk". There are some loud 'bangs' there (drum + guitar + hi-hat) and it sounds weird, almost like a bad MP3. All the new presets that I tested have this effect, none of the ones using the old MB.

Edit: Ok I see what happens now. Of the top 3 bands, the one in the center stays nearly constant after the 'bang' while the other two move up (less reduction). Hence it sounds like the mid part of the highs gets reduced. Averaging each band with the surrounding bands should help a lot. But maybe there are smarter/better solutions. In the old MB I didn't allow bands to move away too far from other bands (band output could never be louder than the maximum of the two surrounding bands, I did something with the minimum as well but not sure what it was).

The "Link" between bands could help, I think this is another reason to implement it.

_________________
by GAP
"Less is More" (Bob Katz)

Thinking about how to implement it. The most simple solution, which will still allow spectral change to happen in case of extreme signals (which might be a good thing), would be an array where for each band you can say how strongly it should use the signal from adjacent bands. Should sound better, but in extreme cases it could still be bad.

Another one - but looking at the output of the sound where I found this issue it's not going to help there - is to lock each band between the value of the band just above and just below it.

A third option is to combine these methods: Use the center of the band above and below the current band, and allow a difference based on the actual level. Sounds complicated...



See the image. It displays multiband attenuation levels (same as the display in the Stereo Tool GUI). The circles indicate things that will make it sound bad. The "sweet spot" for each band is in the center between the surrounding bands; the further it gets away from that center the more the audio will change.


Edit: Mix of both solutions should work best. So the ability to lock the value between the surrounding bands, combined with an array to set the effect of other bands on the current band signal.


Pfff... Back in the days when making software was easy

I still think that using link between bands 1>2, 2>3, 3>4, 4>5, y asi sucecivamente surely minimize el problem.
Then think of something more complex, if is necessary.

_________________
by GAP
"Less is More" (Bob Katz)