Cuts are often rendered with clips/pops in the audio

[thennicke]

Flowblade version 2.4.0 MLT version 6.18 (This issue has occurred for as long as I've used the editor though)

Input and output are both H.264/.mp4 (25fps) with .aac audio codec (48000Hz).

Whenever a cut is made and two different videos or audio tracks are joined together, clips/pops/static is often (but not always) produced between the two tracks.

Not sure if this has something to do with the 1/25 second timeline rate vs the 1/48 000 second audio sample rate, or maybe it's an MLT error.

This is a rendering issue, more than an editor issue, so it's pretty important to get it fixed.

I can provide sample footage if required.

[jliljebl]

Ok, if you could make some of clips involved available I will puth them on timeline here and see if the issue reprodiuces.

[thennicke]

No problem, I'll see what I can do.

I'd say this issue occurs about 50% of the time, but I have a project I'm working on currently where it's pretty bad in some sections. I'll see if I can isolate just a single clip and find a way to reproduce the issue with just that single clip, then I'll upload the clip and the steps to reproduce and get back to you here.

Thanks

[jliljebl]

Also test if adding 1-2 frame audio fade in helps, if that is the case then the pop comes from going in with full volume audio which can cause a pop sound as a matter of physics/human audio perception.

[thennicke]

Audio fades don't affect it -- already tested that strategy.

Just worked out a way to reproduce it. Uploading clips now.

[thennicke]

I've uploaded them to Google Drive, you should be able to access them at the following link: https://drive.google.com/drive/folders/1tiDKqUs8_sXiqN_NL9USCfN1Z7nV0fgd?usp=sharing

Steps to reproduce:

1. Bring 10 second video "input.MP4" into the timeline, right at the start of video track 1
2. Make cuts using "x" at each second mark
3. Delete clips 1, 3, 5, 7 and 9. Make sure remaining clips are stacked against each other.
4. You should be left with clips 2, 4, 6, 8, 10: this represents 4 cuts.
5. Export. I used H.264/.mp4 25000kbps at 48000Hz
6. You should hear a pop at cut number 3 (between clips 6 and 8)

So there's a pop on 1/4 of the cuts

My own output (in which the pop is audible) is also available in the folder, to cross-check against

Hope that helps

[jliljebl]

Thanks, I downloaded the files and tested a bit.

Yes, there is more pops on cuts then usual but I'm also getting them with Shotcut so this not Flowblade specific issue.

I will need to investigate this more thoroughly to form an opinion on the nature of the issue, try out multiple editing programs, this will take some time to move forward.

[dvdlvr]

Hi,

I can hear a pop in the input file at around 6s. That seems to be where the pop in the render file is as well.

[thennicke]

Hi, I can hear a pop in the input file at around 6s. That seems to be where the pop in the render file is as well.

This particular clip (taken from a much longer clip) was causing a lot of pops when cutting. I can get different parts of it and show you if required.

[thennicke]

Thanks, I downloaded the files and tested a bit.

Yes, there is more pops on cuts then usual but I'm also getting them with Shotcut so this not Flowblade specific issue.

I will need to investigate this more thoroughly to form an opinion on the nature of the issue, try out multiple editing programs, this will take some time to move forward.

Yes I suspected it might be an MLT issue. I'll see if I can find more ways to reproduce so that it's unambiguous what the nature of this issue is.

[jliljebl]

I did a quick edit on da Vinci Resolve. It did have one 'pop' less, I will still have to see if the edits are identical. Resolve may do some auto audio smoothing, difficult to say where diff comes from.

[thennicke]

I did a quick edit on da Vinci Resolve. It did have one 'pop' less, I will still have to see if the edits are identical. Resolve may do some auto audio smoothing, difficult to say where diff comes from.

Thank you. Yes I suspect audio smoothing may be the best way to get around this.

[dpack4]

I noticed the same thing when adding a transition between two clips. There is audio static/pops only for the frames with the transition. You do not have to render the project to hear it. Simply playing the video back in the timeline you can hear it and it is still there when rendered to the final output file. I too was using H.264 when applying the transition but I found that if I use MPEG-2 or MPEG-4 the audio static goes away. When done editing, you can still render your project to H.264 MP4; just use MPEG-2/MPEG-4 for your Dissolve/Wipe/Color Dip transitions. Since I now know it was just not me, the issue seems to be specific to using H.264 to render the transitions.

[thennicke]

To give you more of an idea of what these pops sound like in an actual output video, here is a video I made a couple of days ago with lots of them, it's really noticeable on almost every single cut from 4:30 through to 6:00.

https://www.youtube.com/watch?v=FZkGjVbAUhs

None of this noise was in the input footage.

[Efenstor]

This is a well-known problem in a world of audio recording. To solve it audio sequencer software commonly add tiny (about 1ms) fade-in and fade-out to every audio clip added or recorded. Sometimes those fade-ins and outs are even not visible in the timeline. As Flowblade is not strictly an audio editor, those fades can be integrated right into the engine (something of an additional correction of a clip volume when it's close to the clip edges).

This problem is caused by clash of basic audio levels, it's commonly noticeable when there are subsonic frequencies in the clips, e.g. caused by smooth air drifts pressing on the mic membrane. Although this has a different nature from the so-called DC offset (which is caused by the unequal AC power levels inside the amplifying equipment) essentially it's the same thing and it causes the same notorious pops when one tries to edit such recordings without fades.

[jliljebl]

, it's commonly noticeable when there are subsonic frequencies in the clips

Well, this is the case here, wind blowing into the microphone is clearly a factor with the audio presented. But 1 frame fade ins and outs did not help so I believe that low frequence level differences require faster fades to make them inaudible. So the fix would need to go in MLT because interface does not offer sub frame control and realistically cannot do that ever. This can be fixed, but probably not in the near future.

[jliljebl]

I'm marking this as feature request as it does not apper to be a bug perse, but rather requires enhancement to be fixed.

There is a workaroud, one can use export to Ardour feature and do sub frame fades with that application

[thennicke]

Thanks for looking into this jliljebl. Should we open a bug report with the MLT devs?

[jliljebl]

They do not accept feature requests, we would need to present them with code to fix this. This is not a bug, but a new feature that allows badly recorded audio to be edited without using dedicated audio programs. When I looked into this even Avid does not have this feature out of the box, there is some plugin to do this.

[Efenstor]

But 1 frame fade ins and outs did not help

Hmmm. It actually should had helped (have had? had have? I don't know how it's usually said correctly).

I did some more experimentation: generated a low-rumble file in Audacity, added it into Flowblade and sliced it into small pieces. In theory it should make no difference as I did not move any pieces bu still I got pops at some points while just playing the audio in the editor and also in the rendered file although the pops are fewer. All of them tend to happen in the beginning of the file (the first cut is always causes a pop), but they become rarer with time. In general is sounds like some buffer problem.

I though that may be using a file with sample rate corresponding to the project profile may fix the problem but nope: it has no matter, and I suspect that audio is always being resampled although there's not always a need for this.

[Efenstor]

Here are the low-rumble files I used for experimentation: https://yadi.sk/d/yA6vT_VGPV_7PQ https://yadi.sk/d/5KB5SeqdwrG68Q

[jliljebl]

Alright, we need to look at this further, If there are some bugs in Flowblade/MLT these need to be known.

[jliljebl]

But 1 frame fade ins and outs did not help Hmmm. It actually should had helped (have had?

Are we actually sure about this because longer fades allow more information about lower frequence levels to pass through?

[jliljebl]

The 'pop' is not visible on the waveform.

Wave gets carried over unless it is silenced in a fade that is faster then the wave frequency? Just guessing, but long fade does not kill low frequency wave information because it is continually present as the volume goes down.

[jliljebl]

And then that low freqency info comes out as a pop.

[Efenstor]

But 1 frame fade ins and outs did not help Hmmm. It actually should had helped (have had?

Are we actually sure about this because longer fades allow more information about lower frequence levels to pass through?

Actually longer fades should be even better than the short at suppressing low frequencies. I just tried it in Audacity and it works perfectly. Fades compress the whole signal range, frequencies do not count.

By the way, that's an interesting idea: a frequency-aware fade. I know no editor which can do it. I mean, higher frequencies can be cut quicker, that's no problem, while the lower should fade out and in slower to prevent pops. It can be achieved by applying HF filter which gradually moves the cutoff frequency while the fade goes on. Of course, then the total length of a fade should be longer, but this will prevent all and any artifacts.

[Efenstor]

The 'pop' is not visible on the waveform.

Wave gets carried over unless it is silenced in a fade that is faster then the wave frequency? Just guessing, but long fade does not kill low frequency wave information because it is continually present as the volume goes down.

Pop is visible. Just zoom in more. Here is how it usually looks:

And here it is after fixing with fade out and fade in:

[Efenstor]

And by the way, even the cheapest audio equipment nowadays is so precise that no carry-over frequencies exist, the digital level more or less precisely corresponds to the physical position of a diaphragm in headphones or speakers at each particular time.

[jliljebl]

Ok, will need to look for solutions, do have an idea how this could be fixed?

to 13. helmikuuta 2020 klo 15.47 Efenstor notifications@github.com kirjoitti:

And by the way, even the cheapest audio equipment nowadays is so precise that no carry-over frequencies exist, the digital level more or less precisely corresponds to the physical position of a diaphragm in headphones or speakers at each particular time.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jliljebl/flowblade/issues/799?email_source=notifications&email_token=AAN5FVAYVPEAZX76QFPFMXTRCVFN7A5CNFSM4KERGLZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELVAFHI#issuecomment-585761437, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAN5FVAXEYJMXPN5XQ26C73RCVFN7ANCNFSM4KERGLZA .

[Efenstor]

I think simple default 0.05s fades at both ends of each clip will do fine for now. In future may be something more complicated, such as cross-fades.

And I think I got why 1 frame fades do not work: there is simply no interpolation at steps finer than 1 frame!

[jliljebl]

I think I got why 1 frame fades do not work: there is simply no interpolation at steps finer than 1 frame!

Ok, that would be a bug, if I can confirm that i will report.

[jliljebl]

I found the explanation from Dan Dennedy in an MLT issue:

MLT filters cannot represent a parameter value change in a single frame. The minimum is 2. So, if you want the volume to go from 0 to 1.0 over two frames, the first frame is 0 (silent) and the second frame is 1.0. Also, the filter is simple and does not interpolate values between frames such as 0.5 between frames 0 and 1. It does, however, know its previous value and can ramp over the sample in its frame to the value for the current frame. IOW, it is backward looking, not forward. On frame 0 all it knows is 0. On frame 1, it knows the previous value was 0, and the desired value is 1. You can look at normalize/filter_volume.c.

Not sure about solution, but there are ways to move forward with this, so I'm keeping this open. With current available tech users are advised to always use at least 2 frames when doing audio fades.