Re: [PD] noise floor: median in audio signals, for peak extraction

[Thomas Grill]

Hi Alexandre,
maybe the libsms integration into Pd is of use for you - it calculates
a model of sinusoidals + residual noise, the latter representing a
kind of noise floor.
Those components can then also be modified and resynthesized.
http://mtg.upf.edu/static/libsms/

bests, gr~~~

2011/12/21 Alexandre Torres Porres por...@gmail.com:
 Hi there, this is a technique for calculating the noise floor of a spectrum,
 and extracting the peaks.

 It'd be used pretty much like I04.Noie Gate Miller's example, that has the
 mask table with a constant multiplier. We'd have instead this
 noise-floor block of audio, also multiplied by a constant.

 To get the noise floor, we take the magnitude (or power) spectrum and get
 the median of small bits of it, like every 32 samples. So the values of
 every 32 samples would be the median of that section...

 this is where I got this from, check page 4 and
 5 http://homepages.cae.wisc.edu/~sethares/software/SpectralTools.pdf

 this would be kinda like using the [median] or [median_n] objects, but over
 audio blocks and not number lists.

 Since there's the need of calculating this in and using the result back in
 the same block round into the audio chain, I can't put the spectrum into a
 table, and then calculate the median over bits of it.

 But then, how to do it? Should I be able to pull this out only if I write a
 median~ or [noise_floor~] external?

 Or somehow there's another way to do this with some existing external, or a
 similar technique, or even some audio math trick using [fexpr~] or
 something?

 This has to do with the other post I did about a project that attempts to
 isolate notes into a chord in a spectrum, something like melodyne is does.

 thanks
 Alex

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




-- 
Thomas Grill
http://g.org

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

Re: [PD] noise floor: median in audio signals, for peak extraction

[Mathieu Bouchard]

Le 2011-12-23 à 18:53:00, Alexandre Torres Porres a écrit :

Hi there, I had no idea there was such a thing as the [pack~]  
[unpack~] objects. I was about to ask about something like this, or 
propose it, because it is very cool the idea of acting on audio blocks 
as if they were lists,


Also, [#from~] and [#to~] can take multiple signals and turn them into 
columns inside matrices, and back into multiple signals.


  http://gridflow.ca/help/%23from~-help.html
  http://gridflow.ca/help/%23to~-help.html

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] noise floor: median in audio signals, for peak extraction

[Alexandre Torres Porres]

Hi there, I had no idea there was such a thing as the [pack~]  [unpack~]
objects. I was about to ask about something like this, or propose it,
because it is very cool the idea of acting on audio blocks as if they were
lists, and do all sorts of operations we cant with audio objects.

Anyway, now that I there is such a thing, and since I already had
programmed the median filter I needed with control objetcs... voilá! I have
the thing working well.

But then, I need to delay the signal, since [pack~]/[unpack~] delays a
block of audio.

My question is, is it possible to have it done without the delays?

thanks a lot, here's my code for you people to check this out.

==

