Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Loud clicks/transients in SILK mode for music input when inbandfec and loss >= 21%

Open
  • Is something wrong?
#505 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
c
Domain
audio-video-rtc

Research direction

The issue is in the SILK encoder when in-band FEC is enabled with loss >=21%. Start by examining the SILK encoder source files, likely in silk/ directory, focusing on FEC and loss handling. Look for thresholds around 20-21% loss. Reproduce using the provided opus_demo commands with the test file to confirm the clicks. Check the encoder's packet loss simulation and FEC generation logic. Verify the fix by encoding/decoding and comparing spectrograms for clean output.

Written by the indexing model from the issue text.

Description

Version: libopus 1.6.1-70-g91012c65, float build, DRED / deep-PLC / OSCE disabled. Built on MacOS/aarch64 using default build settings.

Summary

Encoding music with in-band FEC enabled produces loud, click-like artifacts in the primary frames when the declared packet loss percentage is 21% or higher, but not at 20%. No packets are actually lost — encode and decode are run back to back, and the range coder states match. This was discovered when encoding music with inbandfec enabled and the loss-parameter set to 21% or more. Later it was discovered that the problem occurs in the SILK part of the coding.

The problem was initially discovered when encoding music in a typical realtime audio communication setting.

Reproduces at both -complexity 1 and -complexity 9
Reproduces at 64 kb/s and 128 kb/s
restricted-silk with -bandwidth WB, so hybrid mode, mode switching, and redundancy are excluded
Disappears entirely without -inbandfec
Threshold is sharp: 20% clean, 21% affected

The compared spectrogram shows wideband "bursts" from around 6s to 12s that are quite audible in the top plot (output from decoder) that are not present in the original input (bottom).

Image

./builddir/src/opus_demo -e voip 48000 1 64000 -complexity 9 -inbandfec -loss 30 valkyrie_s16.raw tmp.opus
./builddir/src/opus_demo -d 48000 1 tmp.opus valkyrie_s16_silk_30pcloss_2gen.raw

How to reproduce:
./builddir/src/opus_demo -e restricted-silk 48000 1 64000 -complexity 9 -inbandfec -loss 21 valkyrie_s16.raw tmp.opus
./builddir/src/opus_demo -d 48000 1 tmp.opus valkyrie_s16_silk_21pcloss_2gen.raw

Counter-example where the problem is not observed:
../builddir/src/opus_demo -e restricted-silk 48000 1 64000 -complexity 9 -inbandfec -loss 20 valkyrie_s16.raw tmp.opus
./builddir/src/opus_demo -d 48000 1 tmp.opus valkyrie_s16_silk_20pcloss_2gen.raw

Dominant language
C
Stars
3.4k
Forks
820
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from xiph/opus

All issues in xiph/opus

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.