I have. ;-)Have you observed what happens at say 0.5db 1.5db 3db 6db 9db overload?
The comportement in level etc ;-)
I have. ;-)Have you observed what happens at say 0.5db 1.5db 3db 6db 9db overload?
The comportement in level etc ;-)
Sorry...@canard I can't really follow what you are saying but it would be great if Wiim implemented a True Peak meter so that any problems with clipping (whatever the reason) can be seen and also the headroom indication like REW can display whilst changing PEQ parameters would be great, then we can see the impact of what our filters do level wise and adjust the (digital) gain accordingly.
Totally agree and all Wiim devices that don't have a screen, make it visible in the Wiim app maybe just clip indicators indeed. But again the headroom indication/calculation like REW is most welcome I think when a user is adjusting EQ's Roomfit, pre-gain or whatever.useful... becomes necessary in the case of possible modifications offered by the Wiim
processing corrections in rew requires some skills and the temp etc...Totally agree and all Wiim devices that don't have a screen, make it visible in the Wiim app maybe just clip indicators indeed. But again the headroom indication/calculation like REW is most welcome I think when a user is adjusting EQ's Roomfit, pre-gain or whatever.
Not sure if I understood correctly what you meant, but note that the overload indication could also be implemented to sense the level just before the signal hits the output limiter, or alternatively it could detect the amount of attenuation the limiter introduced.but also if the idea is to observe in a relevant manner in output num, captured on "can" etc for example, it is necessary to ensure that the "limiter" is not engaged....which is not the case currently it seems....
That's what I've thought since the beginning, and the last VU meter discussion on the Ultra is moving towards this position... (and I insist so much on an overload feedback)Not sure if I understood correctly what you meant, but note that the overload indication could also be implemented to sense the level just before the signal hits the output limiter, or alternatively it could detect the amount of attenuation the limiter introduced.
So it is not strictly necessary to disable the limiter to have usable and actionable overload indication.
E.g. if you added +3dB boost to a 0dBFS peak signal, the overload indication could tell you that the level is +3dB in overload, and then still have the limiter dynamically turn the level down to avoid hard clipping.
As mentioned, another way to achieve the same would be if the WiiM Home App simply reported by how much the built-in output limiter attenuated the signal peaks. So if the signal level was reduced by 3dB by the limiter WHA could report something like "Overload detected! Attenuation: 3 dB"
I'll sometimes do the equivalent in my DAW when processing audio tracks: having peak metering before a limiter on the master bus allows me to adjust the various levels to avoid output overload; but should some peak still manage to somehow hit >0dBFS (for any reason) the limiter will catch it as a kind of last resort line of defense. That way I avoid hard clipping under any condition.
Note that in this case the pre-limiter peak meter will record the same overload peak level that the limiter detected as attenuation.
Not sure what you mean here. It was stated this morning that the VU meter is upstream of the limiter.That's why "as is" and being forced to observe downstream of the limiter, I say it's clumsy, not in its function, but because it prevents us from making accurate observations for the moment.
Not sure what you mean here. It was stated this morning that the VU meter is upstream of the limiter
I guess I simply don't agree with this assessment.That's why "as is" and being forced to observe downstream of the limiter, I say it's clumsy, not in its function, but because it prevents us from making accurate observations for the moment...
Have a look at this post (and also this one). The functionality is not documented well, unfortunately.Were does this limiter come from? I think i read the whole thread but i must have missed the part where it was mentioned that the Wiim had a built-in limiter?
On test signals, yes... on music, it's more delicate...I guess I simply don't agree with this assessment.
Both limiting and clipping should be quite easy to detect with measurements at the analog output (i.e. downstream from the WiiM device).
The main difference is that hard clipping will add significantly more distortion to the signal, so it might be more audible in acute cases. Occasional low-level clipping can also be difficult to hear, unless you know exactly what to listen for.
But you are right that severe (e.g. +10dB overload) would be very easy to hear if the output clips, while it might not be as easy to hear if the limiter is active. Still, I'm not really convinced that makes clipping desirable - people who might overload the output so severely might not know anyway what they did wrong or how to fix it.
Have a look at this post (and also this one). The functionality is not documented well, unfortunately.
Of course I fully I agree with this. Any functionality that is implemented should be adequately documented.That Wiim already really explains the presence, its position, and its impact... will already help everyone much better understand the precautions to take to avoid engaging it "at every turn"...
It does not make you look bad - we're all free to have and share our opinions and reasoning.Well, I'm not really concerned... I'll let it go... (and also makes me look like an idiot )
I guess it depends, some signals definitely make it easier to detect one vs the other.On test signals, yes... on music, it's more delicate...
( But using a few streamed test signals could be very useful for many on these topics... easy...i use often here)
in fact it is very simple to observe in a few clicks ( "can" with num input, rew ,mt virtins etc) on the num output for example....and the situation behavior is very very "simple" in the endBut it is absolutely true that as a first step it is important to know the expected behavior - and improving documentation would be a great way to start. Overload or attenuation level indication in WHA would be another way to improve.