Bug: Preference/Global FX Gain + 5 dB is causing clipping

[Gero5]

related to #821 Preference/Global FX Gain set to +5 dB to compensate -3dB pan gain loss plus -2 dB EQ gain loss B/M/T untouched vol at 100 % a song that ist normalized to 0 dB should cause no clipping - but it does. the song seems to be louder than on QuickTime with 100% volume. --> Are the dB values correct? what is the correct gain to get it played at 0 dB without any clipping?

[mpogue2]

I'll have to dive into this one further. I'll use a 0dB sine wave, so that I can see the precise results.

[mpogue2]

Step 1: I created a sample mono sine wave with peak at 0.99996, using Audacity.

Step 2: With EQ at nominal, volume at MAX, and Force Mono OFF, I recorded the output (stereo) via Audio Hijack.
Using Audacity, I exported sample data to a text file, and the peaks are at 0.38327 . Using a log calculator, that voltage ratio is about -8.3dB.

Step 3: Changed the EQ compensation to +5DB, and recaptured. The new peak is at about 0.68015. Converting 0.68015/0.38327 to dB gives +4.99dB.

So, the EQ compensation seems to be compensating by about the right amount (5dB on the preferences dial = 5dB increase in peak voltage).

Step 4: I turned on Force Mono. Peak was at 0.68243, so really no change to the peak. So, it does not appear to be a problem with Force Mono, unless it's specific to a stereo file (testing above is with a mono file created in Audacity).

@gero Could you kindly send me your Purple Disco Machine file (or at least a piece of it that exhibits the problem)? I'll then try to duplicate the problem here. Thanks!

[mpogue2]

Step 5: Played same file in QuickTimePlayer, and captured with Audio Hijack. Peaks were at 0.99997.

So, QuicktimePlayer seems to be doing just a pass through (which makes sense, we established this earlier). SquareDesk has mixing and EQ, which is why the output volume is lower, as previously discussed.

It should be necessary to set the compensation dial to +8dB, not just +5dB, to correctly compensate for Pan and EQ (without clipping). But, @gero is seeing clipping at levels of only +5dB.

Step 6: Set SquareDesk's Pan/EQ compensation to +8dB. Recapture SquareDesk -> AudioHijack -> Audacity shows peaks of 0.96350.

So, with a mono sine wave, setting Pan/EQ compensation to +8dB allows for nearly full-scale output, with no clipping.

Maybe Gero's source material only clips when channels are added together (some intermediate calculation overflow, perhaps)? I think the next step is to try out that source MP3 file.

[Gero5]

setting Pan/EQ compensation to +8dB allows for nearly full-scale output, with no clipping

Here are my settings:

• Force Mono OFF

• tone center

• tempo center

• volume max

• EQ knobs center

• Boost Itelligibility OFF

• Pan/EQ Volume compensation set to + 5 dB

in comparison to QuickTime Player, volume at max: at + 5 dB: (any) song sounds louder to me (measured by ear), for songs close to 0 dB level VU meter is in peak position very often at + 8 dB: any song sounds much louder to me, VU meter is in peak position permanently

Gain somewhere between +3 dB and + 4 dB sounds to me at almost the same loudness as QuickTime.

BTW: Gain once set to + 8 dB, then I turned it down to 4 dB, closed the panel by clicking OK and the sound gets less loud. When I open preferences again Pan/EQ gain shows +8 dB in the preference panel.

[mpogue2]

OK, I downloaded the song from YouTube. Here's what it looks like when I load it:

Captured by Audio Hijack and viewed in Audacity:

Highlighted samples are these:

0.34866 0.49811
0.52460 0.56287
0.63443 0.59940 <-- peak
0.63086 0.52191
0.54065 0.33383

I expected those samples to be more like the initial picture, close to 1.0 . I am suspecting that the handling of stereo is doing L+R instead of (L+R)/2...just speculating here.

[mpogue2]

I decided to measure two more STEREO test files:

• Baby Don't Hurt Me, by David Guetta (downloaded from YouTube, hopefully matches what @Gero used)
• Chirp, logarithmic 100Hz to 16KHz, amplitude 1.0 (created in Audacity)

Results (capture with Audio Hijack):

Test audio file            LUFS            RMS             Peak
------------------------------------------------------------------------
Baby SOURCE (Youtube)     -6.18           -8.6             1.0  (0dB)
Baby QuickTimePlayer      -6.01 (+0.2dB)  -8.4  (+0.2dB)   1.0  (0dB)
Baby SquareDesk           -9.01 (-2.8dB) -11.4  (-2.8dB)   0.88 (-1.1dB)

Chirp SOURCE (Audacity)   +1.52           -3.0             1.0   (0dB)
Chirp QuickTimePlayer     +1.49 (0dB)     -3.0 (0dB)       1.0   (0dB)
Chirp SquareDesk          -1.52 (-3dB)    -6.0 (-3dB)      0.709 (-3dB)
------------------------------------------------------------------------

LUFS uses K-weighting curves to weight by frequency as per human ear
RMS treats all frequencies equally

numbers in (parentheses) are relative to the volume of the source material

Note that Baby shows definite clipping distortion, when we look at the waveform in detail. I'm gonna guess that this was due to heavy compression. The LUFS value is quite high for Baby, heavily-compressed and typical of DJ material.

From this I conclude:

• QuickTimePlayer is not just a simple pass through, it added 0.2dB LUFS on Baby (but not on Chirp). That's not a lot of difference, but it does show that it's not just passing the audio through.
• SquareDesk is about 3dB lower than the source material and QuickTimePlayer, by LUFS and by RMS
• If we just use PEAK for normalization, it would not have bumped volume up enough for Baby, but it would have been right on for Chirp. So, using PEAK would introduce a content-dependent error of 2dB (in Baby).
• RMS might work better for a per-song automatic adjustment, because at least it came up with the same correction value for both Baby and Chirp (although LUFS is designed to do it "more" correctly, based on the human ear's response curves, in these cases, it didn't seem to matter much)
• The correct value for the Pan/EQ compensation knob, as per these two source files, is +3dB (not +5 nor +8).

[mpogue2]

Proposed actions:

• Change text on Pan/EQ Compensation to suggest +3dB instead of +5dB. Mention that it may be content dependent. This will still not get it quite up to QuickTimePlayer, because QTP provides a boost of 0.2dB for some content, but we can probably just ignore this small value.
• Implement automatic normalization (turned on/off by Preference), based on RMS (maybe good enough?, relatively quick to calculate). Could also limit boost by min(peakBoostdB, RMSBoostdB), so that we typically get RMSboost unless that would cause clipping, in which case we apply as much boost as possible before clipping starts.
• Since this is a single value for the automatic normalization, it's pretty straightforward to boost the waveform too, which I think would be nice for the user.
• With auto-normalization like the above, maybe we should retire the Pan/EQ Compensation?

[Gero5]

Note that Baby shows definite clipping distortion

You mean the source itself is already distorted, do I get that right?

SquareDesk is about 3dB lower than the source material and QuickTimePlayer

That exactly matches my listening experience. The 0.2 dB is not a difference I would be able to distinguish by ear AFAIS.

I am just curious which part pan or EQ compensates differently to what we discussed in #821 ?

Preference/EQ/PAN Volume compensation gain:

• to me it should be limited to values from 0 dB to +3 dB. Values lower or higher do not make sense to me. Even a Toggle ON/OFF for 0 dB/+3dB would do.

[mpogue2]

See #954.

[mpogue2]

Yes, the source material is already very compressed, and shows signs of clipping.

I don't know WHY it's different from our discussion in #821, but I can't argue with the measurement (or your ears!).

If I implement RMS/Peak scaling, would you still want the +3dB boost?

[Gero5]

If I implement RMS/Peak scaling, would you still want the +3dB boost?

definitely yes. the overall output and songs at different levels are two different issues.

see #954

[Gero5]

Baby Don't Hurt Me, by David Guetta (downloaded from YouTube, hopefully matches what @gero used)

yes, it does. does 'downloaded' mean a capture with Audio Hijack? Saved as mp3?

Results (capture with Audio Hijack):

the -1.1 dB Peak for Baby is somewhat strange. Note that the gain distance between QuickTime and SquareDesk as well is 3 dB for LUFS and RMS.

Was the YouTube audio encoded by audio hijack? then a different mp3 encoder (LAME in audacity) might explain the 0.2 dB/-2.8 dB difference.

There is another thing I wanted to discuss with you when I am 100 % sure that I compare sources at the same volume level. It might be related to that or not. now that we are sure that 3 dB is the right gain factor. there is an impression and I am only judging by ear that the sound reproduction of quick time is a nuance clearer. I have the impression that I can distinguish different instruments a tiny bit better when played with quick time compared to squareDesk. I do not know how to describe it any better. I can easily fool myself here as it is only a nuance.

I wonder If a frequency spectrum analysis would show any differences.

can you see how that 0.88 peak looks in the waveform? is it a single needle in the whole song or more than that. I think if we have a lot of peaks at 0.88 level then LUFS and RMS should show other results.

the SqaureDesk mp3 decoder should always reproduce exactly the same wave data as a mp3 decoders on any other music player. So the difference must be somewhere in what happens after the mp3 decoding. suspects: the pan or the EQ or BOOST Intelligibly or the new gain compensation. Is it possible for test puposes that you bypass each one of them and look whether it changes the peak value or not?

[mpogue2]

Downloaded here means using a tool called "Youtube to MP3.app", which given a YouTube URL will download just the music from that video. It's saved as MP3.

No, Audio Hijack is used to directly (in software) capture the audio that is coming out of a specific app. It is saved on disk as Lossless-Compressed MP4, so there is no compression or encoding loss here. It's what I use to capture the audio coming out of either QuickTimePlayer or SquareDesk.

So, the test process is this:

YouTube URL --> Youtube-to-MP3.app --> MP3 file --> Audacity --> WAV input file ("Source material") then WAV input file --> QuickTimePlayer --> Audio Hijack --> Lossless MP4 file --> WAV output file WAV input file --> SquareDesk --> Audio Hijack --> Lossless MP4 file --> WAV output file and WAV output file --> rsgain --> tells me peak and LUFS WAV output file --> Audacity/SelectAllAudio/Analyze/Measure RMS --> tells me RMS

I also looked at the Spectrum Analysis of each file in Audacity. To my eye, they differ only in level, but the frequency content is identical.

There are LOTS of samples up above 0.7, at least 5 above 0.8 in Baby_Squaredesk in the first 1M samples (all I can do easily in Audacity). In the Baby SOURCE file and in the QuickTimePlayer file, there are lots and lots and lots of samples in the first 1M sample that are at 0.99997 .

Yes, I thought about trying to bypass the EQ, and see what happens. It's probably not a perfect passthrough, I would guess.

In these tests, Pan is center, EQ B/M/T are all at 0, Boost is OFF, Gain Comp is 0.

[mpogue2]

The other interesting thing is that the Baby source material is clearly clipping. BUT, the SquareDesk output is NOT simply flattened out at a lower level. Again another indication that SquareDesk is not a pass through filter.

[mpogue2]

Baby, Squaredesk, with EQ disabled:

I verified that the EQ was disabled, and that the factor due to Pan was 0.707107 .

[mpogue2]

And with both EQ and PAN disabled:

[mpogue2]

Test audio file            LUFS            RMS             Peak
------------------------------------------------------------------------
Baby SOURCE (Youtube)     -6.18           -8.6             1.0  (0dB)
Baby QuickTimePlayer      -6.01 (+0.2dB)  -8.4  (+0.2dB)   1.0  (0dB)
Baby SquareDesk           -9.01 (-2.8dB) -11.4  (-2.8dB)   0.88 (-1.1dB)
Baby SquareDesk NO EQ     -9.01 (-2.8dB) -11.4  (-2.8dB)   0.88 (-1.1dB)
Baby SquareDesk NO EQ/PAN -6.01 (+0.2dB)  -8.3  (+0.3dB)   1.0  (0dB)

Chirp SOURCE (Audacity)   +1.52           -3.0             1.0   (0dB)
Chirp QuickTimePlayer     +1.49 (0dB)     -3.0 (0dB)       1.0   (0dB)
Chirp SquareDesk          -1.52 (-3dB)    -6.0 (-3dB)      0.709 (-3dB)
------------------------------------------------------------------------

LUFS uses K-weighting curves to weight by frequency as per human ear
RMS treats all frequencies equally

numbers in (parentheses) are relative to the volume of the source material

So, I'm gonna conclude from this that:

• almost all of the "missing" volume is due to Pan (0.707 = 3dB)
• with EQ set to center on B/M/T, there's not much loss at all due to EQ

So, in theory, the existing Pan/EQ Compensation set to +3dB should work OK for Pan Compensation (when set to center pan).

Alternatives (which we discussed before):

• allow for a non-constant-power PAN law, e.g. the Balance Law approach (Pan to the left of center drops R but not L, Pan to the right of center drops L but not R). This leaves the scaling factors for L and R at exactly 1.0 when Pan == center, and eliminates the need for the Pan Compensation knob entirely (I think).
• • a) replace the existing pan law (and delete the Pan compensation knob)
• • b) a user preference for pan law (and delete the Pan compensation knob)

PER SONG NORMALIZATION And, we can use Peak normalization to scale low-volume songs up, while preventing clipping. Peak normalization is fast, because I already calculate the peaks for the waveform. This will not make all the songs the same apparent level (RMS scaling would be closer, LUFS scaling would be even better), but it would be way better than what we have now (low volume songs have no way to be bumped up from within SquareDesk in the current version).

[mpogue2]

Closing this one, now that Pan is gone from DarkMode, and Pan is replaced by Balance for the Mix control in Light Mode. See #954 for tracking the Per-song auto-normalization enhancement.