Introduction. SyncView includes a very useful Wav Export Tool that can often reduce or eliminate the need to open additional applications during alignment work.
In this tutorial I will describe how SyncView can be used to quickly and effectively prepare audio files for frame-rate conversions. You should be able to extrapolate from this example and then bring the information to bear on other alignment projects, keeping in mind that a frame-rate conversion is just a special case of audio stretching. This is the same process that must often be used to resolve sync problems caused by corrupt or distorted audio programs.
Example Scenario. For this tutorial, let us suppose we have a short movie file that was originally produced at 24 FPS. Let us further suppose that we wish to re-produce this movie to play at 25 fps. There's a lot of work to do. First, the media must be edited and tested for 25 FPS, and then the new video and audio tracks will either have to be remuxed (to restore an AVI), or re-encoded (to restore an MPEG, for example). The SyncView software is designed specifically for the first part; applications like VirtualDub and MainConcept are needed for the second part. SyncView is not a video editor, but the Wave Export Tool does afford some clever audio-editing functions, as you will see soon.
At 24 fps, our original movie length is just over 4.5 minutes (exactly 270770 msec). After demuxing the audio and video streams, we find that the audio program is about 2.5 sec longer (exactly 273253 msec). The audio and video streams have slightly different lengths--a very common situation.
Note. The format of the extracted audio program must be WAV, MP3, MP2 or OGG; if it is something else (say, AC3), then you will have to use an audio-conversion application to create an uncompressed PCM WAV file. SyncView does not fully support many compressed audio types--and there is a good reason for this!
The Alignment Project. When the audio and video streams have different lengths, it is often the case that the base alignment is already off. In other words, if you were to play the two media files separately but simultaneously, the audio and video probably wouldn't match. Thus, we will begin this alignment project by loading both files into SyncView to determine what kind of correction is needed.
For our hypothetical project, the audio and video look and sound good when the Audio Sync setting is -126 msec. In other words, the audio should start 126 msec before the video begins. Another way of thinking about this is that the first 126 msec of audio are useless and should be cut from the movie! Indeed, that is generally the best way to restore base alignment: shift one stream relative to the other either by cutting samples or by adding blank samples (digital silence). In SyncView, either is ridiculously easy.
Continued (see Part 2 below) ...
+ Reply to Thread
Results 1 to 4 of 4
Open the Wav Export Tool and you will see that SyncView is already a few steps ahead. This figure shows several values listed in the Resizing panel, and I didn’t enter any of them. The 126 is from the Audio Sync adjustment I set earlier. The 270770 is the exact video length, and the 2483 is the difference between the video length and the audio length. We’ll first instruct SyncView to trim the leading audio samples, as this is all that is required to restore perfect base alignment.
If we weren’t modifying framerate we could click Run Tool at this point, and in less than 30 seconds our alignment work would be complete. It often isn’t necessary to match playback length, but it is necessary here because the audio must be resized and re-sampled. This second figure shows that SyncView has correctly updated the difference amount to 2357—it was 2483 before we clicked on the first option, remember? If we remove 126 msec from the start of the audio, then fewer samples need to be cut from the end to reach our target length of 270770 msec.
Clicking on the Match video length option forces us to then choose a method of resizing. We are still doing simple resizing (trimming/padding). Stretching the audio at this point is a BIG mistake, because the audio is still longer than the video! Our new movie is going to have a shorter running time at 25 fps. If the present audio is compressed to this shorter time, it will actually be under-compressed because it is missing about 2.5 seconds of material--and that missing material cannot be resized.
The Lock end adjustment switch is relatively new and very important. It basically cuts our work time in half. It will lock the “2357” value (in this particular example) so that we can enter a second target length. This second length will be our new, 25 fps time. Without this lock, SyncView automatically re-calculates and enforces a new difference value whenever the textbox changes.
If we run the WAV Export Tool now, we will end up with a perfectly aligned and perfectly sized WAV file… for the original video stream. However, the goal of this project is to change the video framerate. The new video will run a bit faster, and so the audio must run equally faster, too.
Because we have instructed SyncView to construct a perfectly aligned and perfectly sized starting file, we can be confident that the re-sampling method of resizing will be successful. Some quick calculations reveal that our final target length is exactly 259960 msec, which we can now enter as our new video length.
Figure 7 shows the final configuration, in which the re-sampling method is selected for the second resizing operation. SyncView has taken care of the more difficult calculation. For typical 44.1kHz playback, it is necessary to re-sample the audio at 42.3kHz.
When in doubt, click on the new Details button to check your settings. The entire export operation is described simply and clearly. This figure confirms our previous steps. You can now click Run Tool, and after 15 or so minutes (with typical movie-length files), you’ll be ready to begin restoring your movie file.
Excellent guide and I had almost 'got it' until step seven.
Changing the 'Match video length' to a new number is required, but how that number is arrived at escapes me.
That new number refers to the running time of the movie *after* the framerate change: Movie length (secs) = N frames / FPS. Maybe it is confusing because the article doesn't specify how many frames are in the hypothetical movie (and there might be some minor rounding error).