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