#N canvas 733 146 357 400 12;
#X obj 59 149 readsf~;
#X obj 59 67 openpanel;
#X obj 59 94 symbol;
#X msg 59 122 open \$1 \, start;
#X obj 59 47 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X obj 193 259 *~ 1;
#X obj 218 234 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1
1;
#X obj 129 232 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X obj 148 308 +~;
#X obj 136 348 dac~;
#X obj 104 258 *~ 1;
#N canvas 965 228 735 754 filter-noise-floor 1;
#X obj 9 631 *~;
#X obj -32 74 *~;
#X obj 50 499 *~;
#X obj -32 46 inlet~;
#X obj 9 500 *~;
#X obj -32 103 rfft~;
#X obj 9 530 rifft~;
#X obj 9 661 outlet~;
#X obj 9 74 tabreceive~ \$0-hann;
#X obj 27 593 tabreceive~ \$0-hann;
#X text 25 100 real Fourier transform;
#X obj 314 291 loadbang;
#X obj -104 634 *~;
#X obj -63 502 *~;
#X obj -104 503 *~;
#X obj -104 533 rifft~;
#X obj -104 661 outlet~;
#X obj -104 562 /~ 1536;
#X obj 68 190 expr~ ($v1*$v1+$v2*$v2);
#X obj 303 47 inlet;
#X obj 9 560 /~ 1536;
#N canvas 0 22 450 300 (subpatch) 0;
#X array \$0-hann 1024 float 1;
#A 0 0 1.88351e-05 3.76403e-05 9.41157e-05 0.000150591 0.000244677
0.000338793 0.000470519 0.000602275 0.000771582 0.000940919 0.00114784
0.00135475 0.00159922 0.00184369 0.00212565 0.00240761 0.00272706 0.00304651
0.00340337 0.00376022 0.00415444 0.00454867 0.00498021 0.00541171 0.00588048
0.00634927 0.00685519 0.00736114 0.00790417 0.00844723 0.0090273 0.00960734
0.0102243 0.0108413 0.0114951 0.0121489 0.0128394 0.01353 0.0142572
0.0149843 0.015748 0.0165117 0.0173118 0.0181119 0.0189483 0.0197847
0.0206572 0.0215298 0.0224383 0.0233469 0.0242914 0.0252359 0.0262161
0.0271963 0.0282121 0.0292279 0.0302792 0.0313304 0.032417 0.0335035
0.0346252 0.0357469 0.0369035 0.0380602 0.0392516 0.040443 0.041669
0.042895 0.0441555 0.0454159 0.0467106 0.0480052 0.0493339 0.0506626
0.0520252 0.0533877 0.0547839 0.05618 0.0576096 0.0590392 0.060502
0.0619648 0.0634606 0.0649563 0.0664849 0.0680134 0.0695744 0.0711355
0.0727288 0.0743222 0.0759476 0.077573 0.0792302 0.0808874 0.0825762
0.084265 0.085985 0.0877051 0.0894562 0.0912073 0.0929892 0.0947711
0.0965835 0.0983959 0.100239 0.102081 0.103954 0.105826 0.107729 0.109631
0.111563 0.113494 0.115455 0.117416 0.119406 0.121395 0.123413 0.125431
0.127478 0.129524 0.131598 0.133672 0.135774 0.137876 0.140005 0.142134
0.14429 0.146446 0.148629 0.150811 0.15302 0.155229 0.157464 0.159699
0.161959 0.16422 0.166506 0.168792 0.171102 0.173413 0.175748 0.178084
0.180443 0.182803 0.185186 0.18757 0.189977 0.192384 0.194814 0.197244
0.199697 0.20215 0.204625 0.2071 0.209598 0.212095 0.214614 0.217133
0.219674 0.14 0.224775 0.227337 0.229919 0.2325 0.235102 0.237704
0.240326 0.242948 0.245589 0.24823 0.25089 0.25355 0.256229 0.258907
0.261604 0.264301 0.267015 0.26973 0.272462 0.275194 0.277942 0.280691
0.283457 0.286222 0.289003 0.291785 0.294582 0.297379 0.300191 0.303003
0.305831 0.308658 0.311499 0.314341 0.317196 0.320052 0.322921 0.32579
0.328672 0.331555 0.334449 0.337344 0.340252 0.343159 0.346078 0.348997
0.351927 0.354857 0.357798 0.36074 0.363691 0.366643 0.369605 0.372567
0.375538 0.37851 0.38149 0.384471 0.38746 0.390449 0.393447 0.396444
0.399449 0.402455 0.405467 0.40848 0.411499 0.414519 0.417545 0.420571
0.423603 0.426635 0.429672 0.432709 0.435752 0.438794 0.441842 0.444889
0.44794 0.450991 0.454046 0.457101 0.460159 0.463218 0.466279 0.46934
0.472403 0.475466 0.478531 0.481596 0.484663 0.487729 0.490797 0.493864
0.496932 0.5 0.503068 0.506136 0.509203 0.512271 0.515337 0.518404
0.521469 0.524534 0.527597 0.53066 0.533721 0.536782 0.539841 0.542899
0.545954 0.549009 0.55206 0.555111 0.558158 0.561205 0.564248 0.56729
0.570328 0.573365 0.576397 0.579429 0.582455 0.585481 0.588501 0.59152
0.594533 0.597545 0.600551 0.603556 0.606553 0.609551 0.61254 0.615529
0.61851 0.62149 0.624462 0.627433 0.630395 0.633357 0.636308 0.63926
0.642201 0.645143 0.648073 0.651003 0.653922 0.656841 0.659748 0.662656
0.66555 0.668445 0.671328 0.67421 0.677079 0.679948 0.682804 0.685659
0.688501 0.691342 0.694169 0.696997 0.699809 0.702621 0.705418 0.708215
0.710997 0.713778 0.716543 0.719309 0.722057 0.724806 0.727538 0.73027
0.732984 0.735699 0.738396 0.741093 0.743771 0.74645 0.74911 0.75177
0.754411 0.757052 0.759674 0.762295 0.764897 

Re: [PD] noise floor: median in audio signals, for peak extraction

[Mathieu Bouchard]

Le 2011-12-20 à 21:29:00, Alexandre Torres Porres a écrit :

this would be kinda like using the [median] or [median_n] objects, but 
over audio blocks and not number lists.


Ok, lots of heavy details below...

The way [median] and [median_n] are built, they take a lot of time. 
Sorting each window of 32 elements is slow with any full sort. Even the 
usually slow process of putting elements one by one in a sorted array is 
faster than any full sort like qsort() or [sort], in this kind of 
situation, because you need to look at the result of the sort after each 
insertion/removal.


But a sort based on binary-trees will make your median filter able to 
compete with the speed of FFT, for example. You keep your sorted «array» 
as a sorted binary tree and this makes it fast to insert, delete, and find 
the middle. But you can't do that with C++'s std::map because it offers 
no way to find the middle quickly... you'd need something special.


There may be ways to bend quicksort so that it can do many similar sorts 
quickly, but you can't do that with qsort() nor anything based on it.


I don't know how zexy's [sort]. Apparently it doesn't use the quicksort 
method that I assumed it did, it uses the shellsort method instead, which 
is sometimes slower, sometimes faster. I wonder whether it could speed up 
your task if you made a kind of [median_n] that would reuse the 
already-sorted list to speed up the next sort. (This would not improve a 
quicksort, but I wonder whether it'd improve [sort]).


Generally, median-based methods are harder to work with, as they involve 
lots of comparisons and swaps and such, by sorting or by doing things that 
are like sorting ; whereas mean-based methods involve simple fast passes 
of addition and multiplication. But both give quite different results, in 
many situations.


Since there's the need of calculating this in and using the result back 
in the same block round into the audio chain, I can't put the spectrum 
into a table, and then calculate the median over bits of it.


with [tabsend~] and a [bang~], then you can send a whole block into the 
message domain, compute it, and get it back as a signal, one block later.


But then, how to do it? Should I be able to pull this out only if I 
write a median~ or [noise_floor~] external?


Or somehow there's another way to do this with some existing external, 
or a similar technique, or even some audio math trick using [fexpr~] or 
something?


I don't think you can do any reasonable sort using [fexpr~]... except 
perhaps a strange undecipherable network of a hundred [fexpr~] or so. I 
think it's easier to write an external.


This has to do with the other post I did about a project that attempts 
to isolate notes into a chord in a spectrum, something like melodyne is 
does.


So, why is a mean (average) not good enough, while a median would be good 
enough ? It's possible, but I'd like to hear an explanation.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] noise floor: median in audio signals, for peak extraction

[Alexandre Torres Porres]

 So, why is a mean (average) not good enough, while a median would be good
enough ?
 It's possible, but I'd like to hear an explanation.

I'd need to test and compare, all I know is that I tested [avg~] and
compared it to sethares' objects in MAX, that do this median filter, and
they seem to sound better over there.

But these objects (GNU General Public License v2.0) are actually codes
in java,

for(int i=0; iframesize; i++) { // set the output magnitude by
if(i % medlen == 0){ // taking moving median of input
for(int ij=0; ijmedlen; ij++) { // this takes median
thesevals[ij] = magformed[i+ij]; // of medlen elements
}
noisefloor[i] = (float)(Statistics.median(thesevals));
} else { // advance median by medlen steps
noisefloor[i] = noisefloor[i-1]; // keeping same value


2011/12/22 Mathieu Bouchard ma...@artengine.ca

 Le 2011-12-20 à 21:29:00, Alexandre Torres Porres a écrit :


  this would be kinda like using the [median] or [median_n] objects, but
 over audio blocks and not number lists.


 Ok, lots of heavy details below...

 The way [median] and [median_n] are built, they take a lot of time.
 Sorting each window of 32 elements is slow with any full sort. Even the
 usually slow process of putting elements one by one in a sorted array is
 faster than any full sort like qsort() or [sort], in this kind of
 situation, because you need to look at the result of the sort after each
 insertion/removal.

 But a sort based on binary-trees will make your median filter able to
 compete with the speed of FFT, for example. You keep your sorted «array» as
 a sorted binary tree and this makes it fast to insert, delete, and find the
 middle. But you can't do that with C++'s std::map because it offers no way
 to find the middle quickly... you'd need something special.

 There may be ways to bend quicksort so that it can do many similar sorts
 quickly, but you can't do that with qsort() nor anything based on it.

 I don't know how zexy's [sort]. Apparently it doesn't use the quicksort
 method that I assumed it did, it uses the shellsort method instead, which
 is sometimes slower, sometimes faster. I wonder whether it could speed up
 your task if you made a kind of [median_n] that would reuse the
 already-sorted list to speed up the next sort. (This would not improve a
 quicksort, but I wonder whether it'd improve [sort]).

 Generally, median-based methods are harder to work with, as they involve
 lots of comparisons and swaps and such, by sorting or by doing things that
 are like sorting ; whereas mean-based methods involve simple fast passes of
 addition and multiplication. But both give quite different results, in many
 situations.


  Since there's the need of calculating this in and using the result back
 in the same block round into the audio chain, I can't put the spectrum into
 a table, and then calculate the median over bits of it.


 with [tabsend~] and a [bang~], then you can send a whole block into the
 message domain, compute it, and get it back as a signal, one block later.


  But then, how to do it? Should I be able to pull this out only if I write
 a median~ or [noise_floor~] external?

 Or somehow there's another way to do this with some existing external, or
 a similar technique, or even some audio math trick using [fexpr~] or
 something?


 I don't think you can do any reasonable sort using [fexpr~]... except
 perhaps a strange undecipherable network of a hundred [fexpr~] or so. I
 think it's easier to write an external.


  This has to do with the other post I did about a project that attempts to
 isolate notes into a chord in a spectrum, something like melodyne is does.


 So, why is a mean (average) not good enough, while a median would be good
 enough ? It's possible, but I'd like to hear an explanation.

  __**__**
 __
 | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] noise floor: median in audio signals, for peak extraction

[Charles Henry]

On Wed, Dec 21, 2011 at 11:15 AM, Charles Henry czhe...@gmail.com wrote:
 1.  How to handle the endpoints of the signal blocks?

I've thought this over, and concluded that it really doesn't matter,
for the case of the magnitude of power spectral density.

Any high or low values of the spectrum at DC and at the Nyquist
frequency will be rejected, because of the symmetry of the Fourier
transform about these points.

You'd probably treat the blocks as circular buffers for the purpose of
median filtering your spectrum.  It stays a little neater that way
anyhow, with no samples held over from the previous block.

 2.  The statistical properties of median and weighted median filters
 are tough to describe analytically.  If you've got to justify your
 choice of this one component... it may take some research.  Estimating
 threshold values with mean/variance calculations are much easier
 analytically.

I've also thought this over, and the median filter is the black magic
of non-linear filtering.  It rejects some bad points in the data no
matter how bad they are which makes it robust and really practical,
but quantifying the effects is some kind of arcane secret.

Another way to look at it is what it does for your spectrum's
continuity--it might be good to rid of some of the variability in the
noise floor estimation, just making the spectrum smoother, which the
median filter certainly does.  I wonder if there could be something
analogous for smoothing out phase in a spectrum?

 On Tue, Dec 20, 2011 at 5:29 PM, Alexandre Torres Porres
 por...@gmail.com wrote:
 Hi there, this is a technique for calculating the noise floor of a spectrum,
 and extracting the peaks.

 It'd be used pretty much like I04.Noie Gate Miller's example, that has the
 mask table with a constant multiplier. We'd have instead this
 noise-floor block of audio, also multiplied by a constant.

 To get the noise floor, we take the magnitude (or power) spectrum and get
 the median of small bits of it, like every 32 samples. So the values of
 every 32 samples would be the median of that section...

 this is where I got this from, check page 4 and
 5 http://homepages.cae.wisc.edu/~sethares/software/SpectralTools.pdf

 this would be kinda like using the [median] or [median_n] objects, but over
 audio blocks and not number lists.

 Since there's the need of calculating this in and using the result back in
 the same block round into the audio chain, I can't put the spectrum into a
 table, and then calculate the median over bits of it.

 But then, how to do it? Should I be able to pull this out only if I write a
 median~ or [noise_floor~] external?

 Or somehow there's another way to do this with some existing external, or a
 similar technique, or even some audio math trick using [fexpr~] or
 something?

 This has to do with the other post I did about a project that attempts to
 isolate notes into a chord in a spectrum, something like melodyne is does.

 thanks
 Alex

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


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

Re: [PD] noise floor: median in audio signals, for peak extraction

[Charles Henry]

Hi Alex

I've been reading all your posts lately.  Very interesting--I will
look forward to your new phase vocorder stuff, when I get free time
and enough rest.

Have you considered weighted median filtering?  It's a non-linear
filter structure that takes non-negative integers as arguments.  At
each sample, you create a list of samples, the adjacent values taken
according to the filter arguments.  Then, count through the list
finding the lowest value each time, and add up the filter weights
until you cross the median.

The purpose of weighting is to allow some more flexibility to shape
the spectrum and prefer values that are closer to the original signal.
 It still has the same ability to reject outliers if you select good
weights.

I had made a badly written external, and a cpu-hungry abstraction
(with fexpr~ and a fixed number of weights) a while back.  I'd be
happy to dig up the code and algorithm after work today.

There's just two things that sound difficult in this application:

1.  How to handle the endpoints of the signal blocks?

2.  The statistical properties of median and weighted median filters
are tough to describe analytically.  If you've got to justify your
choice of this one component... it may take some research.  Estimating
threshold values with mean/variance calculations are much easier
analytically.

Chuck

On Tue, Dec 20, 2011 at 5:29 PM, Alexandre Torres Porres
por...@gmail.com wrote:
 Hi there, this is a technique for calculating the noise floor of a spectrum,
 and extracting the peaks.

 It'd be used pretty much like I04.Noie Gate Miller's example, that has the
 mask table with a constant multiplier. We'd have instead this
 noise-floor block of audio, also multiplied by a constant.

 To get the noise floor, we take the magnitude (or power) spectrum and get
 the median of small bits of it, like every 32 samples. So the values of
 every 32 samples would be the median of that section...

 this is where I got this from, check page 4 and
 5 http://homepages.cae.wisc.edu/~sethares/software/SpectralTools.pdf

 this would be kinda like using the [median] or [median_n] objects, but over
 audio blocks and not number lists.

 Since there's the need of calculating this in and using the result back in
 the same block round into the audio chain, I can't put the spectrum into a
 table, and then calculate the median over bits of it.

 But then, how to do it? Should I be able to pull this out only if I write a
 median~ or [noise_floor~] external?

 Or somehow there's another way to do this with some existing external, or a
 similar technique, or even some audio math trick using [fexpr~] or
 something?

 This has to do with the other post I did about a project that attempts to
 isolate notes into a chord in a spectrum, something like melodyne is does.

 thanks
 Alex

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


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

Re: [PD] noise floor: median in audio signals, for peak extraction

[Charles Henry]

On Wed, Dec 21, 2011 at 11:15 AM, Charles Henry czhe...@gmail.com wrote:
 I had made a badly written external, and a cpu-hungry abstraction
 (with fexpr~ and a fixed number of weights) a while back.  I'd be
 happy to dig up the code and algorithm after work today.

Here's the abstraction: wmed5~.pd   Below is also a pasted test patch.
 How it works: it computes all branches!  Just for fun, because it's
not something that scales well with more taps, but works.

wmed5~.pd

#N canvas 0 0 765 642 10;
#X obj 150 132 t b b;
#X obj 189 132 loadbang;
#X obj 452 188 expr $f1+$f2+$f3+$f4+$f5;
#X obj 455 225 expr int(($f1+1)/2);
#X text 591 227 median index;
#X obj 11 33 inlet~;
#X obj 62 230 fexpr~ $f3*($x1$x1[-1]) + $f4*($x1$x1[-2]) + $f5*($x1$x1[-3])
+ $f6*($x1$x1[-4]) \; $f2*($x1=$x1[-1]) + $f4*($x1[-1]$x1[-2]) +
$f5*($x1[-1]$x1[-3]) + $f6*($x1[-1]$x1[-4]) \; $f2*($x1=$x1[-2])
+ $f3*($x1[-1]=$x1[-2]) + $f5*($x1[-2]$x1[-3]) + $f6*($x1[-2]$x1[-4])
\; $f2*($x1=$x1[-3]) + $f3*($x1[-1]=$x1[-3]) + $f4*($x1[-2]=$x1[-3])
+ $f6*($x1[-3]$x1[-4]) \; $f2*($x1=$x1[-4]) + $f3*($x1[-1]=$x1[-4])
+ $f4*($x1[-2]=$x1[-4]) + $f5*($x1[-3]=$x1[-4]);
#X obj 19 449 fexpr~ $x1*(($x2+$f3) = $f4)*($x2  $f4);
#X obj 62 475 fexpr~ $x1[-1]*(($x2+$f3) = $f4)*($x2  $f4);
#X obj 102 501 fexpr~ $x1[-2]*(($x2+$f3) = $f4)*($x2  $f4);
#X obj 143 527 fexpr~ $x1[-3]*(($x2+$f3) = $f4)*($x2  $f4);
#X obj 179 552 fexpr~ $x1[-4]*(($x2+$f3) = $f4)*($x2  $f4);
#X obj 27 594 expr~ $v1+$v2+$v3+$v4+$v5;
#X obj 27 625 outlet~;
#X obj 78 31 inlet;
#X obj 78 54 unpack f f f f f;
#X obj 85 163 \$2;
#X obj 125 165 \$3;
#X obj 152 165 \$4;
#X obj 181 165 \$5;
#X obj 210 165 \$6;
#X text 253 44 1-D weighted median filter using expr \, expr~ \, fexpr~
;
#X text 351 88 uses 5 integer arguments \, representing the weights
of choosing a median from a weighted set of samples as x[0] \, x[-1]
\, x[-2] \, x[-3] \, x[-4];
#X text 348 129 the weighted set includes a number of duplications
of x \, equal to the argument;
#X connect 0 0 16 0;
#X connect 0 1 17 0;
#X connect 0 1 18 0;
#X connect 0 1 19 0;
#X connect 0 1 20 0;
#X connect 1 0 0 0;
#X connect 2 0 3 0;
#X connect 3 0 7 3;
#X connect 3 0 8 3;
#X connect 3 0 9 3;
#X connect 3 0 10 3;
#X connect 3 0 11 3;
#X connect 5 0 6 0;
#X connect 5 0 7 0;
#X connect 5 0 8 0;
#X connect 5 0 9 0;
#X connect 5 0 10 0;
#X connect 5 0 11 0;
#X connect 6 0 7 1;
#X connect 6 1 8 1;
#X connect 6 2 9 1;
#X connect 6 3 10 1;
#X connect 6 4 11 1;
#X connect 7 0 12 0;
#X connect 8 0 12 1;
#X connect 9 0 12 2;
#X connect 10 0 12 3;
#X connect 11 0 12 4;
#X connect 12 0 13 0;
#X connect 14 0 15 0;
#X connect 15 0 16 0;
#X connect 15 1 17 0;
#X connect 15 2 18 0;
#X connect 15 3 19 0;
#X connect 15 4 20 0;
#X connect 16 0 2 0;
#X connect 16 0 6 1;
#X connect 16 0 7 2;
#X connect 17 0 2 1;
#X connect 17 0 6 2;
#X connect 17 0 8 2;
#X connect 18 0 2 2;
#X connect 18 0 6 3;
#X connect 18 0 9 2;
#X connect 19 0 2 3;
#X connect 19 0 6 4;
#X connect 19 0 10 2;
#X connect 20 0 2 4;
#X connect 20 0 6 5;
#X connect 20 0 11 2;



wmed5-test.pd

#N canvas 0 0 724 559 10;
#X obj 175 73 noise~;
#X obj 44 180 +~;
#N canvas 0 0 450 300 (subpatch) 0;
#X array array1 64 float 1;
#A 0 -0.989722 -0.998962 -0.998581 -0.988581 -0.969059 -0.940204 -0.902292
-0.85569 -0.800846 -0.738288 -0.668619 -0.59251 -0.510694 -0.423959
-0.33314 -0.239112 -0.142782 -0.0450761 0.0530638 0.150693 0.24687
0.34067 0.431188 0.517553 0.598933 0.674544 0.743658 0.805609 0.859801
0.905711 0.942897 0.971002 0.989753 0.998972 0.998569 0.988549 0.969007
0.940132 0.902201 0.855581 0.80072 0.738147 0.668464 0.592342 0.510515
0.42377 0.332944 0.238911 0.142576 0.0448686 -0.0532713 -0.150898 -0.247071
-0.340865 -0.431375 -0.517731 -0.599099 -0.674697 -0.743797 -0.805732
-0.859907 -0.905799 -0.942966 -0.971051;
#X coords 0 1 63 -1 200 140 1;
#X restore 364 56 graph;
#N canvas 0 0 450 300 (subpatch) 0;
#X array array2 64 float 1;
#A 0 -0.970948 -0.989722 -0.998581 -0.998581 -0.988581 -0.969059 -0.940204
-0.902292 -0.85569 -0.800846 -0.738288 -0.668619 -0.59251 -0.510694
-0.423959 -0.33314 -0.239112 -0.142782 -0.0450761 0.0530638 0.150693
0.24687 0.34067 0.431188 0.517553 0.598933 0.674544 0.743658 0.805609
0.859801 0.905711 0.942897 0.971002 0.989753 0.998569 0.998569 0.988549
0.969007 0.940132 0.902201 0.855581 0.80072 0.738147 0.668464 0.592342
0.510515 0.42377 0.332944 0.238911 0.142576 0.0448686 -0.0532713 -0.150898
-0.247071 -0.340865 -0.431375 -0.517731 -0.599099 -0.674697 -0.743797
-0.805732 -0.859907 -0.905799 -0.942966;
#X coords 0 1 63 -1 200 140 1;
#X restore 366 218 graph;
#X obj 135 214 tabwrite~ array1;
#X obj 196 273 tabwrite~ array2;
#X obj 224 147 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1
1;
#X floatatom 46 30 5 0 0 0 - - -;
#X obj 43 103 osc~ 689.11;
#X obj 173 174 metro 166;
#X obj 169 124 expr~ $v1*(abs($v1)  0.99);
#X obj 43 244 wmed5~ 2 3 4 3 2;
#X obj 255 151 loadbang;
#X connect 0 0 10 0;
#X connect 1 0 4 0;
#X connect 1 0 11 0;
#X connect 6 0 9 0;
#X connect 

[PD] noise floor: median in audio signals, for peak extraction

[Alexandre Torres Porres]

Hi there, this is a technique for calculating the noise floor of a
spectrum, and extracting the peaks.

It'd be used pretty much like I04.Noie Gate Miller's example, that has the
mask table with a constant multiplier. We'd have instead this
noise-floor block of audio, also multiplied by a constant.

To get the noise floor, we take the magnitude (or power) spectrum and get
the median of small bits of it, like every 32 samples. So the values of
every 32 samples would be the median of that section...

this is where I got this from, check page 4 and 5
http://homepages.cae.wisc.edu/~sethares/software/SpectralTools.pdf

this would be kinda like using the [median] or [median_n] objects, but over
audio blocks and not number lists.

Since there's the need of calculating this in and using the result back in
the same block round into the audio chain, I can't put the spectrum into a
table, and then calculate the median over bits of it.

But then, how to do it? Should I be able to pull this out only if I write a
median~ or [noise_floor~] external?

Or somehow there's another way to do this with some existing external, or a
similar technique, or even some audio math trick using [fexpr~] or
something?

This has to do with the other post I did about a project that attempts to
isolate notes into a chord in a spectrum, something like melodyne is does.

thanks
Alex
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] noise floor: median in audio signals, for peak extraction

[Alexandre Torres Porres]

here's my patch by the way.

I can't attach files to the list, right? I'm sending the code in the body
of the message.

I guess one way would be to write an external that would give me back this
block of audio with the median of each section. I'd replace it in the
[avg~] object in the patch bellow. Cheers.

noise-floor_filter.pd
=

#N canvas 1374 303 359 446 12;
#X obj 52 128 readsf~;
#X obj 52 46 openpanel;
#X obj 52 73 symbol;
#X msg 52 101 open \$1 \, start;
#X obj 52 26 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X obj 142 288 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X obj 70 286 tgl 15 1 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X obj 86 347 +~;
#X obj 78 387 dac~;
#X obj 179 112 noise~;
#X floatatom 117 142 5 0 0 0 - - -;
#X obj 52 166 *~ 1;
#X text 187 178 floor level;
#X floatatom 196 262 5 0 0 0 - - -;
#X text 239 264 floor (average);
#X text 74 24 open sample;
#X obj 179 142 *~ 0.01;
#X text 60 264 dirty;
#X text 133 263 clean;
#N canvas 222 138 574 729 noise-floor_filter 0;
#X obj -38 635 *~;
#X obj -98 78 *~;
#X obj 3 503 *~;
#X obj -98 50 inlet~;
#X obj -38 504 *~;
#X obj -99 107 rfft~;
#X obj -38 534 rifft~;
#X obj -38 665 outlet~;
#X obj -263 221 block~ 1024 4;
#X obj -57 78 tabreceive~ \$0-hann;
#X obj -20 597 tabreceive~ \$0-hann;
#X text -42 104 real Fourier transform;
#X obj -151 638 *~;
#X obj -110 506 *~;
#X obj -151 507 *~;
#X obj -151 537 rifft~;
#X obj -151 665 outlet~;
#X obj -151 566 /~ 1536;
#X obj 1 194 expr~ ($v1*$v1+$v2*$v2);
#X obj 118 258 avg~;
#X obj 118 226 bang~;
#X obj -251 255 loadbang;
#X obj 236 51 inlet;
#X obj 165 286 outlet;
#X obj -38 564 /~ 1536;
#N canvas 0 22 450 300 (subpatch) 0;
#X array \$0-hann 1024 float 1;
#A 0 0 1.88351e-05 3.76403e-05 9.41157e-05 0.000150591 0.000244677
0.000338793 0.000470519 0.000602275 0.000771582 0.000940919 0.00114784
0.00135475 0.00159922 0.00184369 0.00212565 0.00240761 0.00272706 0.00304651
0.00340337 0.00376022 0.00415444 0.00454867 0.00498021 0.00541171 0.00588048
0.00634927 0.00685519 0.00736114 0.00790417 0.00844723 0.0090273 0.00960734
0.0102243 0.0108413 0.0114951 0.0121489 0.0128394 0.01353 0.0142572
0.0149843 0.015748 0.0165117 0.0173118 0.0181119 0.0189483 0.0197847
0.0206572 0.0215298 0.0224383 0.0233469 0.0242914 0.0252359 0.0262161
0.0271963 0.0282121 0.0292279 0.0302792 0.0313304 0.032417 0.0335035
0.0346252 0.0357469 0.0369035 0.0380602 0.0392516 0.040443 0.041669
0.042895 0.0441555 0.0454159 0.0467106 0.0480052 0.0493339 0.0506626
0.0520252 0.0533877 0.0547839 0.05618 0.0576096 0.0590392 0.060502
0.0619648 0.0634606 0.0649563 0.0664849 0.0680134 0.0695744 0.0711355
0.0727288 0.0743222 0.0759476 0.077573 0.0792302 0.0808874 0.0825762
0.084265 0.085985 0.0877051 0.0894562 0.0912073 0.0929892 0.0947711
0.0965835 0.0983959 0.100239 0.102081 0.103954 0.105826 0.107729 0.109631
0.111563 0.113494 0.115455 0.117416 0.119406 0.121395 0.123413 0.125431
0.127478 0.129524 0.131598 0.133672 0.135774 0.137876 0.140005 0.142134
0.14429 0.146446 0.148629 0.150811 0.15302 0.155229 0.157464 0.159699
0.161959 0.16422 0.166506 0.168792 0.171102 0.173413 0.175748 0.178084
0.180443 0.182803 0.185186 0.18757 0.189977 0.192384 0.194814 0.197244
0.199697 0.20215 0.204625 0.2071 0.209598 0.212095 0.214614 0.217133
0.219674 0.14 0.224775 0.227337 0.229919 0.2325 0.235102 0.237704
0.240326 0.242948 0.245589 0.24823 0.25089 0.25355 0.256229 0.258907
0.261604 0.264301 0.267015 0.26973 0.272462 0.275194 0.277942 0.280691
0.283457 0.286222 0.289003 0.291785 0.294582 0.297379 0.300191 0.303003
0.305831 0.308658 0.311499 0.314341 0.317196 0.320052 0.322921 0.32579
0.328672 0.331555 0.334449 0.337344 0.340252 0.343159 0.346078 0.348997
0.351927 0.354857 0.357798 0.36074 0.363691 0.366643 0.369605 0.372567
0.375538 0.37851 0.38149 0.384471 0.38746 0.390449 0.393447 0.396444
0.399449 0.402455 0.405467 0.40848 0.411499 0.414519 0.417545 0.420571
0.423603 0.426635 0.429672 0.432709 0.435752 0.438794 0.441842 0.444889
0.44794 0.450991 0.454046 0.457101 0.460159 0.463218 0.466279 0.46934
0.472403 0.475466 0.478531 0.481596 0.484663 0.487729 0.490797 0.493864
0.496932 0.5 0.503068 0.506136 0.509203 0.512271 0.515337 0.518404
0.521469 0.524534 0.527597 0.53066 0.533721 0.536782 0.539841 0.542899
0.545954 0.549009 0.55206 0.555111 0.558158 0.561205 0.564248 0.56729
0.570328 0.573365 0.576397 0.579429 0.582455 0.585481 0.588501 0.59152
0.594533 0.597545 0.600551 0.603556 0.606553 0.609551 0.61254 0.615529
0.61851 0.62149 0.624462 0.627433 0.630395 0.633357 0.636308 0.63926
0.642201 0.645143 0.648073 0.651003 0.653922 0.656841 0.659748 0.662656
0.66555 0.668445 0.671328 0.67421 0.677079 0.679948 0.682804 0.685659
0.688501 0.691342 0.694169 0.696997 0.699809 0.702621 0.705418 0.708215
0.710997 0.713778 0.716543 0.719309 0.722057 0.724806 0.727538 0.73027
0.732984 0.735699 0.738396 0.741093 0.743771 0.74645 0.74911 0.75177
0.754411 0.757052 0.759674 0.762295 0.764897 0.767499 0.770081 0.772663

Re: [PD] noise floor: median in audio signals, for peak extraction

[Alexandre Torres Porres]

stupid bug; dsp $1 instead of dsp 1 on loadbang

now corrected:


#N canvas 1374 303 359 446 12;
#X obj 52 128 readsf~;
#X obj 52 46 openpanel;
#X obj 52 73 symbol;
#X msg 52 101 open \$1 \, start;
#X obj 52 26 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X obj 142 288 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X obj 70 286 tgl 15 1 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X obj 86 347 +~;
#X obj 78 387 dac~;
#X obj 179 112 noise~;
#X floatatom 117 142 5 0 0 0 - - -;
#X obj 52 166 *~ 1;
#X text 187 178 floor level;
#X floatatom 196 262 5 0 0 0 - - -;
#X text 239 264 floor (average);
#X text 74 24 open sample;
#X obj 179 142 *~ 0.01;
#X text 60 264 dirty;
#X text 133 263 clean;
#N canvas 222 138 574 729 noise-floor_filter 0;
#X obj -38 635 *~;
#X obj -98 78 *~;
#X obj 3 503 *~;
#X obj -98 50 inlet~;
#X obj -38 504 *~;
#X obj -99 107 rfft~;
#X obj -38 534 rifft~;
#X obj -38 665 outlet~;
#X obj -263 221 block~ 1024 4;
#X obj -57 78 tabreceive~ \$0-hann;
#X obj -20 597 tabreceive~ \$0-hann;
#X text -42 104 real Fourier transform;
#X obj -151 638 *~;
#X obj -110 506 *~;
#X obj -151 507 *~;
#X obj -151 537 rifft~;
#X obj -151 665 outlet~;
#X obj -151 566 /~ 1536;
#X obj 1 194 expr~ ($v1*$v1+$v2*$v2);
#X obj 118 258 avg~;
#X obj 118 226 bang~;
#X obj -251 255 loadbang;
#X obj 236 51 inlet;
#X obj 165 286 outlet;
#X obj -38 564 /~ 1536;
#N canvas 0 22 450 300 (subpatch) 0;
#X array \$0-hann 1024 float 1;
#A 0 0 1.88351e-05 3.76403e-05 9.41157e-05 0.000150591 0.000244677
0.000338793 0.000470519 0.000602275 0.000771582 0.000940919 0.00114784
0.00135475 0.00159922 0.00184369 0.00212565 0.00240761 0.00272706 0.00304651
0.00340337 0.00376022 0.00415444 0.00454867 0.00498021 0.00541171 0.00588048
0.00634927 0.00685519 0.00736114 0.00790417 0.00844723 0.0090273 0.00960734
0.0102243 0.0108413 0.0114951 0.0121489 0.0128394 0.01353 0.0142572
0.0149843 0.015748 0.0165117 0.0173118 0.0181119 0.0189483 0.0197847
0.0206572 0.0215298 0.0224383 0.0233469 0.0242914 0.0252359 0.0262161
0.0271963 0.0282121 0.0292279 0.0302792 0.0313304 0.032417 0.0335035
0.0346252 0.0357469 0.0369035 0.0380602 0.0392516 0.040443 0.041669
0.042895 0.0441555 0.0454159 0.0467106 0.0480052 0.0493339 0.0506626
0.0520252 0.0533877 0.0547839 0.05618 0.0576096 0.0590392 0.060502
0.0619648 0.0634606 0.0649563 0.0664849 0.0680134 0.0695744 0.0711355
0.0727288 0.0743222 0.0759476 0.077573 0.0792302 0.0808874 0.0825762
0.084265 0.085985 0.0877051 0.0894562 0.0912073 0.0929892 0.0947711
0.0965835 0.0983959 0.100239 0.102081 0.103954 0.105826 0.107729 0.109631
0.111563 0.113494 0.115455 0.117416 0.119406 0.121395 0.123413 0.125431
0.127478 0.129524 0.131598 0.133672 0.135774 0.137876 0.140005 0.142134
0.14429 0.146446 0.148629 0.150811 0.15302 0.155229 0.157464 0.159699
0.161959 0.16422 0.166506 0.168792 0.171102 0.173413 0.175748 0.178084
0.180443 0.182803 0.185186 0.18757 0.189977 0.192384 0.194814 0.197244
0.199697 0.20215 0.204625 0.2071 0.209598 0.212095 0.214614 0.217133
0.219674 0.14 0.224775 0.227337 0.229919 0.2325 0.235102 0.237704
0.240326 0.242948 0.245589 0.24823 0.25089 0.25355 0.256229 0.258907
0.261604 0.264301 0.267015 0.26973 0.272462 0.275194 0.277942 0.280691
0.283457 0.286222 0.289003 0.291785 0.294582 0.297379 0.300191 0.303003
0.305831 0.308658 0.311499 0.314341 0.317196 0.320052 0.322921 0.32579
0.328672 0.331555 0.334449 0.337344 0.340252 0.343159 0.346078 0.348997
0.351927 0.354857 0.357798 0.36074 0.363691 0.366643 0.369605 0.372567
0.375538 0.37851 0.38149 0.384471 0.38746 0.390449 0.393447 0.396444
0.399449 0.402455 0.405467 0.40848 0.411499 0.414519 0.417545 0.420571
0.423603 0.426635 0.429672 0.432709 0.435752 0.438794 0.441842 0.444889
0.44794 0.450991 0.454046 0.457101 0.460159 0.463218 0.466279 0.46934
0.472403 0.475466 0.478531 0.481596 0.484663 0.487729 0.490797 0.493864
0.496932 0.5 0.503068 0.506136 0.509203 0.512271 0.515337 0.518404
0.521469 0.524534 0.527597 0.53066 0.533721 0.536782 0.539841 0.542899
0.545954 0.549009 0.55206 0.555111 0.558158 0.561205 0.564248 0.56729
0.570328 0.573365 0.576397 0.579429 0.582455 0.585481 0.588501 0.59152
0.594533 0.597545 0.600551 0.603556 0.606553 0.609551 0.61254 0.615529
0.61851 0.62149 0.624462 0.627433 0.630395 0.633357 0.636308 0.63926
0.642201 0.645143 0.648073 0.651003 0.653922 0.656841 0.659748 0.662656
0.66555 0.668445 0.671328 0.67421 0.677079 0.679948 0.682804 0.685659
0.688501 0.691342 0.694169 0.696997 0.699809 0.702621 0.705418 0.708215
0.710997 0.713778 0.716543 0.719309 0.722057 0.724806 0.727538 0.73027
0.732984 0.735699 0.738396 0.741093 0.743771 0.74645 0.74911 0.75177
0.754411 0.757052 0.759674 0.762295 0.764897 0.767499 0.770081 0.772663
0.775224 0.86 0.780326 0.782867 0.785386 0.787905 0.790402 0.7929
0.795375 0.79785 0.800303 0.802756 0.805186 0.807616 0.810023 0.812431
0.814814 0.817197 0.819557 0.821916 0.824252 0.826587 0.828898 0.831209
0.833494 0.83578 0.838041 0.840301 0.842536 0.844771