Forums > MaxMSP

Analysis – 0 detection buffer/cropper ?

November 28, 2009 | 12:06 am

This is my first post on this forum. I am a Max beginner, well a complete beginner at programming, etc in general, but I am loving it! :) Nice to meet you all, I am 5mg3 (Smudge).

I am working on a project where a recording is taken of the participants voice and played back at them in various ways. A sensor (URF) triggers the record when they are in position. However, this means there will be significant unwanted audio recorded.

What tool(s), methods and techniques can I use in order to crop the audio to the desired sample? What objects will I need to use and what would be the best way of approaching such a task?

Some sort of ‘analysis’??

Cheers


November 28, 2009 | 7:46 pm

I do this using peek~ into a buffer with an uzi and a counter looking for a threshold.

For instance this is from one of my patches – looks for a threshold above absolute value of 0.07 or greater in the first 10 seconds of a buffer~. It takes a look every 10 samples (for speed in live situation) – this seems to be enough for what I use it for, but you might want to do every sample. Before doing this I normalize the recorded sample using the normalize command of waveform~. This really helps if you are using signals of varying intensity (ie different instruments or people all the time). Then I use waveform~ to crop to that many milliseconds into the buffer. Or if that is not important, just tell groove~ to play starting that many ms in.

– Pasted Max Patch, click to expand. –

Alternately, since max is made for realtime, just define a threshold and keep track of how far into recording it is crossed with "timer". The only problem here is that you don’t get to normalize for how loud the original voice is. But maybe you could record the occurrence of several different thresholds and the max amplitude over the recording, and depending on what the max gain is, choose which threshold to crop your audio to.


November 28, 2009 | 7:48 pm

PS – and definitely use uzi instead of metro with peek~ – with metro bangs are scheduled for realtime. With uzi, they happen as fast as your computer can do them, which is much, much faster (hopefully!) But beware that other realtime stuff scheduled to happen while uzi is banging out like 1000000 times can sometimes get delayed.


November 28, 2009 | 9:41 pm

Thanks arvidtp that was really helpful but I am still a little stuck, could you show me an example with the use of the waveform~ and audio input please?


November 28, 2009 | 11:16 pm

waveform~ just attaches to a buffer~ with a "set buffername" message – see its help file. Then AFTER the buffer is recorded with record~, you use the crop and/or normalize commands on the waveform~, then play the buffer back. I dont have an example handy but it is pretty simple.

cheers,
Arvid


November 29, 2009 | 12:31 pm

You don’t need to walk around your buffer~ to find zero crossings and transients – if you do it via uzi, depending on the duration of the audio you’re examining, this might also hang your max for a while…
same thing for normalizing – you don’t really need to do it!
what I would do is:
- while you’re recording, check for transients and silences to detect the actual beginning and end of the speech. you may use a timer object to track the start and end positions relative to the beginning of the recording. then you can use these values as the groove~’s loop boundaries.
- while you’re recording, keep track of the maximum amplitude (or, why not, the max RMS power) of your audio: you will use this value (well, its [!/ 1.], actually) as the gain for your playback.
- when you play back your audio, you can send groove~ the startloop message; you can use groove~’s right outlet to stop the playback and control a trapezoid~ object to perform a very short fade-in and fade-out in order to avoid clicks!
I can’t send you an example patch right now, but I hope this helps…
aa


Viewing 6 posts - 1 through 6 (of 6 total)