On Monday 15 September 2003 23:53, Jason Wood wrote: > > The other option is to keep the original samplerate and put it into an > > seperate audio track in the .avi file. Actually I would rather use .ogg > > instead of .avi, but both should be working in a while. > > For video editing, would not a seperate .wav be better? The size of the > audio compared to the size of the video is tiny, so the compression of ogg > does not buy us very much, wavs are non-lossy, and an advantage (that holds > for ogg as well, but not really avi) is that you can open up the file in a > dedicated sound editor to tweak it.
Ogg is not an audio format, it's a container format, much like AVI. You can put all kinds of stuff inside Ogg files. The audio ".ogg" files usually use the Vorbis codec. Hwne I say Ogg, I am speaking of video. .wav is already implemented, just try to play any .wav file. I use libsndfile I probably automatically support most of the hundreds of .wav formats. > There is some work already in place for supporting separate audio tracks - > at the least, the timeline can display tracks of different types, and there > is a sound track class. However, they were put in place very early on so > may need some work to get up to speed - my main thought is that there is > probably no detection as to whether a clip can be placed in a video track > or an audio track. Sure, when asking for a file, piave answers not only the duration, but also the container format, and audio, as well as video codec format. A file without detected video codec is an audio file. > So yes, it will require some work, but probably not as much as if it had > not been anticipated in the first place. Well, I was more concerned with the handling of the two parallel audio streams. One from the video file, one from the audio file. We can in principle define a default operation, but in principle we need to have to give the user the choice between various 'effects', e.g. 'replace' or 'mix' etc. > I am doing these changes on my local machine. Cvs HEAD is still what I hope > to become the Kdenlive 0.2.3 version. I have sorted out the issue with > Kdenlive firing too many scenelists at piave ;-) (committed to CVS now) and > I am happy with what Kdenlive is at the moment for a tarball release. What > would you say is the best plan of action? I think with a lot of the changes > going into Piave now, it is going to take some time before Kdenlive catches > up, and a stable release now is a good idea before starting. What do you > think? If you think the current memory leaks in piave are at an acceptable level, I am fine with it, if not, then I need some time. Cheers, Rolf -- contacts: www.physi.uni-heidelberg.de/~dubitzky
