[Pd] Complex audio signals

[Chuckk Hubbard]

On 6/22/06, Mathieu Bouchard <matju at artengine.ca> wrote:
> On Wed, 21 Jun 2006, Chuckk Hubbard wrote:
>
> >> The mapping is only perfect in the (Real-based) Complex numbers and also
> >> in the Algebraic-numbers-based Complex numbers. However those systems are
> >> more difficult to compute with, so you find them in only a few apps, such
> >> as Mathematica and Maple. (Not even in Matlab, if I'm not mistaken).
> > I guess the question is, can anyone hear the difference?
>
> No, your question was, is the mapping exactly 1-to-1 ? Well, it's not.
> However you won't actually hear a difference unless you really want to. If
> you want to hear a difference, use [-~] to take the difference between the
> original signal and the one that's supposed to be identical. Then use [*~
> 1000000]. You might be able to hear some noises.

I tried that, couldn't hear it.


>
> If you're one of those people who think they hear the difference between
> 16-bit and 24-bit audio, you might not need the [*~ 1000000] ;-)
>
> >> The reconstructed signal will be fine. If instead of sin(440t) you get
> >> sin(420t)+0.2*sin(460t)+0.04*sin(500t)+... (completely made up example)
> >> then this only means that the latter is the closest approximation to the
> >> former in the context of that particular block size.
> > Can it be heard?
>
> The closest approximation is actually as exact as above. The reconstructed
> signal will sound like sin(440t) but only within that block. The
> continuation of sin(440t) to another block won't have the same FFT.
> Looping one block of that sin(440t) over and over won't sound like
> sin(440t) because what you're doing in effect is chopping parts of
> sin(440t) so that it becomes blocksize-periodic.

The reconstructed signal seems to sound fine, even with 4 detuned
oscillators far from block size, ignoring the actual values of the
FFT.

Thanks.
Chuckk