[Simon]

The PHON material is too hard

In line with the numerical score distribution, around a third of respondents found the PHON material very challenging. We will adjust the delivery of this material in future to make it more accessible to people without any background.

For this year, the PHON material is being assessed in both items of coursework and in the exam. Our expectations of what students will master are realistic. Knowing the basics will be enough to do well on this course.

[Simon]

Summary of the numerical responses, with my responses

There is enough ongoing technical support (for the VM, Festival etc): 4.4

This seems to be working fine.

The tutorial sessions are useful: 3.8

The tutorials appear to be mostly useful, but we accept that there is room for improvement. In the second half of the course we will shift slightly towards covering the core material rather than problem sets / Python notebooks. Tutorial groups vary widely in how well they are working – see response to written comments below.

I find speech.zone easy to use and navigate: 4.5

Thank-you. If there is anything you would like to improve in general about the site, post on the Requests forum.

I find the forums on speech.zone useful: 4.4

Also good – please keep using them!

The lecturers (Simon, Catherine, and Rebekkah) are helpful: 4.6 (no ratings below 3 ;5 responses of 3; the rest 4 or 5)

Thank-you for the positive feedback. We very much appreciate that.

The tutors (Jason, and Jason) are helpful: 4.1

Thank-you from the tutors.

The difficulty of the SIGNALS tutorial material is appropriate (1 – too easy, 3- just right, 5 – too hard): 3.8 (with only one response below 3 and all others 3, 4, or 5)

The best way for us to improve the course is to experiment a little each year. This material (new for this year) was designed to be challenging. It ended up a little more challenging than intended. We will be keeping this material in the course, but we will divide each notebook into levels of difficulty to make it clearer what is essential and what is optional.

The difficulty of the PHON tutorial material is appropriate (1 – too easy, 3- just right, 5 – too hard): 3.0 (with a spread of scores right across the range).

This area is where a few students will have a strong background and other no background at all. The wide spread of scores surprised us. In future, we will try to make this material more accessible for students without any background.

I would like a weekly timetabled lecture for the remaining modules (1-strongly disagree, 5-strongly agree): 3.4 (with 8 people rating below 3 and all others 3,4 or 5)

General positive feeling towards this, but not overwhelming. We have responded to this by providing a pre-recorded class video at the start of each week, then going over that same material in a live format on Tuesdays. The live class will be recorded, so attendance is not required for those who cannot make it.

[Simon]

Distance is what we use in pattern matching. A smaller distance is better: it means that patterns are more similar. The Euclidean distance is an example of a distance metric.

Probability is what we use in probabilistic modelling. We use probability density rather than probability mass when modelling a continuous variable with a probability density function. The Gaussian is an example of a probability density function (pdf).

When we use a generative model, such as a Gaussian, to compute the probability of emitting an observation given the model (= conditional on the model) we are calculating a conditional probability density, which we call the likelihood.

A larger probability, probability density, or likelihood is better: it indicates that a model is more likely to have generated the observation.

To do classification, we only ever compare distances or likelihoods between models. We don’t care about the absolute value, just which is smallest (lowest) or largest (highest), respectively.

The log is a monotonically increasing function, so does not change anything with respect to comparing values. We take the log only for reasons of numerical precision.

It doesn’t matter that probability densities are not necessarily between 0 and 1; they are always positive, so we can always take the log. A higher probability density leads to a higher log likelihood.

Taking the negative simply inverts the direction for comparisons. We might use negative log likelihoods in specific speech technology applications when it feels more natural to have a measure that behaves like a distance (smaller is better).

In general, for Automatic Speech Recognition, we use log likelihood. This is what HTK prints out, for example. Those numbers will almost always be negative in practice, but a positive log likelihood is possible in theory because a likelihood can be greater than one when it is computed using a probability density.

[Simon]

Yes, HMMs can be used for speech synthesis. We would not use MFCCs because they are not invertible, due to the filterbank. We might use something closer to the true cepstrum.

[Simon]

Pre-emphasis is primarily to avoid numerical problems in taking the DFT of a signal with very different amounts of energy at different frequencies. Using too much pre-emphasis might have negative consequences by over-boosting high frequencies, but typically only modest pre-emphasis is applied.

Pre-emphasis will boost any non-speech at higher frequencies, yes. So, if that is noise then pre-emphasis will make the Signal-to-Noise Ratio (SNR) worse. Again, this should not be a problem with the modest amount of pre-emphasis typically used.

[Simon]

Try this (again, I’m using echo just as an example of a program that produces output on stdout – you are probably trying to capture the output of a more interesting program):

$ echo -e "this is 1\nand now 2"
$ echo -e "this is 1\nand now 2" | grep this
$ echo -e "this is 1\nand now 2" | grep this | cut -d" " -f3

cut cuts vertically and the above arguments say “define the delimiter as the space character, cut into fields using that delimiter, and give me the third field”

To capture the output of a program, or of a pipeline of programs as we have above, we need to run it inside “backticks”. So, let’s capture the output of that pipeline of commands and store it in a shell variable called MYVAR:

$ MYVAR=`echo -e "this is 1\nand now 2" | grep this | cut -d" " -f3`
$ echo The value is: ${MYVAR}

[Simon]

Unix programs print output on one or both of two output streams called stdout (standard out) and stderr (standard error). The former is meant for actual output and the latter for error messages, although programs are free to use either for any purpose.

Here’s a program that prints to stdout for testing purposes: it’s just the echo command:

$ echo -e "the first line\nthe second line"

which will print this to stdout

the first line
the second line

Now let’s capture that and do something useful with it. We ‘pipe’ the output to the next program using “|” (pronounced “pipe”):

$ echo -e "the first line\nthe second line" | grep second

which gives

the second line

where grep finds the pattern of interest. Or how about cutting vertically to get a certain character range

$ echo -e "the first line\nthe second line" | cut -c 5-9

which gives

first
secon

Now combine them:

$ echo -e "the first line\nthe second line" | grep first | cut -c 5-9

to print only

first

[Simon]

At first, yes, make it by hand so you get the format right.

Eventually, you’ll want to make it from a list of USER names. The forum on shell scripting has some tips on how you might do this using a for loop that reads the USER list from one file and creates an HTK script in another file.

[Simon]

a script file (e.g., it might be called train.scp) would look something like this – a list of MFCC files with full paths:

/Volumes/Network/courses/sp/data/mfcc/train/s1764494_train.mfcc
/Volumes/Network/courses/sp/data/mfcc/train/s1766810_train.mfcc
/Volumes/Network/courses/sp/data/mfcc/train/s1770642_train.mfcc

You pass this using the -S flag like this

HRest ...other command line args here... \
      -S train.scp \
      models/hmm0/$WORD

noting that when you use -S you no longer pass any MFCC files as command line arguments.

[Simon]

You are probably running the script from inside the scripts directory. The scripts are very simple and only work from the main directory. You should run them like this:

$ pwd
/home/atlab/Documents/sp/digit_recogniser
$ ./scripts/initialise_models

[Simon]

Your script should be simply

#!/usr/bin/bash
./scripts/initialise_models
./scripts/train_models

You don’t need the $ – those represent the bash prompt in the instructions.

Your line SCRIPT_PATH="/Documents/sp/digit_recogniser/" is not needed because you don’t use the shell variable SCRIPT_PATH anywhere later in the script. If you did need this, then the path should most probably be ~/Documents/sp/digit_recogniser/ where ~ is shorthand for your home directory.

[Simon]

Look under the “Class” tab for Module 7. The “Live class” item now has written notes.

Let me know if this is useful and I will add this for other modules.

[Simon]

Yes, that’s a reasonable approach.

In this classic paper on voice conversion they use the cepstrum to represent the spectral envelope rather than LPC co-efficients.

In this paper, we do use linear prediction as the parameterisation of the spectral envelope. But we don’t use the co-efficients of the difference equation (the LPC parameters) directly – we transform them to another representation called line spectral frequencies (LSFs) for reasons explained in the paper.

Rather than use the source speaker’s residual (which is one option), we predict the residual from the converted spectral envelope.

[Simon]

If you are Edinburgh, please remember that there are plenty of hardcopies for loan in the main library.

[Simon]

Yes – you can read waveforms!

[Author]

Posts