I predict that this isn't a problem with the program as much as a problem with how it is responding to your content. Use the audio waveform scope to see if your audio is being clipped during the loud parts. Try applying the gain, compressor or limiter filters to see if you can reduce the clipping during loud sections.

Also, do not judge the audio using Shotcut as it is not the best player and known to have some audio continuity issues during playback on some systems.
Please use another tool to simply transcode one of your clips and see if it gives similar results.

Thank you for your fast replys.
I did not see any clipping in the waveforms, although I have to say, that I don't really know, how this looks like. But what I have noticed is, that if I play the movie from Shotcut's playlist, the audio will be correct - no crackling. If I play the clip from the timeline though, it does crackle! The waveforms looked similar to me in both cases.
I have tried the different filters and none of them seemed to solve the crackling.

I have just uploaded two videos, one was transcoded with Shotcut and the audio is crackling and the other one was transcoded with Handbrake with an AC3 passthrough. You will have to turn the volume up a bit to really here the crackling.

PS: I judged the videos with VLC before. The files are named shotcut_export_crackles.mp4 and Handbrake_export_fine.m4v. I hope, I am doing right, since I did not find any sharing link to the files.

I got the file. I hope to take a look at this in the next few days.

I have downloaded both files. I can hear a very subtle ticking sound after the cars have gone by in shotcut_export_crackles.mp4. I do not perceive the same ticking sound in the Handbrake_export_fine.m4v so I assume that I am hearing the "crackling" sound that you describe. I didn't not expect it to be so subtle.

Can you also provide the original source file (not transcoded by Shotcut or Handbrake) so that I can try to reproduce the issue?

The handbrake file is useless since it was pass-through and not transcoded.
Of course we need the original file.

On Wed, Jun 15, 2016, 7:58 PM Brian Matherly notifications@github.com
wrote:

I have downloaded both files. I can hear a very subtle ticking sound after
the cars have gone by in shotcut_export_crackles.mp4. I do not perceive the
same ticking sound in the Handbrake_export_fine.m4v so I assume that I am
hearing the "crackling" sound that you describe. I didn't not expect it to
be so subtle.

Can you also provide the original source file (not transcoded by Shotcut
or Handbrake) so that I can try to reproduce the issue?

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#259 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABF_O6giIsW3BIGygBBbYlIKsT7UM8XNks5qMLvngaJpZM4I1sjn
.

Actually, if the handbrake one was really pass-through then we do have the
original audio to put through shotcut ourselves.

On Wed, Jun 15, 2016, 8:07 PM Dan Dennedy dan@dennedy.org wrote:

The handbrake file is useless since it was pass-through and not
transcoded. Of course we need the original file.

On Wed, Jun 15, 2016, 7:58 PM Brian Matherly notifications@github.com
wrote:

I have downloaded both files. I can hear a very subtle ticking sound
after the cars have gone by in shotcut_export_crackles.mp4. I do not
perceive the same ticking sound in the Handbrake_export_fine.m4v so I
assume that I am hearing the "crackling" sound that you describe. I didn't
not expect it to be so subtle.

Can you also provide the original source file (not transcoded by Shotcut
or Handbrake) so that I can try to reproduce the issue?

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#259 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABF_O6giIsW3BIGygBBbYlIKsT7UM8XNks5qMLvngaJpZM4I1sjn
.

Hmmm. Yes, I think I am able to reproduce the problem with Handbrake_export_fine.m4v

@notusedyet do you reproduce the problem with Handbrake_export_fine.m4v?

I suspect the MLT mix transition with combine=1, but not sure what can be
done.

On Wed, Jun 15, 2016, 8:21 PM Brian Matherly notifications@github.com
wrote:

Hmmm. Yes, I think I am able to reproduce the problem with
Handbrake_export_fine.m4v

@notusedyet https://github.com/notusedyet do you reproduce the problem
with Handbrake_export_fine.m4v?

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#259 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABF_OzzBiFa1vQpVeh5ooXpd45uoJdJLks5qMMFEgaJpZM4I1sjn
.

