So this a trivial note, but as someone with more familiarity with programming than sound engineering, I’d leave out the part about floats being easier and faster for computers to handle from the discussion on why 32 bit floats are the default. I certainly wouldn’t lead off the explanation with that, as its often the reverse(integers are often faster/easier for computers but not always - I’m not an expert but that’s how I learned it).
The other reasons for using floats in that section seem valid to me, and sufficient enough to justify using floats. So I am not at all suggesting the default should be integers, I doubt it would make a noticeable difference performance-wise for computers anyway. But it struck me as less then correct, or at least misleading.
The other reasons for using floats in that section seem valid to me, and sufficient enough to justify using floats. So I am not at all suggesting the default should be integers, I doubt it would make a noticeable difference performance-wise for computers anyway. But it struck me as less then correct, or at least misleading.
I’m not an expert either… I’ve done quite a bit of programming but I’ve never done any DSP. But from what I do know about DSP there is a lot of summation involved and you can easily overflow integers. And of course, multiplication and division are “easier” in floating point too.
It’s definitely a fair point about division, that much I know. And I’m sure people with a lot more knowledge could duke it out over the topic, but looking into it a bit, it still seems to be the consensus that in ‘general’, performance still favors integers - albeit, not as much as in the past.
It’s pedantic to mention it maybe, but just saying if I were to write that help section I wouldn’t mention performance - for one there are better reasons (the ones related to sound engineering/editing), and two it’s not always true.
Audacity uses SSE, which can greatly speed up floating point operations, and internally Audacity always uses floating point arithmetic when processing (if the sample values are integers, they are converted to 32-bit float for processing, then converted back to integer).
Running some benchmarks: On my machine, processing time for 16-bit tracks is about 200% to 700% slower than for 32-bit float tracks (depending on what processing is being done). Most of the extra time appears to be due to the conversion from floating point back to integer.
However, unless processing very large projects that difference is likely to be (almost) insignificant.
I agree. Although (in the case of processing) performance is a factor, it is pretty minor. Clipping and dither / quantize errors are far more important from a user point of view.
If you can post a link to the relevant section of the manual, we will update it for the next version.