Stereo Tool

i dont have Breakway... i will d/l one and try it

_________________
Sexy Girls in your city

Chris, point is just to try other Stereo Encoder...
Tell us what you done...

BETA037:
I've tried 5 different methods to reduce the CPU load - but they all failed (well, there's a VERY minor reduction, but it's almost un-noticeable.). So I'm giving up on this.
I did find a small bug in both Multiband and Noise gate - both should have only very limited effect on the audio though (there might be slightly less bass in band 1-2 in the Multiband output).

Winamp DSP plugin: http://www.stereotool.com/download/dsp_ ... 20-037.exe
Stand alone version: http://www.stereotool.com/download/ster ... 20-037.exe
VST version: http://www.stereotool.com/download/vst_ ... 20-037.dll
VST version (No SSE2): http://www.stereotool.com/download/vst_ ... 20-037.dll
Command line version: http://www.stereotool.com/download/ster ... 20-037.exe
Linux command line version: http://www.stereotool.com/download/ster ... ETA620-037 NOT AVAILABLE
Linux GUI version: http://www.stereotool.com/download/ster ... ETA620-037 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
- Finish declipping filter (clipping level detection + level reduction in dB). 2 days
- Update presets? (BASS_AGC etc.) 1 day
- Finish blind interface
- Add AGC start level
- 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

Hans => the declipper is "broken" in this version ?

Yes, that's the next thing on my todo list...

hans => ok , thank you

If you're using a separate DLL for various math routines, you're limited to the extent that whoever wrote those routines optimized them. Techniques such as making sure that you avoid multiplications / divisions that are avoidable, removing unneccessary operations, etc... All you can do is check your own code for things like that, or try to come up with ideas that might be faster than your current implementation. That is, unless you want to start hand-coding things in Assembly

Whatever you did so far reduced the load from 70-75% at most (GUI up) to generally 35-45% at most on a single-core K8 (Athlon64) system, so it has already been a significant help.

LOL... Already using assembly code (well, SSE2 intrinsics, but that's pretty close). The only external library I use is the FFT from Intel IPP (performance library).

The problem here is the following: For MOST of my filters, the most efficient way to organize the memory is by interleaving the left and right channel. That way I can always do the same thing for 2 channels simultaneously.

There's only ONE thing for which this is not good, and that's for the FFT. Well, actually it's not that difficult to do the same thing for the FFT as well, and I did until version 5.00. But then I switched to Intel's FFT, which turned out to be much faster - even compared to my own SSE2-based implementation, and even if I have to reorganize the samples in memory before and after each FFT call.

So before EVERY FFT call I need to split the data to 2 channels, and afterwards I have to recombine them.

One of the things I did in the last 2 BETA's is skipping this step, and instead perform the filtering based on an analysis of the interleaved data. (For bandpass filters, that's possible, I just have to do the same thing at position x as on 2^N-x).

Anyway, if I could get rid of this it could easily reduce the total CPU load by 10% or so - but unfortunately that doesn't seem to be possible (in some cases, for example in multiband, it is, but it takes more effort than the gain of not having to reorganize the memory).

Basically, if I could find an FFT that can handle interleaved data with the same performance as the Intel FFT I'm using now, that would help. (But the Intel and FFTW FFT's are both WAY faster than any other. So there's little chance for that).

Good declipper news: I just found a completely new method to remove wrongly reconstructed audio (or actually: To more accurately reconstruct the audio, making better use of the available information). Audio with loud bass (Bojcha's example) is now at least 'listenable' again. This does not replace the quest for a better way to detect clipping, but it helps maintain the audio quality if (far) too many samples are marked as clipped - a lot.

Great news !!

waiting for beta