Does using EQ degrade sound quality in Wiim Pro?

[canard]

What do this drc with:

C

Thread 'Important subject...about dac level etc etc'

Sep 20, 2025

A look at the music library: How much DAC intersample overhead is enough? True Peak analysis of genres in an eclectic digital collection.

A blog for audiophiles about more objective topics. Measurements of audio gear. Reasonable, realistic, no snakeoil assessment of sound, and equipment.

archimago.blogspot.com

• canard
• Replies: 4
• Forum: Forum Feedback & Suggestions

• 

The difficulty here is that not even having "control" over this drc...we cannot observe "with and without"....its presence or could even be an option proposed by wiim...

it's not really explicit on wiim's part and we are not given a choice
;-)

 

[dominikz]

It has the merit of existing... but to judge it "But I agree, that this is the most sensible implementation."... no, it's just a discreet workaround for the lack of known autogain solutions on peq etc... but the discussion on ISP saturations etc. omnipresent in the most popular music questions its impact on operation in these situations... a real subject of study in this specific case....
who can perhaps be much more present than many suppose.


;-)

Well I for one don't fully agree, as already discussed before.

"Autogain" has merit in some cases (especially when using fixed volume output) - this I agree with.
But in other cases it would actually be a nuisance (e.g. A/B testing of EQ profiles would be difficult with autogain since it would cause different EQ profiles to have different relative levels).

Likewise, DRC/limiting is beneficial as it is audibly less-offending than digital clipping - think of it as a last-resort safe-guard.

Current implementation of all this in WiiM devices is perhaps less-than-ideal, but it is also far from bad.
You can still completely avoid running into overload by using per-input pre-gain, volume, or volume limit.
On the other hand, if you do happen to run into overload it will be audibly much more subtle due to DRC/limiting.

Lastly, note that overload won't happen at all unless you run volume close to 100% plus have boosts configured.
E.g. in my WiiMs I rarely need to set volume over 50%, which means that anything less than +16dB of boost wouldn't cause ANY overload!

 

[Nanook]

no, it's just a discreet workaround for the lack of known autogain solutions on peq etc... but the discussion on ISP saturations etc. omnipresent in the

My statement did not refer to EQ. For EQ a Pre-gain like APO-EQ does (i will use Volume-limit for this purpose) is the way to go.

I was talking about the Volume-limit, which looks like a global Pre-gain to me. It's surely more versatile and less confusing than a real blocking of higher volume settings would be.
And I for one will use it to provide some headroom for my boost-EQs.

 

[canard]

Well I for one don't fully agree, as already discussed before.

"Autogain" has merit in some cases (especially when using fixed volume output) - this I agree with.
But in other cases it would actually be a nuisance (e.g. A/B testing of EQ profiles would be difficult with autogain since it would cause different EQ profiles to have different relative levels).

Likewise, DRC/limiting is beneficial as it is audibly less-offending than digital clipping - think of it as a last-resort safe-guard.

Current implementation of all this in WiiM devices is perhaps less-than-ideal, but it is also far from bad.
You can still completely avoid running into overload by using per-input pre-gain, volume, or volume limit.
On the other hand, if you do happen to run into overload it will be audibly much more subtle due to DRC/limiting.

Lastly, note that overload won't happen at all unless you run volume close to 100% plus have boosts configured.
E.g. in my WiiMs I rarely need to set volume over 50%, which means that anything less than +16dB of boost wouldn't cause ANY overload!

I also don't care about my listening habits, or the fact that I don't use PEQ, or the simple fact that I'm at 94%...

but you, like me, don't represent the majority of practices (especially you and your 50%)...
We just need to clarify the subject so that everyone can make an informed choice based on their usage....


But it gets enormously complicated when we try to understand the behavior of this DRC in the event of ISO...! Much more present than we want to admit...
It really raises questions.... like the fact that we can consciously engage it or not...according to our needs...
;-)

 

[canard]

This is during tests etc etc but in the final use which I hope is not only that?... ;-)
"But in other cases it would actually be a nuisance (e.g. A/B testing of EQ profiles would be difficult with autogain since it would cause different EQ profiles to have different relative levels)"

 

[dominikz]

I also don't care about my listening habits, or the fact that I don't use PEQ, or the simple fact that I'm at 94%...

but you, like me, don't represent the majority of practices (especially you and your 50%)...
We just need to clarify the subject so that everyone can make an informed choice based on their usage....


But it gets enormously complicated when we try to understand the behavior of this DRC in the event of ISO...! Much more present than we want to admit...
It really raises questions.... like the fact that we can consciously engage it or not...according to our needs...
;-)

We'll I wasn't saying that the way I use my device is representative for most - it was meant as just an example to illustrate one use case where autogain really isn't required at all. No one can say how the 'average' user uses their WiiM device.

Which was kind of my point - I'm not convinced that autogain is really such a big omission as you seem to argue it to be.

Don't take this the wrong way, if WiiM implemented autogain as a bypassable option that would be great! I just don't see it as something crucial, given that there already are ways to avoid overload. As such I see autogain as a potential convenience, not a necessity.

 

[dominikz]

This is during tests etc etc but in the final use which I hope is not only that?... ;-)
"But in other cases it would actually be a nuisance (e.g. A/B testing of EQ profiles would be difficult with autogain since it would cause different EQ profiles to have different relative levels)"

Sorry, but why does this matter?
Weren't you the one who said just a couple of posts ago that we shouldn't be making value judgements on how people use their gear?

It was just one example, and it is relevant to me.

 

[canard]

Sorry, but why does this matter?
Weren't you the one who said just a couple of posts ago that we shouldn't be making value judgements on how people use their gear?

It was just one example, and it is relevant to me.

I respect it...but its highlighting, by you, who are very respected here, cannot overshadow the fact that it is a somewhat special case.... ;-)
I don't think this, the absence of auto-gain and the presence of DRC, is serious... especially since all of this is fundamentally... not serious...

just that sweeping it under the rug bothers me... but let's talk about the Ultra's screen!!! Vumetre etc ;-))))

(The testing phase, etc., is just, I hope for everyone, a temporary phase and not a finality... ;-) )


The impact of DRC in the case of ISO is, however, an interesting topic... and the possibility of removing it from the code if desired is a fairly obvious logic...
;-)


These machines are first and foremost audio machines...and the absence of serious Wiim interlocutors on these subjects is for me, over the years and here on their own forum, heavy....
and I salute the selflessness of people like you who devote so much time to explaining, supporting, and debugging development...with a real level of expertise...

 

[dominikz]

I don't think this, the absence of auto-gain and the presence of DRC, is serious... especially since all of this is fundamentally... not serious...

just that sweeping it under the rug bothers me... but let's talk about the Ultra's screen!!! Vumetre etc ;-))))

Well for some people the screen and the VU meter is obviously important. I'm not one of those people, and based on your comment I suspect neither are you. But we're just a couple of users, and our priorities aren't necessarily relevant.

(The testing phase, etc., is just, I hope for everyone, a temporary phase and not a finality... ;-) )

Again, this doesn't really matter. It could equally be argued that setting EQ and Volume Limit to avoid overload is only done occasionally, so it shouldn't matter if you have to learn how to do it manually (i.e. without relying on autogain).
You may put more importance on autogain and I may put more importance on feasibility on A/B testing EQ profiles at equal loudness. Both are reasonable use-cases so equally valid.

Ideally the implementation should have options that cater to different users, without being very difficult to navigate and understand. I believe such an implementation is indeed possible, but it would require WiiM to step-up their game when it comes to UI/UX and to take a more holistic system design approach. While I very much appreciate WiiM's responsiveness to user requests and feedback, I'm pretty sure this approach won't result in optimal design.

The impact of DRC in the case of ISO is, however, an interesting topic... and the possibility of removing it from the code if desired is a fairly obvious logic...
;-)

Abbreviations:
DRC: Dynamic Range Compression
ISO: Inter-Sample Overload

You mention ISO, do you expect autogain to cater for that as well? If so, how would you propose this to be done, given that ISO is track-dependent?

Also, why would you assume ISO to trigger DRC differently to any other overload, can you explain please?

