Stereo Tool

@Hans:
Two things:

1) Yes, turning off the extreme highs protection does help. But not as much as I thought.
2) I found out the "slow reaction" problem I mentioned. It's the pre-amp actually. So it seems pre-amp works much faster than the other filters (or vise versa) so one has to catch up to the other. So if you have pre-amp set to 10.00, when ST starts processing it'll increase by 10.00 (24db I think) and then the AGC, multiband, etc. will kick in and adjust the sound. Try this experiment: Pick a song, load the Web Radio Loud preset (because it has a 24.00 preamp so it's easy to detect) and process the file (let's say with VST) and save it. Then try to process the same file, same preset BUT turn pre-amp to 1.00 (0.0db) and you'll see the difference at the beginning of the song.

Hope you can fix this in next version Hans. It's the only problem with ST I ever had and I couldn't figure it out until now. Thanks.

baires: So how much effect DOES it have, if you compare it against 6.10?

I have a new version ready (going to build it now), my new measurements (on a PC with no other processes running) are:
6.10 -> 6.20 without 'S' protection: 2% slower
6.20 without 'S' protection -> 6.20 with 'S' protection: 8% slower (total 10% slower).

(This is a bit odd: It's about the same number as before (13%), but I removed a lot of processing steps...)

I'll post the new version when the build is finished.
In this version I've made some changes to the S protection algorithm:
- Simplified the calculation of how much I need to drop the highs level. Result values are typically within 1% of the old calculation
- Calculating this value only for the first processing step, instead of for each processing step as I did before. This may impact the audio a lot more!
- 'Allow louder highs, even if it causes vibrations' - this didn't work before (bug! to get old behavior, set it to x 0.00). Setting this to a higher value makes the highs brighter, but in some cases causes voice vibrations. (Clipping level is 1 + this level times higher than the displayed clipping level; for default settings, values above ~ 1.90 don't have any additional effect on the audio). Add to TODO list: Link this behavior to voice vibration detection in the bass filtering. If voice vibrations are detected there, this value should dynamically be dropped to 0.
- Highs clipping low frequency rumble should be filtered out better than before (potentially at the cost of causing more volume drop of lower frequencies).

I won't have much time to do more (or even to compare the audio against older BETA's) until next weekend.

I'll have to check if further CPU load reductions are possible (potentially, some of the places where I protect 'S' sounds are not necessary, which would reduce the number of calls to this filter - it's currently called 6 (!) times).

Hans,

I get roughly the same percentage difference as you. about 11% instead of 10%.

I think the Extreme highs protection that now we can check on or off should be in the preset file as well. People who don't have high enough resolutions on their monitors have a hard time turning it on and off.

And look into the pre-amp issue when you get a chance. If using the DSP version, it's only an issue with the first song played because ST doesn't reload for every file. This problem is an issue with the VST version when ST has to load again for each file. So the first 2 seconds or so of each song get messed up.

Good work.

baires: I guess if I let the AGC start at an average level instead of at top level it would be a lot better. Or maybe even allow setting a start level. That would definitely be useful for a VST version if you want to process a single track.

