Stereo Tool

The two versions should behave nearly identically, if they don't I just be doing something wrong I. One of the two... Will check!

Ah, you meant Straight line maximum deviation... (Sorry, wasn't home before so I could only check it now). I'll change the name...

But I'm still a bit confused.
First you say that BETA058 restores more than BETA057. Next, you say that you need to increase this slider - which increases the amount of restoration even further...

I'm going to run some tests to see what's going on.

Ok, declipping stopped working properly in version BETA054. In BETA053 restoration is still good, in 054 many clipped samples are not detected anymore.

Cause found: This is not implemented correctly.

With that fixed, 057 works slightly BETTER than 058 though. But that should be easy to fix...


Edit: Is fixed. Building new version now.

BETA059:
Repaired declipping (was broken ever since BETA054, and a bit less broken in BETA058).

What was broken: In BETA054-057, sometimes the maximum level was multiplied by a factor 2 or 4 - due to this many clipped samples were not detected.
In BETA058, this was fixed, but there was another issue: In older BETA's, I always ignored the highest 0.1% of samples. And in BETA058 I rewrote the code and didn't do this (actually I expected it to be not that important). Anyway, in BETA059 I'm ignoring the lowest 0.1% again. I will make this value configurable.

Winamp DSP plugin: http://www.stereotool.com/download/dsp_ ... 20-059.exe
Stand alone version: http://www.stereotool.com/download/ster ... 20-059.exe
VST version: http://www.stereotool.com/download/vst_ ... 20-059.dll
VST version (No SSE2): http://www.stereotool.com/download/vst_ ... 20-059.dll
Command line version: http://www.stereotool.com/download/ster ... 20-059.exe
Linux command line version: http://www.stereotool.com/download/ster ... ETA620-059 NOT AVAILABLE
Linux GUI version: http://www.stereotool.com/download/ster ... ETA620-059 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
- Fix VST plugin version (does not run)
- Dynamically drop 'Allow louder highs, even if it causes vibrations' to 0 when bass filter suspects noticeable voice vibrations. 1-2 hours
- Reduce Loudness CPU load days?
- Check and remove static variables
- Finish new de-essing filter (check what to do with the settings, remove at least some!) 1 day
- Convert Multiband input to MONO, then use arrays [2][4096] --> should give speedup. - FAILED
- Natural Dynamics: Fix or remove transient boost
- Natural Dynamics: Add expected + strength slider per band
- Finish declipping filter (clipping level detection + level reduction in dB). 1. Figure out why removal of unwanted frequencies causes flat lines at high quality setting with small overlap. This causes distortion, with this fixed repairs are MUCH better. 2. Fix MP3 correction, automatically scale down when this deteriorates the sound. --> TOP part fails!
- Declipping filter: Fix low latency behavior
- Always oversample clipping (configurable)
- Declipping filter: Change detection at lower input levels.
- "Test Right Channel" in "FM Transmitter Calibration" does not work since v6.10 (standalone) (bojcha)
- Declipper window close function - check! - Seems ok
- Scopes black background?
- Add AGC start level
- Declipping filter: Add comparting of sample history to make sure loud bursts are still detected properly (now, with 16 blocks of history, 65 samples are removed even when ignoring just 0.1%). I should also check the current block (probably with a margin of a factor 2).
- Declipping filter: Use reliability of tilt detection to determine movement speed; slowly move to default tilt (configurable!)
- RDS issue reported here: viewtopic.php?f=15&t=3703&p=11524#p11524 partially solved
- Declipping filter: Add setting and saving of new sliders (history size, percentage of highest samples to drop, tilt detection range start, end and precision)
- Declipping filter: Optimize tilt detection for performance BUSY SSE2 for maximum? And keep separate smaller histograms to determine the maximum (should perform much better).
- Declipping filter: Optimize peak matching for performance: Move determination to extra preprocessing step; try to change if statements to min/max or something.
- Natural Dynamics: Voices, especially in chorus, still sound weird.
- Natural Dynamics: Smooth out different bands more to reduce low-bitrate-MP3-like sounds.
- Natural Dynamics: Optimize situation with no interaction between bands for performance.
- Update presets? (BASS_AGC etc.) 1 day
- Finish blind interface
- Channels L/R swap in stand alone version when changing filtering/quality (?) (eldoradofm)
- Move pre-emphasis to end of processing 1 day
- Save all new settings, also through VST interface
- 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
- Declipping filter: Automatically override the 3 clipping level sliders if the clipping level is detected very clearly (clear thin spike in sample value histogram). - NONSENSE, this is already done by the histogram function. But it can be made a BIT better - I think - by automatically LOWERING the 'always clipped' slider if a lot of data is present at the highest few bins (but care is needed for DBN - Jack is Back like tracks)

CPU load back to where it was (80s). Did you bring the optimizations forward?

OK. Weird. Audio started stuttering, but CPU load has dropped into the 60s...

Disabling declipper brought the audio back to working properly. I did not have this issue before this most recent version.

Edit: For the moment, never mind this. I didn't realize I was listening to a stream, so that may have been the issue. Moving back to local media.

Edit 2: The stuttering was definitely a stream-related issue. The CPU load is varying. Some tracks, like Drake "Fancy", are in the 80s. Others, like George Michael "Fastlove" are in the low 70s, so meh...

That makes sense. If there's more clipping (more red samples) the CPU load increases. I'll try what I can do about that. (The code that restores a spike is more expensive than code that just copies a not clipped sample).

I just realized that I can move some of the code to a preprocessing step - this will increase the memory usage a bit (which might be bad), but it will reduce the number of calculations a lot (I can determine some things once instead of 10 or more times). I'll add it to the todo list.

Is the CPU load really that much higher now? Then that must mean that my new filter to remove the 0.1% highest samples is too expensive. It might be if your memory is very slow, because it currently won't fit in the cache. I think I know how to fix it - but it would really surprise me if you don't see a considerable drop in CPU usage compared to the older BETA's.

All good now.

and .. is it possible to use more then one core for declipper and so rest of filters...

http://i.imgur.com/QD4Wp.png

Yes, it's all cache and memory bandwidth related. I'm running DDR-500, which is 50 MHz (100 if you count the double rate) higher than the nominal rates for Socket 939 (Athlon 64).

As for "it would really surprise me if you don't see a considerable drop", do you mean with this beta, or the one you're thinking about? You phrased it in the future tense, but I have to ask...

@Bojcha - Your 5600+, is it a Windsor model, or a Brisbane, and do you have it overclocked?

Windsor, on ASUS M2N SLI Deluxe motherboard and 2x1GB OCZ Ram@1000MHz and yes it's OCed at 3.5GHz. That's my pc at work.
Home PC is E8400@4,5GHz.

Then you're basically seeing exactly the same thing as me, except your L1 and L2 cache are running 750MHz higher than mine. On top of that, your memory bandwidth is better than mine. DDR-500 will roughly translate between DDR2-667 and DDR2-800 due to DDR2's extra latency, but I can't reach DDR2-1066 levels.

What I believe is happening is the current implementation cannot fit inside the 1MB L2. It *can* fit in 2MB L2 though, which is why Hans (and others) don't see this happening. Because it can't fit inside 1MB, it has to cross HyperTransport (FSB for Intel systems of that era) to go to main memory. That's where your processor and mine is stalling. Yours doesn't stall as much because of the additional memory bandwidth.

Anyway, I don't think additional cores are needed. It would help you and anyone else with a 1MB cache per core, and if he goes wild and crazy with a bunch of new features, maybe those restricted to 2MB per core, but newer processor designs are trending toward a large monolithic shared cache. So long as you can manually chose what core to use for your player's instance, that should work fine, I would think.

As for you and me, once he finishes optimizing, things should be better. It's just been such a large load for me, that I haven't been able to really adequately test things, but that's more of the Natural Dynamics than the declipper...but anyway...