Integer is King? - final thoughts about the EQ challenge

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

#The fREaK! wrote:
aciddose wrote:(are those qubits ints or floats? :shock:)
Both. :wink:
:lol:
Cakewalk by Bandlab / FL Studio
Squire Stratocaster / Chapman ML3 Modern V2 / Fender Precision Bass

Formerly known as arke, VladimirDimitrievich, bslf, and ctmg. Yep, those bans were deserved.

Post

stefancrs; it is good in some situations, i've mentioned that many times already. it can be good if you're not really doing anything which requires linearity. on the other hand, it isnt really that much of an improvement over an absolute noise floor for most things as well.

an example of a place where a relative noise floor is useful is in something like a series of integrators where the scale of the signal isnt normalized at each stage. in each integrator the level of the signal will drop, but thanks to the relative noise floor each integration stage will have the same accuracy. this eliminates the need for normalization between each stage, but it doesnt really do anything else.

it is bad if you're running a single integrator, or normalizing between each stage because it will be non-linear and much lower accuracy than it could be with int. in most cases we _do_ normalize between stages in order to apply other processing, so float doesnt provide an advantage.

scaling down in float doesnt make you lose (much) accuracy. scaling up and translation do. opposite is true in int. scaling down you lose accuracy, with scaling up and translation you dont.

scaling up or down by 2 or 1/2 in float is the same as incrementing or decrementing the exponent, you maintain 100% accuracy there.

i'm putting this in far too simple terms, so what i'm stating isnt 100% correct. it depends upon what type of scaling is being done in both cases.

Post

Thank you very much Aciddose. Your are very open minded.
Much respect.

thorK

Post

Translation is probably one of the biggest issues with floating point, I cannot disagree there :)

Post

thorkz wrote:Thank you very much Aciddose. Your are very open minded.
Much respect.

thorK
Yes, but Thorkz...

You stated the highest quality one to your ears was the 32 bit int.
Christian wrote:
thorkz wrote:]While X and Y for me are both what I'm used from floating point. They both loose bass. Y is a little worse in the high freq distortion department. It gets "foggy" if you tweak to extreme. The sound gets sourrounded by some "clowd" that gets really hot on my ears.
X is somthing in between ( not integer though), it also gets clowdy, but has a little better high end.

To me Z is of much higher quality.

X was floating point (double), Y was integer (int64) and Z was plain integer (normalized to 24bit).
Which even if acidose's conjecture proves to be correct on further investigation, your preferred choice would still be the worst of the lot. In fact you rated int64 as slightly worse in the top end that float64.

So not only did you not display any preference for integer (you liked one integer version more than the float, and one less), but you actually claimed the highest quality for the one which is undoubtedly the lowest quality in any objective measurement (in other words it will have the greatest noise and be the least stable).

So your subjective opinion actually contradicts acidose's reasoning. In fact it appears to contradict pretty much any reasoning, except the one that says you actually prefer more noise and distortion.

(edit: or you prefer the EQ resulting from the less accurate format, which is going to be different and probably less stable).

Post

we still do not know exactly how each of the three were calculated though. i'd need to see the assembly for each option to see that they're all "the same", or point out differences.

even the graphs do not provide an accurate analysis without being generated through the use of bignums. really, all coefficients should be generated with bignums and converted to each data type with bignums using nearest neighbour. some static audio should be processed using doubles, floats, qwords, dwords, and bignums. the results should all be converted back into bignum and then analyzed in bignum using the transforms of each processed clip, the source audio should be analyzed, and the differences between all clips should be analyzed. we should then look at all the differences in frequency and phase information for all clips and decide where the differences are.

after that, double blind testing should be done using randomly selected audio clips where an original audio clip, and four processed versions of the clips are provided. the individual running the test should sort the clips into order from 1...4 in terms of whatever quanta are selected for the test. possible quanta could include enjoyability, bass, treble, clarity, smoothness, or more subjective properties.

we should then attempt to find correlations between the first set of test data and the orders produced in the double blind tests and then explain the function of the correlation between measured differences and listening test results.

i would suggest that the bignum accuracy be set to about 200db (1e-10). we'll also need a sample size on the order of perhaps several decades to get reasonable results.

Post

aciddose, agreed that a more exhaustive test would be neccessary to work out what differences are really present, and what their objective and subjective effects are.

I was just pointing out that the person who said
Integer is King
Also said
While X and Y for me are both what I'm used from floating point. They both loose bass. Y is a little worse in the high freq distortion department. It gets "foggy" if you tweak to extreme. The sound gets sourrounded by some "clowd" that gets really hot on my ears.


And that he said
And all those effects that are "far below the hearing level", as everybody calls them, are not somewhere hidden far behind the signal, they are right there on the surface of the signal! Wanted to say that for a long time.
After he had said
To me Z is of much higher quality.
So actually although I think he was trying to be sarcastic, as far as his own hearing ability is concerned, he appears to have been right when he said
This whole int vs float thang is just a pile of shit!!!!!!!

