View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000228KdenliveEffectspublic2008-10-19 21:112008-11-12 22:28
Assigned To 
PlatformOSOS Version
Product VersionRecent git 
Target Version0.7.0Fixed in Version0.7.0 
Summary0000228: audio crossfade between different cutted parts of the same clip produces cracking noise
Description1. put a clip on the timeline (track 1)
2. cut the clip 2 times --> you got 3 parts
3. delete the 2nd part
4. move the 3rd part to second track a bit below the first part
5. create a crossfade between the clips with fade-out on first part and fade-in on third part

So you will get cracking noise when playing in preview and also after rendering.

Crossfade between different clips works fine.
TagsNo tags attached.
Build/Install Method
Attached Files

- Relationships

-  Notes
repli2dev (reporter)
2008-10-20 09:27

I have same problem, I did some research about it. So my perceptions:

0. Problems do not depend on audio frequency
  1. Two diffrent clips
  2. Two same clips added to project list twice (first to first track, second to second track)
  1. With 0.6svn version on Kubuntu 8.10 32bit
  1. 0.7svn on Kubuntu 8.10 64 bit, OpenSuSE 11.0 (up-to-date)
  1. with soundcards (tested on two computers with three soundcards)

So, now I suppose it is problem in newest Kdenlive or using 64bit. If you want to test more let me know.
(I suggest to make this bug blocking 0.7 version, because I think it is very serious problem)
doitux (updater)
2008-10-20 15:53

If this is an MLT issue should i place a bug report on MLT mailing list?
repli2dev (reporter)
2008-10-20 17:06
edited on: 2008-10-20 17:07

No, It appears as problem of Kdenlive because the script (taken from MLT demo) renders OK (the Aym8_S3BXKw.flv is from youtube).

/home/jan/bin/bin/inigo \
"+voice over demo.txt" \
                font="Sans Bold 72" \
                fgcolour=0x00000000 \
                bgcolour=0xff9933aa \
                pad=10 \
-track Aym8_S3BXKw.flv \
-track Aym8_S3BXKw.flv out=149 Aym8_S3BXKw.flv \
-transition \
        mix:0.0 \
        end=0.6 \
        in=75 \
        out=99 \
        a_track=2 \
        b_track=1 \
-transition \
        mix:0.6 \
        in=100 \
        out=299 \
        a_track=2 \
        b_track=1 \
-transition \
        mix:0.6 \
        end=0.0 \
        in=300 \
        out=324 \
        a_track=2 \
        b_track=1 \
-transition \
        composite:0%,80%:100%x20% \
        distort=1 \
        in=100 \
        out=299 \
        a_track=2 \
        b_track=0 \

madsdyd (administrator)
2008-10-20 22:06

I can confirm this issue, although the issue did not exist with the first clip I tried. So, trying different clips may be neccesary.
administrator (administrator)
2008-10-25 14:23
edited on: 2008-10-25 18:26

This problem is due to a bug in MLT. In fact, having the same clip overlapping on two different tracks is enough to reproduce the problem.

It looks like this is not easily fixable in MLT, see quote from Dan Dennedy:


Hmm, yeah, this is a big problem with the design of the framework and
 the avformat producer (and vorbis producer). The audio is demuxed
 and/or decoded by packets which contain sample counts that do not
 correspond to the video frames. Therefore, the producers decode the
 audio into a temporary buffer that might be larger than what the
 mlt_frame_get_audio() requests. In that case, it first uses the
 overflow for the next request if no seeking is required. When the
 transition requests the audio from the same producer twice (A and B
 frames), this temporary buffer gets used and creates all sorts of
 problems with alignment/synchronization. This is not proving easy to
 fix in the least; even hacks have proven unsuitable thus far.
 Interestingly, the libdv producer does not suffer this problem because
 it supplies the audio that is embedded into each DV frame and does not
 use an overflow buffer.

I think I have an idea to work around it in Kdenlive, but it will require some rather important changes...

jmpoure (developer)
2008-11-01 13:48

Resample all transitions to the higher rate? Anyway this should not block Kdenlive release ... This is only 0.7.0. Then we can release 0.7.1, etc ... It is important to release very often.
jmpoure (developer)
2008-11-01 14:02

