Stereo Tool

Thank you Jesse for your detailed explanation.

But I wasn't serious.
It was pure irony (still waiting for a public BA release version including the Passive Aggressor preset).
I hope your preset for Stereo Tool will have less release date delay than Passive Aggressor.
Sorry, maybe it was a stupid joke, because I know that you are not responsible for the release delay.

On the other hand we have proven again the old golden rule that irony does not work in radio (and in forums too).

And one final question:
You remember the recommended low bitrate LAME version topics (BA forum).
http://www.claessonedwards.com/forum/vi ... f=5&t=1749

Have you ever tried the free FhG V4 Surround MP3 CLI encoder ?
http://www.all4mp3.com/SoftwareLine.aspx

I haven't finished yet my detailed comparisons, but as sure as the old LAME 3.93.1 is much better than any other LAME version @ CBR128, it is astonishing how good (relatively !) the FhG sounds even @ CBR96 (much better than any LAME version that all tend to add S-artifacts).
Especially for transcoding audiobook material (PCM on Audio CDs) for mobile MP3 players the FhG V4 (CBR96) is the best choice (the high-cut filtering @ 12 KHz is more or less irrelevant for spoken words).

Are you intending to work on the CPU load for 6.20, or after you release 6.20? It's pretty high again with it enabled. I'm back into the 70s, with some peaks into the low 80s...and, yes, it does impact performance system-wide. If it was just a number and no performance difference, meaning that it was a non-blocking / yielding situation, I wouldn't bring it up...

I also haven't gone back to see if the file you posted some time ago is being handled automatically now or not. The way it was previously is I had to adjust the tilted values slider for it to clean up that file. That was when, and I'm sorry to bring this back up, I was being doubted. I'll test it again for you in a little while, but if I say I have to adjust the tilt, or if I say something like it doesn't seem to be working for me on my system, I mean it. If there is a problem, then whether or not you want to pursue figuring out what's going on with my setup or with someone else that is in the same CPU generation (P4 / K8 era) is up to you.

@Brian: I will try to reduce it later. I think I can do almost the same thing that I do now in 32 steps in about 6-7 steps. But first I'm working on improvements of the filtering quality itself - when I know what it has to do (I think I'm getting very close now) I'll look into code optimizations. I'm not sure how much I can reduce it though - so on a P4 it might be better to turn it off (or turn other filters off, depending on the quality of your input material). For now, try the following settings to get a slightly lower CPU usage: Quality to 1.0, 'Max input distortion' to 1%. (This doesn't affect the auto tilt determination though).

Also: Automatic tilt detection now works in a range, I think -50 .. +50 degrees. So if your track falls outside that range it won't work. (I still have to make that configurable, and also the number of steps).

I could also allow manual tilt correction on slower pc's (the issue is that very often, for different tracks different tilt values are needed, and changing them manually during listening or broadcasting doesn't seem usable). This would greatly reduce the CPU load.


@michi: About LAME: I can confirm that Fraunhofer's mp3enc (version 3.0 and 3.1) sounds considerably better than LAME, especially for highs with phase differences between the channels. This is even though mp3enc cannot encode frequencies above 16 kHz (if you fill in a higher lowpass frequency and feed audio with higher frequencies in it, it even crashes!). This is even noticeable at 320 kbit/s. (But at lower settings, for example 56 kbit/s mono 44.1 kHz, mp3enc also clearly outperforms LAME).

BETA041:
Added an extra filter that draws a line through the peaks in a part of clipped audio, and then marks any sample more than 'clipping detection - straight line maximum deviation' (new slider) closer to 0 as NOT clipped.

Declipped audio sounds better now, since far less samples are thrown away.

I think I'm getting pretty close now, but there are still a few tracks (DBN - Jack Is Back - loud bass with softer highs) that sound bad. I think I know how to fix this as well, but I still have to do it. (Basically, if there's a larger block of data marked as clipped, and the amplitude goes down in both the left and the right side, we're probably detecting a sine wave instead of clipping).

Clipping detection now seems pretty accurate for both the Metallica and the Madonna track, and the extreme clipping example.

From the previous beta (still valid):
The CPU load is also pretty high because I'm calculating 32 different tilt levels to find the best match (so automatic tilt detection works, but it needs serious optimization).

New slider: "Declipping margin" - if you set this to 75%, everything above 75% of the maximum level is considered to be potentially clipped.

Changed slider: "Never consider samples to be clipped if they are lower than:" - rule out soft sounds, whatever they look like, they are not clipped.


Winamp DSP plugin: http://www.stereotool.com/download/dsp_ ... 20-041.exe
Stand alone version: http://www.stereotool.com/download/ster ... 20-041.exe
VST version: http://www.stereotool.com/download/vst_ ... 20-041.dll
VST version (No SSE2): http://www.stereotool.com/download/vst_ ... 20-041.dll
Command line version: http://www.stereotool.com/download/ster ... 20-041.exe
Linux command line version: http://www.stereotool.com/download/ster ... ETA620-041 NOT AVAILABLE
Linux GUI version: http://www.stereotool.com/download/ster ... ETA620-041 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
- "Test Right Channel" in "FM Transmitter Calibration" does not work since v6.10 (standalone) (bojcha)
- Channels L/R swap in stand alone version when changing filtering/quality (?) (eldoradofm)
- 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

That FhG encoder in/out can be piped too, neat. That should work just fine for streaming.

I downloaded the extreme example clip again, and with the default values, I do hear an improvement. It's still extremely expensive (CPU-wise) for my system, and I'm only using the defaults. To get a cleaner sound, I'd pretty much be to the point where I couldn't do anything else but run Winamp and StereoTool.

That said, beyond the extreme example, I'm not really hearing much change, if any, to the tracks that I currently have as MP3s. I do see some red in the waveform display, but it is very sporadic / transient...

So, we're back to the point where I tell you that due to the extreme CPU load, it's not worth $43 (current 30 Euro)...at least not for my needs...but at least this time, the auto-declipping worked, so that is good news for you, I suppose...

Again sliders missing in stand alone version.

@Brian:

If your audio is already good (not clipped, or very sporadically), there's of course no need to use the declipper. It depends a lot on the type of music that you're playing, and possibly also where you got it. Sporadic 'red' in the display doesn't even have to mean that there is clipping, it could be incorrect detection as well.

So if you don't need it, just keep it turned off. (Actually, that's even better, because in case of incorrect detection the audio quality may suffer. That's why I'm trying to improve the detection.).


@eldoradofm:

When i set Quality / Precision slider higher then 14.5 in the stand alone version i have a problem with the buffer. It's a little better in the winamp version. Is it possible to better spread the load of this over the cores? Tested with version 40 because with the latest stand alone version the de-clipping is broken.

In 512 latency mode it sounds bad, because a lot more samples get flagged as clipped.