Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fasttrackpy / fasttrack inconsistency #59

Closed
JoFrhwld opened this issue Mar 13, 2024 · 2 comments · Fixed by #61
Closed

fasttrackpy / fasttrack inconsistency #59

JoFrhwld opened this issue Mar 13, 2024 · 2 comments · Fixed by #61
Assignees
Labels
bug Something isn't working

Comments

@JoFrhwld
Copy link
Member

Problem description

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.

@JoFrhwld JoFrhwld added the bug Something isn't working label Mar 13, 2024
@santiagobarreda
Copy link
Collaborator

santiagobarreda commented Mar 13, 2024

The behavior in fast track (praat original) is:

  • 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.

JoFrhwld added a commit that referenced this issue Mar 14, 2024
@JoFrhwld
Copy link
Member Author

I've created a branch to work on this.

@JoFrhwld JoFrhwld linked a pull request Mar 15, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants