What is check_dataVals for?

Once you have finished step #6 of the General Analysis Guide, you generally have looked at each trial one at a time in audioGUI. Step #7 of the general guide is to use check_dataVals, which does two things. First, check_dataVals automatically evaluates every trial on a couple criteria (discussed below) which might indicate that the trial needs to be corrected in some way. Second, it allows you to look at several "good" trials at once, to see if there are any obvious outliers. 

Navigating check_dataVals

In Matlab, navigate to the participant data folder. This is the folder with data.mat and expt.mat in it. In the Command Window, type check_dataVals and hit Enter. If it asks to overwrite a file dataVals.mat, say Yes.

Once the GUI opens, clicking an Error Type button on the left will take you to all trials in that category. Any category that's colored in has trials in it.

The Alerts area in the top center will show you how many trials are currently selected. You can click on the formant track of an individual trial to select just that trial.

Clicking the launch_GUI button in the top right will open audioGUI for the currently selected trial(s).

When you End out of audioGUI or Continue through all of the trials, you will be returned to check_dataVals. If you are prompted to overwrite a file called wave_viewer_params.mat, say No. (For a full explanation about overwriting, see this article.) The changes you made in audioGUI will not automatically update in check_dataVals. You must click the reload_dataVals button in the top right (and then say Yes to overwrite dataVals.mat) before trials you "fixed" will disappear from one Error Type category and hopefully move to the goodTrials category.

Fixing automatic errors

As mentioned above, check_dataVals has certain built-in checks to evaluate if a trial might have a problem. Your job is to 1.) Evaluate if the trial does in fact have a problem, and if it does, then 2.) Fix that problem. 

In general, some combination of adjusting audioGUI parameters and adding/removing user events will resolve all these issues. If that isn't working, you can mark the trial Bad in audioGUI. It's not worth spending more than a minute or two trying to fix any individual trial.

Here are all of the error types, what causes them, and generally how to fix trials in that category. 

• badTrials: all the trials you have marked as bad
  • These can be left alone
• shortTrials: trials that are under 200 ms
  • Take note of the horizontal x-axis in check_dataVals. How short are these short vowels? Often trials which appear in here are only 10-20 milliseconds long. This could be because the formant track looks like this: =   =================. As in, there's a very short formant track at the start which is being considered "the vowel," when you really want the longer =============== to be "the vowel".
    • Resolve this by either lowering the amplitude threshold so that the two formant tracks connect, or put in user events around the long, true vowel.
• longTrials: trials that are greater that 1 second (1000 ms)
  • If the participant truly did produce a vowel that was longer than 1000 ms, you should probably mark that trial as Bad, since it is too different from typical speech (where a vowel is 200-400 ms). In the past, our lab has run experiments where we ask participants to produce longer vowels, but the longest we typically allow is 550 ms.
• nanFTrials: trials that contain at least one sample of NaN
  • NaN stands for "not a number." It is Matlab's way of saying, "there should be a number here, but I don't know what it's supposed to be."
  • Typically NaNs happen in trials where user events (the vertical cyan bars) were added. If there is any space between the user events where there is no formant track, that will cause a NaN. In the screenshot below, everything in the pink region would be NaNs.
    • Remember: user events specify exactly when a vowel starts and stops. The computer doesn't know what to do if there is no formant track (and therefore no formant values) during "the vowel"

• • • • To fix this, either:
        • Remove the user events entirely (by putting the yellow cursor under the user event and pressing 'd') and just rely on the formant track start/stop points to mark vowel onset/offset
        • Put the user events in the correct place, and lower the amplitude threshold to some very low value (like 0.02), so that there is a constant formant track between the two user events. It's OK to have the amplitude threshold really low on trials with user events, because the user events specify exactly where the vowel onset/offset occurred.
  • Sometimes NaNFTrials is red (indicating that there are trials with NaN) but there are no visible formants in plotted on the graphs in check_dataVals. This can happen if a trial is only NaNs, since there are no values to plot. In that case, the "alert" section should still say "1 trial(s) selected." Just click launch_GUI, and you can fix those trials with all NaNs.
• jumpF1Trials: from one sample to the next, F1 changed by 200 Hz or more (typically a sample is 2ms)
  • Typically this means that there was a drastic change at the beginning or end of the vowel. First, check that the vowel onset and offset are accurately marked. If they are, consider changing the preemphasis to adjust the values of the formant track
• jumpF2Trials: Same as jumpF1Trials, but for F2
• fishyFTrials: trials in which F1 goes outside its typical range of 200-1000 Hz
  • Similar to jumpF1Trials, this typically happens at the beginning or end of the vowel. Make sure the beginning and end are marked properly.
  • If doing analysis on signalOut, this might happen because of a strong up or down F1 shift
• earlyTrials: trials in which the amplitude is too high during the first sample
  • Typically due background noise, or the person starting to talk before the word appeared on screen.
  • If the participant pronounced the word normally, you can keep it. But if it sounds weird, or is partially cut off, mark the trial as Bad.
• lateTrials: trials in which the amplitude is too high during the last sample
  
  • See notes on earlyTrials
• goodTrials: trials that did not fall into any of the error categories

Lastly, remember that these are simple, automated checks designed to find predictable problems. In contrast, you are an intelligent person who can consider context and nuance. If a trial is in any error category but it looks and sounds fine in audioGUI, you don't need to do anything. It's okay if that trial stays in an error category as long as you reviewed it.

Remember that you need to click the reload_dataVals button in the top right (and say Yes to overwrite dataVals.mat) to see your changes in check_dataVals.