Bug 410726 - Audio artifacts in export
Summary: Audio artifacts in export
Status: CONFIRMED
Alias: None
Product: kdenlive
Classification: Applications
Component: Video Display & Export (show other bugs)
Version: Appimage - Refactoring
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Jean-Baptiste Mardelle
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-08 13:49 UTC by dave41264
Modified: 2021-04-23 12:06 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:
fritzibaby: Brainstorm+


Attachments
an archive with 3 files that reproduce the problem (16.16 KB, application/x-bzip)
2020-05-17 02:45 UTC, Steve
Details
an archive with 4 files that reproduce the problem (52.69 KB, application/x-bzip)
2020-05-20 03:40 UTC, Steve
Details
Original audio vs rendered audio with cut in-between (276.22 KB, application/gzip)
2021-03-08 22:14 UTC, Ruman Gerst
Details
Audio artifact is not reproducible in 24 FPS (598.69 KB, application/gzip)
2021-03-08 22:41 UTC, Ruman Gerst
Details

Note You need to log in before you can comment on or make changes to this bug.
Description dave41264 2019-08-08 13:49:31 UTC
SUMMARY
I have 2 audio tracks, one is background music the other is foley. Everytime something on the foley track plays it makes a click happen (I use fade in/outs for every clip). This only occurs in a rendered file (I've tried all formats of video and audio) it doesn't occur in the timeline preview.

If I export the foley track by itself there is no problem, same if I export the music track on its own.

ADDITIONAL INFORMATION
There is a forum thread about this with recent posts confirming the issue and providing more insight into the problem.

https://forum.kde.org/viewtopic.php?f=271&t=150644
Comment 1 Steve 2020-05-17 02:45:43 UTC
Created attachment 128535 [details]
an archive with 3 files that reproduce the problem

Enclosed is a *very* simple reproduction case. Extract this archive to some convenient directory, replace all instances of CURRENTDIR with wherever you put the .mlt and .wav file, and all instances of PROFILEDIR with your kdenlive profile directory. You can move the customprofile32 file there, although I don't think it affects anything.

Here are the parameters to mlt that I'm using:

xml:///CURRENTDIR/audio-artifact.mlt properties=WAV -consumer avformat:audio-artifacts.wav ar=44100

The .mlt file literally plays one clip with a Gain filter and a fade-in/fade-out. It's very simple.

At the end of the generated audio, there's a little glitch that's visible in Audacity; it sounds like a "pop" sound. (Sometimes, my attempt to use kdenlive to make audio for my video is filled with these artifacts, making it unusable.)

I spent most of today single-stepping through mlt in Qt Creator (mostly consumer_thread() in consumer_avformat.c), inspecting memory, etc. in an attempt to track down the source of this bug, but the audio being returned from mlt_frame_get_audio() didn't look like the audio being output to the .wav file, so I'm not sure how to track this. Hopefully you take this as evidence of a good-faith effort to find the bug myself, and that someone that knows this code better takes a look at my reproduction example.

I noticed two odd things that might be related to the bug:

1) filter_get_audio(), in filter_volume.c, sets the _previous_gain property to the current
   value of "gain" at the beginning of any volume change. That seems like it would have a
   non-intuitive effect on fade-in and fade-out, i.e. a 1-frame fade-in would actually be
   a 1-frame mute followed by a 1-frame fade-in, and a 1-frame fade-out would actually be
   1 frame of unaltered audio, followed by a 1-frame fade-out.
   Since the artifact commonly happens after the clip's audio is supposed to be faded out,
   this may be related.
2) fps values are represented by floats and doubles. NTSC framerates are fractional, e.g.
   24000/1001 and 30000/1001 are commonly found. ffmpeg internally uses a struct called
   AVRational to avoid problems with fractional framerates.

Please, please, PLEASE look into this! The original forum post is almost 2 1/2 years old, and this artifact is ruining my ability to use kdenlive.
Comment 2 farid 2020-05-17 18:20:10 UTC
(In reply to Steve from comment #1)
> Created attachment 128535 [details]
> an archive with 3 files that reproduce the problem
> 
> Enclosed is a *very* simple reproduction case. Extract this archive to some
> convenient directory, replace all instances of CURRENTDIR with wherever you
> put the .mlt and .wav file, and all instances of PROFILEDIR with your
> kdenlive profile directory. You can move the customprofile32 file there,
> although I don't think it affects anything.
> 
> Here are the parameters to mlt that I'm using:
> 
> xml:///CURRENTDIR/audio-artifact.mlt properties=WAV -consumer
> avformat:audio-artifacts.wav ar=44100
> 
> The .mlt file literally plays one clip with a Gain filter and a
> fade-in/fade-out. It's very simple.
> 
> At the end of the generated audio, there's a little glitch that's visible in
> Audacity; it sounds like a "pop" sound. (Sometimes, my attempt to use
> kdenlive to make audio for my video is filled with these artifacts, making
> it unusable.)
> 
> I spent most of today single-stepping through mlt in Qt Creator (mostly
> consumer_thread() in consumer_avformat.c), inspecting memory, etc. in an
> attempt to track down the source of this bug, but the audio being returned
> from mlt_frame_get_audio() didn't look like the audio being output to the
> .wav file, so I'm not sure how to track this. Hopefully you take this as
> evidence of a good-faith effort to find the bug myself, and that someone
> that knows this code better takes a look at my reproduction example.
> 
> I noticed two odd things that might be related to the bug:
> 
> 1) filter_get_audio(), in filter_volume.c, sets the _previous_gain property
> to the current
>    value of "gain" at the beginning of any volume change. That seems like it
> would have a
>    non-intuitive effect on fade-in and fade-out, i.e. a 1-frame fade-in
> would actually be
>    a 1-frame mute followed by a 1-frame fade-in, and a 1-frame fade-out
> would actually be
>    1 frame of unaltered audio, followed by a 1-frame fade-out.
>    Since the artifact commonly happens after the clip's audio is supposed to
> be faded out,
>    this may be related.
> 2) fps values are represented by floats and doubles. NTSC framerates are
> fractional, e.g.
>    24000/1001 and 30000/1001 are commonly found. ffmpeg internally uses a
> struct called
>    AVRational to avoid problems with fractional framerates.
> 
> Please, please, PLEASE look into this! The original forum post is almost 2
> 1/2 years old, and this artifact is ruining my ability to use kdenlive.

Hi Steve, 

Are you experiencing this with latest MLT (6.20)? Which version of MLT and Kdenlive are you using? 

This seems to be similar to https://bugs.kde.org/show_bug.cgi?id=371849

Which seems to be fixed via this commit: 
https://github.com/mltframework/mlt/commit/25f28d95d689f28a6bea6232ef7e8308c71b189a
Comment 3 farid 2020-05-17 18:30:41 UTC
(In reply to Steve from comment #1)
> Created attachment 128535 [details]
> an archive with 3 files that reproduce the problem
> 
> Enclosed is a *very* simple reproduction case. Extract this archive to some
> convenient directory, replace all instances of CURRENTDIR with wherever you
> put the .mlt and .wav file, and all instances of PROFILEDIR with your
> kdenlive profile directory. You can move the customprofile32 file there,
> although I don't think it affects anything.
> 
> Here are the parameters to mlt that I'm using:
> 
> xml:///CURRENTDIR/audio-artifact.mlt properties=WAV -consumer
> avformat:audio-artifacts.wav ar=44100
> 
> The .mlt file literally plays one clip with a Gain filter and a
> fade-in/fade-out. It's very simple.
> 
> At the end of the generated audio, there's a little glitch that's visible in
> Audacity; it sounds like a "pop" sound. (Sometimes, my attempt to use
> kdenlive to make audio for my video is filled with these artifacts, making
> it unusable.)
> 
> I spent most of today single-stepping through mlt in Qt Creator (mostly
> consumer_thread() in consumer_avformat.c), inspecting memory, etc. in an
> attempt to track down the source of this bug, but the audio being returned
> from mlt_frame_get_audio() didn't look like the audio being output to the
> .wav file, so I'm not sure how to track this. Hopefully you take this as
> evidence of a good-faith effort to find the bug myself, and that someone
> that knows this code better takes a look at my reproduction example.
> 
> I noticed two odd things that might be related to the bug:
> 
> 1) filter_get_audio(), in filter_volume.c, sets the _previous_gain property
> to the current
>    value of "gain" at the beginning of any volume change. That seems like it
> would have a
>    non-intuitive effect on fade-in and fade-out, i.e. a 1-frame fade-in
> would actually be
>    a 1-frame mute followed by a 1-frame fade-in, and a 1-frame fade-out
> would actually be
>    1 frame of unaltered audio, followed by a 1-frame fade-out.
>    Since the artifact commonly happens after the clip's audio is supposed to
> be faded out,
>    this may be related.
> 2) fps values are represented by floats and doubles. NTSC framerates are
> fractional, e.g.
>    24000/1001 and 30000/1001 are commonly found. ffmpeg internally uses a
> struct called
>    AVRational to avoid problems with fractional framerates.
> 
> Please, please, PLEASE look into this! The original forum post is almost 2
> 1/2 years old, and this artifact is ruining my ability to use kdenlive.

In case this is not fixed someone from the dev team will look into it. thanks for providing such useful information. :)

Btw, the 20.08 cycle will see a lot of work in the audio front. See here: https://invent.kde.org/multimedia/kdenlive/-/issues/382
Comment 4 Steve 2020-05-18 11:32:35 UTC
>Are you experiencing this with latest MLT (6.20)?

Sorry, I should have said...yes, this is with the latest MLT from github's version control.

>Which version of [...] Kdenlive are you using?

I'm still using kdenlive 18.12.3. The last time I tried to use 19, it ground my machine to a halt, especially when zoomed in closely on the timeline. One crippling bug at a time. :-)

>This seems to be similar to [...]

That seems to have fixed one source of audio artifacts, but there are still more.

Thank you for looking into this! I attempted another round of looking for it myself yesterday, but mostly just got more familiar with the code, and didn't get to the point of being able to look for the bug.
Comment 5 farid 2020-05-18 14:21:09 UTC
(In reply to Steve from comment #4)
> >Are you experiencing this with latest MLT (6.20)?
> 
> Sorry, I should have said...yes, this is with the latest MLT from github's
> version control.

Ok
> 
> >Which version of [...] Kdenlive are you using?
> 
> I'm still using kdenlive 18.12.3. The last time I tried to use 19, it ground
> my machine to a halt, especially when zoomed in closely on the timeline. One
> crippling bug at a time. :-)

That one got fixed, see: https://invent.kde.org/multimedia/kdenlive/-/issues/474
> 
> >This seems to be similar to [...]
> 
> That seems to have fixed one source of audio artifacts, but there are still
> more.

Could you just test the AppImage to make sure it is not happening?

> 
> Thank you for looking into this! I attempted another round of looking for it
> myself yesterday, but mostly just got more familiar with the code, and
> didn't get to the point of being able to look for the bug.

Thanks for your contribution to MLT as well. Btw, we have a telegram dev group if you are interested: https://t.me/kdenlive_dev

Cheers
Comment 6 Steve 2020-05-19 00:10:12 UTC
> Could you just test the AppImage to make sure it is not happening?

Yes, the problem happens in the AppImage I just downloaded (kdenlive-20.07.70-5e52a8d-x86_64.appimage). The audio artifact is still visibly present when the output is opened in Audacity.

I can't test if the latest version freezes when zoomed in closely, because the AppImage crashed when trying to load an older video-project. I can diagnose that later with the latest source. One crippling bug at a time.
Comment 7 Jean-Baptiste Mardelle 2020-05-19 09:26:25 UTC
Thanks Steve for your detailled analysis. As your testing suggests, this seems to be an MLT issue. I will try to reproduce and will get back to you before the end of the week.
Comment 8 Jean-Baptiste Mardelle 2020-05-19 10:40:36 UTC
So I made a few tests and in fact the issue has nothing to do with fades, or effects, but it all relates to the profile.
It can easily be reproduced in MLT with the command line utility, using the provided files :

melt -profile ./customprofile32 AI_NORM3.WAV -consumer avformat:output.wav channels=1