And lastly, why would you want to disable DRC at all? Without DRC any overload would trigger hard clipping which is easily audible (unlike DRC/limiting). What downsides to current implementation of DRC do you see?

 

[canard]

Well for some people the screen and the VU meter is obviously important. I'm not one of those people, and based on your comment I suspect neither are you. But we're just a couple of users, and our priorities aren't necessarily relevant.


Again, this doesn't really matter. It could equally be argued that setting EQ and Volume Limit to avoid overload is only done occasionally, so it shouldn't matter if you have to learn how to do it manually (i.e. without relying on autogain).
You may put more importance on autogain and I may put more importance on feasibility on A/B testing EQ profiles at equal loudness. Both are reasonable use-cases so equally valid.

Ideally the implementation should have options that cater to different users, without being very difficult to navigate and understand. I believe such an implementation is indeed possible, but it would require WiiM to step-up their game when it comes to UI/UX and to take a more holistic system design approach. While I very much appreciate WiiM's responsiveness to user requests and feedback, I'm pretty sure this approach won't result in optimal design.


Abbreviations:
DRC: Dynamic Range Compression
ISO: Inter-Sample Overload

You mention ISO, do you expect autogain to cater for that as well? If so, how would you propose this to be done, given that ISO is track-dependent?

Also, why would you assume ISO to trigger DRC differently to any other overload, can you explain please?

And lastly, why would you want to disable DRC at all? Without DRC any overload would trigger hard clipping which is easily audible (unlike DRC/limiting). What downsides to current implementation of DRC do you see?

It's just a matter of available choices... or not, autogain, DRC... autogain no..drc all the time... ;-)


And regarding the behavior of DRC in the case of ISOs, which are ultimately very present... I'm wondering about its behavior... and would be curious to see how it interferes... whether subjectively or in measurement...
it's interesting, and precisely because we can't remove DRC, we won't be able to sort things out...
;-)

 

[slartibartfast]

I respect it...but its highlighting, by you, who are very respected here, cannot overshadow the fact that it is a somewhat special case.... ;-)
I don't think this, the absence of auto-gain and the presence of DRC, is serious... especially since all of this is fundamentally... not serious...

just that sweeping it under the rug bothers me... but let's talk about the Ultra's screen!!! Vumetre etc ;-))))

(The testing phase, etc., is just, I hope for everyone, a temporary phase and not a finality... ;-) )


The impact of DRC in the case of ISO is, however, an interesting topic... and the possibility of removing it from the code if desired is a fairly obvious logic...
;-)


These machines are first and foremost audio machines...and the absence of serious Wiim interlocutors on these subjects is for me, over the years and here on their own forum, heavy....
and I salute the selflessness of people like you who devote so much time to explaining, supporting, and debugging development...with a real level of expertise...

Do you actually own any WiiM devices or are just a concerned onlooker

 

[canard]

Do you actually own any WiiM devices or are just a concerned onlooker

Hehe

I own Wiimproducts ( mini -pro plus)... the forum didn't even exist yet... 02/22 my firts mini...

(and from the first days of EQ mode's ,and presets existence, I had informed the team directly at the time of the obvious and factual risk of saturation without... autogain mode, 05-06/22, very old subject ;-) )
(I happened to slip a few measurements here..it would have been difficult for me without having owned any Wiim products ;-) )

 

[slartibartfast]

Hehe

I own Wiimproducts ( mini -pro plus)... the forum didn't even exist yet... 02/22 my firts mini...

(and from the first days of EQ mode's ,and presets existence, I had informed the team directly at the time of the obvious and factual risk of saturation without... autogain mode, 05-06/22, very old subject ;-) )

I think we were all surprised when WiiM announced they were using DRC to prevent clipping. I just set the volume limit for my worst case RoomFit.

 

[canard]

(regarding the screen of the vu meter...it's just that we can t perhaps consider it as a priority in terms of resources...which concerns ---All---Wiim products...and not just the screen of the simple ultra)

 

[canard]

I think we were all surprised when WiiM announced they were using DRC to prevent clipping. I just set the volume limit for my worst case RoomFit.

I don't think Wiim really announced the presence of DRC.... it was pointed out by others, then discreetly acknowledged... ;-)

a workaround....not new at wiim because it was used from 2022 then removed..to come back...*
;-)


For me, and this is personal, if it had been so assumed, we would have had an option available "with or without"... with a little explanation... quite simply ;-)

