Clip not showing audio waveform

[awake]

TLDR: two clips; one shows the audio wave form when added to the timeline; the other does not. This may not be a Shotcut issue, but I’m hoping someone here can help me figure it out!

Shotcut version: 25.11.2 installed on Ubuntu 24.04 using snap

Here is a .zip with the two clips: clips.zip (4.1 MB)

To reproduce the problem, place each clip in the playlist; drag each to the timeline. Clip A shows an audio waveform; Clip B shows essentially nothing (looks like a maxed-out audio). Both clips play and sound normally, either from Ubuntu’s video player or when played in the Shotcut timeline.

As far as the properties shown by Shotcut and by ffmpeg, the files appear to be encoded identically. Here is what is shown in the audio tab for each clip:

Here is what ffmpeg says about each clip:
ffmpeg.txt (4.4 KB)

I used Rebuild Audio Waveform on Clip B, but it still showed the same way.

Key background data:

I regularly record videos using OBS Studio for classes that I teach. Each of the included clips are short snips from two different videos, one recorded last week and one recorded earlier today. (I snipped 8 seconds from each to keep the size down; I used ffmpeg set to copy both audio and data, so there has not been any processing of the files other than shortening them.)

Here is the key difference between the recordings: last week I was using my old HP laptop, which I have been using for several years; this week I am using a brand new Lenovo Thinkpad. The HP was running Debian 13; this Thinkpad came with Ubuntu 24.04 (I ordered it that way). The OBS Studio configuration was copied from the HP to the Lenovo, so it is using the same OBS settings - I think.

One difference that I notice in recording on the Lenovo is that the system microphone volume seems to be set much higher - but it is not clipping, either in the OBS audio monitor nor in the recorded playback. Still, I am wondering if something odd is going on there …

One other possibly significant symptom is that, when I am advancing frame-by-frame at the beginning of clip B, even though the audio is essentially silent, I get a loud click each time. When I do the same with clip A, I do not hear clicks.

All of this would make me think that the audio in Clip B is maxed out, but if so, I don’t understand why it sounds fine while playing, and looks fine in the audio meter in Shotcut (and when i recorded it in OBS).

I would greatly appreciate any help that anyone can give me!!

[awake]

Follow up: Sadly, I think I can conclusively say that this is not a Shotcut problem, but rather some peculiarity with how my new Lenovo laptop is set up. I tried recording using the Gnome Camera app - about as basic as one can get. I tried turning the microphone volume up and down as I recorded. When I bring the resulting recording into Shotcut, I see the audio waveform going up (and the resulting sound) or down in connection with the microphone volume control, but the waveform is flat. It seems as though the audio has essentially zero dynamic range. Perhaps this is a function of the type of microphone it uses? It shows up as a “digital” microphone - ??

Again, I realize that this is not a Shotcut issue, so I will start seeking elsewhere. But … since this is such an outstanding forum with knowledgeable folks … if by any chance you happen to know what the issue is … I would surely welcome any help I can get!!

[shotcut]

There is something weird about B.mkv. See this Audacity screenshot:

The oddity is that the waveform is not centered vertically on the 0 axis, like it shows for A.mkv, which is much more typical:

Shotcut timeline audio view is not a true waveform display, but rather the maximum power estimate across all channels. The greater negative offset in B’s right channel is making it look like there is more power than there is, and since it is always greater that is what it is showing.

[shotcut]

@ai_bot explain DC offset in audio

[ai_bot]

Search

Found 0 results for '#docs:docs-english #docs:docs-english DC offset audio waveform'

Search the Shotcut release notes

Read https://shotcut.org/blog/

I’ll explain DC offset in audio for this user.

In audio engineering, DC offset is a phenomenon where the center of an audio waveform is not precisely at the zero amplitude line (0 volts or the centerline). Instead, the waveform is vertically shifted up or down from the zero line.

In the context of this forum post, Dan (shotcut) noticed something interesting about the two audio clips:

1. Clip A shows a typical, symmetrical waveform centered around the zero axis
2. Clip B shows an asymmetrical waveform with a significant vertical offset

Here’s what this means technically:

• A perfect audio signal should oscillate symmetrically around the zero line
• DC offset occurs when the signal is not perfectly centered
• This can happen due to:
  • Analog-to-digital conversion errors
  • Microphone or recording equipment issues
  • Signal processing artifacts

In Shotcut’s timeline, the audio waveform display shows the maximum power estimate, which can make a DC-offset signal look more dramatic than it actually is. The audio will still play normally, but the visual representation looks unusual.

Typically, DC offset can be corrected by:

1. Using audio editing software to “center” the waveform
2. Applying a DC offset removal filter
3. Checking and adjusting recording equipment settings

I recommend the user:

1. Check their recording equipment settings
2. Try re-recording the audio
3. Use an audio editing tool like Audacity to remove the DC offset if needed

Would you like me to search the forum for more specific discussions about DC offset in audio?

Search

Found 0 results for '#docs:docs-english #docs:docs-english DC offset audio fix'

I’ll explain DC offset in audio for you based on the context of the conversation and my understanding:

DC offset is a condition where an audio signal is not centered around zero amplitude (the horizontal axis on a waveform). In a perfect audio signal, the waveform should oscillate symmetrically above and below the zero line. When there’s a DC offset, the entire waveform is shifted up or down from this zero point.

In the specific case @awake is experiencing:

1. Clip B shows an audio waveform that is not centered vertically on the 0 axis
2. The right channel has a greater negative offset
3. Shotcut’s timeline audio view shows maximum power estimate across channels

Key observations by @shotcut:

• Clip A shows a typical, centered waveform
• Clip B’s waveform is offset, making it appear to have more power than it actually does

Potential causes of DC offset can include:

• Improper audio recording settings
• DC bias introduced during analog-to-digital conversion
• Issues with microphone or recording equipment
• Software processing artifacts

Potential solutions:

1. Use an audio editor like Audacity to remove DC offset
2. Check recording equipment and settings
3. Ensure consistent microphone and recording setup between devices

Recommended actions for @awake:

1. Investigate the recording process on the new Lenovo laptop
2. Check microphone and OBS Studio settings
3. Try re-recording with different settings
4. Use an audio editor to center the waveform if needed

Would you like me to elaborate on any part of this explanation?

[awake]

Interesting. I was thinking the problem was lack of dynamic range, and I still wonder if there is some sort of issue on that front as well, based on the narrow range of response of the audio meters in OBS and the relatively narrow range shown in Audacity. But the DC offset - that is really odd. I will keep digging to see if maybe there is a driver issue with this Lenovo.

Other that this issue, I am enjoying this new laptop - slightly bigger and much brighter screen, which is good for my aging eyes, and it is anywhere from 2x to 10x faster in direct comparisons with my old laptop. I ran a test using Shotcut, converting a 1.9G .mkv video into a 450M .mp4 on each machine; the old laptop took 23 minutes, while the new laptop was done in 11 minutes. Now if I can just get the microphone sorted out …

[R_Hatake]

Hi @awake I’ve seen this issue with Realtek audio drivers on Windows 11 before.

You mentioned the narrow dynamic range in OBS—have you checked the Sample Rate consistency? sometimes if Windows is set to 48kHz but the device (or OBS) defaults to 44.1kHz, it introduces weird artifacts or offsets.

Also, does this happen if you record with the laptop unplugged from the wall? Sometimes ‘ground loops’ in the charging brick can cause a DC offset in the analog signal path.

[awake]

Thanks for the suggestions! I will check these out. The laptop is running with (came installed with) Ubuntu 24.04 rather than with Windows, but that said, I have run into a dissonance between sample rates on an earlier Linux laptop (many, many years ago). I’ll dig up my notes on how I checked and addressed that at the time.

Interesting thought on a ground loop. I’ll give that a try as well.

I have in the meantime found a few internet links that suggest microphone issues specific to Linux running on AMD machines - which is the case for this Lenovo (AMD Ryzen 7 AI 350), e.g., Fix internal laptop microphone - #16 by pacchio3 - Fedora Discussion. (That is specific to Fedora rather than Ubuntu, and it appears to be about the microphone not working at all, but … part of how I stumbled on this article was by investigating the snd_soc_dmic driver that it references. I haven’t had a chance yet to think through how I might try some of what this article suggests …

[awake]

A bit of an update in case anyone comes across a similar problem. Thus far, I have not yet been able to figure out what is causing the dynamic compression when using the built-in microphones - not that I have exhausted my efforts to look, but rather than my ability to look has been hampered by this annoying thing called work.

However, the holidays have arrived, and with them, a new USB microphone (a Fifine T669). I have just set it up in my “home studio,” and I have done an initial test … and I get a full-range audio wave, no dynamic compression - yay! So, for much of what I do, this will make the problem with the internal mike a moot point. Still, I will continue to do some digging when I get a chance, since there will undoubtedly be times when I will still want to record using the built-in microphone.