Subject: [Speechsc] Speaker Verification Comments

From: Claudia Daboul <[email-masked]>
Date: Sun, 23 May 2004 21:13:43 +0200

Hello,

I have some comments and some questions on the Speaker Verification
section of the MRCPv2 spec.

By the way of introduction: I took part on some integrations of speaker
verification functionality in the ECTF S.100 framework and also in other
vendor specific frameworks. Some intergrations were based on Nuance's
Verifier/Recognizer but we also integrated a "standalone" verifier
running in parallel with an independent recognizer.

My questions/comments:

1 a) It seems impossible to create a new speaker identification group
with the protocol, since according to the examples for
VER-SET-VOICEPRINT, it will fail if the group doesn't exist. It should
be possible to specify a new group in a training session, but not in an
identification session.
The problem seems to be that the session type can only be specified
after the voiceprint is set. This leads me to the next question, which
is a bit more general.

1 b) Why should the speaker model be changeable in a training or
verification session? In the frameworks I've worked in so far, a
training or verification session has always been associated with only
one speaker model/group record. This also means that the commands
SET-VOICEPRINT and SET-PARAMS(verification-mode) are included in the
START-SESSION command.
Furthermore the parameters "security-level",
"num-min-verification-phrases" and "num-max-verification-phrases" are
usually specified for a session and not for a single utterance (in the
VERIFY command).

1 c) The headerfields voiceprint-uri and adapt-model can't be fixed 
through the SET-PARAMS function, although they will usually not change 
in an application.

1 d) The protocol doesn't specify an interval for verification and
training scores.

1 e) Shouldn't it be possible for the client to set thresholds for
acceptance or rejection and for adaptation based on
verification/training scores?

2 a) A question concerning buffering in a file (using VERIFY with the
"save-waveform" headerfield): It is not clear to me what happens when
VERIFIY is called for the second time with the header-field
"save-waveform = true". Should the second utterance be appended to the
first one in the already existing file or will a new file be created for
each utterance?

2 b) For verification from a file the VERIFY function is used, although 
the action is similar to the VERIFY-FROM-BUFFER function.

3 a) Why can a digit sequence be specified as a required phrase, but not
a text phrase? In any case a recognizer is needed to check the required
phrase or digit sequence, but then it depends on the grammar used by the
recognizer which phrases can be used as the required phrases.

3 b) For checking the required phrase or digit sequence a standalone
verifier would have to communicate with a recognizer running at the same
time. This would only make sense, when verifier and recognizer are on
the same host. When they are on different hosts, I suppose that the
communication would have to include the client, but then it would be
easier, if the client checks the required phrase itself and deletes the
utterance from the verification process if necessary.

3 c) I did not quite understand how the "verification-type" parameter
should influence the verifiers behaviour.

4) Some database operations are missing in the spec, which I think are
necessary:

4 a) It should be possible to make copies of speaker models and of group
records.

4 b) As a voiceprint can be part of several groups it should be possible
to delete a group record without deleting all the voiceprints it contains.

4 c) There should be a function allowing to subscribe existing
voiceprints to a group which may already exist or otherwise be created.

5) When verifier and recognizer are colocated (in one session), the
VERIFY and RECOGNIZE commands usually specify the same action twice.

6) There is no parameter for the verifier specifying the maximum length
of an utterance. For the recognizer it was called recognition-timeout.

Suggestions:

1a)&1b) The START-SESSION command should have the following optional
header fields:
- adapt-model,
- voiceprint-uri,
- voiceprint-identifier,
- voiceprint-group,
- verification-mode,
- security-level,
- num-min-verification-phrases,
- num-max-verification-phrases.

The SET-VOICEPRINT command should be ommited.

1 c) The headerfields voiceprint-uri and adapt-model should be settable
also through the SET-PARAMS function.

1 d) Set the interval for verification and training scores to [-100, 100].

1 e) Allow setting thresholds for acceptance or rejection and for
adaptation based on verification/training scores.

2 a) Make file buffering similar to internal buffering. Thus utterances
should be concatenated and there should be a mechanism to delete the
buffering file.
Alternative: By default create a new file for each utterance, but if the
client wishes to append an utterance to an existing file, it should set
the header-field "waveform-url = existing waveform-url" together with
"save-waveform=true" in the VERIFY function.

2 b) Use the VER-FROM-BUFFER (with the headerfield input-waveform-url)
function rather than VERIFY to process the utterances stored in the file.

3 a) Allow also text phrases as required phrases.

3 b) There should be a communication mechanism between verifier and
recognizer similar to the communtication between player and recognizer
when the prompt is finished. When verifier and recognizer are on
different hosts, the required phrase should not be settable.

4 a) Extend the DELETE-operation to allow deleting a group record
without deleting all the voiceprints it contains.

4 b) Define a COPY-RECORD function for speaker models and groups.

4 c) Define a SUBSCRIBE-GROUP function.
Alternative: Make subscription a special case of the COPY-RECORD function.

5) Allow sending the VERIFY and RECOGNIZE commands in one message, when
verifier and recognizer are in the same session.

6) Rename the headerfield recognition-timeout to max-speech-duration and
make it an optional headerfield of the VERIFY command.

With best regards,

Claudia Daboul

-- 
Dr. Claudia Daboul
Luetkensallee 19
22041 Hamburg
Tel.: +49 (40) 3172541
Fax.: +49 (40) 3172547
E-mail: [email-masked]

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc