Does the dpdfnet model have any obvious drawbacks?

[openff]

I tested Deepfilternet-v2 and found that in a strong noise environment, it had a significant problem of mistakenly cutting off human voices. Is there any already exposed weakness or deficiency in DPDFNet?

[openff]

Sorry, I was wrong. It was Deepfilternet-v3 that caused this error, not Deepfilternet-v2.

[danielr-ceva]

@openff, thanks for your interest in the DPDFNet project!

I’m aware of the over-attenuation issue in DFN3, and overall I’d say that DPDFNet models are generally more robust. However, it’s hard to comment definitively without knowing what kinds of noise you tested or how low the SNR was in your case.

The best way to check would be to take an example where DFN3 struggles and try it with DPDFNet, either through our PyPI package, the GitHub project, or the Hugging Face live demo.

If you discover anything interesting, I’d love to hear about it. That kind of feedback could help us improve DPDFNet even further.

[jacksongoode]

I wanted to make an issue here but it feels better to discuss it here, I believe the "low latency" DF2/DF3 model has a lookahead of 0 (with 2 samples as prev buffer) while the full band DPDF model has 2 and 2 which I believe in streaming situations cause some phasing between the dry/wet attenuation.

https://github.com/Rikorose/DeepFilterNet/blob/d375b2d8309e0935d165700c91da9de862a99c31/ladspa/README.md?plain=1#L3

Wondering if this is a structural decision with DPDF?

[danielr-ceva]

The current DPDFNet checkpoints are not zero-lookahead. They use df_lookahead=2 and conv_lookahead=2, which results in an overall latency of about 40 ms.

On its own, this does not introduce phasing in our attenuation-limit path, since we already align the noisy reference before blending. The only case where phasing would occur is in an external dry/wet mix where the dry path is not delay-compensated relative to the enhanced signal.

So this behavior is not inherent to the DPDFNet architecture, but rather a latency versus quality tradeoff in the current checkpoints. A zero-lookahead variant of DPDFNet is possible, but it would involve different quality tradeoffs.

This is also why the “low-latency” DFN2/3 variants were further tuned. Because they operate with reduced lookahead, they require significantly more parameters compared to the regular models in order to recover some of the lost quality.

[jacksongoode]

I see, it would be very interesting as a point of comparison to have a zero lookahead variant, but I suppose the model would need to be rearchitected/reexported? I remember that the DF2/DF3 had the individual encoder, decoders as sub models Rikorose/DeepFilterNet#628 would a similar approach be needed here?

[openff]

Hi, I am evaluating DPDFNet on a device with a very powerful and clear loudspeaker output.

When two devices are placed very close to each other, occasional acoustic feedback can be observed in single-talk scenarios, including echo and harsh howling / squealing. The howling tends to decay over time, but it still appears intermittently.

In some cases, the combination of echo and feedback also causes speech suppression or missing words.

Do you have any recommended approach to completely remove this echo / acoustic feedback issue?

[openff]

Can this echo-induced speech suppression / dropped-word issue be mitigated by retraining or fine-tuning DPDFNet?

Or is the better approach to use a dedicated acoustic echo cancellation (AEC) solution first, and then apply DPDFNet for noise suppression afterward?

[danielr-ceva]

@openff
What you’re seeing is an acoustic echo/feedback issue, which DPDFNet is not designed to handle.

DPDFNet focuses on background noise suppression, not echo cancellation. It won’t reliably remove echo or prevent feedback (e.g., howling/squealing), especially in close, high-gain setups.

The recommended approach is to use a dedicated AEC solution first, then optionally apply DPDFNet for residual noise suppression.

[he-jinlai]

@danielr-ceva What training data is currently used for the model? DNS3? If echo and howling data are included, can such noises be removed?

[danielr-ceva]

@he-jinlai

16 kHz models:

• DNS3 dataset
• Facebook MLS (English only)

48 kHz models:

• DNS4 dataset

That said, the choice of dataset itself doesn’t determine how robust the models are to echo or howling. Those issues fall under AEC, which should be handled as a separate component in the processing pipeline.

@openff
The very loud speech you’re observing is likely caused by the AGC I added in the realtime demo. Could you try disabling it (there’s a toggle button in the GUI) and see if that improves the behavior?

[sakshibansalsb]

Hi, I’m using the provided 16 kHz DPDFNet model with telephony audio (8 kHz). After resampling to 16 kHz, I’m noticing that parts of the speech still get suppressed.

Is this expected when using narrowband audio? Do you have (or plan) a version specifically trained for 8 kHz input?

Thanks!

[danielr-ceva]

Hi @sakshibansalsb,

Yes, this can be expected. Our 16 kHz models were trained mostly on true 16 kHz audio, with only limited exposure to lower-sample-rate data. The same general principle applies to the 48 kHz model family as well.

So, for optimal performance, the 16 kHz models should be used with real 16 kHz audio, and the 48 kHz models with real 48 kHz audio. If 8 kHz telephony audio is resampled to 16 kHz, the models perform suboptimally.

It’s useful to know that there is interest in 8 kHz telephony support. Based on this, I’ll start working on dedicated 8 kHz variants.

Thanks again for your interest in the project.