If you manage Audacity on Windows, you are about to see 4.0.0 turn up in whatever you use to track updates. Winget lists it. Your patching tool probably lists it. It looks like the next version after 3.7.9, and every instinct says approve it and move on.

We nearly did. Then we pulled the installer apart and found that Audacity 4 is, for all practical purposes, a different application that shares a name with Audacity 3. Deploying it as an update either leaves you with two copies of Audacity on every machine, requiring a cleanup.

This post is what we found and what we are doing about it. None of it depends on which deployment tool you use.

A bit of background

Muse Group have owned Audacity since 2021. Over the last few years their influence has become more visible, first with the MuseHub integration in 2023, and now with Audacity 4, which Muse describe as another step towards their connected ecosystem, with tighter Audio.com integration and links into MuseHub.

What changed in the installer

This is the part that should make you stop and look before approving anything.

Audacity 3.7.9 is an Inno Setup EXE. It registers in Apps and Features as Audacity_is1 and installs to C:\Program Files\Audacity.

Audacity 4.0.0 is a WiX MSI. It has a proper MSI ProductCode, its own UpgradeCode ({C9D47FF5-2A6D-4A42-9038-93C7D3C3FB23}), and it installs to C:\Program Files\Audacity 4.

Different installer technology. Different product identity. Different install folder. So when you run the Audacity 4 MSI on a machine that already has Audacity 3, nothing is upgraded. You get both:

• Audacity 3.7.9 in C:\Program Files\Audacity
• Audacity 4.0 in C:\Program Files\Audacity 4

The MSI does include a standard MajorUpgrade rule, but it only applies within the Audacity 4 family. 4.0 → 4.0.1 → 4.1 will upgrade over each other cleanly. 3.x → 4.x will not. Looking at the install path alone, this is clearly deliberate on the vendor’s part rather than a packaging oversight.

Why the vendor did this on purpose

Once you look at the application itself, side by side starts to make sense.

Audacity 4 is a rebuilt Qt-based interface with a new project format, .aup4. It can convert your existing .aup3 projects and keeps the originals, but a .aup4 project cannot simply be saved back to .aup3. Anyone who opens a shared project in Audacity 4 and hits save has moved it off the 3.x line.

Audacity 4 has also dropped 32-bit Windows entirely. The official Winget manifest lists x64 and arm64 only.

So the two-day release gap is not a coincidence. Audacity 3 is still an active, separately maintained branch. Muse have shipped Audacity 4 as a parallel generation you can run next to Audacity 3, not as its replacement. If you have a school media department, a podcast team, or anyone with a scripted Audacity workflow, they will find out very quickly which features are missing.

What goes wrong if you treat it as an update

There are two failure modes, depending on how your deployment handles the version change.

If your tooling just runs the new installer, users end up with two Audacity icons and no explanation. Support tickets follow, along with the question of which one their projects should open in.

If your tooling is clever enough to uninstall the old version first, you have just removed an application with features your users rely on and replaced it with one that cannot open their work the same way. That is worse.

Neither is what Winget is telling you. Winget uses the same package identifier, Audacity.Audacity, for both 3.7.9 and 4.0.0, so standard version comparison sees a normal update. This is a good example of why a package identifier and an application identity are not the same thing, and why major generation changes need a human to look at them even when the upstream ID never changes.

Detection notes

If you package this yourself, a few things to watch.

Audacity 4 registers roughly like this:

• DisplayName: Audacity 4.0
• DisplayVersion: 4.0.0.262451524
• InstallLocation: C:\Program Files\Audacity 4

Do not build a detection rule expecting DisplayVersion to be a clean 4.0.0. And do not use a single ProductCode as your long-term detection, because the MSI ProductCode will change with every release. Something like DisplayName -like "Audacity 4*" combined with a version comparison is safer.

Note: MuseHub is not required to install or run Audacity 4. The official GitHub releases still provide a direct MSI, and the Audacity developers have said it can be installed without any middleware. Use audacity-win-4.0.0-x86_64.msi directly and leave MuseHub out of your deployment.

Silent install is the usual:

msiexec.exe /i "audacity-win-4.0.0-x86_64.msi" /qn /norestart

What we recommend

This is how we are handling it, and it should translate to Intune, SCCM, or any other tool you use.

Keep your existing Audacity deployment on 3.x. Block or hold 3.7.9 → 4.0.0 so it does not go out as a routine update. Audacity 3 is still being maintained, so there is no urgency.

Package Audacity 4 as a new application. Give it its own package, its own detection, and its own assignment. Let future 4.x releases flow through that package as normal MSI upgrades.

Do not remove Audacity 3 when you deploy Audacity 4. If a device already has Audacity 3 and someone deliberately deploys Audacity 4, leave both in place. That matches the vendor’s intent and gives users a fallback for anything 4 cannot do yet.

Migrate on purpose, later. Once Audacity 4 reaches feature parity, a separate “replace Audacity 3” package that detects, uninstalls and reinstalls is the right way to do it.

How Pckgr is handling it

For anyone using Pckgr, this is exactly the model we have applied. The existing Audacity application stays on the 3.x line and continues to receive 3.x updates. Audacity 4 is a separate application built from the official MSI, and deploying it does not remove Audacity 3.

If you would rather not track this sort of thing yourself, you can try Pckgr free at intunepckgr.com.