Error: "No row matches criterion"

[MJTeaford]

Hi Hiram,
We exchanged email a couple of weeks ago, and as a script related issue came up in my research, I figured I'd post it here rather than send you an email about it, especially as past issues in this repository indicate that others have had similar problems. In running the script, I get the error 'No row matches criterion', followed by "Pitch has the value 'undefined'. Don't understand contents of field "pitch". Script line 582 not performed or completed: Add point...spot type'q". I've attached here the textgrid and .wav on which I'm attempting the analysis, I'm fairly certain that I've got my boundaries wholly around TBU's and thus can't figure out the problem. Any thoughts? I'll also attach the settings on which I'm running the script. Thanks, Max
MaxBa.zip

[MJTeaford]

Small update/detail: I recorded an identical file of myself, with identical tiers and labels. On the same settings as before, the script ran without a hitch, telling me that it must be a problem of either the original textgrid or the .wav file, both of which I appended in by above post about this issue. I've attached my own productions - "controls" - below. There must be some crucial difference between these file sets which allows the controls to work and the earlier set to throw an error, I just can't see what it is. Thanks again

ControlFiles.zip

[lingdoc]

Hi Max, thanks for the update! I'll take a look at the files tomorrow, but it sounds like the issue is with Praat's automatic detection of pitch in the boundaries you set.

The error basically means that for all of the sounds extracted for a particular label, none of them have a detectable pitch at one of the points where the script is looking. Depending on the speaker, this might be due to some kind of voicelessness at that point (on the consonant, breathiness before vocal fold vibration), or a host of other factors (including recording quality or proximity to microphone, etc.).

One way to mitigate this is to ensure that your label boundaries are located where you see visualization of tone in the Praat visualization window. But I'll double-check tomorrow and get back to you if I haven't heard more.

[lingdoc]

Ok, so looking at the file you sent, what is happening is that somewhere in the middle of one of the labeled segments, Praat's automatic pitch detection is not working properly. This might be due to the fact that one of the tones is much shorter than the others, so when the script tries to get the pitch value at 5% increments for that one sound, it fails at one of those points. With the file you sent, the fix is to change the 'Percentage increments' value in the initial script window from the default of 20 (which gives 5% increments) to something else - I tried 10 (which gives 10% increments). This works and produces the following plot:

This would probably not be an issue if you had multiple repetitions of the same word/tone in your sound file. As noted on the FAQ/Readme, the script works best when there are multiple items in the same category. This is because normalization works like averaging, and you need multiple items in the same category for averaging to work. It also smooths over problems with Praat's pitch detection algorithm, which seems to be the issue here.

[MJTeaford]

Hi Hiram, Wow, you are a wizard. Thank you so much! Tangential question, I suppose: How would the script work on something like the 3rd token in the .wav I uploaded, in which the speaker uses creak on the 3rd Mandarin tone, thus interfering with the automatic pitch detection? I’m attaching an image below to demonstrate. Thanks again, Max

…

On Oct 18, 2020, at 8:45 PM, Hiram Ring ***@***.***> wrote: Ok, so looking at the file you sent, what is happening is that somewhere in the middle of one of the labeled segments, Praat's automatic pitch detection is not working properly. This might be due to the fact that one of the tones is much shorter than the others, so when the script tries to get the pitch value at 5% increments for that one sound, it fails at one of those points. With the file you sent, the fix is to change the 'Percentage increments' value in the initial script window from the default of 20 to something else (I used 10), which works and produces the following plot: <https://user-images.githubusercontent.com/15827864/96399012-dbfc2680-11ff-11eb-9890-dfbf5f6dc9fe.png> This would probably not be an issue if you had multiple repetitions of the same word/tone in your sound file. As noted on the FAQ/Readme, the script works best when there are multiple items in the same category. This is because normalization works like averaging, and you need multiple items in the same category for averaging to work. It also smooths over problems with Praat's pitch detection algorithm, which seems to be the issue here. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHTM64PESVGWPJJCP3NHBZ3SLOY6HANCNFSM4SUTE6IQ>.

[lingdoc]

I can't see an image, but in general anything that is a problem for Praat's pitch detection is also an issue for the script (since it depends on Praat's detection). You would probably just need to play around with the settings a bit and see if that helps. I would also record the speaker doing multiple repetitions and with multiple words (perhaps creak is not as consistent in some phonological contexts for that speaker?). If creak is really a correlate of one of the tones for that speaker, it might be hard to visualize with this script.