OpenShot Video Editor

Timing problem with modified WAVE file

Asked by wboe

Hi,
If a project contains a clip from a WAVE file, and this file is modified afterwards (using another tool), then the timing of clips that follow this sound clip is wrong. The visual apearance of the clips do not match the audio anymore. The only remedy appears to be to remove the WAVE file from the track and from file list, and then re-import it. This is not nice.

As an additional question: why is the message "Estimating duration from bitrate, this may be inaccurate" sent to the screen so often, and what is the user supposed to do? A WAVE file is containing the number of frames that are present in a track, so I don't see the problem.

Regards,
wboe

Question information

Language:
English Edit question
Status:
Solved
For:
OpenShot Video Editor Edit question
Assignee:
No assignee Edit question
Solved by:
Olivier Girard
Solved:
Last query:
Last reply:
Revision history for this message
Olivier Girard (eolinwen) said : 		#1

Hi,

What is your version of MLT ? and on which system are you ? (Ubuntu, Debian, Arch, Opensuse,..........................)

You should try to update your version of MLT, it could resolve this.
Currently, we assist at a lot of bug on features which have not given some issues or thoses were resolved since a long while.

Another track is about "inaccurate". Perhaps, your tool audio conversion gives you not a "good" file. At first look the bitrate can not be calculated. What give you an output with some tools like ffmpeg, tcprobe or mediainfo ?

Thanks.

Revision history for this message
wboe (w-boeke) said : 		#2

Hi Cewen,
Thanks for the answer.
My MLT version is the newest: 0.7.6. As I pointed out in an earlier post this solved some problems, but not all.

The problem with audio files is yet worse then I mentioned: most (or all) formats generate the warning message "Estimating duration from bitrate, this may be inaccurate", and indeed, it is. I had to stretch a wave file about 0.3% in order to make it track the video more or less. The result is that my YouTube video http://www.youtube.com/watch?v=35hGLGZxjx0 does not look very professional.

> Another track is about "inaccurate". Perhaps, your tool audio conversion gives you not a "good" file.
> At first look the bitrate can not be calculated. What give you an output with some tools like ffmpeg,
> tcprobe or mediainfo ?

About the quality of my wave files: I used 'file' to get information about my wave files. Two examples:
=> file fbam_rhodes.wav
fbam_rhodes.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 44100 Hz
=> file l-boos-ohs-103.wav
l-boos-ohs-103.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 32 bit, mono 22050 Hz

This looks correct, does'nt it? I do not understand why you stated "the bitrate can not be calculated", because this is specified in the header of every wave file, together with the exact number of frames.

As an aside: the correlation between "what you see" and "what you hear" can be very bad in OpenShot. In a small test project, video's appear in the video window that are not present in the tracks, and audio can be heard in advance of the moment that the timeline in the tracks has arrived at the corresponding clip. Maybe it's useful to create a small button labeled "Recalculate everything"?

Another aside: my computer is not very big or fast, but the rendering if audio sometimes is horrible (many sound gaps). The CPU usage is 100%, and stays at about 95% after OpenShot got idle. Might it be true that the use of python is responsible for all this, or is the scripting language used only for administrative functions?

Regards,
wboe

Revision history for this message
Best Olivier Girard (eolinwen) said : 		#3

>>My MLT version is the newest: 0.7.6. As I pointed out in an earlier post this solved some problems, but not all.
You should try to update at the last (yesterday evening) 0.7.7. Not yet tested.

>>About the quality of my wave files: I used 'file' to get information about my wave files. Two examples:
I don't know this command. Anyway, My preferred application is Mediainfo because she is the most complete than the both other.

>>This looks correct, does'nt it? I do not understand why you stated "the bitrate can not be calculated", because this is specified in the header of every wave file, together with the exact number of frames.

You said "As an additional question: why is the message "Estimating duration from bitrate, this may be inaccurate" sent to the screen so often, and..."

So I conclude that the bitrate is not well calculated. What give you this FAQ with this Audio file ?
https://answers.launchpad.net/openshot/+faq/983
Like this we will know better (I hope :-()

>>As an aside: the correlation between "what you see" and "what you hear" can be very bad in OpenShot. In a small test project, video's appear in the video window that are not present in the tracks, and audio can be heard in advance of the moment that the timeline in the tracks has arrived at the corresponding clip. Maybe it's useful to create a small button labeled "Recalculate everything"?
This problem comes from MLT and SDL. All the audio issues will be resolved with our future new own librairy : libopenshot.

>>Another aside: my computer is not very big or fast, but the rendering if audio sometimes is horrible (many sound gaps). The CPU usage is 100%, and stays at about 95% after OpenShot got idle. Might it be true that the use of python is responsible for all this, or is the scripting language used only for administrative functions?

To this side, we are working on this point and the solution will come of our new own librairy : libopenshot.

Regards.
Olivier

Revision history for this message
wboe (w-boeke) said : 		#4

Thanks Cenwen, that solved my question.

Revision history for this message
wboe (w-boeke) said : 		#5

Hi Oliver,

That was not me, saying "Thanks Cenwen", I just hit the 'problem solved' button. My real answer was:

Thanks for your answers. I learned from them that ffmpeg simply ignores the specified number of frames in the header of an audio file, but instead sends uninformative messages to the screen. I'm looking forward to libopenshot!

wboe

Revision history for this message
Olivier Girard (eolinwen) said : 		#6

In fact, it is MLT who commands at FFmpeg to ignore the specified number of frames in the header of an audio file.