You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's currently an inconsistency between how fasttrackpy and fasttrack implement
The number of LPC coefficients to use
The number of formants to optimize over
The number of formants to return
In fasttrack:
$o = x$ = The number of formants to optimize over, and the number of formants returned.
$(2x)+3$ = The number of LPC coefficients used
In fasttrackpy
$1 \le o \le x$ = The number of formants optimized over and returned.
$2x$ = The number of LPC coefficients used.
The reason $o \le x$ is because some formants may not be tracked with just $2x$ LPC coefficients, so the number of formants optimized over is dynamically adjusted downwards to the largest number of formants in common within a set of candidate tracks.
Proposal
We should adjust the fasttrackpy behavior to be like fasttrack, adding an additional 3 LPC coefficients prior to formant tracking.
This keeps the range of sensible max-formants more compatible with the settings and results using fasttrack
This keeps the behavior of the two packages consistent.
Consequences
The documentation will need to be updated to communicate that 3 more LPC coefficients are added prior to audio processing. That is
n_formants is the number of formants users want to optimize over and get back.
n_formants + 1.5 is what will be passed to Praat's To formant burg
Since we're still at v0.x.x, we may not need to release a 1.0 version, even though this is a breaking change within fasttrackpy.
The text was updated successfully, but these errors were encountered:
3 <= o <= 4: number of formants to optimize over and return.
11: the number of LPC coefficients used. This is independent of the parameters to optimize over.
This ensures that at least 4 non-zero formants can be tracked in any (?) situation. My proposed solutions would be to fix coefficients at 11 and not make it be 2*n_formants+3. The latter solution would mean maximum formant ranges are analysis specific. Also pushing the Nyquist frequency away from the formant of interest is usually good within these frequency ranges. At the very least I believe this should be under the control of the user if we are going to have the number of coefficients vary. For example some people may desire to optimize over 3 formants but still use 11 coefficients.
Problem description
There's currently an inconsistency between how fasttrackpy and fasttrack implement
In fasttrack:
In fasttrackpy
The reason$o \le x$ is because some formants may not be tracked with just $2x$ LPC coefficients, so the number of formants optimized over is dynamically adjusted downwards to the largest number of formants in common within a set of candidate tracks.
Proposal
We should adjust the fasttrackpy behavior to be like fasttrack, adding an additional 3 LPC coefficients prior to formant tracking.
Consequences
The documentation will need to be updated to communicate that 3 more LPC coefficients are added prior to audio processing. That is
n_formants
is the number of formants users want to optimize over and get back.n_formants + 1.5
is what will be passed to Praat'sTo formant burg
Since we're still at v0.x.x, we may not need to release a 1.0 version, even though this is a breaking change within fasttrackpy.
The text was updated successfully, but these errors were encountered: