"Show Clipping" Options

[Gale Andrews]

The default is actual sound damage — that "three over" thing, or as close as can be achieved with high probability. We have too many highly processed songs that live at 0 dB giving an entirely wrong impression of damage.

So are you still talking about Show Clipping here? The meters currently clip on four consecutive samples.

I agree with the reservation that Show Clipping lines or even meter clipping at four clipped samples may not necessarily indicate audible damage in a file processed for the loudness wars, but again, you can't make one size fit all, and there can be no default "high probability". Files will differ and live recording is more dangerous than playback.

A file that exercises the meter clipping lights or Show Clipping may not sound clipped to you, but on someone else's equipment or when burnt to CD, it may well sound clipped. That is why Normalize defaults to -1 dB.

So again, I say let meters and Show Clipping default to clip at one sample. Everyone agrees that the meters should be able to customise what number of samples they clip at and whether the clip light stays on, so let's do that.

If you also insist on Show Clipping being configurable or its bars being differentiated, I'd probably agree if that means we can start making a patch. I have a hunch adding the complication of making Show Clipping configurable may lessen chances of acceptance. After all, why not use Find Clipping then you can set the threshold for your saturated MP3 just as you want it?


Gale

[Edgar]

The lines remain visible after playback or recording is stopped, and are reset when a new playback or recording session is started

This is not reliably true with divorced meters on SVN HEAD (13567, 8 November 2014) on Windows.

Can you make steps to show that? Note that if you click in the playback meter this now removes the peak and clipping indicator in the playback meter.

I just updated to SVN HEAD13577; I DID NOT see the problem again with numerous trials. I did not turn on the experimental LED-style meters for this test. Sorry, false alarm.

[Edgar]

I think we are very close to consensus. We have 3 interface elements related to clipping: the Analyze Effect "Find Clipping"; the clipping indicators in the meters; the markers in the waveform enabled/disabled from the View menu.

In regard to the Effect, its name is not perfectly intuitive. I would propose a name change: "Label Clipped Samples" or, for brevity's sake: "Label Clipping". Anyone already familiar with using this effect to label clipping should have no problem with this renaming and anyone new to the concept might find it more discoverable. This Effect is begging for a Help button! I have not read (at least don't remember reading) the Manual and I have absolutely no idea what these "threshold" values mean. Otherwise, I think this interface element should continue to function independently from the other 2 elements.

Currently, the other 2 elements are effectively real-time but use slightly different concepts in determining when to trigger their display; the determining factor is the number of concurrent clipped samples - 1 for the wave track, 4 for the meters.

• Should these numbers be in lockstep? If so, only by default or, should the user be able to change either or both?
  
  Are the current values reasonable?

GUI Changes
Some proposals have been made which might improve the visual aspect of both the meter and the waveform clipping indication.

For the waveform, suggestions include changing the color of the vertical line, making it somewhat transparent or drawing it as a dotted or dashed line. Transparency is probably off the table at least until the swap to wxWidgets 3; the other 2 are easy to implement.

For the meters, suggestions include making the indicators wider so they are more discernible with modern day high resolution monitors and making a fading indicator. Making the meter indicators wider is trivial. Since the meters have 2 clipping indicators (the momentary one which shows up within the meter's range and the latched one which is drawn at the extreme right-hand edge and remains until dismissed by clicking on the meter or starting a new recording/playback) fading need some definition.

• Should there only be one meter indicator? If so, within its range or at the extreme right-hand edge?
  
  If we retain both indicators, which should fade?
  • We could leave the latched one as is and fade the currently momentary one.
    
    We could leave the currently momentary one as is and fade out the latched one either to completely faded out until the next clipping occurs or leave just a little bit of color until the next clipping occurs and then make it fully saturated.

[kozikowski]

I need to go back over that again. I missed the step where we got two meter flashers.

Koz

[Edgar]

I need to go back over that again. I missed the step where we got two meter flashers.

Take a look at the image I show a few posts back in this thread. You can see a vertical red bar between 0 & -1 which is the "momentary" indicator; it stays for a few seconds, does not fade, then disappears. Upon closer inspection of the code, I think this is an unintended side effect of the Gradient meter code; in actuality this is the Peak indicator which has inherited its color (in the traditional meter code it has a fixed color value which would never be red). Nevertheless, for either meter style it could be red (discriminatory code would need to be added to the traditional meter code) and could be made to fade over time as opposed to maintaining its original saturated shade.

[Edgar]

Here is a very small patch to play with; in srcwidgetsMeter.h at or near line number 34:

Code: Select all

//to make the latched  clipping indicator stand out more
//width when horizontal; height when vertical
//make this value 2 for current behavior
#define EXTRA_INDICATOR_SPACE 8

Currently, these indicators are 2 pixels (wide for horizontal, tall for vertical meters). I suggest that this value be set to 4; I have set it to 8 here just to make it very obvious what is going on. This value is used in a few places in srcwidgetsMeter.cpp.

[Edgar]

Here's a new patch, it must be applied INSTEAD of the previous patch, it gives you 2 more things to play with:

Code: Select all

#define EXTRA_CLIP_INDICATOR_SPACE 4
#define EXTRA_MOMENTARY_INDICATOR_SPACE 4
#define EXTRA_PEAK_INDICATOR_SPACE 4

wider.png (642 Bytes) Viewed 1059 times

In the above image the red rectangle refers to EXTRA_CLIP_INDICATOR_SPACE, the blue rectangle refers to EXTRA_PEAK_INDICATOR_SPACE and the orange rectangle refers to EXTRA_MOMENTARY_INDICATOR_SPACE.

[kozikowski]

There was one meter option I thought about briefly. A single click somewhere that snaps the meters to full width. Everybody gets out of the way just like they do when I expand manually (attach). It seems we're constantly telling posters to look at a specific value or meter reading in order to Get Out of Jail — but the information can't be seen on the default meters.

"Make sure your live performance sound peaks don't go much above -6."

Can you even see -6 with the default meters?

Obviously, if you have a 13" laptop, you may not want that. Too much real estate vanishes. But correct me, you are managing new flasher colors and sizes for the much more common larger monitors. My office screen is 27". The larger meters are perfectly appropriate.

Koz

[steve]

James made an interesting suggestion quite recently. As there is such broad range of features that different users do/don't want for their meters, he suggested implementing meters as "modules" (plugins). This would allow a variety of meters to be written and users to choose what sort of meters they want, without that being imposed on other users - you could even get your "jellyfish" koz, if someone wrote one.

[kozikowski]

you could even get your "jellyfish" koz, if someone wrote one.

I need to lie down for a minute.
Koz