Source-Changes-D archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: audio2
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 <isaki%pastel-flower.jp@localhost / isaki%NetBSD.org@localhost>
Home |
Main Index |
Thread Index |
Old Index