Tagging it for 0.7.1.
doitux (updater)
2008-11-01 18:02

On 2008-10-31 in rev 2605 jb already added the workaround.
Here is the corresponding mail --> [^]

Just because it also belongs to this bug-topic i will add a comment about (maybe) a side effect of this big changes here:

What i do is following:

1. Add a clip to track 1
2. Cut the clip two times
3. Remove the second part
4. Place the third part on track 2 overlapping the end of the first part
5. Add a fadeout effect on the end of the first part with the green blinking
clip indicator
6. Add a fadein effect on the beginning of the third part with the green
blinking clip indicator

This should look like this: [^]

When playing this crossfade you will hear at the fadein on track 2 that the
volume is on 100% for a few frames. Then suddenly it goes to 0% and slowly
fades in. --> [^]

Can anybody reproduce this?
madsdyd (administrator)
2008-11-05 11:57

doitux, could the problem you describe be the same as [^] ?

jb har committed a fix for 307, I have just not had the time to test it. (Yes, I know, excuses, excuses). Could you perhaps test it, see if the svn rev 2622 fixes these problems (it should actually fix 228, 307 and "most of" 188).
doitux (updater)
2008-11-06 00:56

madsdyd, no it is not 307 related. 307 is fixed in svn rev 2624 here.
But you are right, this bug 228 is also fixed in svn rev 2624.
My comment 800 was just about maybe a side-effect coming with the changes for 228 bugfix. maybe i will open a new report for this.
administrator (administrator)
2008-11-06 23:42

Ok everyone, I found the bug responsible for problems described in comment 800. It is a bug in the MLT volume effect. I have a fix ready, but am currently waiting for Dan's opinion on the matter.
administrator (administrator)
2008-11-07 09:38

Fixed now in MLT svn, I think we can now completely close the bug...
madsdyd (administrator)
2008-11-08 18:55

Tested with Kdenlive 2636 and MLT 1227 - everything works as expected.

- Issue History
Date Modified Username Field Change
2008-10-19 21:11 doitux New Issue
2008-10-20 09:27 repli2dev Note Added: 0000476
2008-10-20 15:53 doitux Note Added: 0000481
2008-10-20 17:06 repli2dev Note Added: 0000482
2008-10-20 17:07 repli2dev Note Edited: 0000482
2008-10-20 22:06 madsdyd Note Added: 0000494
2008-10-20 22:06 madsdyd Status new => acknowledged
2008-10-23 00:26 madsdyd Target Version => 0.7.0
2008-10-25 14:23 administrator Note Added: 0000689
2008-10-25 14:23 administrator Severity minor => major
2008-10-25 14:24 administrator Note Edited: 0000689
2008-10-25 14:24 administrator Note Edited: 0000689
2008-10-25 14:26 administrator Note Edited: 0000689
2008-10-25 14:28 administrator Note Edited: 0000689
2008-10-25 14:32 administrator Note Edited: 0000689
2008-10-25 14:34 administrator Note Edited: 0000689
2008-10-25 18:26 administrator Note Edited: 0000689
2008-11-01 13:48 jmpoure Note Added: 0000793
2008-11-01 14:02 jmpoure Note Added: 0000795
2008-11-01 14:02 jmpoure Target Version 0.7.0 => 0.7.1
2008-11-01 18:02 doitux Note Added: 0000800
2008-11-05 11:57 madsdyd Note Added: 0000808
2008-11-06 00:56 doitux Note Added: 0000815
2008-11-06 23:42 administrator Note Added: 0000846
2008-11-07 09:38 administrator Note Added: 0000851
2008-11-08 18:55 madsdyd Note Added: 0000892
2008-11-08 18:55 madsdyd Status acknowledged => closed
2008-11-08 18:55 madsdyd Resolution open => fixed
2008-11-08 18:55 madsdyd Fixed in Version => Recent git
2008-11-12 22:22 madsdyd Fixed in Version Recent git => 0.7.0
2008-11-12 22:28 madsdyd Target Version 0.7.1 => 0.7.0

Copyright © 2000 - 2016 MantisBT Team
Powered by Mantis Bugtracker