This invention relates to a method to convert text into its correct phone sequence and form a compact phone dictionary that may be embedded in a compact computer chip.
In a large vocabulary speech recognition system, a text-to-phone component is required to convert the text into its correct phone sequence. The system then selects corresponding phonetic models to construct recognition models based on the phone sequence. The size and complexity of the text-to-phone component vary widely for different languages. For a language with more regular pronunciations than English, such as Spanish, a few hundred rules are enough to convert text to phone accurately. On the other hand, for a language with more irregular pronunciation, such as English, tens of thousands of rules are required to convert text to phone accurately. There are about as many pronunciation rules as there are words in English. It is really a pronunciation dictionary. We use a typical English pronunciation dictionary with 70,955 entries. It takes up to 1,826,302 bytes in ASCII form.
It is highly challenging to implement the text-to-phone dictionary in an embedded system such as part of a computer chip where memory space is a premium. One such use, for example, is building speech recognition models for a phrase used in a voice controlled web browser. One has to start with the text and look up a pronunciation dictionary of phones for the text. Once the phones are identified and the sequence of phones for words are determined, HMM model for each phone is determined. A dictionary with 1.8 Mbytes is too large a storage requirement for an embedded system. While compression techniques such as the asymptotically optimal Lempel-ZIV coding can be used for compression, this form of compression is not computable or searchable. The compressed data must be uncompressed to do a dictionary lookup. One, therefore, must have the memory space to do the lookup and therefore the uncompression defeats the purpose of saving memory space.
In addition, dictionary lookup usually requires additional data structures other than the dictionary itself. For example, once a dictionary is loaded into the memory which requires, for the example, 1.8 Mbytes, a very large array of address pointers is required to search the memory.
In accordance with one embodiment of the present invention, a resource efficient representation of a pronunciation dictionary is provided by efficiently formatting the pronunciation dictionary by reducing vocabulary.
In accordance with another embodiment of the present invention, the dictionary only contains entries with pronunciation rules different from the rule set prediction.
Referring to
The format of a dictionary follows the example format below:
Every entry takes up one line: the word followed by tab, followed by phone sequence.
In accordance with one embodiment of the present invention, delta coding is used between neighbors since word and phone sequences look a lot alike between neighbors. This is step 101 in
This algorithm is very effective due to the fact that the dictionary is sorted in alphabetical order. For an English dictionary list of 70,955, it is almost as good as the asymptotically optimal Lempel-ZIV coding wherein the original ASCII file is 616K, the Lempel-ZIV is 284K, the prefix delta encoding is 311K. The prefix delta encoding is computable or searchable.
In accordance with a preferred embodiment of the present invention, a public domain rule set from the Naval Research Laboratory is used. The rule set is from NRL Report 7948, dated Jan. 21, 1976, published by the National Technical Information Service as document “AD/AO21929.” A copy is provided in Appendix A. It has 384 rules. Each rule consists of the text to be converted to phone, left/right contexts, and the output phone sequence.
An example of one of the rules is:
{Anything, “AW”, Anything, “AO”}
It means that the text “AW” will be converted to phone “AO” (as in lAWn). The left and right contexts can be anything (do not care).
Because it is a small rule set, the accuracy of the phone sequence it predicts is not good. When all 70,955 entries in the example dictionary are run through these rules and calibrate the performance, the word error rate (WER) is 19.7%. The WER means the percentage of phones of the prediction that do not match the correct pronunciation. The sentence error rate (SER) is 69.5%. The SER means the percentage of words where the pronunciation does not completely match the prediction. In other words, the rule predicts only about 30% of the word entries correctly. Most of the errors are substitution errors. The substitution error rate is 16%. The insertion error rate is the error of wrongly inserting a phone and this error rate is 2.6%. The deletion error is a missing phone and that error rate is 1.1%. The WER error rate of 19.7% means that about 80% of the phones are predicted correctly.
Because 80% of the phones can be predicted correctly, the dictionary can be error encoded to save space. This is Step 102 in
The SER is 100% because only the difference from prediction entries is used. There are a total of 348K phones in the pronunciation of these 49,344 entries. Using the same formula, substitution and deletion require 2 bytes and insertion requires one byte, Substitution (21.5)+Deletion (1.5)=23×2=46+Insertion (3.5)=49.5%. Error encoding of these phones will require 348K×49.5%=172K.
There is redundancy of the error encoded pronunciation. Therefore, prefix delta encoding is applied after the error encoding to the pronunciation. This is Step 103 in
Using the above, there are 50,624 entries needed to code. More than 49,344 to account for multiple pronunciations All entries of the same word are needed when some alternate pronunciations are different.
The size in bytes of 411,723 for the original ASCII is reduced to 187,734 for prefix delta encoding.
For the pronunciation, also 50,624 entries the size in bytes for original ASCII is 356,386, for the prefix delta is 218,479, for the error encoding is 172,579 and for both error encoding plus prefix delta is 129,241.
In addition to the above data, delimiter characters are needed to separate each entry and to separate word and pronunciations in each entry. Therefore, the final encoded entry comprises:
Therefore, the final size of the encoded dictionary is 187,734+50,624+129,241=367,599.
We can load the above files of 367,599 bytes and create an array of 50,624 addresses to access each entry. The prefix delta encoding and error encoding can be decoded easily.
However, 50,624 addresses requires 50,624×4 (address or index requires 4 bytes)=202,496 bytes. This is too large and almost as large as the dictionary. The alternative is to embed some alignment characters (the delimiter discussed above) in the encoded dictionary so that no matter which byte we fall in the dictionary byte stream, we can always find the start of an entry. See Step 104 in
This application claims priority under 35 USC § 119(e)(1) of provisional application number 60/144,216, filed Jul. 19, 1999.
Number | Name | Date | Kind |
---|---|---|---|
4342085 | Glickman et al. | Jul 1982 | A |
5835888 | Kanevsky et al. | Nov 1998 | A |
6148283 | Das | Nov 2000 | A |
6230131 | Kuhn et al. | May 2001 | B1 |
6243680 | Gupta et al. | Jun 2001 | B1 |
6308149 | Gaussier et al. | Oct 2001 | B1 |
6363342 | Shaw et al. | Mar 2002 | B1 |
6738741 | Emam et al. | May 2004 | B1 |
Number | Date | Country | |
---|---|---|---|
60144216 | Jul 1999 | US |