FAVE & ING (and other variables)

[Laurel MacKenzie]

Hi all,

My students and I have noticed that a few -ing words in FAVE-align's dictionary have two pronunciations, one with final NG and one with final N. This becomes problematic when they want to use Praat scripts like Joe's handcoder to code ING variation. Even if they transcribe a word as ending in -ing, if FAVE overrides that and phonemicises it with a final N, the ING handcoder won't pick it up (as it searches only for instances of velar nasals). This is definitely the case with the word GOING, which has two pronunciations in cmudict, G OW1 IH0 NG and G OW1 IH0 N. A student also found FAVE to do this with ASKING, i.e. phonemicise it with a final N even though she transcribed it with -ing, which is somewhat mysterious as there only appears to be one entry for ASKING in (at least my version of) cmudict and it ends in a velar nasal.

I recognise that we want to incorporate some pronunciation variants into FAVE's dictionary (many function words, for instance, are in there with two pronunciations, one with a full vowel and one with a reduced one), but it seems like a slippery slope from there toward incorporating all possible sociolinguistic variants, which we obviously don't want to do, so I wonder where we should draw the line. At the very least, it seems like we should be consistent within variables, so either giving all -ing words two possible pronunciations, or giving all of them only one.

Naturally, those of us who are running FAVE locally on our own machines can edit its dictionary however we want. But my students are running FAVE through the web interface, and we don't have access to its dictionary. (It also seems like a herculean task to have to go through the dictionary and hand-correct all of these loci of variation, but that's a separate matter...)

On a related note, it would be nice if the web version of FAVE allowed users to upload their own dictionaries. I know users can supplement the existing dictionary with an out-of-dictionary word file, but given cases like this I'd almost rather start afresh and use my own, cleaned-up version. (I did try using the 'import dictionary transcriptions' feature to upload a complete, 8MB dictionary, just to see what would happen, but this resulted in alignment failure for all annotation units.)

Best,

Laurel

[Hilary Prichard]

Hi everyone,

To add to Laurel's point -- Unfortunately this is a problem with the CMU dictionary itself, not specific to the one used by FAVE, although I'm sure our procedures for adding words to the dictionary through FAVE has only exacerbated this problem. In addition to the ING problem, I've noticed recently that FAVE's short-a coding is similarly being sabotaged by CMU alternatives which include elision or consonant cluster reduction. E.g., words like SANTA are being variably coded as tense or lax based on which pronunciation is selected - S AE1 N T AH0 or S AE1 N AH0.

Best,

Hilary

--
You received this message because you are subscribed to the Google Groups "FAVE (Force Alignment and Vowel Extraction) Users Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fave-users+...@googlegroups.com.
To post to this group, send email to fave-...@googlegroups.com.
Visit this group at http://groups.google.com/group/fave-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/fave-users/35629842-47df-42ad-a439-8bb49ef46db6%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Josef Fruehwald]

One possibility for cleaning up the FAVE dictionary would be to filter through the CMU dictionary looking for multiple entries for words, and just keep the longest entry. That'll process will have to be reviewed by a person, though. I just quickly loaded up the cmudict in python through nltk to play around with this, and the word I used to test if I'd done it correctly was "what", which turns out to have two entries: "W AH1 T" and "HH W AH1 T." The keep the longest approach would align everything with "HH W AH1 T" which is definitely not desirable.

I think this is an important issue to think about as development of "best practices" for using forced alignment for sociolinguistics. For some purposes, you want to give the aligner more choices so you can get a more accurate alignment, but you can't trust the general purpose aligner to make the right choice in cases like these. 

-Joe

[Meredith Tamminga]

For what it's worth, I have a version of the CMU dictionary from which I've removed the ING pronunciations with the alveolar /n/ (it affects many many ING words in the dictionary). This was to solve exactly the problem Laurel pointed out. I would be happy to share it with anyone who is working on this particular issue, and also would be happy to share the Python script that I used to remove the unwanted pronunciation variants in case someone is interested in adapting it to clean up other issues in the CMU dictionary. As Laurel points out, of course, this is only currently useful if you are running FAVE on your local computer.

Meredith

To view this discussion on the web visit https://groups.google.com/d/msgid/fave-users/ba15eb4d-8034-4fe6-b0e1-fd231a64ab7e%40googlegroups.com.

[Kyle Gorman]

Hi all, just had a few thoughts to add.


It only matters that a variable rule is not projected into the dictionary in the case that application of that rule leads to an alignment error. Though (ing) is very frequent, it probably leads to very few confusions, whereas r-vocalization would lead to many (as work on AAVE speech recognition has shown). And an alignment system is capable of sorting out quite a bit of variation not present in the dictionary. The aligner "deletes" by giving a segment zero duration. Coronal/dorsal nasal variation as in (ing) is possible with appropriately permissive acoustic models. In general, that is an argument for not putting stable variants into the dictionary (or removing them). There is fancy engineering work which tries to extract rules which can be used to avoid word confusions when the dictionary does not match the dialect, but that's probably outside the scope of this project.


When resources like the CMU dictionary are used "in industry", it is common for someone to edit it to remove weird words, rare words, strange proper names, weird entries for common words, etc. It is certainly not too late to do this, nor would it be inappropriate to use another, more-constrained dictionary resource. But, the acoustic model bin trained (remote past) with the full CMU dictionary. So, if you remove a bunch of stable variants in the dictionary, it might have a negative effect on the acoustic model because it was trained with (ing) variation occasionally present in the dictionary. If you do choose to make major changes to the dictionary, you may want to get a hold of the SCOTUS data (or whatever; much better would be something more domain-appropriate, say the PNC) and retrain.


There is one thing that is (variably) in the dictionary which, IMO, emphatically should not be: wordforms with the Saxon genitive ('s) clitic. As you probably know, that clitic can attach to any part of speech:

(Noun) Fred's opinion about the English genitive is different from mine.
(Verb) Every linguist I know's opinion about the English genitive involves functional categories.
(Preposition) That young hotshot who was recently hired at Princeton that I was just telling you about's opinion about the English genitive is simply wrong.
(Adverb) That linguist who is wrong often's analysis of the English genitive is overly complex.

So adding these to the dictionary is a futile struggle against Zipf's law. A better approach is to treat the clitic as an independent word---insert a space before any instance of "'s" (not already preceded by whitespace) in the label file---and add it to the pronunciation dictionary. I'd be willing to assist with implementing that functionality if changes to the dictionary are being made anyways.


Kyle

> To view this discussion on the web visit https://groups.google.com/d/msgid/fave-users/CAHue2pqRpDV5Tgudz4_4A2trkcKRBzi8VSQHTNPKME-oJXQc%3Dg%40mail.gmail.com.