At Sat, 25 May 2019 18:01:11 +0300, Valery Ushakov wrote: > Speaking in the abstract: The operation that happens here is > rescaling, as far as I understand. Yes, the two-complement ranges are > lopsided with an extra value on the negative side, but that is far > less important, I think, than commuting with negation. If you negate > all samples, you have basically the same audio > https://manual.audacityteam.org/man/invert.html ("invert" is a bit > unfortuante as a name b/c of the confusion with the bitwise > operation), so it's nice to have: > > -scaleN(sample) = scaleN(-sample)
Partially, yes. If I make an userland offline waveform editing software on modern arch, and the output wave can be used as another input, I may do so. But this is in-kernel online(realtime) processing including m68k and the output is final stage that human hear. > > The correct operation is not exist whenever rounding to integer > > occurs. > > > > And in audio area, we need to understand that both rounding > > are not correct but are acceptable. > > I think you are confusing correctness and precision here. What is your correctness and precision here? > My point is exactly that you are confusing implementation detail that > uses right shift as a good enough implementation (which, I reiterate, > I don't object to here) and what is the meaning of the operation that > you are implementing/approximating (see my first paragraph above). I'm sorry, I don't understand (I can't parse) this paragraph due to my poor English skill. Would you write it again? And anyway I don't understand your point well. Can you show me your proposal patch? Thanks, --- Tetsuya Isaki <is...@pastel-flower.jp / is...@netbsd.org>
