Skip to content

Document and test forced-alignment variant-token handling #503

Description

@lenzo-ka

Summary

PocketSphinx's forced alignment already honors explicit dictionary pronunciation variants, but the behavior is neither documented on the API nor covered by tests. This proposes documentation and regression coverage for the existing contract, with no behavior change.

Existing behavior (v5.1.1, commit 511126b)

ps_set_align_text() verifies each whitespace-separated token with an exact dict_wordid() lookup and builds the alignment FSG from the spelling supplied. As a result:

  • An explicit variant spelling such as a(2) is aligned with only that dictionary entry's pronunciation (in the shipped cmudict-en-us.dict, a is AH and a(2) is EY).
  • A base spelling such as a still expands to its alternate pronunciations (fsg_search_add_altpron() walks dict_nextalt() from the base word id), so it may align as AH or EY.
  • An unknown spelling such as a(99) is rejected: ps_set_align_text() returns -1 and logs Unknown word a(99).

None of this is stated in the ps_set_align_text() documentation, and there is no test asserting it, so the contract could regress silently.

Proposal

Document the contract on ps_set_align_text() and add unit tests: one asserting the unknown-variant rejection and acceptance of known base/variant spellings, and one asserting that the constructed alignment FSG adds an alternate-pronunciation transition for a base token but not for an explicit variant token. No change to dictionary lookup or decode behavior.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions