Re: [Speechsc] Question on Verification Result Device type

Nik Waldron <nik.waldron@kaz-group.com> Thu, 11 June 2009 20:58 UTC

Return-Path: <nik.waldron@kaz-group.com>
X-Original-To: speechsc@core3.amsl.com
Delivered-To: speechsc@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4CF73A68CB for <speechsc@core3.amsl.com>; Thu, 11 Jun 2009 13:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mium0E5kWwLn for <speechsc@core3.amsl.com>; Thu, 11 Jun 2009 13:58:58 -0700 (PDT)
Received: from mail51.messagelabs.com (mail51.messagelabs.com [216.82.241.99]) by core3.amsl.com (Postfix) with SMTP id C33543A67EE for <speechsc@ietf.org>; Thu, 11 Jun 2009 13:58:57 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: nik.waldron@kaz-group.com
X-Msg-Ref: server-2.tower-51.messagelabs.com!1244753943!46717075!1
X-StarScan-Version: 6.0.0; banners=kaz-group.com,-,-
X-Originating-IP: [203.28.13.56]
Received: (qmail 7415 invoked from network); 11 Jun 2009 20:59:04 -0000
Received: from mail02.kaz-group.com (HELO mail02.kaz-group.com) (203.28.13.56) by server-2.tower-51.messagelabs.com with SMTP; 11 Jun 2009 20:59:04 -0000
Received: from AUKGHB01.Corporate.KAZ-Group.priv (aukghb01.corporate.kaz-group.priv) by mail02.kaz-group.com (Clearswift SMTPRS 5.2.5) with ESMTP id <T8edfabd6d8ac10f02ae24@mail02.kaz-group.com>; Fri, 12 Jun 2009 06:58:56 +1000
Date: Fri, 12 Jun 2009 06:59:41 +1000
MIME-Version: 1.0
To: Christian.Groves@nteczone.com
From: Nik Waldron <nik.waldron@kaz-group.com>
X-Mailer: Microsoft Outlook v 11.00.8217, MSOC v 2.00.4007.00
Message-ID: <OF451B10D3.692C043A-ON4A2575D2.00715DE0@kaz-group.com>
X-MIMETrack: Serialize by Router on AUKGHB01/KAZGROUP/AU(Release 6.5.2|June 01, 2004) at 06/12/2009 06:59:02 AM, Serialize complete at 06/12/2009 06:59:02 AM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Cc: speechsc@ietf.org
Subject: Re: [Speechsc] Question on Verification Result Device type
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Speech Services Control Working Group <speechsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/speechsc>, <mailto:speechsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/speechsc>
List-Post: <mailto:speechsc@ietf.org>
List-Help: <mailto:speechsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/speechsc>, <mailto:speechsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2009 20:58:58 -0000

Hi Christian,

I'm not an expert on MRCPv2 but as someone working on Verification
implementation and having some familiarity with the field I think that
this is due to the time at which MRCPv2 was originally drafted.  At that
time (a part of) the state of the art was an idea known as handset
normalisation or HNorm.  HNorm set about solving the problem that
different handsets had very different log likelihood ratio scores.  There
were several variants on the solution, but basically several scores for
different utterances against the same voiceprint, or scores for the same
utterance against the different voice prints (or a combination) were used
to normalise the score.

In particular the microphone type (carbon button, or electret) were major
categories for distorting scores, and compensating for the microphone type
found to be effective.  I guess that in order for the system to operate in
an online way (updating the sets used for normalisation), it might be
necessary for the results to be categorised by microphone type (if known).
Others more familiar with the motivations for these fields may wish to
correct me.

Things have moved on a bit since then, however if you do a search (HNorm,
TNorm or CNorm) you should be able to find the relevant papers.  If the
engine you are interested in does not support / use these types of
normalisation or identify the categories then I'm sure 'unknown' will
satisfy the specification.

Best regards,




NIK WALDRON



This is an email from Fujitsu Australia Limited, ABN 19 001 011 427. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you.
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________