0000028: NTSC Audio Sync Incorrect When Exported

Notes
(0000054) el_jefe (reporter) 2007-10-31 16:25	I have the same uissue after using the work-around discussed in Bug 0023 (http://www.kdenlive.org/mantis/view.php?id=23 [^]). I have attached that .kdenlive project file also; I plan on creating a "test" movie as well which may better show the sync issue, but I kinda think the two bugs (0028 and 0023) are related. Maybe not tho since I don't have much of a clue. I am willing to provide any info needed, however.

(0000059) devvy (reporter) 2007-11-09 09:27	I have the same issue. I am living in a PAL country (Netherlands) but need NTSC since the clips from my Digital Camera (Fuji S6500fd) are in 30fps. I have also used the workaround in bug 0023, which works but the audio is now coming behind.

(0000115) linuxpaul (reporter) 2007-12-19 20:08	This should be a critical severity bug, as it not only makes the system unusable to anyone using NTSC, but is in the form of an ambush that presents itself only AFTER you've spent hours editing your project to perfection (because the sound is fine in the GUI), and then find it is un-renderable. If you absolutely MUST have something reasonably watchable. I have had some success with a lame work-around which speeds up audio from the VOB files created for DVD. It is NOT a complete work-around, but if you are reading this, you probably already have a project you need to render. If not, and you are using NTSC, you need to edit your video using something else until this bug is resolved. Work-around: Add 5% more video to the end of your project, render as "kdenlive_output.vob", and run these commands, replacing "<time-in-seconds>" and "<time>" with the appropriate values (e.g. for project with 10 minutes and 22 seconds of desired video (excluding the extra 5%), use "622" and "10:22" respectively): ffmpeg -i kdenlive_output_video.vob audio.wav sox -V audio.wav faster.wav speed 1.033 ffmpeg -i faster.wav -t <time-in-seconds> -ab 384 faster.ac3 mencoder -endpos <time> -nosound -o video.mpg -ovc copy -of rawvideo kdenlive_output.vob mplex -f 8 -o fixed.vob video-mpg faster.ac3 The resulting "fixed.vob" file should have watchably synchronized sound (for files up to 30 min anyway). You can tinker with the "1.033" value to speed up or slow down the audio, but for my 24 minute project it seems to be accurate to within +/- 0.0002

(0000119) raydude (reporter) 2007-12-26 20:04	I'd like to see this be given a higher priority. The output for the first clip works perfectly with the "MLT_NORMALISATION=NTSC kdenlive" work around, but each subsequent clip has the audio several seconds off. I love kdenlive. Its the first software I tried and every editor I've tried since this one failed to do an NTSC DVD for me has turned into a real disaster because the video clips are in MP4 MOV (kodak camera) and a lot of non-linear editors can't deal with the format. Cinelerra completely freaks over the format. I'm going to try to convert the videos using ffmpeg as a work around. But, just to reiterate. I'd really like to use kdenlive. Thanks, Brian

(0000138) ddennedy (developer) 2008-01-20 02:44	This is fixed in MLT SVN as of r1050. If you want to fix your copy without upgrading, locate src/modules/consumer_avformat.c, line 626, and change the int to a double: double fps = mlt_properties_get_double( properties, "fps" ); However, NTSC users might run into another problem with edit points not being interpreted correctly during rendering. This is documented in MLT's bug tracker: http://sourceforge.net/tracker/index.php?func=detail&aid=1875583&group_id=96039&atid=613414 [^]

(0000159) antlionking (reporter) 2008-02-19 17:50	On Feb. 17 I SVN'd the latest MLT and KDEnlive versions, compiled and installed, and it looks as though this edit point bug for NTSC still exists in MLT. The bug tracker linked to above indicates that the latest issue was resolved in r1051, but a short test render still shows audio/video sync problems. SVN tells me my version of MLT is r1074. My KDEnlive is at r1873. As I write this, I realize one thing that I didn't do is completely delete the previous MLT and KDEnlive installs. Should I have done this?

(0000163) ddennedy (developer) 2008-02-21 08:53	Did you load an old project or create a new one? If loading an old project, then did you confirm the edits in the timeline/monitor? If your project is not configured at NTSC, and you attempt to render at NTSC frame rate, then all the edits will be wrong. For example, the video.westley.kdenlive attachment to this bug has the video project setup as PAL. Can you attach a short .kdenlive demonstrating the problem?

(0000170) antlionking (reporter) 2008-03-04 06:34	Oops...sorry, but I've updated some libraries to my Fedora 8 install, broke my KDEnlive install, did an "svn up" on kdenlive/ffmpeg/mlt/mlt++, rebuilt everything (according to the recipe on the wiki), seemed to get everything straighened out again...only to find that KDEnlive locks up my mouse/keyboard/system/TheWholeBallOfWax when I try to render the timeline, right at the instant I click the "Export" button in the "Render Timeline" dialogue box. I'd send you the .kdenlive I've been working from but that timeline is 53 minutes long. I was hoping to create a special 3-minute test project for you, but wanted to be able to repeat my previous rendering results before I bothered you with it. I can tell you that the previously reported NTSC a/v sync issue was on an old project and that my job was definitely started as a DV-NTSC project. I can still open the project on the current KDEnlive build and play the timeline with no problems; I just can't attempt to render the timeline without a hard system lock (can only regain my system by hitting the hardware reset button). I figure that I must not have MLT or MLT++ built correctly. I'm thinking that there's an issue between where KDEnlive thinks my MLT install is and where it actually is. I'll keep trying to get a proper build of 0.6.0svn on my Fedora 8 but I'm also thinking that at this point it might be more productive for me to just look forward to the QT4/KDE4 version and help debug that instead. I've done several rebuilds of my current setup and am pretty well clueless as to what I've managed to mess up this time.

(0000908) madsdyd (administrator) 2008-11-08 20:09	This issue appears to have been fixed a while ago and/or It appears this bug was filed against the KDE3/qt3 version of Kdenlive. Due to a shortage of developers, this version is no longer supported (see http://www.kdenlive.org/news.php [^]), and this issue has been closed. If you believe this is an error, or can reproduce this issue using the KDE4/qt4 version of Kdenlive, please file a new report. If you have trouble building/obtaining the KDE4/qt4 version of Kdenlive, please consult http://www.kdenlive.org/compile [^] You may especially be interessted in the Kdenlive Builder Wizard, available at http://www.kde-apps.org/content/show.php?content=85826 [^] . Note, that you do not need to run KDE4 to build and run the Kdenlive KDE4 version.

Issue History
Date Modified	Username	Field	Change
2007-10-31 03:48	rushfan	New Issue
2007-10-31 03:48	rushfan	File Added: video.westley.kdenlive
2007-10-31 16:25	el_jefe	Note Added: 0000054
2007-10-31 16:25	el_jefe	File Added: Agents3_02.kdenlive
2007-11-09 09:27	devvy	Note Added: 0000059
2007-12-19 20:08	linuxpaul	Note Added: 0000115
2007-12-26 20:04	raydude	Note Added: 0000119
2008-01-20 02:44	ddennedy	Note Added: 0000138
2008-02-19 17:50	antlionking	Note Added: 0000159
2008-02-21 08:53	ddennedy	Note Added: 0000163
2008-03-04 06:34	antlionking	Note Added: 0000170
2008-11-08 20:09	madsdyd	Note Added: 0000908
2008-11-08 20:09	madsdyd	Status	new => closed
2008-11-08 20:09	madsdyd	Resolution	open => fixed

Relationships