MP4Joiner handles everyday joins without drama, but some users report the program closing unexpectedly or appearing to freeze partway through big jobs — many files at once, or very large ones. Those reports cluster around size and system resources rather than any single bug. This page gives you the practical workarounds, in the order most likely to get your join finished.

First: is it crashed, or just busy?

A direct-copy join of ordinary clips finishes quickly, but a job with force re-encoding enabled is a full conversion of every clip — on a large set that can legitimately take a long time, and the interface may look unresponsive while the encoder works flat out. Before killing the program, check whether the output file is still growing or the disk/CPU is active, and give a re-encoding job real time. If the output hasn’t changed for a long while and system activity is idle, it has genuinely stalled — move on to the fixes.

Fix 1: join in smaller batches

The single most effective workaround for crashes on many-file jobs: split the set. Join the first half of the clips into one file and the second half into another, then join those two results together. Each pass handles less data at once, and if one pass still fails you have narrowed the problem to a smaller set — possibly one damaged clip, which you can find by playing the suspects individually. This batching approach is also the stability advice in our guide to joining large MP4 files.

Fix 2: free up disk space and move the temporary directory

A join needs room for the output — roughly the combined size of all clips, as explained in why joined files are large — plus working space while it runs. A nearly full system drive is a classic cause of joins dying midway. Free space, and if your system drive is tight, use MP4Joiner’s temporary directory option (in its settings/options) to point the working space at a drive with plenty of room. Saving the output itself to that roomier drive helps too.

Fix 3: reduce the load on the machine

• Restart the program — and the computer — before a retry. A clean session rules out leftover state from the failed run.
• Close heavy applications. Re-encoding is CPU-hungry; browsers with many tabs, games and other encoders compete for the same resources and memory.
• Don’t multitask the disk. Copying huge files or running a backup to the same drive during a join slows everything and can starve the join of throughput.
• Check the clips. One corrupt input can kill every job it’s part of. Remove clips one at a time, or use the batch method above, to isolate it.

Fix 4: use the log to see where it stops

MP4Joiner has an option to save a log of the joining process. Enable it before a retry: if the job fails again, the log shows how far it got and which file it was processing — often enough to identify the exact clip or the exact moment things go wrong, instead of guessing. Pair that with the batch method: if the log stops on the same clip every time, that clip is the problem, not the program.

If the program won’t even start, your issue is installation, not joining: on Windows see the SmartScreen guide, on a Mac the Gatekeeper guide. And if the join completes but the result is broken, work through MP4Joiner not working and joined MP4 won’t play. Make sure you’re on the current release — MP4Tools 3.8 from the download page.

Each clip sounded fine on its own, but in the joined file the voices drift away from the lips — a little at first, worse toward the end. This is one of the most reported join problems, and it has a specific main cause: variable frame rate video from phones and screen recorders. Here is why it happens and the fixes in the order to try them.

The main cause: variable frame rate (VFR) sources

Phones and screen-recording software rarely record at a perfectly steady frame rate. They record at a variable frame rate — speeding up and slowing down with the scene and the device’s load — while the audio runs on its own steady clock. Each clip keeps itself in sync internally, but the timing assumptions differ from clip to clip.

MP4Joiner’s default mode copies streams directly into one container (see joining without re-encoding). A direct copy pastes those differing timing bases back to back. Small timing differences that were invisible inside one clip accumulate across a long joined file, so the drift grows the further you watch — the classic signature of a VFR sync problem. The same mismatch family also explains outright failures; the general background is in MP4Joiner not working.

Fix 1: re-join with force re-encoding

The first thing to try costs nothing. Enable MP4Joiner’s force re-encoding option and join the same clips again. Re-encoding decodes every clip and writes one uniform output stream instead of pasting the originals together, which resolves many sync cases — particularly when the drift comes from clips that simply differ in frame rate or encoding parameters. Test the result around each join point and near the end of the file, where drift is worst. It is slower than a copy and not lossless, but if it syncs, you are done.

Fix 2: convert VFR to constant frame rate first

If force re-encoding still drifts, the durable fix is to normalise the sources before joining: convert each VFR clip to a constant frame rate (CFR) version with a converter, using a standard rate such as the one your footage mostly targets. Once every clip runs on the same steady clock — same frame rate, same resolution, same audio format — MP4Joiner can join the converted set with a plain direct copy, quickly and losslessly from that point on. This “convert first, then copy-join” route is also the pattern behind joining files with different resolutions: make the clips agree, and the join becomes trivial.

Prevention for next time: if your recording app offers a constant frame rate or “compatibility” mode, use it for footage you plan to join. Screen recorders and phone cameras set to a fixed rate produce clips that join cleanly from the start.

When the free route isn’t enough

To be straightforward about MP4Joiner’s limits: it is a joiner with a re-encoding fallback, not a timing-repair tool. If a set of clips still won’t sync after re-encoding and CFR conversion — heavily damaged timing, mixed professional sources — a full converter-editor that rebuilds timing during conversion is the more capable instrument. Wondershare UniConverter (affiliate link — we may earn a commission at no extra cost to you) is the paid option we point readers to for that case: it converts and joins in one pass with explicit frame-rate control. Try the free fixes above first; they cover the large majority of phone and screen-recording sets. If your problem is instead missing audio entirely, see joined MP4 has no sound, and if the file won’t open at all, see joined MP4 won’t play.

You joined ten clips and the result is a multi-gigabyte monster that won’t fit in an email or upload anywhere. Nothing went wrong — a lossless join cannot be smaller than what went into it. This page explains the arithmetic, the one honest way to make the file smaller, and the practical options for storing and sharing a big joined video.

Why the joined file is the size it is

MP4Joiner’s default mode is a direct stream copy: it takes the existing video and audio data from every clip and writes it, unchanged, into one container — see how joining without re-encoding works. Copying adds nothing and removes nothing, so the output size is, by design, approximately the sum of all the input clips (plus a small container overhead). Five 400 MB clips make a roughly 2 GB file. That is not bloat; it is the price of a join that is fast and completely lossless.

It also means the join needs room to work: the output file plus temporary working space. If a join stops midway on a nearly full disk, free space first — or point MP4Joiner’s temporary-directory option at a drive with more room — then re-run. Problems of that kind are covered in MP4Joiner not working and MP4Joiner keeps crashing.

The only way to make it smaller: re-encode

There is no setting that shrinks a file while keeping every bit of the original data — smaller always means re-encoding at a lower bit rate or a smaller resolution, which discards some information. Done well, the loss is invisible in practice; done aggressively, it visibly softens the picture. MP4Joiner’s own force re-encoding mode is built for making mismatched clips compatible, not for tuned compression. For deliberate size reduction, follow our dedicated guide: compress a joined MP4 without visible quality loss. Keep the full-size joined file as your master copy, and compress a separate copy for sharing.

Storing and sharing a large joined file

If the file has to travel or be archived at full quality, compression is the wrong answer — storage is. Two practical routes:

• Cloud storage with share links. Upload the joined file once and send a link instead of the file, which sidesteps email and messenger size limits entirely. pCloud (affiliate link) is a solid fit for this: generous plans including lifetime options, and link sharing that doesn’t force recipients to register. Keep in mind the upload itself still takes time on a slow connection.
• Local hardware headroom. If big joins are routine — GoPro chapters, long recordings — a fast portable SSD gives both working space for joins and an archive for the masters. Current portable SSDs are listed via our Amazon search link (affiliate link); buy capacity for your library plus at least the size of your largest single join as scratch space.

For the joining side of large files — disk rules, batching and stability — see how to join large MP4 files. And if the “too large” file also refuses to play, that is a different fault: go to joined MP4 won’t play.

You opened the MP4Tools disk image on your Mac and macOS refused: the app “cannot be opened because it is from an unidentified developer”. That is Gatekeeper, macOS’s check for developer-signed apps, meeting a small open-source program that isn’t signed with an Apple developer certificate. The official MP4Joiner project documents this itself — here is how to open the app the way its own wiki describes, and the honest compatibility limits of a 2019 Mac build.

Why Gatekeeper blocks MP4Tools

By default, macOS only opens apps from the App Store or from developers who sign their software with an Apple-issued certificate. MP4Joiner is free, open-source software distributed through SourceForge without that signing and notarisation process, so Gatekeeper treats it as “unidentified”. The block is about provenance, not a finding that the app is malicious — but you should still only proceed with the genuine file. Our download page links the official SourceForge DMG and publishes its verified SHA-256 hash (f9af7f53e5a9c6c0d576c8c14311f04fb6c39c30919a5594b24c51a64fc7cde0 for MP4Tools-3.8-MacOSX.dmg), which you can check in Terminal with shasum -a 256 before opening anything.

Method 1: right-click and choose Open

1. Open the DMG and drag MP4Joiner (and MP4Splitter, if you want it) into your Applications folder, as usual.
2. In Applications, right-click (or Control-click) the MP4Joiner app icon — don’t double-click.
3. Choose Open from the context menu.
4. The dialog appears again, but this time with an Open button. Click it. macOS remembers your choice, and the app opens normally from then on.

Method 2: allow it in System Settings

1. Try to open the app once by double-clicking, and dismiss the block message.
2. Open System Settings → Privacy & Security (on older macOS: System Preferences → Security & Privacy).
3. Near the bottom you’ll see a note that MP4Joiner was blocked, with an Open Anyway button. Click it and confirm.
4. Launch the app again — it now opens, and macOS won’t ask again.

These are the same steps the project’s own wiki page for starting on macOS Catalina describes — the official project keeps a dedicated page for this because unsigned apps have needed this workaround since Catalina tightened Gatekeeper. See our MP4Joiner for Mac page for the full installation walkthrough.

The honest compatibility picture

MP4Tools 3.8 was released in November 2019, and the Mac build is an Intel-era application officially listed for OS X 10.10 and later. Two consequences are worth stating plainly. First, the official project does not claim native Apple Silicon support — on M-series Macs the app depends on Apple’s Intel compatibility layer rather than running natively. Second, the project does not publish support statements for the newest macOS releases, and reviewers have noted that the Mac interface can feel sluggish. For many users it still does its one job — joining MP4 files — perfectly well, and the Gatekeeper steps above are all it takes to start it. But if you need a tool that is actively maintained for current macOS versions, that is a reasonable reason to look at alternatives rather than fight an ageing build.

Once the app opens, the joining workflow is the same as everywhere: see how to join MP4 files. If a join then fails or produces a broken file, the cause is almost never Gatekeeper — work through MP4Joiner not working instead.

You downloaded MP4Tools and Windows stopped the installer with a blue “Windows protected your PC” message. That is Microsoft Defender SmartScreen doing its job on a small open-source program — not a virus detection. This page explains why the warning appears, how to proceed after verifying your download, and how to check the file against the published hash so you don’t have to take anyone’s word for it.

Why SmartScreen flags MP4Joiner

SmartScreen checks programs against a reputation system. Commercial software earns trust through an expensive code-signing certificate and large download volumes. MP4Joiner is a free, open-source tool by an independent developer (Alex Thüring), distributed unsigned via SourceForge — the official MP4Tools 3.8 installer is a plain 32-bit Inno Setup package with no commercial signature. To SmartScreen, “unsigned and not widely tracked” is enough to show the warning, whatever the file actually contains. Many legitimate open-source tools trigger the same screen.

Step 1: verify the file before you bypass anything

The warning is only safe to dismiss if the file is genuinely the official one. Our download page links the official SourceForge file directly and publishes its verified SHA-256 hash: e369f3c39e74ca6e106767817b63179c59d030497dde01cfb1e9f64393a0247b for MP4Tools-3.8-win32.exe (24,156,961 bytes). Check your copy in PowerShell:

1. Open the folder containing the downloaded installer.
2. Hold Shift, right-click an empty area, and choose “Open PowerShell window here” (or open PowerShell and browse to the folder).
3. Run: Get-FileHash .\MP4Tools-3.8-win32.exe -Algorithm SHA256
4. Compare the result with the hash above, character for character. If it matches, you have the untouched official file. If it doesn’t match, delete the file and re-download from the download page.

Step 2: run the installer past SmartScreen

1. Double-click the verified installer. The blue SmartScreen message appears.
2. Click More info in the message.
3. Click Run anyway, which appears after expanding the details.
4. Complete the normal setup. Both MP4Joiner and MP4Splitter are installed, since they ship in the same MP4Tools package.

