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

Stereo Tool 6.10
https://forums.stereotool.com/viewtopic.php?t=3065		 Page 52 of 213
Author:  hvz [ Tue May 24, 2011 4:37 pm ]
Post subject:  Re: Stereo Tool 6.10
Well, cache is definitely an important factor - that's why the performance improvement on Multiband by splitting the channels failed, even though all the samples need to reorganized for each band of the multiband in the current implementation. If cache was no issue, splitting the left and right data should have given a considerable performance boost.
Author:  michi95 [ Wed May 25, 2011 12:31 am ]
Post subject:  Re: Stereo Tool 6.10
Quote:
...what I'm mentioning really does help EVERYONE, not just me.
Yes, I agree. :)
I think that my "aggressive tone" has led to an interesting discussion here.
IMO we have much more consensus than antithesis.
Quote:
Quote:
Quote:
What about December 21, 2012?
aha, this is the real reason for an old PC.
I'm trying to avoid the Y2.012K bug... :lol:
The only way to avoid that, is to use a MAYA soundcard !
Author:  Brian [ Wed May 25, 2011 3:21 am ]
Post subject:  Re: Stereo Tool 6.10
Quote:
Quote:
...what I'm mentioning really does help EVERYONE, not just me.
Yes, I agree. :)
I think that my "aggressive tone" has led to an interesting discussion here.
IMO we have much more consensus than antithesis.
Perhaps. My line of thinking is that if AMD had made such a thing as my same processor core (Athlon64 3700+ San Diego revision), but it was equipped with at least 2MB cache, but probably more towards 4MB cache, I wouldn't notice any issue, much like those of you who have newer processors. As Hans keeps adding things, it ends up being too much to run inside the 1MB cache that my processor has, and thus has to go out to main memory, causing the CPU to stall waiting for main memory. If he doesn't optimize and then starts exceeding the capacity of processors with 2MB cache per core, they'll start noticing the performance hit too.

It really does pay off to optimize any kind of realtime processing to as small a memory footprint as possible, that way there is more overhead for future features, as well as overhead to handle additional load from other programs that happen to be running at the same time.
Quote:
Quote:
I'm trying to avoid the Y2.012K bug... :lol:
The only way to avoid that, is to use a MAYA soundcard !
Nah... Too much inca in their manuals...
Author:  michi95 [ Wed May 25, 2011 4:25 am ]
Post subject:  Re: Stereo Tool 6.10
Quote:
The only way to avoid that, is to use a MAYA soundcard !
Quote:
Nah... Too much inca in their manuals...
:arrow:
http://www.digonsite.com/drdig/mesoamerica/10.html
http://www.adishakti.org/mayan_end_time ... 1-2012.htm
Author:  Brian [ Wed May 25, 2011 4:57 am ]
Post subject:  Re: Stereo Tool 6.10
Quote:
Quote:
The only way to avoid that, is to use a MAYA soundcard !
Quote:
Nah... Too much inca in their manuals...
:arrow:
http://www.digonsite.com/drdig/mesoamerica/10.html
http://www.adishakti.org/mayan_end_time ... 1-2012.htm

Too much Inca....

Bad pun phail... :oops:
Author:  hvz [ Thu May 26, 2011 11:54 am ]
Post subject:  Re: Stereo Tool 6.10
In case anyone is interested: I *think* I have improved the declipping filter to better handle MP3 files. MP3 files have some specific issues that are not present if no MP3 encoding step has been performed. This makes it impossible to perform perfect restorations. In some cases it helps to remove MORE samples than just the ones that appear to be clipped. But in other cases doing that hurts the quality - a lot.

So I've tried to device an in-between solution, that - based on the audio that I've tested with so far (and those tests were very limited), seems to combine the best of both strategies.

I've also added some extra information to the reconstruction process, which causes distorted (vibrating) 'S' sounds to be restored better. However, if I am too strict about this, in many cases reconstruction leads to a flat line - so I had to tone it down a bit. (If I can fix this, the audio will be a lot better!)

The result of this can be found in BETA620-044. I'm not going to create a separate post for this one because I haven't had time yet to test it thoroughly. But if you're already using the declipper in your current stream AND you're playing MP3 (lossy compressed) files, this thing MIGHT sound a bit better. But due to the issues that I mentioned I'm not really sure at the moment - I think I need to fix them first...

2 new sliders are present: Samples that are 'close to' samples that are detected as clipped (close to in position and value) are also marked as clipped. One slider indicates how much LOWER the sample value may be, the other how many samples to the left and right are considered (set to 0 to turn the MP3 feature off).
Author:  garfield [ Thu May 26, 2011 12:43 pm ]
Post subject:  Re: Stereo Tool 6.10
Hans => excuse me hans :oops: , but i don't see links for the beta BETA620-044 ?
Author:  hvz [ Thu May 26, 2011 12:57 pm ]
Post subject:  Re: Stereo Tool 6.10
That's on purpose... You know the URL from previous versions, right?
Author:  garfield [ Thu May 26, 2011 1:00 pm ]
Post subject:  Re: Stereo Tool 6.10
hans => ok it's good ;)

i try the new beta on my stream :D
Author:  hvz [ Fri May 27, 2011 10:48 am ]
Post subject:  Re: Stereo Tool 6.10
The declipper is in some cases still too greedy. I think I have now *finally* found a solution: If I restore a clipped area and the peak level is not (much) higher than before, apparently it wasn't clipped, and I shouldn't declip it... (Until now I checked for the AVERAGE level, but in some cases the peak is replaced by a valley, with some edges sticking up on the sides. And then this fails completely).

*Maybe* I should also check for deep valleys, or for a big change in average value.

Will try to build that in ASAP, if it works I think the declipper is more or less finished (apart from 2 other issues that are already on the todo list).
Page 52 of 213 All times are UTC+02:00
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/