I think we have a frame dropping problem. When I compare the audio (exported to Audacity) between the two clips, the Shotcut export is shorter (100ms fewer audio samples) and I see discontinuities in the waveform (where the waveform has a sharp vertical line connecting one sample to another sample). These discontinuities do not exist in the handbrake file. Perhaps the PTS values in the source file are causing seeking problems and therefore frames (or maybe samples) are being dropped.

Interesting. Is there anything that I can do about it? Or will I have to wait for a fix?
Yes, I can reproduce it with the Handbrake encoded file. I have uploaded the original file "00191.MTS".

I will have to do some more investigation before I can suggest a workaround. You could try transcoding the audio to see if re-encoding it works-around the problem.

Today I took another look at this. Previously, I could only reproduce the crackling when the clip was in the timeline but not when it was in the source tab. Today I have just the opposite problem: I can reproduce the crackling in the source tab, but not in the timeline.

Previously I was suspicious of the mix transition - thinking that a buffer might be overflowing. But I put in some debug messages and I never see an overflow. Plus, the mix transition is not used when playing from the source player.

I think the next step would be to look in the avformat producer.

When compiling MLT on OS X with clang, I saw this compiler warning. Yes, it is in the mix transition, but maybe this warning could apply in other situations:

URCE=1 -D_THREAD_SAFE   -c -o transition_mix.o transition_mix.c
transition_mix.c:60:57: warning: implicit conversion from 'double' to 'int16_t' (aka 'short') changes value from 32768 to 32767 [-Wliteral-conversion]
                        buffer_a[ i * channels_a + j ] = CLAMP( v, -32767.0, 32768.0 );
                                                       ~                     ^~~~~~~
../../framework/mlt_types.h:190:66: note: expanded from macro 'CLAMP'
#define CLAMP(x, min, max) ((x) < (min) ? (min) : (x) > (max) ? (max) : (x))
                                                                 ^~~

I really appreciate that you guys spend your time on this.
(Especially, because my HDD is continuously being flooded with new videos. ;-D)

I haven't been able to make progress on this. I've unassigned it from myself.

I have recently switched to Ubuntu (Elementary OS respectively) and the problem is still there.
As a temporary replacement for Shotcut I tried out Kdenlive which uses the MLT Framework too and that did not have the same issue. So possibly the problem is not the MLT Framework, but something specific to Shotcut.
Also, if I only drag one single video file (MTS) into Shotcut's timeline without doing any editing to it and export my "movie", I get the annoying crackles as well. Of course the source file is OK again.
If I open a blank project in Shotcut and just add a bunch of videos to the playlist but NOT to the timeline and export the playlist, everything is just fine.

Strangely, I can play Shotcut generated .mlt-project files (timeline used) from the Kdenlive playlist and I get the same problem with Kdenlive. A can also add the whole movie in it's .mlt-form to Kdenlive's timeline and export it. As you would expect, the crackling audio persists.

=> Something, somewhere went wrong with this timeline. :-(

(Since the audio is actually more important than the video in my case, this really hurts me badly. Please, take another look at this.
Unfortunately I'm not totally satisfied with Kdenlive, so I am still trying to hang on with Shotcut.)

I am only able to reproduce this problem with the files that you provided. I have many other files that work fine. So this problem is specific to the files you are using. It is unlikely that I will make this issue a priority (unless someone wants to hire me).

Have you tried transcoding the files to an intermediate lossless format like DNxHD? I would expect that everything will work fine with transcoded files - and it would be a very simple work-around.

Well, I can understand that.

Thank you for the tip to transcode the files. I have not tried it yet. If that works, I'll be happy.

I have the kind of reverse of this. When I have quiet classical music playing in the background of a video, the pianos create a sort of low crackling sound, that's not in the original file. Would this be related to this issue somehow?

If you listen carefully around 20 seconds+, the crackling starts. It's super annoying, and if you aren't listening on headphones, you probably won't hear it, but I'm a sound engineer also, and I hear these things until they annoy the heck out of me.

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

(Yes, you do need to crank the volume up loud to hear it)

Yep, sounds rather the same. But it is even more subtle than the noises I had.

Referring to my previous post: Transcoding the files to DNxHD, reencoding the videos with x.264 or demuxing the audio, converting it to AAC and remuxing it into the video again did not work.
I will now work on with Kdenlive, which does work, but hasn't got such advanced export options and making transitions is near to torture.

Interesting. For the record, I am using Windows 10 x64 and Shotcut 16.07.01 currently on this machine.

I would like to see this fix, because a few clients have complained about crackling issues, which I originally didn't even notice until I went back to listen to them. It's a deal breaker, because some of the projects I produce, have quieter parts, and I'm huge in the dynamic range area (I want spoken dialog in a movie to sound normal, but explosions to blow you out of the chair). For this people have to turn up their amp, and yes, they are hearing the crackling issues.

notusedyet, I bet this is more audible like yours: https://www.youtube.com/watch?v=kdBpghE-BAE

Especially at the end with the slow motion.

That crackling just isn't acceptable anymore.

@notusedyet Interesting to hear that Kdenlive does not give you the problem when we are both using MLT and FFmpeg with the same code for decoding, mixing, and encoding.

Related issue: mltframework/mlt#124

@lnx64 Are you comfortable with editing XML files in a text editor? It would be interesting for you to edit one of your project files (make a backup copy of it first), locate every <transition> that has a child <property name="mlt_service">mix</property>", and add child <property name="disable">1</property> to see if that eliminates the problem. It will disable all audio mixing; so best to use a project that does not depend on it. This will help confirm the general source of error.

If that removes the problem, another test is to remove the <property name="disable">1</property> lines you added and then change <property name="combine">1</property> to have the value 0 instead of 1.

I do not have good hearing and struggle to hear or read this (Audacity waveform) to run these tests myself and determine if they make a difference.

@ddennedy Not to worry, I'll do whatever tests you need done. I am quite comfortable editing XML. I did as you recommended, and here are the results.

Using the disable 1 property, yielded NO crackly parts in the audio, and clears it up perfectly.
Removing that child, and changing combine to 0 also has no crackly parts in the audio, but the volume is not as loud. (It's not as drastic of a volume change, but it's noticeable).

That is the same conclusions my daughter came to. When I make a changes I will rely upon her to provide testing feedback. Assuming I can figure it out, I will post a nightly build that contains a hopeful fix for additional testing by people here.

I experienced the same issues when rendering videos of my kids' piano performances in kdenlive; after some time I noticed an unpleasant crackling distortion after nearly each tone. It almost made me switch from Linux environment to Windows for editing of my home videos as the sound degradation is unacceptable. I am so grateful to you guys for finding out the cause and posting the XML-editing workaround. It works perfectly for me, too. I can't wait until the proper fix is released.

@ddennedy: It is quite weird, yes. But Kdenlive (v0.9.6, Ubuntu 14.04, little old) works, Shotcut does not. I am using transistions for both, video and audio and since that is probably the only "editing" I am doing to my videos, I have to rely on that.
I am glad that this is now brought to life again!

I wonder if you two are using two different versions of Kdenlive? balevas and notusedyet are both using Kdenlive, but have two different results. Hmm..

@lnx64: this is most likely because we're both using so much different versions. I am on Arch Linux, using the latest released versions: kdenlive 16.08.1-1, mlt 6.2.0-1. In contrast, notusedyet uses 2 years older software.
Yes it is strange that if both Shotcut and kdenlive depend on mlt even in versions used by notusedyet, one app works for him while the other doesn't. Perhaps we could compare the mlt scripts generated for a mutually agreed scenario by my and his versions of kdenlive, to find out the difference.

As I suspected, the problem is in the mixer's "combine" method, as shown here:
https://github.com/mltframework/mlt/blob/master/src/modules/core/transition_mix.c#L66

In particular, see the comment "uses an inline low pass filter to allow mixing without volume hacking", line 72 "double B = exp(-2.0 * M_PI * Fc);" and line 87 "v_prev[j] = buffer_a[ i * channels_a + j ] = v * A + v_prev[j] * B;"

This represents an odd technique that can be described as a "quick and dirty" solution to the problem of attenuation with the simpler but more recommended method of summing with averaging. See the links below for details. Without "combine=1" (which is what this change does), we resort back to the simple method that results in some softening of the dynamics, and people will have to apply audio filters to compensate where needed.

http://dsp.stackexchange.com/questions/3581/algorithms-to-mix-audio-signals-without-clipping
http://www.voegler.eu/pub/audio/digital-audio-mixing-and-normalization.html