Zoom waveforms to fit vertical space in summary and overview

[Sean M. Pappalardo]

The detailed track waveform should be maximally vertically zoomed so that you can see as many details as possible in the given vertical space. That is, the loudest sample in the track should just touch the top/bottom of the waveform widget. (It currently changes with the Gain knob, which is not practically useful.)

[RJ Skerry-Ryan (rryan)]

I disagree that we should do this -- it's useful to be able to look at two waveforms and tell how loud they are relative to each other.

[Sean M. Pappalardo (pegasus-renegadetech)]

Isn't the point of ReplayGain to make them equal volume anyway?

[jus (jus)]

Some good points here. Imo the waveform is for viewing the audio detail and should be maxed by default, cant we just leave it to the VUmeters to display the relative loudness?
With the current gain-relative implementation the waveform is also often cut off at the top/button even if the loudness does not peak according to the peak indicators. This is especially visible with the waveform2.0 branch.

And if we choose to change that, we should make sure the waveform OVERVIEW should zoom to fit the vertical space too. Often if you have older tracks , before the loudness wars, they are only displayed as nearly flat line which makes the waveform overview less useful (think Samplers too).

[Thomas Vincent (vrince)]

I took a look at the way "total_gain" in use to scale the waveform (not the overview) and I tihnk I'am misusing it ... I don't remember why I did that.

I need to take a look at the vu code if we want to have a similar behavior (VU peak -> waveform goes out of the widget) but I don't even know if those two represent the same thing ... VuMeter display db loudness for a given time frame ... and waveform is signal max power. My knowloedge here is to limited but I'll try to make them coherent.

For the overview I can "scale it" according the the absolute maximum ... problem is during analysis I dont know the maximum. But I can find an easy work around if we give it a go.

[Sean M. Pappalardo (pegasus-renegadetech)]

My vote is to throw out using total_gain completely and just fill the widget (but don't clip.) With your new waveform, it seems reasonable to me to vertically scale each frequency band independently, or give the lower-energy ones a higher scaling weight so that e.g. the bass is the largest as now, mids max at no less than 70% of the size of the bass, and highs max at no less than ~70% of the mids (or ~50% of the bass.) Obviously these percentages may need tweaking, but you get the idea I hope.

[Thomas Vincent (vrince)]

I do beleive that using "total_gain" is a good idea since it's represent the actual playing sound.
I should use it in the overview too, it'll tend to make the waveform overview "fill" the space for low level sound (I guess...).

Then what about a settings to enable "normalized" waveforms ?

[Owen Williams (ywwg)]

I don't really mind having the widget scale the waveform, but would it be possible to also show clipping information too? If the internal gain is set too high, it would be nice if the peaks were indicated in bright red somehow. Right now I do adjust the gain if I see that the waveform is filling too much space, or if the peaks are getting squashed at the top and bottom of the widget.

[Thomas Vincent (vrince)]

I think peaks (as shown in vumeter) and waveform overview are slightly "different" thing. For the moment waveform summary data represent average sound power (linear) in the duration represented by the width of one overview pixel ... It quite a long time :) ). Means peaks are not a all visible in this time frame. So setting overall gain to avoid peak is, I think, a bad idea (but I can be wrong).

Plus VuMeter treats sound power in dB, when the waveforms are a linear representation of sound power.
Perhaps what I can do is coloring vertically the waveform (main) in dB scale so that we can see peaks better ...

[Sean M. Pappalardo (pegasus-renegadetech)]

While coloring based on a log dB scale would be interesting, all I (and jus) are asking is to see as much waveform detail as possible (without any of the peaks being off of the scale) both for the main waveform and the overview one, regardless of the gain or volume settings.

[Sean M. Pappalardo (pegasus-renegadetech)]

Look, here's an example of the problem. Notice that both the detail and overview waveforms are nearly useless on this track. (This is with the FIltered waveform, FWIW. The GLSL one is even less useful.)

Thanks to ReplayGain the track sounds fine and of comparable loudness to others, so your use case is nullified RJ, since the waveform height is NOT indicative of relative volume anymore.

[Thomas Vincent (vrince)]

It's obvious, especially if the overall loudness is similar to other track.
I really think I am not using ReplayGain and Gain in general properly to scale waveform data.

Do anyone know a good reference to understand better what ReplayGain do and help me find a better relationship between peak height and applied gain ?

[Sean M. Pappalardo (pegasus-renegadetech)]

Vittorio knows the most of us about it since he wrote the feature.

Let me also put forth that neither Serato DJ Intro nor Virtual DJ LE scale their waveforms when you change gain.

[RJ Skerry-Ryan (rryan)]

These are two issues that are being confused in this discussion -- waveform not showing detail and waveform not zooming so its max value is at the max widget height.

The no-detail issue is tracked in Bug #976650 and it has a known root cause and a viable fix. Sean -- your screenshot from #10 is Bug #976650 and not this one.

As for waveform height being directly correlated to waveform RMS energy multiplied by its total gain (replay gain times the pregain) -- I think this is something unique about Mixxx that makes the software feel interactive and fun. We should not make the waveform height fixed. (I don't give a crap what Serato DJ Intro or Virtual DJ LE do, Sean :P)

@Owen -- I think it would be cool to show clipping info in the waveform!

[Sean M. Pappalardo (pegasus-renegadetech)]

Thanks for clarifying. My screen shot does expose that other bug, but that wasn't my intention. (This has been an issue long before the new waveforms.) Attached is a screen shot from 1.10: while there's certainly more detail than in current trunk, note that the waveforms still have alot of wasted vertical space. I could raise the gain to make the detailed one max out, but Vittorio warned me that doing so would defeat the purpose of ReplayGain (which is to make all tracks the same nominal volume.) This is also why I am against RG having its own "hidden" gain but would rather it adjust the existing on-screen gain, just as a DJ/sound tech would normalize pre-fader levels on an analog mixer.

I only mentioned the other software packages to show that there's a precedent. I'm all for fun (and I agree that the feature is indeed fun) but not when it gets in the way of the primary purpose of helping DJs to mix better. Perhaps making it configurable is the way to go since that would make us both happy.

And I also agree that it would be great to show clipping in the waveform, as that would allow telling at a glance if the gain is too high instead of having to keep an eye on the clip indicators. (You can still do this with maximized waveforms by coloring everything above the clip point red, so adjusting the gain would move the clip point rather than the waveform scale.)

[Thomas Vincent (vrince)]

I implemented a 'normalized overview' in trunk.
Not the it's *graphically* normalized regarding the overall sound peak (not low/mid/high).
You can enable it from preference "normalize overview" if it suits your need I'll finalize it (translatable etc ...).
Let me know !

[xorik (xor29a)]

Great!
Thank you, Thomas

[RJ Skerry-Ryan (rryan)]

Have you tried the patch from Bug #976650 Sean? 1.10 is a very different approach to rendering and is not worth talking about.

RE: ReplayGain, RG corrects for the real-world bug of studios compressing the crap out of tracks to make them louder. We've discussed this considerably when we originally implemented RG and it doesn't make sense for the user's gain knob to magically change all the time. With transparent RG applied, the user will be able to set their pregain /once/ the entire night and not have to adjust it. Beyond that, if the pregain is shifting all the time, then if they have mapped pregain via a controller then their controller will always be out of sync with the GUI which is a poor user experience ("will soft-takeover work or am I going to blow everyone's ear drums out?")

TLDR we treat the RG as if the source audio in the track has that gain applied and there are good reasons for it.

[Daniel Schürmann (daschuer)]

The patch was committed to lp:mixxx/1.11 #3220
So I think it is save to change state to "Fix commited"

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/6256