Stereo Tool

Thought it would all end with my last post.
Well ideally if you can't tell one from the other on your setup, I don't expect posting records would help the cause either.

As for the effort and band-width it would require to upload two 32 bit IEEE wav files, count me as the last person to do so. I already did something simliar in the past when I found distinction between the processed sound of VST plugin and Winamp DSP plugin - which in this case was dismissed as a difference in bit depths.

All in all, if you don't perceive anything, please don't trouble yourself

_________________
visit website

The code that was posted allows for a float, but explicitly casts the value into an int. If you want to try for a crash, try putting an alpha or special character in there instead of numerics.
Most likely, this is the case, although I'm sure there'll be vociferous arguments.
Yeah, other places need to be checked to make sure the value isn't read in or referenced elsewhere.

4096, 8192, 16384.. etc.. No single difference in quality in any filter. period.

Based on the code posted, that's expected. The only possiblity of a difference is if the value is referenced elsewhere, either through a new file read or assignment variable / pointer. If what was posted is the only reference, then any non-defined value will fall into the default statement, which makes it 4096.

Ok.
Internally there is no difference.
But what does the host know about that latency setting ?
Internally Stereo Tool ignores those higher values in STS and use instead 4096 samples.
Ok.
But maybe the host still gets the information about those higher latency settings and allocate more buffers (higher priority) ?

I have tested some WAVs.
First it seemed that these tests could prove the quality differences:
The foobar bitcompare component showed more than one hundred thousand different samples.
But after some additional tests I found out that it is not possible (on my system) to write identical WAV files with Winamp/Foobar with Stereo Tool DSP enabled:
Even my 4096 1st run, 4096 2nd run, etc. files have differences !

What else should I use to create the WAV files ?
The CLI version ?

Can you create identical files with Winamp/Foobar and the Stereo Tool DSP (using identical processing settings) ?

Check the WAVs with the foobar bit compare component.
The bit compare component works correctly.
I have used it intensively for CD ripping comparisons and to compare and prove that the results of different LAME 3.93.1 builds are identical:

http://www.claessonedwards.com/forum/vi ... f=5&t=1749

Bojcha, you are the dude! Period.

_________________
visit website

That is true for version 6.21.

But now I have tried version 6.20beta77 and that creates identical WAVs with Winamp/Foobar when I use identical STS settings.
With that version processing 4096 1st run, 4096 2nd run, etc. files I get bit identical WAVs.
And bit identical results with higher latency settings in STS (4096 = 8192 = 16384 etc.) !

So, yes what Bojcha wrote is 100 % true.
There are no (internal) processing differences with forced higher latency settings in STS (at least with versions older than 6.21).

So is this the end of the story ?
No !

Why is it impossible with my (old) AMD based system to create identical WAVs with version 6.21 (though older versions work correctly) ?
Some of the processing (new vocals protection ?) seems to create somehow random data with my AMD X2 6000+ CPU.
So what change from version 6.20 (or 6.00) to 6.21 causes this random differences in the resulting WAVs ?
Is it only a problem for old AMD systems ?

Most important:
There are definetly quality differences with higher non-standard latency settings in STS files during realtime listening.
It is not placebo !
So I (still) believe it is not caused by Stereo Tool and its internal processing, the differences Phoenix and I hear are based on the host and the allocated process priority.
I guess internally Stereo Tool indeed ignores those higher latency settings in STS files, but the host application gets an information about that latency value in STS and therefore allocates a much higher realtime priority.
That causes the higher quality Phoenix and I hear with higher latency settings in STS.


@ Phoenix

I will send you a very interesting PM soon (in 2 or 3 hours) !

Hello everyone,

I don´t understand the techno talk in this thread, but i think this is a wonderful preset.
Testing it on a stream now.
I think that most people listen to web-radio on rather cheap loudspeakers. 30-50 euro/dollar, the Logitech, Creative stuff. So it must sound best on this kind of equipment.
Maybe you experts can listen to it for a bit. It's classic disco. Thank you in advance.

There's no website, but I've pasted an URL here. Click listen

http://178.20.171.115/index.html

Simply " Perfect " thanks for another perfect preset Phoenix

_________________
http://www.kanal80.net
Best 80's & 90's Music

Oops, I completely forgot about this thread - sorry!

The piece of code that I pasted is the only place where the values is being read - any other location where this value is used (this includes feedback to the host for VST hosts) is based on the actual delay value (which can even be different from the selection, in some cases).

@phoenix: Actually, your 16 vs 24 bit post has given me an idea for a new filter that I want to make: A bit depth increaser. So basically a filter that takes 16-bit audio and converts it to - say - 18 or 19 bit. Not by adding zeroes, but by reconstructing useful data.