About the CPU load: Great, then I can trust my own measurements again - still no idea where the times 2 difference you reported earlier came from though... (My 10% was measured using the new, more optimized, version, which I'll upload in a moment).

That sounds great for the VST version. Hope you can make that change soon.

And yes I really don't know why those times were so different. But now I'm getting the same numbers roughly as you so everything is good now.

Thanks.

BETA032:
Optimized 'S' protection. See previous post, this might affect the audio quality. (Could be better. Could be worse. Probably very similar. No idea yet).
Clipping is still broken.

Winamp DSP plugin: http://www.stereotool.com/download/dsp_ ... 20_032.exe
Stand alone version: http://www.stereotool.com/download/ster ... 20_032.exe
VST version: http://www.stereotool.com/download/vst_ ... 20_032.dll
VST version (No SSE2): http://www.stereotool.com/download/vst_ ... 20_032.dll
Command line version: http://www.stereotool.com/download/ster ... 20_032.exe
Linux command line version: http://www.stereotool.com/download/ster ... ETA620_032 NOT AVAILABLE
Linux GUI version: http://www.stereotool.com/download/ster ... ETA620_032 NOT AVAILABLE

TODO:
- Fix loading changed multiband frequencies
- Add buffer and filter for SCA output (SCA1 ok, SCA2 ok)
- Finish AGC improvement - make mono value configurable (replace checkbox by slider) 1 hour --> NO, not needed - anything else needed? -> NO
- Fix Punch
- Check what to do with new filters (such as bass AGC) - keep them, remove them, change them? --> KEEP
- Save new BASS_AGC setting in VST mode
- Loudness: Annoying cracking sound in bass. Slightly present in 5.00, worse in 6.00, maybe even worse in 6.10. Only when bass is too loud. Much worse than in Final Limiter (at same input level!) - so this clearly indicates a bug. Most likely cause: The filter that was added to remove bass artifacts....... - No, it's the louder bass. But it can be fixed by changing some settings. Default settings updated, and behavior for 'not Very strict' improved. Also Deep bass boost and Very deep bass protection are enabled for latency 512 now.
- Fix crash at program close
- Reduce Loudness CPU load days?
- Finish new de-essing filter (check what to do with the settings, remove at least some!) days?
- Dynamically drop 'Allow louder highs, even if it causes vibrations' to 0 when bass filter suspects noticeable voice vibrations. 1-2 hours
- Finish declipping filter (clipping level detection + level reduction in dB). 2 days
- Update presets? (BASS_AGC etc.) 1 day
- Finish blind interface
- Fix VST plugin version (does not run)
- Change version number 1 hour
- Release 1 hour
- Add lowpass filter for stereo signal (will cause a lot of extra latency!) - it might be possible to avoid this latency using a Hilbert transform
- Add smarter clipping detection. Maybe something much simpler suffices: Current clipping detection with threshold + flat line detection

just me, feeling ignored again...

New version reduced CPU load down to 45-50%, up from 38-43% without Advanced Highs enabled...

According to Bojcha though, that filter is only useful for FM broadcast mode? I reckon I could go back and read old posts, but would someone mind summarizing whether or not it would still be ok for non-broadcast, or if the prior De-esser is good enough? I'd like to update my preset accordingly...

Thanks much...

@Brian,

Don't feel ignored, I just don't have time to change everything at once

It is much less needed for non-FM processing. Not sure if it is needed at all, I still have to check what the impact is. Anyway, I'm glad that the CPU load dropped so much for you - if the audio is still good it means that I'm moving in the right direction.

Turning this on SHOULD still be possible for non-FM broadcasts (at the very least in case someone likes really loud highs).

Things I need to do now:
1. Find out if the audio quality is still as good as before (if not, add this new mode as a 'lower quality, lower cpu usage' mode)
2. Check where this filter might NOT be needed (as I mentioned earlier, I'm now using it 6 times)
3. Turn off (at least by default) for non-FM output
4. Move buttons so they fit on smaller displays
5. Save settings

Not necessarily in that order...

DOH!

I reported to you incorrectly... Apparently I needed sleep more than I thought I did yesterday...

I'm listening to Eminem - "Lose Yourself" right now, and the CPU usage of Winamp is tracking between 57% and 71%, so not really that much better...

I have no idea what I was seeing for the 45-50% reading... I'll try another few tracks and see...

Hmm... within the same track, I'm dipping down to 53%... Looks like it was consistent 65-70% before, but widely variable now. More Hmmmm... These readings are with beta32. I'm falling back to 31 and see what happens.

With Beta31, which as far as I know was Beta30 with only a bugfix and the ability to toggle the advanced highs on/off, cpu load is staying very consistent at 72-75% with the same track.

So, I have no idea where the 45-50% came from, but it seems like B32 does reduce the cpu load, but has wide variability.

A-ha!! (and not the band)

The 45-50% I was seeing before can be had by not having the GUI up.

It can also be had by having the GUI up, but disabling the Advanced Highs Protection.

Soooo, something there is interfering with the GUI thread, or that visualization meter for the Advanced highs is causing significant loads.