[mirtoolbox] Re: peak fluctuation value as input for miremotion
- From: Olivier Lartillot <olartillot@xxxxxxxxx>
- To: mirtoolbox@xxxxxxxxxxxxx
- Date: Wed, 23 Feb 2011 10:49:09 +0200
Hi Hendrik,
Thank a lot for your feedback. You are absolutely right, I just realized that
the values of the output of mirfluctuation appears to be linearly dependent on
the audio input length. (Because we compute FFT along time of each frequency
band.) I propose to divide the values by the duration of the audio input. How
does this sound?
This might have important impact on miremotion indeed. At least, miremotion
with 'Frame' option is not sensible to that problem, because in that case,
mirfluctuation was computed on successive segments of constant default size.
But speaking of this outer 'Frame' decomposition, I just realize also that the
default frame length (1 s) is too short, because we cannot compute pulse
clarity correctly with this short time window. I propose to change the default
to 2 s and issue a warning if the use specifies shorter frame length.
I modify therefore both mirfluctuation and miremotion for the upcoming update
of MIRtoolbox.
Cheers,
Olivier
Hendrik Schreiber kirjoitti 15.2.2011 kello 12.37:
> Hi,
>
> I've been studying miremotion a little bit and in that context also
> mirfluctuation.
>
> It seem to me that you are using the peak value of the summary (the plain
> sum) of mirfluctuation as input for miremotion.
> However, this value does not seem to be normalized, i.e. it seems to heavily
> depend on the length of the audio fed into it.
> In my tests, long audio pieces seem to consistently produce higher peak
> (summarized) fluctuation values.
>
> If that's really the case, miremotion results should also heavily depend on
> the audio length, which is probably not desired.
>
> Am I missing something crucial here?
>
> Thank you.
>
> -hendrik
>
> tagtraum industries incorporated
> 724 Nash Drive
> Raleigh, NC 27608
> USA
> http://www.tagtraum.com/
> http://www.beatunes.com/
Other related posts:
