On Wed, 27 Sep 2006 23:14:54 +0100 (BST) Tas Pas tprotopgr@yahoo.gr wrote:

As "clicks" I mean what in the pd/doc/B09.loop.smooth.pd we try to avoid when the phase wraps around.

I noticed in a wave file with a "click", that we have a steep drop of the ampitude. The amplitude of each sample is near (in amplitude value) to the one before and next to it, but the sample that produces the click has an amplitude that is not near to the preceeding sample's amplitude value.

That's a pretty good definition of a click. It's a discontinuity in the signal.

Maybe that is what produces the clicks...

So new questions may rise (if I am correct in my speculations)...

Is there a "safe" amount of amplitude change in a sample comparably to the amplitude of the previous and the next sample's amplitude, in order to avoid "clicks"?

Is there a way to prevent clicks when a wave loops in an arbitrary range?

It depends very much on the source signal you loop, some noisy sounds that are already very full of buzz and clicks can be looped easily and the click doesn't matter. Whether you hear the click depends on the size of the jump compared to the dynamic range of the rest of the signal. It will sound worse on pure tones. It sounds worse on low frequency sounds or ones with a strong low fundamental. It can happen even when the sound is apparently silent if you have a DC offset. The oldest trick is to crossfade the end and start points, a la early samplers like the Fairlight, Mirage, and Akai which introduced crossfade looping. You could work out some magic number for the least audiable click sound using psychoacoustic metrics, but from experience it's about 2 or 3 hundred in 65536 (for 16 bits) or about 0.25% fsd, anything above that you can usually hear. If you think about why it happens it is obvious - the chances of the end of a loop finishing on the exact value the loop starts with is small. For most musical applications you can just cut the loop visually, start on a rising positive phase (crossing zero going up) and end on the zero of a negative, rising cycle (so they wrap round nicely). Just getting the zeros isn't enough, if you are out of phase it will still click like a bastard. The perfect loop length then is an integer multiple of the period of one cycle. In theory, once you've got that size you can move it about over the sample with impunity. In practice, with real recorded sounds, that doesn't happen but you can find sweet spots by hand where it does work. If you need exactly sized tables for a wavetable synth or something then you will probably have to use timestretching too, because there is probably no solution of two correct zeros that just happen to be a perfect block size. What are you looping? Beats or musical tones, it makes a difference to which technique is best.

Remind me again what Hilbert does for us Chuck, shifts all the "negative" frequencies relative to its application by -pi and all the "positive" frequecies by +pi so sin(t) -> -cos(t) and cos(t) -> -sin(t) ?? How does that give us a measure of phase change?

Any reconstruction has to be of the entire sample afaics. But if you think of an efficient way to work locally on a small part of a file (specifically the ending) and operating backwards samplewise turn a small time error into a frequency error spread out to be imperceivable you have a useful piece of software. The use would be to simply make the signal end (and start) on a zero of known phase. Do that and editing jobs that has to be done by hand on cut and spliced musical clips get more fun :) But anything like that would have application in a sampler as "automatic best loop" finder. A Roland I used to have did an autocorrelation type thing to blend out of phase loops nicely, if I remember it worked ok for long windows of about 2 seconds, but was rubbish for short loops.

I always wanted to see a feature in protools, hey maybe Ardour will have it one day... where you are trying to align two clips and you want it to snap to the phase of the signal above (which a human can obviously see when zoomed in enough), it just has to look at the a little bit of the audio in each section and line them up for the most coherency at the start of the block, right?

I digress, so Hilbert can be a phase comparator (or can be used as one)?

On Wed, 27 Sep 2006 20:26:08 -0500 "Charles Henry" czhenry@gmail.com wrote:

...

Just getting the zeros isn't enough, if you are out of phase it will still click like a bastard.

I just thought I'd submit my half-formed analysis idea for this.... We can use the Hilbert transform to capture the instanteous phase of the signal, so we might could use it to detect phase discontinuities. If so, the phase could be smoothed out by using a running average filter over the location of the discontinuity, and then the signal could be reconstructed.

Chuck

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Yeah, I'm not getting much joy from that either :/ But it's still instructive to follow your implementation from fft. There is actually a [hilbert~] unit available, which is why I am interested.

I'm somewhat familiar with the principle I think, at least in practice as a "phase shifter" for removing sidebands with a quadrature mixer etc, but even though I understand Hilbert is fundamental there's a big hole in my maths in that subject, around about the point I fell asleep in engineering maths lectures.

Can you give a description, in words rather than equations if possible please, how Hilbert arises and why its central to complex signals. Maybe with another example of why you would use the transform for a practical purpose.

One thing that confuses me right now is how you can have a phase signal? Relative to what? That is why I said phase comparator, it kinda doesn;t make sense to me to have absolute phase, it must be relative to something. ??

Cheers Chuck,

ANdy

On Thu, 28 Sep 2006 00:23:36 -0500 "Charles Henry" czhenry@gmail.com wrote:

...

Remind me again what Hilbert does for us Chuck, shifts all the "negative" frequencies relative to its application by -pi and all the "positive" frequecies by +pi so sin(t) -> -cos(t) and cos(t) -> -sin(t) ?? How does that give us a measure of phase change?

The hilbert transform takes the second half of the fft (which is the conjugate of the first half...the negative frequencies, if you will) and sets them to zero. The ifft of this (multiplied by two) is a complex signal, z(t) where the real part is exactly the original signal and the imaginary part is 90 degrees out of phase.

this signal can be decomposed into amplitude and phase as a continuous signal: A(t)=sqrt(Real(z(t))^2+Imag(z(t))^2) phase(t)=arctan(Imag(z(t))/Real(z(t))

I tried to implement this so I could show ya.... it doesn't work but I'll post it anyway. It uses ==~ from zexy. Use the hilbert_test patch and Open up the grapher subpatch to see what happens.... Maybe it's just a lousy algorithm....but I've actually used this once before to decompose phase and amplitude for other types of signals, and it seemed to work fine then... Chuck