<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Hi Jean-Marc,</p>
<p>Thank you for the valuable feedback. You're correct in that we focused on enabling this just for SILK. Because our solutions are focused on voice, we did not explore doing the same in CELT mode, but we can certainly look into the details of analysis.c.</p>
<p><br>
</p>
<p>Regarding the concern of exposing internals, do you have a specific proposal in mind?</p>
<p><br>
</p>
<p>We've been sharing this patch with our customers over the last several months, and the preference obviously would be to have it in the public domain. We're interested in any opportunity to accelerate this.</p>
<p><br>
</p>
<div id="x_Signature">
<div style="font-family:Tahoma; font-size:13px">
<div style="font-family:Tahoma; font-size:13px">
<div style="font-family:Tahoma; font-size:13px">
<div style="font-family:Tahoma">
<div style="font-family:Tahoma">
<div style="font-family:Tahoma">
<div style="font-family:Tahoma">
<div style="font-family:Tahoma">
<div style="font-family:Tahoma">
<div style="font-family:Tahoma">
<div style="font-family:Tahoma">
<div style="font-family:Tahoma">
<div style="font-family:Tahoma">
<div style="font-family:Tahoma">
<div style="font-family:Tahoma">
<div style="font-family:Tahoma">Thanks,
<div style="font-size:13px">Peter</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Jean-Marc Valin <jmvalin@mozilla.com><br>
<b>Sent:</b> Wednesday, June 7, 2017 2:46:52 AM<br>
<b>To:</b> Freshman, Peter; opus@xiph.org<br>
<b>Subject:</b> [EXTERNAL] Re: [opus] Submitting a patch that exposes VAD voiced/unvoiced signal type</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hi Peter,<br>
<br>
There's two main issues with a patch like the one you're proposing.<br>
First, the data is only valid when SILK is being used and is essentially<br>
undefined in CELT mode. The second issue is that by exposing internals,<br>
it makes it impossible to improve these algorithms since it would break<br>
API compatibility. I'm not fundamentally against trying to expose some<br>
information, but there would have to be a way to address those two issues.<br>
<br>
On a slightly different topic, have you looked at the VAD probability<br>
that's computed in analysis.c (along with the speech/music probability)?<br>
<br>
Cheers,<br>
<br>
Jean-Marc<br>
<br>
<br>
> I'm reaching out because we'd like to contribute back to the project<br>
> a patch that exposes the signal type of the audio packet when<br>
> encoding the PCM audio to OPUS. We've found the Opus VAD algorithm to<br>
> be exceptional in this regard and have written a library that<br>
> leverages this information for audio end-pointing. Attached is the<br>
> patch. Please let us know if you'd be willing to accept it, or if<br>
> you'd prefer we fork libopus or recommend some other option.<br>
<br>
<br>
<br>
</div>
</span></font>
</body>
</html>