<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Hi,</div>
<div><br>
</div>
<div>Apologies if this is a known issues, but I have found what I believe is a bug in the fixed point implementation of the Silk codec and could not find any mention on this in the archives.</div>
<div><br>
</div>
<div>The bug can be easily reproduced with the fixed point demo program (./configure —enable-fixed-point —disable-float-api && make) using the following command:</div>
<div><br>
</div>
<div>./opus_demo voip 16000 1 23000 sweep_in.raw sweep_out.raw</div>
<div><br>
</div>
<div>Where sweep_in.raw is a 30 seconds full scale frequency sweep from 0 to 8kHz sampled at 16kHz.</div>
<div><br>
</div>
<div>The first 6 seconds of audio after transcoding sound Ok. After that artefacts are introduced all the way to the end of the file.</div>
<div>The floating point version does not have the issue (even though the quality is subjectively worse roughly from the same point).</div>
<div><br>
</div>
<div>I believe I narrowed down the problem to the file burg_modified_FIX.c – if I make sure the input signal is scaled down to 14 bits before processing the coefficients of the predictor are calculated correctly and no artefact is introduced.</div>
<div><br>
</div>
<div>Is anyone experiencing the same problem or has a proper fix for this? (I can work around the bug with input scaling for now).</div>
<div><br>
</div>
<div>Thanks and best regards,</div>
<div><br>
</div>
<div>Marcello Caramma</div>
</body>
</html>