If the warning appears again for a file you did not get from the official SourceForge channel, stop and re-download instead of bypassing — the hash check above is what makes the bypass a considered decision rather than a habit. More Windows setup detail is on our MP4Joiner for Windows page.

An honest note about old “bundled software” complaints

Search old reviews and you will find complaints from the 2.x era about the installer offering extra software or trying to change the browser homepage. Those complaints were real, but the attribution matters: they concerned SourceForge’s platform installer wrapper of that period (2013–2015), not the MP4Joiner program itself — a point other reviewers in the same thread make explicitly. We verified the current official 3.8 package directly: its hash matches SourceForge’s published value, and a scan of the installer found no bundling components and no bundled-offer code in its setup script. The honest summary is: historical complaints, explained by the old SourceForge wrapper; the current 3.8 SourceForge package checks out clean — and the hash above lets you confirm that for yourself.

The join finished without an obvious error, but the result refuses to open, freezes partway through, or goes black exactly where two clips meet. That behaviour has a well-understood cause, and the fix is usually a single re-join with the right mode. Here is what happened and how to redo the merge properly.

Why it happens: a stream copy over mismatched clips

MP4Joiner’s default mode copies the existing streams into one container without re-encoding. An MP4 file describes its streams once, in its header — one codec, one resolution, one frame rate. When the clips actually differ (different camera, different app, different settings) but are copied anyway, the header stops describing the data truthfully partway through the file. Players then fail in exactly the ways users report on the official SourceForge project: a mixed-in clip encoded by another program can make the joined file play abnormally or lock up entirely, even when the settings looked identical.

A second, simpler possibility is an incomplete file: if the join was interrupted — the program closed, the disk filled up, the computer slept — the output can be missing the final structure a player needs to open it at all. In that case the only fix is to redo the join to completion.

The redo steps

1. Verify the sources. Play every input clip on its own, start to finish if you can. A clip that is already damaged will poison any join.
2. Decide which mode fits. All clips from the same device with the same settings? A direct copy should work — if it didn’t, one clip probably differs, so move to step 3. Mixed sources? Skip the copy entirely.
3. Re-join with force re-encoding. Enable MP4Joiner’s force re-encoding option so every clip is converted to one consistent set of parameters. This is slower and not lossless, but it produces a file with a truthful header throughout. The background is in joining files with different resolutions and how lossless joining works.
4. Give it room and let it finish. Make sure the destination disk has free space well beyond the combined size of the clips, and don’t close the program mid-join.
5. Test the new file fully. Scrub past each join point, especially where the old file froze.

Rule out the player before blaming the file

Open the joined file in a second, codec-flexible player. The free VLC media player, available from its official site videolan.org, plays a very wide range of MP4 variants and is the standard way to check whether a file or a player is at fault. If VLC plays the file cleanly, your join is fine and the first player is the limitation. If VLC also fails or freezes at the same point, the file itself is damaged — redo it with force re-encoding as above.

Related symptoms: if the file plays but is silent, see joined MP4 has no sound; if sound and picture drift apart, see audio out of sync after joining. For the full checklist of join failures, start at MP4Joiner not working.

The video joined, the picture plays — but the merged file is silent. Sound problems after a join almost always trace back to the audio streams of the source clips: they differed from each other, one clip had no audio at all, or the player cannot decode what ended up in the file. Work through the causes below in order.

Cause 1: the clips’ audio parameters don’t match

MP4Joiner’s default mode copies streams directly, and a direct copy needs every clip to carry the same audio format — same codec, sample rate and channel layout. If one clip was recorded at a different sample rate or with a different audio codec, the copied output can end up with audio that stops at the join point, or no playable audio at all. This is the same parameter rule that governs the video side, covered in our hub guide on MP4Joiner not working.

Fix: join again with force re-encoding enabled. Re-encoding normalises every clip’s audio to one consistent format, which is the reliable cure for mixed-source sets. See also joining files with different resolutions or frame rates — the audio side follows the same logic.

Cause 2: a clip has no audio track — or more than one

