ShareX Recording Audio and Video Are Out of Sync: How to Fix It

When a ShareX recording starts in sync but the microphone or system audio gradually moves ahead of or behind the video, the problem usually falls into one of four categories: playback trouble, dropped video frames, mismatched audio paths, or recording settings that place too much load on the computer. The important first step is to determine whether the saved file contains true desynchronization or whether one media player is simply struggling to play it correctly. The troubleshooting process below starts with short, controlled tests so you can identify the cause without repeatedly changing unrelated ShareX or Windows settings.

1. Confirm the Symptom and Reproduce It With a Simple Test

Do not begin by reinstalling ShareX or changing every encoder option. First, create a repeatable test that reveals when the synchronization problem appears.

1.1 Record a short synchronization test

Record a 30 to 60 second clip using the same capture region, audio source, and workflow that produced the problem. While recording, count aloud and create visible timing cues by clicking the mouse, clapping near the microphone, or opening and closing a window. A sharp sound paired with a visible action makes synchronization easier to judge than ordinary speech.

Watch the beginning, middle, and end of the clip. The pattern provides useful diagnostic information:

• If the offset is nearly identical from beginning to end, the issue may be fixed audio latency, Bluetooth delay, or a playback problem.
• If the recording begins correctly but becomes progressively worse, suspect dropped video frames, unstable timing, or sustained CPU or GPU overload.
• If only the preview or one player is affected, the recording file may be healthy.
• If short clips work but long clips drift, the problem is more likely related to timing, performance, or the recording workflow.

Success at this stage means you can describe the symptom precisely. Once you know whether the offset is constant or increasing, stop repeating the test and move to the relevant checks.

1.2 Test the same file in multiple media players

Play the original local file in at least two players. For example, compare the Windows media player available on your system with VLC or another established desktop player. Do not rely only on a browser preview, cloud-storage preview, chat application, or the player embedded in an upload service.

If one player is out of sync while another plays the file correctly, you are seeing playback lag or a player compatibility issue rather than confirmed desynchronization in the file. Hardware decoding, seeking behavior, damaged player caches, or incomplete codec support can make one application present the streams differently.

Also play the file from a local internal drive. If it is currently on a network share, external drive, synchronized folder, or remote destination, copy it locally before testing. This separates recording quality from slow or inconsistent delivery.

Success means the file plays in sync in more than one capable local player. If it does, stop changing ShareX recording settings. Troubleshoot or replace the affected playback application instead.

1.3 Distinguish a fixed offset from progressive drift

A fixed offset means the audio is early or late by roughly the same amount throughout the clip. This often points to device latency, particularly when a wireless headset is involved. Progressive drift means the gap grows as the recording continues. That is more consistent with missing video frames, overloaded encoding, or timestamps that the player interprets poorly.

This distinction matters because manually delaying an audio stream may disguise a fixed offset, but it will not repair drift that continues to increase. If the difference grows over time, prioritize reducing recording load.

2. Check the ShareX Settings Directly Related to This Problem

ShareX uses FFmpeg for screen recording. The exact options visible in ShareX can vary with the installed build and FFmpeg configuration, so use the labels shown in your own Screen recording options rather than copying an old command from an online post.

2.1 Verify the selected audio sources

Open the ShareX screen recording options and check which audio source is selected. System audio and microphone audio travel through different Windows device paths. They can use different drivers, sample rates, buffers, and latency characteristics.

Run three short tests if the problem occurs while capturing both types of audio:

1. Record video with system audio only.
2. Record video with microphone audio only.
3. Record video with both sources using the normal workflow.

If only one source causes the problem, focus on that device or capture path. For example, a microphone-only test that drifts while system audio remains synchronized suggests a microphone driver, Bluetooth, or input-device issue. If each source works alone but the combined recording fails, the mixed workflow may be too demanding or may involve incompatible device timing.

Success means you identify a stable source combination. Once a particular device or combination is clearly responsible, stop changing unrelated video settings until that audio path has been checked.

2.2 Lower the frame rate

A high frame rate makes the encoder process more frames every second. This can be useful for games or fast motion, but it increases recording load and can contribute to dropped or delayed video frames. For troubleshooting, try 30 frames per second. If the computer is under heavy load or the content is mostly demonstrations and menus, test a lower frame rate as well.

Keep the test region and audio source unchanged so that frame rate is the only meaningful variable. A short 30 FPS test that remains synchronized while a higher-FPS test drifts is strong evidence that the original workload exceeded the system's reliable recording capacity.

Success means the audio remains aligned through the end of the test. Keep the lowest frame rate that still looks appropriate for the content, and stop increasing it unless the visual benefit is necessary.

2.3 Reduce the capture region

Recording a large desktop, particularly a high-resolution or multi-monitor area, requires more capture bandwidth and encoding work. Test a smaller region around the application you actually need. If you normally record an entire 4K display, compare it with a smaller window-sized region at the same frame rate.

Reducing the region is especially useful when the drift appears during animation, scrolling, video playback, gaming, or other periods of rapid visual change. Those moments can be harder to encode than a mostly static desktop.

Success means a smaller capture area eliminates the growing offset. Keep that region, lower the frame rate, or choose a faster encoding configuration instead of returning immediately to the original workload.

2.4 Review the encoder configuration

Encoder choices affect both compatibility and system load. A software encoder can consume substantial CPU time, while a hardware encoder depends on supported graphics hardware and functioning drivers. Presets that prioritize compression efficiency can also require more processing than faster presets.

For diagnosis, return unusual custom FFmpeg arguments to a known, simple configuration. Avoid combining copied parameters until a basic recording works. If ShareX provides a supported hardware encoder for your system, compare it with the current encoder. Alternatively, use a faster software preset or lower quality temporarily to determine whether encoding pressure is causing dropped frames.

Some editing tools and playback workflows also expect consistent frame timing. If you have manually added FFmpeg arguments that alter timestamps, frame synchronization, or variable frame-rate behavior, remove them for the clean test. Do not assume that forcing a constant frame rate can recover frames the computer failed to capture. It can improve compatibility in some workflows, but reducing the actual workload is the more important fix when video frames are being missed.

Success means an ordinary encoder configuration produces a synchronized file in multiple players. Keep that working configuration and add custom options back only one at a time.

3. Check Windows, Display, Audio, and Workflow Factors

3.1 Look for CPU, GPU, memory, or disk pressure

Open Windows Task Manager and observe performance while running the same recording test. Pay attention to sustained CPU or GPU usage near capacity, high memory pressure, and heavy disk activity. A brief spike is not automatically a problem, but sustained saturation during the exact period where synchronization deteriorates is meaningful.

Close applications that compete for resources, including games, video editors, virtual machines, browser tabs playing video, background encoders, and other screen-capture tools. Disable unnecessary overlays for the test. If security software or a synchronization client is scanning or uploading every newly written segment, temporarily record to an ordinary local folder to compare behavior.

When the video side cannot capture or encode frames on schedule, audio may continue arriving at a steadier rate. The result can look like audio gradually moving ahead of the picture.

Success means resource use remains stable and the test clip stays synchronized. If closing one workload fixes the problem, do not continue changing ShareX. Adjust that workload, lower the recording demand, or avoid running both tasks simultaneously.

3.2 Test without Bluetooth audio

Bluetooth headsets can introduce noticeable latency, and their behavior may change when Windows switches between high-quality playback and a headset mode that includes the microphone. This can create a fixed delay or make monitoring sound misleading even when the saved file is closer to correct.

Repeat the short test using a wired microphone, a USB microphone, the computer's built-in microphone, or no microphone. Play the result through wired speakers or headphones. If you must use Bluetooth, verify that ShareX is capturing the intended input and that Windows has not switched to a different headset endpoint.

