Stereo Tool

NOTE TO SELF #2: Maybe I should just keep what I have now - it works very well for many sounds - but add an extra step to find large areas marked as clipped which do not appear to be clipped. That should be relatively easy...

No. I should fix the initial filter that's wrong, not fix it elsewhere.

NOTE #3: First perform very aggressive declipping. Then calculate amount of clipping based on the output of that. Should be nothing - unless there are sounds present that 'look like' clipping. Then I'll measure the same thing in the declipped audio!

Even if you zoom in on it? How would you then know that it's clipped?

Yes. But you can still hear it. So it must be possible to detect it.

I didn't say it was easy

When i look at the picture you've posted, could it be that the time between the spikes determines if we perceive the audio as clipped or not?
Short time between spikes is probably perceived as clipped then?
b.t.w. I wonder how audio from vinyl will behave through the de-clipper where you sometimes also heard distorted sounds.

I don't really know. And there are loads of different situations where clipping can occur that all look completely different.

Here's a thought:
Say I *know* that exactly *1* sample is clipped (over a period of time, say 1000 samples).

Then I could try to reconstruct EACH sample separately (assuming that the others are all valid). The sample that moves the most from the input is most likely to have been clipped. (If the sample doesn't move much, the clipping will also not be very noticeable. So I could just flag, say, the 10 samples that moved the most as clipped, and start reconstruction from there).

Unfortunately this requires a huge amount of computation power (1000 reconstructions just to FIND a clipped sample! On top of that, I would also have to run each combination of 2, 3, 4, 5, ... samples). So this isn't really a solution. But it does indicate that clipping CAN be detected.

Now "all" I need to do is find an efficient way to do it. (And I actually have one which seems to work reasonably well).


I will know more when I have implemented the last "note to self" idea - that MIGHT solve everything - or not...

Since the clipping detection for more difficult tracks is taking far too much time, I'll first create a 6.20 version where I'll use the same behavior as the Omnia 9 had at the NAB - that's already A LOT better than nothing. Then at a later point I'll create a version 6.30 with improved clipping level detection.

Which means I have to fix the following TODO list:

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
- 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

QUESTION to those that reported a VERY HIGH CPU load (maic, baires):
Could you try the following?

1. Load the version below
2. Select a preset, or your own settings (I tested with 'FM Europe Extreme', but it shouldn't matter much which settings you pick).
2. Open the Loudness window, TURN OFF "Advanced extreme highs protection" (bottom of the screen, above the 2 blue bars). This filter was added in version 6.20 and uses a lot of CPU power.

On my system, with these settings the CPU load is about 2.5-3% higher than that of version 6.10. I would like to know if you get something similar.

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

Note: Declipping is broken in this version. Please keep it turned off!

I just attempted to download beta version 6.20 -31 and got a broken link message.

I will try this again in the morning.

Thanks

Oops! Links are ok now!

With Advance Highs Protection cpu oveloads 47-49% and without cpu 37-39%

_________________
Sexy Girls in your city