48 kHz vs 44.1 kHz: Sample Rate for Video Editing

Why is 48 kHz the video standard?#

Sample rate is the number of audio samples stored per second, measured in hertz: 48 kHz means 48,000 samples for every second of sound (see sample rate in the glossary). Video projects run at 48 kHz; convert a 44.1 kHz file once rather than mixing rates on the timeline. The 48 kHz rate is also what YouTube Help lists for uploads, while 44.1 kHz (44,100 samples per second) remains the CD rate.

The reason is arithmetic. At 48 kHz every common frame rate gets a whole number of samples per frame: 2,000 at 24 fps (48,000 / 24), 1,920 at 25 fps, 1,600 at 30 fps and 800 at 60 fps. At 44.1 kHz, 25 fps and 30 fps divide evenly (1,764 and 1,470), but 24 fps gives 1,837.5 samples per frame (44,100 / 24), so every second frame boundary falls between two samples.

At 48 kHz even 29.97 fps, at 1,601.6 samples per frame (48,000 x 1.001 / 30), lines up again every 5 frames at 8,008 samples.

YouTube asks for the same rate. As of September 2026, the YouTube Help upload recommendations list a 48 kHz sample rate for audio in AAC-LC, Opus or Eclipsa Audio. For the codecs themselves, see the hub on codecs and formats for editing YouTube footage.

Which sample rate does YouTube audio use?#

As of September 2026, YouTube does not publish the sample rate of the streams you download, so read the rate from each file instead of assuming it. The 48 kHz in YouTube Help is what creators should upload; the stream you download is YouTube’s own encode of that upload.

YouTube serves more than one audio stream per video, and the stream yt-dlp picks decides whether your editor has to resample. Measured values per stream, with the codecs and bitrates, are collected on YouTube audio quality explained: Opus, AAC and bitrates.

The table lists the sources an editor usually mixes in one timeline, their typical rate and what to do with each in a 48 kHz project.

What happens when you mix 44.1 kHz and 48 kHz on one timeline?#

A 44.1 kHz clip on a 48 kHz timeline usually plays correctly, because DaVinci Resolve, Premiere Pro and Final Cut Pro resample it to the project rate as they play and export. The trouble starts when a clip’s samples are played at the wrong rate instead of being resampled.

The size of that error is fixed by the two rates. Play 44.1 kHz samples at 48 kHz and the clip runs 8.8 percent fast (48,000 / 44,100 = 1.088), 1.47 semitones sharp (12 x log2 of 48,000 / 44,100), and a 60-minute track ends after 55.1 minutes (60 / 1.088). Play 48 kHz samples at 44.1 kHz and the clip runs 8.1 percent slow (44,100 / 48,000 = 0.919) and flat.

Slow drift is a different symptom with different causes. An 8.8 percent error is audible within seconds, while a sync slip that grows over minutes points to a small speed change: a 0.1 percent pull-down (1,000 / 1,001, the 29.97 fps factor) slips 3.6 seconds per hour (3,600 x 0.001). Variable frame rate video and MP3 timing can also slip; the MP3 side is compared in MP3 vs WAV vs FLAC for video editing.

How do you check a file’s sample rate?#

Check the sample rate in three places: yt-dlp’s format list before you download, ffmpeg’s stream line after you download, and your editor’s clip information after import. B-ROLL’s card shows the real bitrate of an audio file, for example 160 kbps, but not its sample rate.

Before a download, yt-dlp lists every stream of a video with its audio sample rate in the ASR column:

yt-dlp -F "https://www.youtube.com/watch?v=VIDEO_ID"

After a download, ffmpeg prints each stream with its rate in Hz. B-ROLL keeps its own copy of ffmpeg in %LOCALAPPDATA%\Broll, so this works without a separate install. If an ffmpeg was already on the Windows PATH when B-ROLL first launched, B-ROLL uses that one instead: type ffmpeg in place of the full path.

& "$env:LOCALAPPDATA\Broll\ffmpeg.exe" -hide_banner -i "C:\Audio\track.m4a"

Look for the Audio: line, which names the codec and the rate, such as 48000 Hz or 44100 Hz. The closing note that no output file was given is expected with -i alone. If you have ffprobe installed, the ffprobe documentation describes -show_entries for printing only the rate:

ffprobe -v error -select_streams a:0 -show_entries stream=sample_rate -of default=nw=1:nk=1 "C:\Audio\track.m4a"

In DaVinci Resolve, select the clip in the media pool and read its sample rate in the Metadata panel or in Clip Attributes.

How do you fix a 44.1 kHz and 48 kHz mismatch?#

The fix is one rule: set the project to 48 kHz before you import media, and convert every 44.1 kHz file to 48 kHz once, before it reaches the timeline. Then check sync at the end of each long clip, not only at the start.

The ffmpeg documentation and ffmpeg -h list -ar as the option that sets the audio sampling rate in Hz. This command converts a 44.1 kHz track into a 48 kHz, 16-bit WAV:

& "$env:LOCALAPPDATA\Broll\ffmpeg.exe" -i "C:\Audio\track.m4a" -ar 48000 -c:a pcm_s16le "C:\Audio\track_48k.wav"

16-bit PCM is enough for a lossy YouTube source: the stream holds less detail than 16 bits can store, so a 24-bit WAV is 1.5 times larger (24 / 16) with no added detail. B-ROLL uses the same format for the audio inside its ProRes and DNxHR files, uncompressed 16-bit PCM.

To get downloaded audio in an editing format in the first place, B-ROLL saves YouTube audio as MP3, M4A, WAV, FLAC or OPUS; the options are on extract audio from YouTube for video editing. If a clip still plays fast or slow after conversion, work through the checks in order:

• Clip speed: look for a speed change or retime on the clip itself.
• Clip rate: read the sample rate again on the imported clip, not on the source file.
• Project rate: confirm the project is still set to 48 kHz.
• Sync at the end: play the last minute of long clips, where drift shows most.