GTCRN: speech enhancement that fits in 48.2K parameters

A model sized for a CPU, and a repository that ships the weights

GTCRN is the official implementation of the ICASSP 2024 paper on a speech enhancement model requiring ultralow computational resources. The model itself is a Grouped Temporal Convolutional Recurrent Network, and the headline figures are 48.2K parameters and 33.0 MMACs per second.

Those two numbers define what the project is for. Speech enhancement models are usually large enough that running them on a live audio path needs a GPU or at least a server, and the paper's own claim is that the model surpasses RNNoise, a typical lightweight model with similar computational burden, while staying competitive against recent baselines with significantly higher resource requirements. So the goal was not the highest score on a benchmark, it was competitive quality at a size that fits on a CPU.

The repository ships the practical parts. Pre-trained models are provided in a checkpoints folder, and they were trained on the DNS3 and VCTK-DEMAND datasets respectively, so there are two weights sets to choose between depending on the noise conditions. The inference procedure is presented in infer.py, the model definition is in gtcrn.py, the training loss is in loss.py, and a test_wavs folder holds audio for trying things out.

The audience is a developer building a real-time voice path: a conferencing client, a dictation tool, a voice interface running on a thin client or in a container. The MIT licence and the presence of pre-trained weights make it easy to start.

The published complexity numbers were revised for the ERB module

The README carries a note that anyone reading the paper alongside the code will notice, and it is worth taking in full because it explains a discrepancy.

The complexity reported in the paper is 23.7K parameters and 39.6 MMACs per second. The repository updates these to 48.2K parameters and 33.0 MMACs per second. The stated reason is the inclusion of the ERB module. The ERB module's parameters are unlearnable, but counting them anyway raises the parameter total to 48.2K. Separately, replacing the invariant mapping from linear bands to ERB bands in the low-frequency dimension with simple concatenation rather than matrix multiplication is what brings the MACs per second down to 33 MMACs.

So the parameter count went up and the compute went down, and both changes are implementation decisions rather than modelling breakthroughs. A reader comparing the paper's table with the repository's own numbers should use the repository's figures, and should understand that the ERB band mapping is a fixed transform rather than learned weights, which is why it costs memory but not compute.

The second note in the same section is about streaming. The explicit feature rearrangement layer in the grouped RNN, implemented by feature shuffle, can produce a model that cannot be streamed, so the implementation discards it and achieves the same rearrangement implicitly through the following FC layer in the DPGRNN. That is a design decision made for the streaming use case rather than for the paper's numbers.

Two benchmark tables and what they actually compare

The README presents two results tables, and their structure tells you more than the numbers alone.

Table 1 is the VCTK-DEMAND test set, with columns for parameters in millions, MACs in gigaseconds per second, SISNR, PESQ and STOI. The noisy baseline scores 8.45 on SISNR, 1.97 on PESQ and 0.921 on STOI. GTCRN is listed at 0.05 million parameters, 0.03 MACs, 18.83 SISNR, 2.87 PESQ and 0.940 STOI, against RNNoise at 0.06 and 0.04 with 2.29 PESQ, PercepNet at 8.00 and 0.80 with 2.73, DeepFilterNet at 1.80 and 0.35 with 16.63 and 2.81, and S-DCCRN at 2.34 with 2.84 PESQ and 0.940 STOI.

Table 2 is the DNS3 blind test set, with DNSMOS-P.808, BAK, SIG and OVRL columns. GTCRN scores 3.44, 3.90, 3.00 and 2.70, while the noisy input scores 2.96, 2.65, 3.20 and 2.33, and RNNoise scores 3.15, 3.45, 3.00 and 2.53.

Two observations are worth making. First, several cells are blank, and DeepFilterNet is the only baseline with an STOI value above GTCRN's 0.940 in the first table, so the claim is competitive performance rather than dominance. Second, the SIG column in Table 2 is 3.00 for both GTCRN and the noisy input, which means the signal distortion metric did not move. Anyone relying on this model should read the tables rather than the summary line.

The streaming variant and its measured real-time factor

A streaming GTCRN is provided in a stream folder, and the README reports a real-time factor of 0.07 on a 12th Gen Intel Core i5-12400 CPU at 2.50 GHz.

A real-time factor of 0.07 means the model uses about seven percent of the time available for the audio it processes, so roughly fourteen times faster than real time on that processor. That is the number that makes the whole project interesting, because it means the enhancement can run inside a live pipeline on a CPU rather than on an accelerator. The streaming folder is a separate deliverable from the offline infer.py path, and the feature rearrangement change described earlier is what makes that possible.