Success means the wired or built-in device produces synchronized audio. At that point, the Bluetooth path is the likely cause. Stop changing video settings and either use the stable device, update the relevant Bluetooth and audio drivers, or accept and correct a consistent device-specific offset during editing.

3.3 Confirm Windows input and output devices

Windows can change the default audio device after a headset reconnects, a monitor wakes, a dock is attached, or a USB interface is moved. Confirm that the device selected in ShareX matches the device you intend to record. Check that the microphone is enabled and permitted for desktop applications in Windows privacy settings.

Where device properties allow it, compare the format settings used by the relevant input and output devices. Using a common sample rate across the workflow can reduce unnecessary conversion, although changing sample rates should not be your first step unless testing identifies one device as the source of drift.

Success means ShareX consistently captures the expected device without switching endpoints or losing access. Once the correct source is stable, leave it selected.

3.4 Record to a simple local destination

Use a local folder on an internal drive for the clean test. Avoid recording directly to a network location, removable drive, cloud-synchronized directory, or folder managed by an automated process. ShareX can run after-capture and after-upload tasks, but those tasks should not be allowed to obscure whether the original recording was created correctly.

Check the saved local file before uploading, converting, trimming, or passing it to another application. If the original file is synchronized but a converted or uploaded copy is not, the recording stage is working. The problem belongs to the later processing or playback stage.

Success means the untouched local file plays correctly. Stop modifying ShareX capture settings and investigate the conversion, upload service, editor, or destination that changes the result.

3.5 Check display and driver changes

If the problem began after changing monitors, resolution, display scaling, refresh rate, graphics drivers, docks, or remote-desktop software, reproduce the recording with a single display and a smaller region. Update or roll back graphics and audio drivers only when the timing of the problem supports that action.

Mixed-refresh displays and high-resolution desktops increase the complexity of capture, but they are not automatic proof of the cause. A controlled single-display test is more useful than changing several display settings at once.

Success means the simplified display arrangement records reliably. Reintroduce the second display or original resolution one change at a time to find the threshold.

4. Run a Clean Temporary Test With Minimal ShareX Settings

A clean test helps separate a ShareX recording problem from custom automation, uploads, editing steps, and aggressive encoder settings. It does not require deleting your normal configuration.

4.1 Build the minimal test

1. Choose a small capture region with limited motion.
2. Select one known-good audio source, preferably wired or built in.
3. Use 30 FPS or lower.
4. Use a standard supported encoder configuration without custom FFmpeg arguments.
5. Save directly to a local internal drive.
6. Disable unnecessary after-capture and after-upload actions for the test.
7. Record for 30 to 60 seconds with visible clicks and spoken timing cues.
8. Play the untouched result in two local media players.

If this file is synchronized, ShareX and FFmpeg can record correctly under the minimal conditions. Reintroduce your normal settings individually: first the larger region, then the higher frame rate, then the second audio source, then custom encoder options, and finally automation or destination changes.

Do not change two variables together. The first change that brings back progressive drift is the best lead. Success means you can name one setting, device, or workflow step that reliably triggers the symptom.

4.2 Know when to stop changing settings

Stop troubleshooting ShareX when the untouched file plays in sync in multiple players. Also stop when several repeat tests work at the chosen resolution, frame rate, audio source, and duration. Endless tuning after the symptom has disappeared can reintroduce instability without improving the recording.

For an important long recording, make one test that is longer than the earlier diagnostic clips. A five-to-ten-minute test can confirm that progressive drift is gone before you record a presentation or tutorial.

5. Check Task History, Logs, and Recent Workflow Output

ShareX task history can help you locate the exact file, confirm its destination, and distinguish the source recording from later outputs. Review the task associated with the recording and make sure you are testing the original file rather than a converted, uploaded, or edited copy.

If ShareX reports an error, preserve the complete message. Encoder initialization failures, unavailable audio devices, permission problems, and failed output operations require different fixes. Search the message exactly rather than treating every problem as generic ShareX not working behavior.

