Add HmmTreeBuilder #154
Open
Add HmmTreeBuilder #154
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds a treebuilder for the HMM-topology which is, in contrast to the old treebuilders ("minimized-hmm" and "classic-hmm"), compatible with the new TreeTimesyncBeamSearch.
For monophones, the tree is very simple:
To get this tree, the variation of the phonemes in the lexicon needs to be set to "none". If it's set to "context", it will work as well, but have unnecessary root states:
For diphones (diphone-dense state tying), the tree looks as follows:
Triphones are not supported. Depends on #127 as I am using the shared base class here as well.
I did one test run with the TreeTimesyncBeamSearch and there are not obvious errors. However, I still observe a degradation from 5.8% to 6.2% which could have multiple reasons. Therefore, some considerations for future work:
In order to get competitive results, there might still be some details we need to implement. Most importantly, we need an exit penalty, which might be easy to add to the search, but we should probably allow for different exit penalties for words and non-words (silence/unknown). Furthermore, with the TransitionLabelScorer, it is easy to define TDPs, but again, we should have the possibility to have different TDPs for non-words, so we would need more transition types (especially silence-transitions) and tiny adjustments in the search algorithms.