The measurement is a single figure on a single processor, and the README does not give the audio format, the chunk size, or the number of threads, so it is a demonstration of feasibility rather than a portable performance guarantee. A machine an order of magnitude slower, or a live path that also has to run a vocoder or a network stack, has less headroom. The Streaming folder is where to look for the actual inference loop.

Related to this, the news entries record that on 2025-3-10 GTCRN became supported by sherpa-onnx, and on 2025-3-13 a quick inference web was built on Hugging Face Spaces, so the model is not confined to running inside this repository.

The dependency set is small and pinned to an older PyTorch

The requirements file is short, which is what you would expect from a repository whose stated goal is a small footprint.

einops==0.7.0
numpy==1.24.4
ptflops==0.7
soundfile==0.12.1
torch==1.11.0

The pins are exact, and the torch pin of 1.11.0 is the one that will cause friction. That release predates a long stretch of PyTorch changes, so a fresh environment built from this file will install an old torch and an old matching numpy, and on a current Python the install may not resolve at all. einops is there for the tensor rearrangements that the grouped architecture needs, soundfile handles audio input and output, and ptflops is the tool used to count the MACs and parameters that the README quotes.

So the environment is small but frozen in the past. A team that needs to run this inside a modern stack, or on a Python version newer than the one the pins were resolved against, will spend time on dependency resolution before any of the model code runs. The related repository SEtrain is described as a training code template for DNN-based speech enhancement, and TRT-SE as an example of converting a speech enhancement model into a streaming format and deploying it with ONNX or TensorRT, and those are the more likely homes for a modernised setup.

A LADSPA plugin puts it in a Linux audio path

The most recent news entry, dated 2026-1-18, records that a LADSPA plugin was added for filtering live audio on Linux using pipewire. The note is explicit that LADSPA support is experimental and is currently maintained by a community contributor rather than by the original author.

That distinction matters for anyone planning to rely on it. A LADSPA plugin is loaded by a host audio system and processes audio in real time, which is exactly the shape this model is suited to, and pipewire is the audio server on current Linux distributions, so the plugin is usable as a system wide filter rather than only inside a Python script. A ladspa directory at the top level of the repository holds the plugin code.

The arrangement also means the plugin inherits the plugin host's constraints. It runs in the audio thread, so any hitch affects the stream, and it inherits the pinned PyTorch environment of the rest of the repository. Treating it as a production filter in a conferencing or recording setup would be premature, and treating it as a way to hear the difference the model makes on your own machine, which is what a live filter is good for, is reasonable.

Other news entries point to related work: a lightweight hybrid dual-channel SE system for low SNR conditions released as H-GTCRN in May 2025, and an improved ultra-lightweight model named UL-UNAS proposed in March 2025.

Against a general purpose denoiser, and against training your own

The realistic comparison is not against other neural enhancers, because GTCRN was built to be one of the small ones. It is against the two other options: a conventional denoiser, or a model you train yourself.

A conventional spectral or adaptive filter needs no model weights, no PyTorch, and a fraction of a millisecond of compute, and it handles stationary noise well. What it cannot do is the non-stationary case, a fan, a keyboard, a second speaker, which is where a learned model earns its keep. GTCRN's case is that it reaches that quality at 33.0 MMACs per second, which a general purpose filter cannot reach because it is not a filter.

Training your own is the other option, and here the repository's own resources are the answer rather than a competitor. The pre-trained weights were trained on DNS3 and VCTK-DEMAND, so if your noise environment is in one of those datasets you can skip training. If it is not, the inference code and the loss definition are here, and SEtrain is described as a training code template for DNN-based speech enhancement, with TRT-SE showing how to convert such a model into a streaming format and deploy it with ONNX or TensorRT.

The practical point is that GTCRN occupies a specific middle position: small enough to ship, real enough to beat a filter, and accompanied by the tooling to retrain or convert it. It is not the smallest option, and it is not the highest scoring one.

Editorial conclusion

GTCRN fits a developer who needs speech enhancement inside a live audio path on a CPU, in a container, or on a device that cannot host a full neural enhancer, and it does not fit a project that needs a general purpose denoiser for arbitrary noise or a model adapted to a specific microphone. Before adopting it, run the included streaming version on your own hardware and check the real-time factor yourself, since the reported 0.07 RTF was measured on a 12th Gen Intel Core i5-12400 CPU, and listen to the audio examples in the demo repository, since the published numbers compare GTCRN only against the lightweight baselines it was designed to beat.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Xiaobin-Rong/gtcrn on GitHub