Discussion of reversing PAL speedup

From Free Knowledge Base- The DUCK Project: information for everyone
Jump to: navigation, search

I. You can use command line parameters to force a workable video player to compensate for PAL speedup, thus restoring the proper audio pitch and playtime duration.

VLC Player aka VideoLAN Player will easily accomplish this and has been able to for many versions to present. Example:

vlc -f videofilename.avi --no-audio-time-stretch --rate=0.96 --no-embedded-video --no-sub-autodetect-file vlc://quit 

If you install zenity on your linux system you can use the following shell script called [altplayer] which will give you a dialog and allow you to choose NTSC or PAL when launching VLC to play a video.

See Also: Compensate for PAL Speedup in Digital Video.

VLC can be made to correct for the speed and audio pitch problems introduced by crappy PAL video in multiple ways besides using command line parameters.

If you have VLC, here's how to fix it:

   Open VLC.
   Go to the 'VLC' menu and select 'Preferences…'
   In the radio buttons in the lower-left corner of the window, change 'Basic' to 'All'.
   Click on 'Input / Codecs' in the left-hand side list.
   In the right-hand side frame look for 'Playback speed' and change it to 0.96 (use a comma if your system uses that as the decimal separator).
   Click on 'Audio' in the left-hand side list.
   In the right-hand side frame disable 'Enable time stretching audio'.
   Click the 'Save' button on the lower-right corner of the window.
   Quit and relaunch VLC.

Here is a command line switch example using VLC:

"C:\Program Files\VideoLAN\vlc.exe" "c:\palvideo.wmv" --no-audio-time-stretch --rate=0.96

Question: Can a flag be set in the video file such as a tag in an mkv file to instruct a video player that it shall apply PAL speedup compensation?

Answer: Theoretically this is very possible. As to practical application it is unknown if any current video players or flag/tag standard exists to accomplish this. The digital video community has mostly tended to ignore this problem although something of the sort might exist by the time you read this.

II. You can re-encode or convert PAL speedup videos back to NTSC with the correct audio pitch and playtime.

There are different tools to accomplish this. There are also some side effects such as the introduction of slight jerkiness in video from things like duplicated frames depending on the process you use. The sample rate of the audio needs to be changed so the audio is stretched to the correct playtime. Then the video has to be stretched (which may involve the replication of frames) to match the audio runtime.

Stretching the audio so that the audio tract is at the correct pitch and total length in runtime involves the formula calculated by ((24000/1001) / 25) * 48000. Then the video can be stretched which involves extracting the video stream then a mux to put it back with the corrected audio stream. (1). Separate audio and video into 2 files. (2). process audio to correct pitch and runtime (3). process video to correct play length (4). mux correct audio and video into new file.

For the audio track the process is lossy. For the video track this depends on the software and method you use which may either introduce a slightly noticeable jerkiness in the video or some loss in quality.

From a video discussion forum a bash/shell script that uses ffmpeg:

ffmpeg -loglevel info -y -i "$file" -map 0 -c copy -c:a ac3 -filter:a aresample=resampler=soxr,asetrate=46033.92 -ar 48000 tmp.mkv
mkvmerge -o "$outfile" --default-duration 0:23.976fps tmp.mkv

In this person's example the change in video speed is lossless, only the metadata gets updated.

Here is another example:

ffmpeg -i input.mkv -filter_complex "[0:V:0]setpts=25/24*PTS[vout];[0:a:0]asetrate=46080,aresample=resampler=soxr:osr=48k[aout]" -map "[vout]" -map "[aout]" -r:v 24/1 -vsync vfr output.mkv

A new problem is introduced when you have subtitles. If the subtitle track has already been timestamped to match the PAL video, the subtitles will lose synchronization with the newly corrected video. This is especially troublesome with Forced Subtitles that are in their own track, like an srt embedded into an mkv file. If the track is forced subtitles you might find that editing the timestamps in the file by hand with a text editor your only remedy. This is less practical with a full line by line subtitle track. Additional software is required or a clever bash script involving regex.

III. You can adjust the audio pitch and ignore the faster playtime (not recommended).

The audio file is not stretched, but processed so that the pitch is decreased to match the original pitch of the sound. However, speech and audio will still be delivered faster than the original. Imagine the actor being perceived as delivering a line faster than the original and yet not sounding higher pitched, just seeming to talk faster. Human perception is not likely to notice the subtle time shift as long as the actor does not seem higher pitch in sound.