Screen recordings, exported animations and some camera modes produce video-only files. If the first clip in your list has no audio track, a direct-copy join can produce a file whose audio layout confuses players, even if later clips do have sound. The reverse also happens: a clip with multiple audio tracks (for example a commentary track) does not match single-track clips.

Fix: check each source clip in your player before joining — does it play with sound on its own? Remove silent clips from the set or join them separately, and use force re-encoding when you must combine clips whose track layouts differ.

Cause 3: audio settings during re-encoding

When you do re-encode, MP4Tools 3.8 lets you set the audio sample rate and bit rate for the output — this was one of the headline additions in the 3.8 release. Keep the sample rate consistent with your sources (do not force an unusual rate), and avoid setting the bit rate extremely low, which can make some players treat the track as broken. If a re-encoded join came out silent, re-run it with the audio settings left at sensible defaults and test again.

Cause 4: it’s the player, not the file

Before re-joining anything, rule out the player. Open the joined file in a second player — the free VLC media player from videolan.org decodes a very wide range of audio formats and is a good referee. If the file has sound in VLC but not in your usual player, the joined file is fine and the first player simply lacks support for that audio format; in that case, a re-encoded join with standard audio settings produces a file both players accept.

If the sound is present but drifts away from the picture, that is a different problem — see audio out of sync after joining. And if the file will not play at all, go to joined MP4 won’t play.

You added your clips, clicked Join, and got an error, a broken file, or nothing at all. In most cases MP4Joiner itself is fine — the join failed because of what was fed into it. This page is the troubleshooting hub: it explains the single most common cause, walks through a checklist in the order most likely to fix your problem, and links out to the detailed guide for each symptom.

The number one cause: mismatched encoding parameters

MP4Joiner’s fast mode joins files by direct stream copy — it copies the existing video and audio streams into one container without decoding them, as explained in our guide to joining without re-encoding. That only works when every clip shares the same encoding parameters: the same codec, resolution, frame rate and audio format. One output stream can only carry one set of parameters.

Users on the official SourceForge project report exactly this pattern: clips recorded by one program join perfectly, but mixing in a clip encoded by a different program — an intro rendered by another editor, for example — produces a file that plays abnormally or freezes, even when the settings “look the same”. Looks are not enough; the underlying parameters have to match. If your set mixes sources, resolutions or frame rates, follow the dedicated guide to joining MP4 files with different resolutions and use force re-encoding as described below.

The fix that solves most mixed-source joins: force re-encoding

When the parameters genuinely differ, enable MP4Joiner’s force re-encoding option before joining. The program then decodes and re-encodes every clip to one consistent set of parameters, so the output plays as a single uniform stream. Be aware of the trade-offs: re-encoding is no longer lossless, and it takes noticeably longer than a direct copy. For same-source clips it is unnecessary — keep it off and enjoy the fast, lossless join.

Step-by-step troubleshooting checklist

1. Confirm the basics. Make sure you have the current release — MP4Tools 3.8 — from the download page, and that every input file is actually an MP4. MP4Joiner is an MP4 tool; MOV and M4V are not officially supported and results with them are unreliable.
2. Play each clip on its own. If one input already fails or stutters in your player, the join cannot fix it. Remove or repair that clip first.
3. Check whether the clips share parameters. Clips from the same device with the same settings are the safe case. Mixed phones, cameras, screen recorders and editors usually are not — see the mismatch section above.
4. Retry with force re-encoding. If the direct copy failed or produced a broken file, enable force re-encoding and join again.
5. Watch the output location and free space. The joined file is roughly the sum of all clips, and the join also needs temporary working space. A nearly full disk can stop a join midway — our guide to the joined file being too large covers the space rules.
6. Reduce the set. If a large batch fails, join in two smaller batches, then join the two results. This also helps if the program keeps crashing on big jobs.
7. Install problems instead? If Windows blocks the installer, see the SmartScreen guide; on a Mac, see the unidentified developer guide.

Match your symptom to the right guide

• The joined file plays but has no sound
• The joined file won’t play at all, or freezes
• The picture and sound drift out of sync after joining
• The joined file is far larger than expected
• The program itself crashes or hangs during a join

New to the tool? Start with how to join MP4 files for the normal workflow on Windows and Mac, and check the FAQ for quick answers.