When available, inspect the generated FFmpeg command or recording log associated with the failed workflow. Look for repeated warnings, device failures, timestamp-related messages, or signs that frames were duplicated or dropped. Do not add random command-line switches in response to a single warning. First reproduce the warning with the clean test and compare it with a successful run.

Also compare the creation time and file size of recent outputs. An unexpectedly small, incomplete, or abruptly terminated file may indicate that the recording did not close normally. In that case, synchronization trouble may be a consequence of an interrupted recording rather than a stable configuration problem.

Success means the task history points to a complete original file and the clean run produces no relevant repeated errors. If errors remain, keep the exact message and use it when consulting ShareX documentation, issue reports, or support channels.

6. Quick Fix Checklist

• Record a 30-to-60-second clip with visible and audible timing cues.
• Play the original local file in at least two media players.
• Determine whether the offset is fixed or grows over time.
• Test system audio and microphone capture separately.
• Replace Bluetooth audio temporarily with a wired or built-in device.
• Reduce the recording frame rate to 30 FPS or lower.
• Capture a smaller region instead of the entire high-resolution desktop.
• Close games, editors, virtual machines, overlays, and competing recorders.
• Use a simple encoder configuration without copied custom arguments.
• Save to a local internal drive before uploading or converting.
• Check Task Manager for sustained CPU, GPU, memory, or disk pressure.
• Reintroduce settings one at a time after a clean test succeeds.

The practical definition of success is simple: the original recording remains synchronized at the beginning and end, plays correctly in multiple players, and repeats successfully under the settings you intend to use.

7. Frequently Asked Questions

7.1 Why does ShareX audio start correctly and drift later?

Progressive drift usually indicates that the audio and video streams are not advancing consistently. A common practical cause is recording load: the computer continues receiving audio while video capture or encoding falls behind and drops frames. Lower the FPS, reduce the capture area, choose a faster encoder configuration, and close competing workloads. A longer clean test should remain synchronized before you consider the issue fixed.

7.2 Why is the recording out of sync in only one player?

If the same original file plays correctly in another capable player, the file does not have confirmed universal desynchronization. The affected player may be struggling with decoding, seeking, hardware acceleration, or the file's timing information. Update or reconfigure that player, or use the player that handles the recording correctly. Do not alter a working ShareX configuration solely to accommodate one problematic preview.

7.3 Can Bluetooth headphones cause ShareX audio delay?

Yes. Bluetooth adds latency, and headset mode can behave differently when both playback and microphone functions are active. Test with a wired, USB, or built-in device. If the offset disappears and remains gone across repeated clips, the wireless audio path is the likely cause rather than the video encoder.

7.4 Should I force constant frame rate?

Constant frame-rate output can improve compatibility with some players and editors, but it is not a substitute for reliable frame capture. If the computer is overloaded, forcing a frame-rate mode cannot recreate visual information that was never captured. First lower the workload and remove custom FFmpeg options. Consider frame-rate conversion only when the original records reliably and a specific editing application requires it.

7.5 Why do short clips work while long ShareX recordings drift?

Long recordings expose sustained performance limits and timing differences that may not be visible in a ten-second sample. Test for several minutes while watching system load. If the gap grows only during demanding visual activity, lower the capture size or FPS. If it grows at a steady rate even on an idle desktop, isolate the microphone and system-audio paths and review the encoder output for timing warnings.

7.6 When should I use a dedicated recorder instead of ShareX?

ShareX is highly effective for screenshots, quick screen captures, uploads, OCR, hotkeys, image editing, and automated workflows. A dedicated recorder may be better when you need long-form production, multiple independently editable audio tracks, detailed audio-delay controls, scene switching, extensive monitoring, or sustained high-resolution and high-frame-rate capture. If the minimal ShareX configuration works but your required production setup repeatedly exceeds it, moving that specific recording task to dedicated software is more efficient than forcing ShareX to match a specialized studio workflow.