Forum: help
Monitor Forum | 
Start New Thread
| RE: Chirp-fitting example - difficulty with fast chirps [ Reply ] By: Dan Stowell on 2012-07-18 21:05 | [forum:109869] |
|
Remi - thanks - code now committed to SVN, with doc. Dan |
|
| RE: Chirp-fitting example - difficulty with fast chirps [ Reply ] By: Rémi Gribonval on 2012-07-18 10:38 | [forum:109867] |
|
Hi Dan, Excellent, thanks for the update! I have added you as senior developper, so you should now be able to access the svn to include your patch in the trunk. You may want to update the documentation accordingly. Remi. |
|
| RE: Chirp-fitting example - difficulty with fast chirps [ Reply ] By: Dan Stowell on 2012-07-17 21:41 | [forum:109866]
chirpRateThreshold_asoption.diff.txt (35) downloads
|
|
Hi Remi, Thanks for the replies. Regarding turning my two hacks into options: yes, it'd seem sensible. It looks like I could follow the way that "numFitPoints" and "numIter" are provided as parameters. Attached is a patch where I implement the chirpRateThreshold parameter. Looks OK? If so, I will implement the other parameter and tidy up, and submit it for addition. What type should I use for a boolean parameter? (the (b) option) use an unsigned int, with 0 or 1 in the XML? BTW, I'm using the 0.6.1 code release; the SVN source doesn't seem to be accessible at all to non-developers. If it was accessible then I could post patches to this forum? Best Dan |
|
| RE: Chirp-fitting example - difficulty with fast chirps [ Reply ] By: Dan Stowell on 2012-07-18 10:05 | [forum:109865]
chirplet_two_user_options.patch.txt (55) downloads
|
|
Attached is an updated patch, which implements both of the features as user options. I've tested it and it works well here (64bit ubuntu, commandline). Please let me know if you're willing to commit this patch, or if more work is needed. I'd prefer it if my own version of MPTK did not diverge too far from the official one! Best Dan |
|
| RE: Chirp-fitting example - difficulty with fast chirps [ Reply ] By: Rémi Gribonval on 2012-07-17 14:32 | [forum:109863] |
|
One more point: the chirp code has been initially designed for a Gaussian window, so you may get better result with "gauss" than with "cosine" as :windowtype". Remi. |
|
| RE: Chirp-fitting example - difficulty with fast chirps [ Reply ] By: Rémi Gribonval on 2012-07-17 14:29 | [forum:109862] |
|
Hi Dan, It's been a while since the last time I played with the chirp code, but you seem to have found a good way out, and I am glad you find MPTK useful! Rather than replacing the old hard-coded MP_CHIRP_THRESH value with a new hard-coded one, I think it would be better and not too difficult (I can give you some advice) to make it a parameter of the chirp block, to be set to the default value at creation unless the xml description file specifies a "chirpthresh" value. This will gain in flexibility without having to recompile ... Regarding point b), I sort of remember this was introduced because in some cases we observed that the fitted chirp increased the energy of the residual, leading to an exponential increase in residual energy. Purely removing this could thus make the code less stable. A safer option would be, again, to add an option to the chirp block: by default, the test would be used, but it wouldn't if one explicitly does not want to use it. What do you think ? Remi. |
|
| RE: Chirp-fitting example - difficulty with fast chirps [ Reply ] By: Dan Stowell on 2012-07-17 11:42 | [forum:109861] |
|
Update: I can get pretty decent results if I do two things in the source code: (a) use a higher value of MP_CHIRP_THRESH; (b) deactivate the checks which return the original un-chirped atom if the correlation of the chirped atom doesn't beat it. Below is a diff which shows my simple hacks. Point (a) is simple enough; regarding point (b), I wonder if the correlation test incurs some kind of local-minimum issue? I need to grok the code better. But it may be worth removing those checks in general. Dan diff -ru orig061source/src/plugin/base/chirp_block_plugin.cpp 061source/src/plugin/base/chirp_block_plugin.cpp --- orig061source/src/plugin/base/chirp_block_plugin.cpp 2011-12-16 13:31:53.000000000 +0000 +++ 061source/src/plugin/base/chirp_block_plugin.cpp 2012-07-17 12:31:56.382559596 +0100 @@ -647,7 +647,9 @@ chirprate += deltaChirp; /* BORK */ //#define MP_CHIRP_THRESH 1e-5 -#define MP_CHIRP_THRESH 0.5e-5 +//#define MP_CHIRP_THRESH 0.5e-5 +//DAN: +#define MP_CHIRP_THRESH 0.5e-2 //#define MP_CHIRP_THRESH 0.2e-5 if ( fabs(chirprate) > MP_CHIRP_THRESH ) { @@ -739,6 +741,7 @@ /* TEST: if the correlation of the chirped atom is less than or equal to the correlation of the original unchirped one, it's a case where the chirp detection model is invalid => keep the unchirped one and exit. */ +/*DAN if (energy <= maxIPValue ) { mp_debug_msg( MP_DEBUG_CREATE_ATOM, func, @@ -755,7 +758,7 @@ " Returning the original (un-chirped) Gabor atom.\n"); return( 1 ); } - +*/ mp_debug_msg( MP_DEBUG_CREATE_ATOM, func, "iter 0 : New freqIdx = %lu.\n", freqIdx ); @@ -906,6 +909,7 @@ /* TEST: if the correlation of the chirped atom is less than or equal to the correlation of the original unchirped one, it's a case where the chirp detection model is invalid => keep the unchirped one and exit. */ +/*DAN if (energy <= maxIPValue ) { mp_debug_msg( MP_DEBUG_CREATE_ATOM, func, @@ -916,6 +920,7 @@ chirprate = chirprateBefore; break; } +*/ mp_debug_msg( MP_DEBUG_CREATE_ATOM, func, "iter %2d : New freqIdx = %lu.\n", iter, freqIdx ); |
|
| Chirp-fitting example - difficulty with fast chirps [ Reply ] By: Dan Stowell on 2012-07-15 13:47 | [forum:109860]
chirptest.zip (25) downloads
|
|
Hi - I'm using the commandline MPTK 0.6.1 tools to analyse birdsong audio which contains fast frequency modulations. Attached is example code, which works nicely - there's a Python script "mptk_wav2csv.py" which takes a WAV file, analyses it, and plots a graph of the chirp trajectories recovered. Included is an example WAV file with a synthetic chirp, 6950--5100 Hz in 0.02 secs (this is measured to match a real birdsong example). You can see from the plot (PDF included in attachment) that it doesn't really recover the pure chirp. Typically, MPTK will fit a bundle of shallow-slope chirps, rather than the one or two strongly-sloping chirps that would be more what I'd expect. So, QUESTION: is there some way to make the chirp-fitting code work better on this kind of data? For example - is there a hard limit to the maximum slope it can consider, some setting I could change? (In the code I see #define MP_CHIRP_THRESH 0.5e-5, which might be part of the answer!) Any suggestions gratefully received. |
|
