#The fREaK! wrote:Both.aciddose wrote:(are those qubits ints or floats?)
Integer is King? - final thoughts about the EQ challenge
- KVRAF
- 2187 posts since 25 Jan, 2007 from the back room, away from his wife's sight (or so he thinks)
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.
Squire Stratocaster / Chapman ML3 Modern V2 / Fender Precision Bass
Formerly known as arke, VladimirDimitrievich, bslf, and ctmg. Yep, those bans were deserved.
- KVRAF
- 12615 posts since 7 Dec, 2004
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.
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.
-
- KVRAF
- 4738 posts since 20 Feb, 2004 from Gothenburg, Sweden
Translation is probably one of the biggest issues with floating point, I cannot disagree there 
Stefan H Singer
https://dropshotaudio.com/
https://dropshotaudio.com/
-
- KVRian
- 770 posts since 2 Apr, 2003
Yes, but Thorkz...thorkz wrote:Thank you very much Aciddose. Your are very open minded.
Much respect.
thorK
You stated the highest quality one to your ears was the 32 bit int.
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.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).
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).
- KVRAF
- 12615 posts since 7 Dec, 2004
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.
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.
-
- KVRian
- 770 posts since 2 Apr, 2003
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
And that he said
I was just pointing out that the person who said
Also saidInteger is King
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
After he had saidAnd 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.
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 saidTo me Z is of much higher quality.
This whole int vs float thang is just a pile of shit!!!!!!!
-
- KVRian
- 770 posts since 2 Apr, 2003
That would only amount to 33 bits, Christian's calculation of coefficients with doubles already far exceeds that. Or am I missing something?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.
-
- KVRist
- 86 posts since 14 Jan, 2007 from around
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
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
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
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
-
- KVRian
- 770 posts since 2 Apr, 2003
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.
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.
-
- KVRAF
- 2665 posts since 11 Jun, 2007
Hi thorkz,
I would provide some .wav files and you tell which of the 3 eqs was used. Deal?
Shogger
Would you do a blind test? With processed .wav files?thorkz wrote: The Sounddiffs are there.
Again, 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.
Would a real blind test convince YOU?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
I would provide some .wav files and you tell which of the 3 eqs was used. Deal?
Shogger
- KVRAF
- 12615 posts since 7 Dec, 2004
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.
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.
- KVRAF
- 12615 posts since 7 Dec, 2004
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.
- KVRAF
- 6478 posts since 16 Dec, 2002
oh fer f**ks sakes don't feed the troll folks.
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.
would've thought the "intel sounds better than AMD" bit was clue enough.
-
- KVRian
- 770 posts since 2 Apr, 2003
The problem is, even if he is kidding...Kingston wrote:oh fer f**ks sakes don't feed the troll folks.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.
There are people who will believe it...
And then they tell other people...
