Hi emanuelle,

Sorry for the delay in replying, been travelling...

First off, the most current release of the VoxForge acoustic model is old and needs to be updated.  

>would know if i have to do a new acusticus model for this julius all time that

>i insert a new word in my .voca

It depends... the dict file included in the Julius_AcousticModels_8kHz-16bit_MFCC_O_D_build726 build only shows the words that were used in the training set used to create those acoustic models.  However, Step 10 of the acoustic model creation process (note the VoxForge tutorial uses a different lexicon than was used in the VoxForge acoustic model) creates tied-state triphones for the entire lexicon file.

So in theory you are not limited to just the words in the dict file.  You are really only limited to the words in the original lexicon (much larger set of words) that was used to train the acoustic model (likely revision 2107 of the VoxForge Lexicon file).

>so is there any tiedlist with all possible word or i have to do this?

The tiedlist file is simply a list of the monophones, biphones and triphones that were created as part of the acoustic model creation process.  Adding new triphones for new words is done automatically when you retrain a new acoustic model as new words are added to your training set.  You can't add new mono/bi/tri-phones to the tiedlist file if they don't exist in your hmmdef file. 

You could theoretically manually create a mapping from a "logical" triphone to a "physical" triphone (i.e. the actual hmmdef entry) - which is basically what step 10 of the training process is doing automatically, but it would get very tedious to do this for every new word you come across.  It might not be as accurate as retraining with real speech audio data containing the new word you want to recognize.

Hoe that helps.

Ken

--- (Edited on 8/23/2008 9:51 pm [GMT-0400] by kmaclean) ---

I have a question about building a robust acoustic model for ASR with an arbitrary vocabulary.  This thread suggests that in order for the recognizer to work robustly, training data must be included for all possible triphones.  Is this the case?  That would suggest a very large corpus of training data that includes some unusual phoneme combinations.

--- (Edited on 9/7/2008 7:56 pm [GMT-0500] by Visitor) ---

Hi,

>This thread suggests that in order for the recognizer to work robustly,

>training data must be included for all possible triphones.

See nsh's comments (7th post down) here for a correction of this assumption: Re: covering all nodes of a language

Ken

--- (Edited on 9/7/2008 9:39 pm [GMT-0400] by kmaclean) ---