Stereo Tool :: Stereo Tool 6.10

One of the filters that's used a lot in the declipper is more expensive on AMD than on Intel.

@Brian: The declipper uses a huge amount of processing power - I know, I'm working on improvements. The S protection also used a lot of extra CPU power - most of that should be gone now (I'll try to upload the latest version in a moment using my laptop and a somewhat unreliable unprotected wireless connection from one of my neighbours).

What I said is that the GUI *SHOULD* not cause a CPU load increase. *SHOULD*. If it does, something really strange must be going on. I don't know what it can be - and it doesn't reproduce on my end. That's why I'm asking so many questions - I don't see anything here.

Ow, and I just noticed: AMD. That makes sense. One of the filters that's used a lot in the declipper is more expensive on AMD than on Intel.

Beta 34 took care of the GUI / S-Protection issue... You might take a further look at what you did, if you're curious as to what was going on...

I don't think there was ever an official conclusion to the thread where we were talking about the Intel compiler and whether or not it was penalizing AMD processors...but I don't really have a need for the declipper, at least not right now, so I'm not concerned about it.

I don't know how many Pentium 4 / Athlon64 systems you may have running your software, but my system is pretty much the fastest of that single-core era, as I'm running overclocked and with DDR-500 memory instead of the normal DDR-400. Only the P4 Prescott series processors are going to be faster...and then only slightly. So, if I'm struggling, then it's likely that many others with P4/A64 are also struggling, but like I said, I don't know how much of a user base remains on this admittedly older architecture.

Quote:

Beta 34 took care of the GUI / S-Protection issue... You might take a further look at what you did, if you're curious as to what was going on...

I only reduced the number of processing steps - everything is still there, just a bit less often.......

Quote:

No, but it at least seemed a lot like the AMD's were running at much slower speeds than expected. Anyway, the declipper is an extra feature, I always try to keep existing features at or below the CPU load of previous versions (even if there are improvements), which isn't always possible. But new features - especially features that have (depending on the input material!) such a big impact on the audio can of course be more CPU intensive.

Quote:

Makes sense. Those machines are starting to become dated (the most recent versions of the IPP library - JesseG already mentioned it - don't even include hand-optimized code for them anymore!). But I want to try to keep supporting them for as long as I can.

beta33 Testing FM Output...

@Brian: singlecores are very dated, even if you own a very fast one, they never have the power of a medium quadcore. I know, you would need to buy everything new, but its worth it.

Author:	JesseG [ Sun May 08, 2011 5:04 am ]
Post subject:	Re: Stereo Tool 6.10
Quote: One of the filters that's used a lot in the declipper is more expensive on AMD than on Intel. IPP? Check out FFTW. Basically as fast as IPP (slightly more slightly less on different dimensions and types), but also fully optimized for AMD too. http://www.fftw.org/ If you meant something else then... still happy to spread the word about FFTW.

Author:	Brian [ Sun May 08, 2011 5:19 am ]
Post subject:	Re: Stereo Tool 6.10
Quote: @Brian: The declipper uses a huge amount of processing power - I know, I'm working on improvements. The S protection also used a lot of extra CPU power - most of that should be gone now (I'll try to upload the latest version in a moment using my laptop and a somewhat unreliable unprotected wireless connection from one of my neighbours). What I said is that the GUI SHOULD not cause a CPU load increase. SHOULD. If it does, something really strange must be going on. I don't know what it can be - and it doesn't reproduce on my end. That's why I'm asking so many questions - I don't see anything here. Beta 34 took care of the GUI / S-Protection issue... You might take a further look at what you did, if you're curious as to what was going on... Edit: So you get an idea, GOM Player loads StereoTool too. Before B34, I could not play videos in GOM without the audio going out of sync. Now, it works just fine. Maybe a small added delay, but I might be able to deal with that by going down to 2048 instead of 4096... Quote: Ow, and I just noticed: AMD. That makes sense. One of the filters that's used a lot in the declipper is more expensive on AMD than on Intel. I don't think there was ever an official conclusion to the thread where we were talking about the Intel compiler and whether or not it was penalizing AMD processors...but I don't really have a need for the declipper, at least not right now, so I'm not concerned about it. I don't know how many Pentium 4 / Athlon64 systems you may have running your software, but my system is pretty much the fastest of that single-core era, as I'm running overclocked and with DDR-500 memory instead of the normal DDR-400. Only the P4 Prescott series processors are going to be faster...and then only slightly. So, if I'm struggling, then it's likely that many others with P4/A64 are also struggling, but like I said, I don't know how much of a user base remains on this admittedly older architecture.

Author:	hvz [ Sun May 08, 2011 5:51 am ]
Post subject:	Re: Stereo Tool 6.10
Quote: Beta 34 took care of the GUI / S-Protection issue... You might take a further look at what you did, if you're curious as to what was going on... I only reduced the number of processing steps - everything is still there, just a bit less often....... Quote: I don't think there was ever an official conclusion to the thread where we were talking about the Intel compiler and whether or not it was penalizing AMD processors...but I don't really have a need for the declipper, at least not right now, so I'm not concerned about it. No, but it at least seemed a lot like the AMD's were running at much slower speeds than expected. Anyway, the declipper is an extra feature, I always try to keep existing features at or below the CPU load of previous versions (even if there are improvements), which isn't always possible. But new features - especially features that have (depending on the input material!) such a big impact on the audio can of course be more CPU intensive. Quote: I don't know how many Pentium 4 / Athlon64 systems you may have running your software, but my system is pretty much the fastest of that single-core era, as I'm running overclocked and with DDR-500 memory instead of the normal DDR-400. Only the P4 Prescott series processors are going to be faster...and then only slightly. So, if I'm struggling, then it's likely that many others with P4/A64 are also struggling, but like I said, I don't know how much of a user base remains on this admittedly older architecture. Makes sense. Those machines are starting to become dated (the most recent versions of the IPP library - JesseG already mentioned it - don't even include hand-optimized code for them anymore!). But I want to try to keep supporting them for as long as I can.

Author:	Brian [ Sun May 08, 2011 6:27 am ]
Post subject:	Re: Stereo Tool 6.10
Quote: Quote: Beta 34 took care of the GUI / S-Protection issue... You might take a further look at what you did, if you're curious as to what was going on... I only reduced the number of processing steps - everything is still there, just a bit less often....... Well, the increase now is within a few percent, and the issue I mentioned about GOM Player has been taken care of... Quote: Quote: I don't think there was ever an official conclusion to the thread where we were talking about the Intel compiler and whether or not it was penalizing AMD processors...but I don't really have a need for the declipper, at least not right now, so I'm not concerned about it. No, but it at least seemed a lot like the AMD's were running at much slower speeds than expected. Anyway, the declipper is an extra feature, I always try to keep existing features at or below the CPU load of previous versions (even if there are improvements), which isn't always possible. But new features - especially features that have (depending on the input material!) such a big impact on the audio can of course be more CPU intensive. Yes, but the CPU usage kept increasing over time, much more than I felt that there was value being added. That's why I was asking about newer features yet to come, like the Dynamics Booster, and how much estimated CPU usage it would add, because I felt it was already at the maximum level that I could really accept for the value being added to the product. Beta 34 returns the usage back to approximately where it was with 6.10, so that seems to be an increase that is worth the added value (not including the declipper). Quote: Quote: I don't know how many Pentium 4 / Athlon64 systems you may have running your software, but my system is pretty much the fastest of that single-core era, as I'm running overclocked and with DDR-500 memory instead of the normal DDR-400. Only the P4 Prescott series processors are going to be faster...and then only slightly. So, if I'm struggling, then it's likely that many others with P4/A64 are also struggling, but like I said, I don't know how much of a user base remains on this admittedly older architecture. Makes sense. Those machines are starting to become dated (the most recent versions of the IPP library - JesseG already mentioned it - don't even include hand-optimized code for them anymore!). But I want to try to keep supporting them for as long as I can. Well, unless you have something gee-whiz-bang to add, I'm about at the point where I doubt there could be much more enhancement in sound quality that I could hear. I might be able to measure a difference via software at the waveform level, but not just hear it with my ears. It was really already that way with the S-Protection. You all were claiming it was better than the de-esser, but I don't think I can really hear a difference...

Author:	Brian [ Sun May 08, 2011 6:54 am ]
Post subject:	Re: Stereo Tool 6.10
Quote: beta33 Testing FM Output... Now that the CPU usage is under control, are you saying that the extreme highs protection is only useful for FM broadcasting? If so, why? Have you tried modifying B-Town__Web with the new filter, or are you still using just the de-esser?

Stereo Tool https://forums.stereotool.com/

Stereo Tool 6.10 https://forums.stereotool.com/viewtopic.php?t=3065	Page 38 of 213

Author:	Vortan [ Sun May 08, 2011 10:27 am ]
Post subject:	Re: Stereo Tool 6.10
Tried the beta34. Declipper does not stutter anymore, CPU load lowered ~2%. Agc on/off doesnt really change anything, the knacking is still there, even without declipper. I use Bojchas Addiction V11 preset (the best in 6.00 imo) - maybe you can test your music with that preset. @Brian: singlecores are very dated, even if you own a very fast one, they never have the power of a medium quadcore. I know, you would need to buy everything new, but its worth it.

Author:	hvz [ Sun May 08, 2011 11:45 am ]
Post subject:	Re: Stereo Tool 6.10
@Vortan: I just compared your 1st and 2nd track, and the 2nd is clearly louder (I also measured the difference, on average it's 0.6 dB, in softer parts it's around 0.9 dB. This indicates that the input level for Loudness (which is the most likely cause of the issue with the highs that you describe) must have been around 1 dB louder in 6.20 BETA033 than in 6.00. Lowering the Final Limiter level by 10% in 6.20 should compensate for that. This might not completely solve it though - there are also clippers in Multiband, if the audio is already louder there (and I expect that it is), those clippers will also add (some) distortion. So I would suggest lowering the AGC output level - but I don't know how much (AT LEAST 1 dB, but probably a bit more). I still have to check why this difference is there, but it's very likely that this is the cause. There are also some other things that may affect the audio, but if anything I would expect it to be cleaner instead of scratchier. And like I said: I tested the 6.00 Loudness vs 6.20 (all other filters off), and the difference is mainly in the lows-mids.

Author:	Vortan [ Sun May 08, 2011 12:17 pm ]
Post subject:	Re: Stereo Tool 6.10
Yes, you´re right. 6.00 reduce the loudness more than actual betas. Now i turned off nearly everything except multiband compressor, and it was still there. So i decided to listen the .mp3 original without Winamp or anything else - and if i turn it very loud, i can still hear it. Maybe ST is just fine, it just amplifies that knacking. Some songs does have it, some other does not.

Author:	Brian [ Sun May 08, 2011 9:27 pm ]
Post subject:	Re: Stereo Tool 6.10
Quote: @Brian: singlecores are very dated, even if you own a very fast one, they never have the power of a medium quadcore. I know, you would need to buy everything new, but its worth it. Not an option... I'm unemployed...

Author:	hvz [ Mon May 09, 2011 8:50 am ]
Post subject:	Re: Stereo Tool 6.10
BETA035: "Advanced highs protection" settings moved (window should fit on smaller displays again) and saved to disk. Default settings changed. No further changes. Winamp DSP plugin: http://www.stereotool.com/download/dsp_ ... 20-035.exe Stand alone version: http://www.stereotool.com/download/ster ... 20-035.exe VST version: http://www.stereotool.com/download/vst_ ... 20-035.dll VST version (No SSE2): http://www.stereotool.com/download/vst_ ... 20-035.dll Command line version: http://www.stereotool.com/download/ster ... 20-035.exe Linux command line version: http://www.stereotool.com/download/ster ... ETA620-035 NOT AVAILABLE Linux GUI version: http://www.stereotool.com/download/ster ... ETA620-035 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 - Finish declipping filter (clipping level detection + level reduction in dB). 2 days - Update presets? (BASS_AGC etc.) 1 day - Finish blind 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

Page 38 of 213	All times are UTC+02:00
Powered by phpBB® Forum Software © phpBB Limited https://www.phpbb.com/