You can see a clear click on the last frame in the result output.wav
Using a 25 or 29.97 profile the click doesn't happen.
I will report it on mlt's bugtracker.
Comment 9 Jean-Baptiste Mardelle 2020-05-19 10:47:30 UTC
Reported in MLT:
https://github.com/mltframework/mlt/issues/564
Comment 10 Steve 2020-05-19 12:43:54 UTC
If it helps, another recent video that reproduced a bunch of audio artifacts (though not as many as my current 23 fps project) was at 24000:1001 fps.
Comment 11 farid 2020-05-19 21:13:16 UTC
Fixed upstream via https://github.com/mltframework/mlt/commit/bd3fa58ceeae20c3c9cddfc572fbf86c0a5d9793

@steve your debugging was very helpful thanks! 

We could use those skills elsewhere (if you are interested of course) ;)

cheers
Comment 12 Steve 2020-05-20 02:24:22 UTC
Well...I can honestly say that I never would have found that fix. :-) Thanks for all your help!

It does bring up another suspicion I had, looking through the code...I would convert all producer audio to floating-point, and do all internal audio processing in that format, so that no matter what the internal transformations, the samples wouldn't clip. But I'm not expecting anyone to jump on that...perhaps I can try to do it, as I get more familiar with the code.

There are still some pops left, but I haven't been able to reduce them to a simple reproduction case yet. I will continue to try. (At least there are far fewer pops!)

>We could use those skills elsewhere (if you are interested of course) ;)

I would love too...energy willing, of course. I have a lot more energy since I started working from home (as part of the reaction to the pandemic), but who knows when that will end. I can continue to try to find reproduction cases for audio artifacts.
Comment 13 Steve 2020-05-20 03:40:16 UTC
Created attachment 128621 [details]
an archive with 4 files that reproduce the problem

I'm on a roll...after several blissful hours of effort, I managed to narrow down an affected part of my video to reproduce more audio pops. (I was even able to do it with only two sound effects...truly a miracle.) Anyway, the enclosed sample has six loud pops, three of which are clearly visible when the output is viewed in Audacity. Hopefully the source of these pops can be found as quickly! I would certainly be grateful.
Comment 14 farid 2020-05-20 12:20:06 UTC
(In reply to Steve from comment #13)
> Created attachment 128621 [details]
> an archive with 4 files that reproduce the problem
> 
> I'm on a roll...after several blissful hours of effort, I managed to narrow
> down an affected part of my video to reproduce more audio pops. (I was even
> able to do it with only two sound effects...truly a miracle.) Anyway, the
> enclosed sample has six loud pops, three of which are clearly visible when
> the output is viewed in Audacity. Hopefully the source of these pops can be
> found as quickly! I would certainly be grateful.

Amazing! JBM reported it upstream: https://github.com/mltframework/mlt/issues/566

Cheers :D
Comment 15 emohr 2020-05-22 11:40:19 UTC
Maybe your findings with fps has something to do with audio crackling while playback as I could reproduce audio crackling while playback. 

The "PAL_1080i_DVCPRO_HD_colorbar.avi" is a 25fps file contains 8 audio streams and sin tone on the first 2 audio streams (from http://www.gvgdevelopers.com/concrete/products/k2/test_clips/). 

Make a new project with 50fps and add above clip to the timeline -> play it -> I hear crackling. Can you reproduce as well? 

You can test this with the daily build only as the test file has 8 audio streams.
Comment 16 emohr 2020-05-24 11:30:42 UTC
If I pre-render the clip the audio crackling is gone. @Steve should we open a new bug for this?
Comment 17 Steve 2020-05-25 13:26:39 UTC
Pre-rendering didn't help in my case.

Anyway, it appears that four recent commits got rid of the issues:

https://github.com/mltframework/mlt/issues/564
https://github.com/mltframework/mlt/issues/566

So once the other responders to this bug report reply and concur, I think we can close this!
Comment 18 dave41264 2021-01-13 19:05:00 UTC
I don't have time to test at the mo, but if you guys say it's fixed that's good enough for me.
Comment 19 Ruman Gerst 2021-01-13 19:17:35 UTC
Sorry, I went a bit on autopilot and added myself to the mailing list.

I have a similar bug on my current project that I was trying to get info about

Sorry!
Comment 20 farid 2021-01-13 20:31:35 UTC
(In reply to Ruman Gerst from comment #19)
> Sorry, I went a bit on autopilot and added myself to the mailing list.
> 
> I have a similar bug on my current project that I was trying to get info
> about
> 
> Sorry!

What version are you using? Canyou try with the latest AppImage.
Comment 21 Ruman Gerst 2021-01-13 21:25:34 UTC
(In reply to farid from comment #20)
> (In reply to Ruman Gerst from comment #19)
> > Sorry, I went a bit on autopilot and added myself to the mailing list.
> > 
> > I have a similar bug on my current project that I was trying to get info
> > about
> > 
> > Sorry!
> 
> What version are you using? Canyou try with the latest AppImage.

I tried it with the newest appimage and still have the audio artifacts with my newest project. 
My non-appimage version should be up-to-date as well, as I am using the Ubuntu 20.10 PPA (comes with 20.12.1 and MLT 6.25.0).

The audio was captured using the recording track and I cut the beginning and end of them, before putting them to their destined located.
Rendering audio only (FLAC) had the "pop"/"click" sounds at beginning of some clips (which are also present in the preview).
These should have been fixed in MLT, but I managed to break them ...

I edited the audio file in Audacity and imported it back into Kdenlive. I was required to make edits to this track, which also involved cuts.
Interestingly, here I have an additional artifact: The rendered video (as well as the preview) contains "lags", similar to if the real-time preview gets stuck on some effects 
and slows down/distorts the audio - just in the final render.

This "lag" appears in renders created by Kdenlive (Ubuntu PPA), Kdenlive (Appimage), and MLT CLI, so this might be an upstream issue.


For now I edited everyting in Audacity and just put the final audio over the video and it rendered fine.
Comment 22 farid 2021-03-05 13:58:16 UTC
Hi Ruman

(In reply to Ruman Gerst from comment #21)
> (In reply to farid from comment #20)
> The audio was captured using the recording track and I cut the beginning and
> end of them, before putting them to their destined located.
> Rendering audio only (FLAC) had the "pop"/"click" sounds at beginning of
> some clips (which are also present in the preview).
> These should have been fixed in MLT, but I managed to break them ...

Can you upload one of your flacs so I can test? 

> 
> I edited the audio file in Audacity and imported it back into Kdenlive. I
> was required to make edits to this track, which also involved cuts.
> Interestingly, here I have an additional artifact: The rendered video (as
> well as the preview) contains "lags", similar to if the real-time preview
> gets stuck on some effects 
> and slows down/distorts the audio - just in the final render.
> 
> This "lag" appears in renders created by Kdenlive (Ubuntu PPA), Kdenlive
> (Appimage), and MLT CLI, so this might be an upstream issue.

Can you share your MLT command?
Comment 23 farid 2021-03-08 21:48:50 UTC
(In reply to Ruman Gerst from comment #21)
> (In reply to farid from comment #20)
> > (In reply to Ruman Gerst from comment #19)
> > > Sorry, I went a bit on autopilot and added myself to the mailing list.
> > > 
> > > I have a similar bug on my current project that I was trying to get info
> > > about
> > > 
> > > Sorry!
> > 
> > What version are you using? Canyou try with the latest AppImage.
> 
> I tried it with the newest appimage and still have the audio artifacts with
> my newest project. 
> My non-appimage version should be up-to-date as well, as I am using the
> Ubuntu 20.10 PPA (comes with 20.12.1 and MLT 6.25.0).
> 
> The audio was captured using the recording track and I cut the beginning and
> end of them, before putting them to their destined located.
> Rendering audio only (FLAC) had the "pop"/"click" sounds at beginning of
> some clips (which are also present in the preview).
> These should have been fixed in MLT, but I managed to break them ...
> 
> I edited the audio file in Audacity and imported it back into Kdenlive. I
> was required to make edits to this track, which also involved cuts.
> Interestingly, here I have an additional artifact: The rendered video (as
> well as the preview) contains "lags", similar to if the real-time preview
> gets stuck on some effects 
> and slows down/distorts the audio - just in the final render.
> 
> This "lag" appears in renders created by Kdenlive (Ubuntu PPA), Kdenlive
> (Appimage), and MLT CLI, so this might be an upstream issue.
> 
> 
> For now I edited everyting in Audacity and just put the final audio over the
> video and it rendered fine.

Doing some debugging in another similar issue I saw that your artifacts might be related to 60fps projects. What is your project profile?

https://bugs.kde.org/show_bug.cgi?id=410726
Comment 24 Ruman Gerst 2021-03-08 22:14:14 UTC
Created attachment 136501 [details]
Original audio vs rendered audio with cut in-between

As requested the original audio file and the Kdelive render (FLAC)

The original audio was cut to remove the "uuhh" part. This yielded in the audio artifact.

Preset: 1080p, 60FPS
Comment 25 Ruman Gerst 2021-03-08 22:17:20 UTC
(In reply to farid from comment #22)
> Hi Ruman
> 
> (In reply to Ruman Gerst from comment #21)
> > (In reply to farid from comment #20)
> > The audio was captured using the recording track and I cut the beginning and
> > end of them, before putting them to their destined located.
> > Rendering audio only (FLAC) had the "pop"/"click" sounds at beginning of
> > some clips (which are also present in the preview).
> > These should have been fixed in MLT, but I managed to break them ...
> 
> Can you upload one of your flacs so I can test? 

Thank you for your reply! I uploaded an attachment that contains the original audio plus rendered audio (the original audio was cut in Kdenlive to remove an "uuhhh").

> 
> > 
> > I edited the audio file in Audacity and imported it back into Kdenlive. I
> > was required to make edits to this track, which also involved cuts.
> > Interestingly, here I have an additional artifact: The rendered video (as
> > well as the preview) contains "lags", similar to if the real-time preview
> > gets stuck on some effects 
> > and slows down/distorts the audio - just in the final render.
> > 
> > This "lag" appears in renders created by Kdenlive (Ubuntu PPA), Kdenlive
> > (Appimage), and MLT CLI, so this might be an upstream issue.
> 
> Can you share your MLT command?

Fortunately ZSH remembered my command: melt video.kdenlive -consumer avformat:output.mp4

> Doing some debugging in another similar issue I saw that your artifacts might > be related to 60fps projects. What is your project profile?

This is quite interesting ... I used 1080p, 60FPS as preset.
Comment 26 farid 2021-03-08 22:23:00 UTC
(In reply to Ruman Gerst from comment #21)

> 
> This is quite interesting ... I used 1080p, 60FPS as preset.

Could you confirm that this isn't happening in say a 30fps or 24fps project?
Comment 27 Ruman Gerst 2021-03-08 22:41:09 UTC
Created attachment 136502 [details]
Audio artifact is not reproducible in 24 FPS

> Could you confirm that this isn't happening in say a 30fps or 24fps project?

I tried to cut the audio the same in two projects (60 FPS and 24 FPS). I could not get the 24 FPS project to make audio artifacts.

But I noticed something interesting: In the 24 FPS project, the rendered result contains still a part of the "uuuh" (very hard to notice, but it's there). With 60 FPS it's exactly at the time where the audio artifact happens.
Comment 28 Crone123 2021-04-21 23:54:53 UTC
Hello,
I confirm I also have the bug with videos profiles of 1080p 30fps (from my phone), and 1080p 50fps (camera).

My main usage of KDEnLive (at this time) is to sync the sound from the phone/camera with another better microphone, so it's really a problem for me too. I also cut the part of the sound before and after the video to have the same duration.

I have the problem on KDE Neon with all the latest updates.

KDEnLive version 20.12.3.

With 1080p 24fps, it seems to work, but it's not really good because I have better framerate in source files...

Thank you :)
Comment 29 emohr 2021-04-22 14:30:18 UTC
Do you have set variable framerate on your phone? Id so try with non-variable frame rate.
Comment 30 Crone123 2021-04-23 12:06:34 UTC
Hello,
No I have a constant 30fps video from my phone, and a constant 50fps video from my camera, no variable framerate :)