I’m not fundamentally agaist the idea of a setting here, but “bad to the point where they really should do something about it.” is really subjective.
As far as I’m concerned, any clipping deserves attention, and most DSP requires headroom in order to operate at its best. That idea is reflected in Roon. The thing you see when opening DSP Engine for the first time is educational text about Headroom Management and a single click that enables it and sets it up sensibly.
We are not the only product with this opinion. HQPlayer shares it, but takes a different approach in the UX–if you try to set the volume knob too close to maximum, the knob turns yellow, then red. Regardless of clipping. Basically, unless you want to live with an ugly red knob, you’re forced to make some headroom.Same idea–DSP needs headroom.
I guess what I’m missing is: why is your answer “make the sensor less sensitive” instead of “make adequate headroom for my DSP”?
History for the clipping indicator is an interesting idea.
Just because you say some other programs (the consensus?) ignore the ‘fine’ clipping and it crops up from time to time on the forums. If it makes no audible difference and can be safely ignored then making it less sensitive would stop it cropping up. People simply turning it off sort of then leaves them ‘unprotected’ from serious clipping. Ie I’d be happy to not know about tiny inter-sample clips or whatever they are but would still want the light to go red when I was genuinely setting up dsp or making adjustments.
The idea behind it being its simpler to make it less sensitive than automatically adjust people’s headroom or explain the intricacies.
But I see your point - who decides what’s audible? I’m guessing there’s not a person alive that could detect a clip of the type you’re explaining to Rodney and the rest of us?
Actually, doing an automatic headroom adjustment doesn’t seem like a bad idea. Maybe that’s better than the ‘-3’ default. Each time we run into a clip, auto-adjust it by the amount that would have avoided that clip, perhaps with a gentle ramp. At some point, based on your settings/source material, it will stop moving. Raises a question of what to do if DSP settings change…deserves some thought. Maybe there’s a max adjustment that it’s willing to do before it stops adjusting and “lets clips through”.
What’s interesting about that idea, is that it might enable a world where we could turn the indicator on by default. Which would be more in keeping with the mission here–which is to stop people from experiencing Roon’s DSP with any potential clipping-induced distortion.
Unfortunately, it could still make Roon “sound worse” just because it’s quieter. Some people will always hear quieter as worse, and our SRC would not stack up well in some comparisons if it had a permanent, non-disable-able gain adjustment baked in, simply because “quieter” has a larger effect size than this issue.
Surely it is possible to check and save highest allowed amplitude/frequency when building the audio library, and then from that calculate a headroom, so that Roon could suggest the highest sound level that would not produce any clipping in the library you have.
Of course, this would not include Tidal songs, but it would certainly be a good starting point for headroom management, or as an option for automatic volume leveling.
Yes of course, but if you save the required information during library tune-processing, you can add a “suggest headroom” function that uses the current DSP to provide the highest volume that wont create any clipping in your library.
Or if using this feature as part of volume leveling (which would be neat), just refresh the calculation or maxgain whenever DSP is changed.
[quote=“brian, post:24, topic:30158, full:true”]
This is not possible without re-processing the whole library through your current DSP settings each time they change.
[/quote]Oops, don’t ever say “thats not possible”, say its vert hard and complicated instead. As a developer I know you often ends up having to take it back
I know the convolution/DSP issue is not straight forward, but we are talking about numbers here (typically 16 or 24 bits long), and whether new values after DSP is to high to fit in those 16/24 bits. So an overflow check given than you know all max values from processing your library, and your new DSP, is certainly theoretically possible. But I know to little about DSP and convolution to take a guess if its practical and easy to implement!
Would you even need to know the library dynamic range details?
Perhaps there could be an assumption made that you want your DSP to work with any material (I certainly do, including Tidal) so just assume all formats will be recorded to the limits and compressed as hell, and see if dsp would clip under those circumstances? Might be a lot simpler and wouldn’t need updating for library changes or streaming.
Even that could get complicated for people with lots of experimental DSP presets (like me). I try and keep one headroom to rule them all but whereas PEQ can have local headroom, convolution can’t, so if the convolutions vary a lot it might get tricky?
I didn’t say it’s not possible absolutely. I just said it’s going to be inefficient
This isn’t just about overflow of individual samples–just knowing the max sample value in a track does exactly nothing to help determine what happens after DSP–filters act on blocks (potentially very long blocks) of audio. There is an aspect of loudness analysis that tells us something about inter-sample peaks–part of the R128 procedure actually involves upsampling the signal to see what peaks arise. This number is recorded as the “dbTP” value.
That only really tells us something about upsampling, however, and really is only fully accurate for certain kinds upsampling filters that resemble the ones used during analysis, since a different filter may produce different peak values. So even this is an approximation.
EQ is much harder to pin down, since the clips are triggered by interactions between the frequency response/phase response of the filter as it interacts with a particular block of material within a track. There is not a good way to pre-digest a track, since the areas likely to interact depend on the design of the filters themselves, which are not known up front.
You started with the idea of the library, so I was running with it. What I’d want in return for analyzing the whole library was 100% certainty, not just an approximation. And 100% certainty is the thing that’s going to be inefficient. So maybe it’s not worth it.
It would be cheaper to do an approximation–run some designed abusive signals through the DSP setup and see what happens. That’s not a totally easy project, the signals might need to be generated based on the characteristics of the processing involved, and might take lots of time and iteration to get right as we discover new causes of clipping, but it would at least be tractable from an efficiency standpoint.
I think Roon has all the appropriate tools. If someone wants to ignore the clipping turn off the indicator. If you want to eliminate most clipping use -3db of headroom. If you want to avoid all clipping -6db is the safest bet.
I ended up turning the dsp engine off and implementing the filter I wanted in DIRAC
I listened to a lot of bass heavy tracks with 0 headroom and the light merrily flashing away and couldnt detect the typical crunchy sound of digital clipping
The problem I would have had is a -10 db digital attenuation system wide with headroom. I dont want to run my devialet amps in to digital gain mode to get the loudness I want.
Right now the -6db I implement in dirac is ok to deal with
I have 2 Devialet 500w monoblocks driving a set of 92db vivid audio Giya G1 spirits
Another (much easier) suggestion would be to implement a “Check for clipping” functionality that does exactly what you say: use the current DSP and check all tunes in the library to see if any clipping occur. This would take some time, but would still be usable provided you can fast-play tunes to check for clipping.
Also: when clipping occur, is there any way to check how much was clipped? It could indicate (or even tell exactly) how many dB you would need to subtract to avoid clipping in that spot. Maybe make a clipping-log so you can see if you missed any red-blinks, and also an indicator how much was clipped.
Easy, but bad product, because for some users the check would take days to weeks (time to fetch and decode hundreds of thousands of tracks). It would get the job done, but I would not want to stand behind or defend the decision to make that functionality.
Yeah, @hifi_swlon mentioned the idea of maintaining history above. I think it’s a good idea, but don’t know what the UX might look like yet.
In my “usual” settings I don’t use the Roon DPS engine, but I implement headroom, upsampling and convolution in HQP. HQP has a “Limited” counter (in the Time Panel on the Main screen) that performs much the same function as the red light in Roon. I normally use -7 dB of headroom and that is generally sufficient to avoid incrementing the Limited counter. My convolution filter has some (tasteful) gain in the mid-bass.
As Brian pointed out further up the thread, the Roon clipping indicator is a nervous flighty beast compared to others and it fails soft. A headroom setting that avoids clipping for every single album might be overconservative if analog gain is an issue. If you just see one or two red lights when playing a deliberately over produced bass line then I wouldn’t be too fussed about changing the headroom to suit the material. If it’s flashing every bar then I probably would. I’ve got gobs and gobs of analog gain available though (volume has never gone past 11 o’clock on the preamp as it tends to make the ears bleed), so it’s not really an issue with perceived loudness.
Liking a little bass is nothing to be ashamed of, tasteful or not
I guess this all maybe just leads back to a less sensitive indicator? If there ends up being historical clipping data, the sort of ‘unimportant’ inter sample type clips could just be thrown in there - not lost, but not flagged in red either?
Dr…the devialets volume control is in the digital domain … 32 bit dsp chip
At -10db before the signal hits the dac means that with soft recordings I am playing the Devialets at 10+ and the little dots around the display are beginning to turn orange …whatever that means…and I dont think it means anything good
I have a little more headroom now as Im biamping my speakers with 2 x 1.5kw d-sonic amps for the bass and using the 500w devialets for the mids and tops