View–>Show Clipping tags any 0dB peak as ‘clipping’. This is, of course, misleading, but still possibly useful. ‘Analyze -->Find Clipping’ with its user settable thresholds for consecutive 0dB samples and sample context (3 and 3 being a reasonable default) is much more accurate as a marker of clipping. Find Clipping’s ‘clipping’ track is more informative, but Show Clipping’s striking red lines on the waveform itself are more intuitively compelling.
I request making ‘Show Clipping’ user-configurable, including options ‘mark all 0dB peaks’ vs ‘mark only X consecutive 0dB as clipping’.
Occasional thin red lines indicate a warning that your audio is hitting 0dB.
Thick red lines, or a large number of red lines indicate a greater problem.
Any amount of red lines indicate a potential problem, and if you’re doing an important recording you should investigate, so I don’t personally think that making the indicators less sensitive is a good idea.
If you know that the in a particular project the red lines are not a problem, then you can turn them off (temporarily).
It is kind-of strange that they use different methods/algorithms but Show Clipping is simpler & faster and doesn’t have to do any real processing so I can see why that’s done automatically and quickly. If you’ve just recorded something it’s handy to immediately see if you’ve hit 0dB and probably have clipping.
Neither algorithm is perfect. They aren’t analyzing the wave shape, both show potential clipping, and both can give false positives and false negatives.
I don’t think there’s any foolproof method because not you can have square waves or squared-off waves that are not caused by clipping.
I didn’t suggest removing the functionality that Show Clipping has now. I said make it one of the options. It can be the default if changing that upsets users. But a 0dB peak does not absolutely mean ‘clipping’ , and that’s a fact.
I also notice that the 3rd party Find Peaks plugin also behaves differently. Unfortunate.
Finally, I notice that Show Clipping doesn’t always flag a 0dB peak, so something else is going on there. My example is a multichannel file that had no peaks at 0dB in any channel. In Audacity I amplified (NOT normalized) it to 0dB. It now has at least one 0dB peak, but Show Clipping doesn’t flag it. Find Peak detects it. Find Clipping, correctly, does not. Curiously, if I do use Normalize to 0dB instead , it generates one peak in each channel that is detected by Show Clipping, so something is going on there too. This even happens if I Normalize to 0dB *after * amplifying to 0dB. I don’t think Normalize works correctly with multichannel audio.
If a sample is at 0 dB, then the true peak will almost certainly be above 0 dB. It is generally considered good practice to always allow a bit of headroom. When following best practices, the issue that you are referring to should never occur.
Understood about intersample overs, and true peak readout would be a valuable tool*, especially when resampled audio is involved. But again, even assuming every 0dB peak is an over (which isn’t true) in isolation you won’t necessarily hear them. It’s when there is a series of 0dB peaks, consecutive or very close together, that it’s really problematic.
You seem to be coming from a recording/production perspective. Here I am coming from an analysis perspective here…‘forensic’ analysis and comparison of masterings that have already been released. Not everyone using Audacity is recording music - though I use it for that too and I’d never aim to hit 0dB.
What I asking for is that the tools that ostensibly seem able to do the same thing, be configurable to yield the same result.
*IIRC Audition actually reconstructs overs as overs?
Yes I agree. When there are only a few thin red lines, then there probably isn’t a problem, whereas dense bands of red indicate that there is probably a serious issue.
It might be nicer if “runs of one sample” were indicated in a less alarming colour (orange?), but that would be more demanding on the computer in an area where speed is crucial. The waveform and clip indicators need to be drawn as fast and efficiently as possible because they need to be frequently updated during playback / recording. If you toggle clipping on/off with a heavily clipped track, you will notice that there is a delay, and that would become very much worse if more complex analysis was implemented.
Yes, and that is precisely why Audacity provides two different tools. The clip indicators are extremely useful from a recording perspective, but from an analysis perspective greater flexibility is highly desirable, hence the reason for having a separate “Find clipping” tool.
The “Find Clipping” tool, because it does not need to run in real-time, could be made even more powerful. A couple of additional features that I would like would be:
Automatic detection of the threshold level. Clipping can occur below 0 dB, but the current tool only looks for clipping at 0dB.
Automatic “Stop threshold” so as to be able to mark heavily clipped regions with a single label rather than hundreds of labels.
For the label to show the maximum level within each labelled region.
I agree with your reasoning, but we differ in our conclusions. You want to make the two tools more similar, whereas I’d prefer them to be more different. I’d like to see the “Find Clipping” effect become more flexible and more obviously intended for analysis, while retaining a slimline “zero dB indicator”.