(I don't want to come back to it....but the story of the drc and wiim facing the overload eq peq etc is not new... what can be misunderstood in my instance's words is that it's an old subject for me who has been wiim since almost its beginnings... ;-) )

(*without pride...I'm even the person who observed it , drc, and made it known (asr) first, following a clumsiness of wiim who had engaged one at -1db on the eq modes but just forgot to remove it on the "direct" mode ......10/22)

 

[dominikz]

and I salute the selflessness of people like you who devote so much time to explaining, supporting, and debugging development...with a real level of expertise...

That is kind of you to say!

It's just a matter of available choices... or not, autogain, DRC... autogain no..drc all the time... ;-)

As mentioned already, I personally support having choices. Though I also understand that some people might find too much choice paralyzing...

The option to enable/disable the limiter could be added to the "Audio Output" screen - that would be the easy part.

Regarding autogain, note here that it is not only EQ and RoomFit which can cause output overload, but there's also the Pre-Gain control in the "Audio Input" screen. So to avoid any chance of overload it's needed to ensure that a combination of per-input pre-gain, EQ boost, and RoomFit boost never runs the signal into 0dBFS (but also taking into account Volume Limit).

This makes things a little bit more complicated, since no single control can universally take all of this into account - given that all WiiM devices have multiple inputs and outputs which can be used in various combinations (I'll call these 'pipelines'), causing differences in internal gain-staging.
As such, the "autogain" function could be implemented in several different ways:

• Independent autogain for EQ and RoomFit screens, with values linked to the specific EQ/RoomFit profile.
  • This is the most intuitive option, but may result in wasted headroom since total boost of EQ+RoomFit could be less than the sum of their individual boosts (i.e. one of them could cut where the other boosts).
• One common autogain that is based on combined EQ and RoomFit total boost level. This would probably belong to the "Audio Output" menu.
  • This better optimizes total headroom, but is not very intuitive to manage.
• One common autogain that takes into account all level-affecting controls in the current signal processing pipeline (pre-gain, EQ, RoomFit, volume, volume limit). This would probably belong to the "Audio Output" menu.
  • This is best from overall headroom optimization perspective, but unfortunately the least intuitive to manage.

IMHO each of the above options have their benefits and I suspect different users might have different preferences between them.

In case autogain is implemented, there should IMHO also be some kind of overview screen that makes it easier for the user to understand the entire signal processing pipeline. Given that there are several features which influence signal level, and the frequency-dependent nature of some of them (EQ and RoomFit) it should be clear that this is not a trivial task - but it is of course doable.

As you suggested, inter-sample peaks (ISP) can also cause overload when volume is at (or close to) 100%, but ISP is track-dependent so difficult to address universally. The recent article by Archimago you linked to suggests that about 2-3dB of headroom would be more than enough to handle inter-sample peaks of 99% of tracks in most music genres.
Worst example track he found had inter-sample peaks reaching +7,75dB. Of course we should note that any music with such high inter-sample peaks simply isn't well produced anyway, meaning that just compensating for inter-sample peaks won't be enough to make such tracks sound good.
This also suggests that the audible impact of inter-sample peaks (ISP) may be overstated in practice - tracks that are considered "audiophile quality" will usually have very low (or no) ISP, while high ISP is a result of tracks being severely dynamically squashed.
A quote from the same Archimago article (underlines are mine):

My recommendation of +3dB discussed a few years back for DAC intersample overhead I think remains fair. This will easily cover the vast majority of music out there (including 96% of my Electronica tracks). However, if you're very much into electronica/techno/EDM, maybe a DAC with +4.25dB headroom would given you a bit more assurance - or simply attenuate your DAC digital volume by a few dBs, or even better, use ReplayGain with something like -18 LUFS target.

While these >0dBFS calculated intersample peaks might exist in 'good' sounding recordings, I see them mainly as a reflection of loud productions that are the victims of the Loudness War. So while I think it's useful to consider whether our CD players and DACs can handle them, to me it's actually not that important. When possible, the prudent audiophile is simply advised to look for recordings that are not so "hot", that are more dynamic, and in turn more "natural" sounding (more like classical music production quality).

Personally I fully agree with Archimago's conclusion here. Note that by keeping volume less than about 95% we're sure to avoid ISP-related overload completely in the vast majority of cases.
If I ever find the time I might try to measure ISP overload handling in WiiM Mini - but I can't promise it.

That being said, in general I'd also like to see output signal overload indication somewhere in the WiiM Home app, or even on the WiiM devices themselves (using LEDs or on the screen where available). This would make it easier to determine if the combination of settings in use (per-input pre-gain, EQ, RoomFit) and content (ISO/ISP) results in overload, without any guesswork.

All this being said, I personally still don't find this crucial - so even if current implementation remains that would be OK with me.
As you can see, implementing this optimally while keeping it all easy to use may not be trivial at all. There's a lot of dependency to existing functionality, and UI/UX would IMHO be challenging as well. But it is doable, IMO!

 

[canard]

That is kind of you to say!

As mentioned already, I personally support having choices. Though I also understand that some people might find too much choice paralyzing...

The option to enable/disable the limiter could be added to the "Audio Output" screen - that would be the easy part.

Regarding autogain, note here that it is not only EQ and RoomFit which can cause output overload, but there's also the Pre-Gain control in the "Audio Input" screen. So to avoid any chance of overload it's needed to ensure that a combination of per-input pre-gain, EQ boost, and RoomFit boost never runs the signal into 0dBFS (but also taking into account Volume Limit).

This makes things a little bit more complicated, since no single control can universally take all of this into account - given that all WiiM devices have multiple inputs and outputs which can be used in various combinations (I'll call these 'pipelines'), causing differences in internal gain-staging.
As such, the "autogain" function could be implemented in several different ways:

• Independent autogain for EQ and RoomFit screens, with values linked to the specific EQ/RoomFit profile.
  • This is the most intuitive option, but may result in wasted headroom since total boost of EQ+RoomFit could be less than the sum of their individual boosts (i.e. one of them could cut where the other boosts).
• One common autogain that is based on combined EQ and RoomFit total boost level. This would probably belong to the "Audio Output" menu.
  • This better optimizes total headroom, but is not very intuitive to manage.
• One common autogain that takes into account all level-affecting controls in the current signal processing pipeline (pre-gain, EQ, RoomFit, volume, volume limit). This would probably belong to the "Audio Output" menu.
  • This is best from overall headroom optimization perspective, but unfortunately the least intuitive to manage.

IMHO each of the above options have their benefits and I suspect different users might have different preferences between them.

In case autogain is implemented, there should IMHO also be some kind of overview screen that makes it easier for the user to understand the entire signal processing pipeline. Given that there are several features which influence signal level, and the frequency-dependent nature of some of them (EQ and RoomFit) it should be clear that this is not a trivial task - but it is of course doable.

As you suggested, inter-sample peaks (ISP) can also cause overload when volume is at (or close to) 100%, but ISP is track-dependent so difficult to address universally. The recent article by Archimago you linked to suggests that about 2-3dB of headroom would be more than enough to handle inter-sample peaks of 99% of tracks in most music genres.
Worst example track he found had inter-sample peaks reaching +7,75dB. Of course we should note that any music with such high inter-sample peaks simply isn't well produced anyway, meaning that just compensating for inter-sample peaks won't be enough to make such tracks sound good.
This also suggests that the audible impact of inter-sample peaks (ISP) may be overstated in practice - tracks that are considered "audiophile quality" will usually have very low (or no) ISP, while high ISP is a result of tracks being severely dynamically squashed.
A quote from the same Archimago article (underlines are mine):

Personally I fully agree with Archimago's conclusion here. Note that by keeping volume less than about 95% we're sure to avoid ISP-related overload completely in the vast majority of cases.
If I ever find the time I might try to measure ISP overload handling in WiiM Mini - but I can't promise it.

That being said, in general I'd also like to see output signal overload indication somewhere in the WiiM Home app, or even on the WiiM devices themselves (using LEDs or on the screen where available). This would make it easier to determine if the combination of settings in use (per-input pre-gain, EQ, RoomFit) and content (ISO/ISP) results in overload, without any guesswork.

All this being said, I personally still don't find this crucial - so even if current implementation remains that would be OK with me.
As you can see, implementing this optimally while keeping it all easy to use may not be trivial at all. There's a lot of dependency to existing functionality, and UI/UX would IMHO be challenging as well. But it is doable, IMO!

This is why I often point out the idea of a return of "persistent overload" (see Peak True) on Wiim Home which would allow, by trial and error, to quietly, on a daily basis, correct levels even without a VU meter on all Wiim products...
;-)

 

[Nanook]

It has the merit of existing... but to judge it "But I agree, that this is the most sensible implementation."... no, it's just a discreet workaround for the lack of known autogain solutions on peq etc...

Can you elaborate what's wrong implementing this protection feature in this way?
For me the Vout setting must be meant as "protection", otherwise compressing higher output levels due to boost-EQ would not make sense at all.
Interesting if it covers the per-EQ Pre-gain settings as well as @dominikz pointed out - 10dB more voltage -> 10x more power.

APO - EQ calculates and recommends a Pre-gain considering all combined filters. It's up to you if you want to dial in the calculated or some other negative Pre-gain to avoid clipping. This is basically what the Volume-limit setting does on the WiiM - and this is how I'm going to use it because I also don't like the idea of compression.
My favorite implementation would be that the app calculates the needed Pre-gain for the EQ and allows the user to activate the calculated pre-gain (or some other value). It would be helpful if "Pre-gain on/off" and "EQ on/off" were both check-buttons such that I can compare EQ on/off without being fooled by a volume step. Both of these buttons in the EQ section of the app.
I would still appreciate to have a global "Pre-gain" that I can apply on top (lowering volume or headroom for Inter-Sample-Overs).

DRC probably has been chosen to simplify things for users who don't want to dig deeper into these technical topics. If it's about maximum undistorted volume, DRC is needed anyway.

The WiiM app offers a lot of settings and this can be confusing - especially, when some of them have a misleading name like Volume-Limit.
To help other users, we could set up a list with settings and a description what they really do.

 

[Nanook]

We should not forget that WiiM has an extraordinary difficult job. In the end these units are consumer products, the majority of the users will just use them, they will not want to dig into technical details, they will not spend time to lurk around in this forum - and this is perfectly fine.
On the other hand there are experienced and extremely knowledgeable people who spend time to optimize their setup, do measurements and try to figure out how the unit works in detail.

DRC is a lot nicer than hard clipping and a bunch of users will even like the "exausted" and upfront sound that limiting delivers.
So from my perspective the DRC is a reasonable approach. I would prefer Auto-gain (automatic Pre-gain according to the EQ currently dialed in) as a default to conserve as much as possible from the original recording. But I would like to have manual access to these features (Auto-gain on/off, EQ-Pre-gain [dB] , EQ-Pre-gain on/off).

As @dominikz pointed out, Auto-gain is a wide field that will confuse many users. This is why I would keep the Auto-gain / manual Pre-gain and the on/off buttons in the EQ section.
The global Pre-gain should remain in the general Audio settings.

What is definitely needed IMHO is a feedback from the app regarding the calculated overall headroom (be it positive or negative) for the presently chosen signal path. This must include everything (per-input Pre-gain, volume limit, EQ + EQ-Pre-gain), except volume.
When you adjust those settings, you would see at one glance if you will run into DRC and you are free to decide to spend another 2dB for ISOs.
(btw. I thought the AKM DACs have 2 or 3dB headroom internally).

Should we try to get a block diagram of the signal path from WiiM? This would help us a lot to explain the various features.

Last not least an indication of line input overload (hard clipping) is desperately needed. This could just be the LED on the WiiM flashing red, just like the overload LED on my Genelecs.