Post

aciddose wrote:i would suggest that the bignum accuracy be set to about 200db (1e-10). we'll also need a sample size on the order of perhaps several decades to get reasonable results.
That would only amount to 33 bits, Christian's calculation of coefficients with doubles already far exceeds that. Or am I missing something?

Post

I wasnt listening for noisefloor. I was after hiend-clowds and bass weekness.

And I found what I was familiar with in Z. I was really happy about that. And basicly just tripplechecked Z, which sounded the most towards the integer how I knew it to that date.

The Sounddiffs are there.

If I would have known that there is more than one int in this test I would have been more careful I think. But hey. This was a rather quick test. I wasnt sure myself if the diffs would be audible in this "simple" plugin.

But yeah, your right. I chose int32 over int64, maybe by accident, maybe not. May be that I prefere a balanced quantisation noise even over the tracks I record after all those floatingpoint plugs I tried :D

But what also might have caused confusion, was the song I was listening to. I forgot it has some bad samples in it. Some old soundfonts from the internet with wierd high-end stuff. I guess those cutting through more in int64 than in int32 where not really good for judging an unknown compedetor for his high end.

finding the int was the challange for me. I'm not so much into code that I would have ever been able to say: thats int64.

If you want I can do a relisten of int32 vs int64 and try to describe what I hear. Of course that would be a totally different situation and if that would be of any use is up to you.
I think though, if you are happy with the sound floating provides how can I expect you to change anything. Even a "better" test could not have convinced you. And how could it.


thorK

Post

It's not just that you chose int32 over int64, it's that initially (without the benefit of knowing what was what), you chose float64 over int64, so it apparantly isn't some kind of "intness" you're liking. You are also not liking less noise, which sort of makes it doubly interesting from a psychoacoustics point of view.
Note that I'm not saying you can't hear a difference, I'm saying that your own results tend to suggest that your hypothesis that the difference is down to the use of ints over floats is incorrect.

However aciddose's ideas have got me thinking about certain things, and they definately bear further investigation. I have to program DSP on a range of systems, some very constrained (try programming an MP3 decoder on a processor with only a 16 bit int multiply, not enough MHz and a rather shitty set of shift instructions if you ever want a challenge), so knowing what people can hear and how much is very useful to me to get the maximum quality in any given set of circumstances).

If I have time to code it I hope you'll join in with the test I have in mind.

Post

Hi thorkz,
thorkz wrote: The Sounddiffs are there.
Would you do a blind test? With processed .wav files?
thorkz wrote: But what also might have caused confusion, was the song I was listening to. I forgot it has some bad samples in it. Some old soundfonts from the internet with wierd high-end stuff. I guess those cutting through more in int64 than in int32 where not really good for judging an unknown compedetor for his high end.
Again, would you do a blind test with processed .wav files?
thorkz wrote: If you want I can do a relisten ...
I think though, if you are happy with the sound floating provides how can I expect you to change anything. Even a "better" test could not have convinced you. And how could it.
thorK
Would a real blind test convince YOU?

I would provide some .wav files and you tell which of the 3 eqs was used. Deal?

Shogger

Post

jon, i figured that 200db would be reasonable for the ranges we're concerned about, although nothing would stop us from setting this to any arbitrary range if we were to use a bignum library for it. the reason i suggested bignums isnt to get a lot of extra range, but rather to make sure the calculations are all uniform. calculating the coefficients in each format might introduce error into the coefficients and the idea of one having "more bass" doesnt seem so far fetched then.. it might literally have had more bass due to the coefficients being different.

if we're doing the fourier analysis in doubles we'll have all the non-linearity issues happening which may create some additional noise. doing the analysis in bignums would prevent any format-induced error from occurring.

you might be right though, it might actually be best to use something like 400db as a default if we're concerned about getting 100% of the possible range.

Post

shogger, i think the three-eq test is flawed anyway. also, if you were to give him the files it wouldnt be double-blind. also it wouldnt prove much what thorkz says since he seems a bit nuts and is also only a single subject, we need several decades like about 30 or 40.

Post

oh fer f**ks sakes don't feed the troll folks. :bang: some of you are spending an awful lot of time typing high grade explanations to obvious wind up trollage questions.

would've thought the "intel sounds better than AMD" bit was clue enough.

Post

Kingston wrote:oh fer f**ks sakes don't feed the troll folks. :bang: some of you are spending an awful lot of time typing high grade explanations to obvious wind up trollage questions.

would've thought the "intel sounds better than AMD" bit was clue enough.
The problem is, even if he is kidding...

There are people who will believe it...

And then they tell other people...

Post Reply

Return to “DSP and Plugin Development”