Still 32-bit?

I tried using Audacity’s “Change Tempo” feature to lower the tempo of a 1-hour audio file, and was told it’d take over 2 hours. Clearly that’s not practical.

Why is Audacity, a CPU-intensive app, still available in only a 32-bit version? Why not release a 64-bit version, so it can take advantage of modern processors?

The time estimate can sometimes be way off, especially on Windows (though the reason why is not yet clear). It may be worth testing with some shorter sections to get an idea of how long the effect is likely to actually take.

Note that Change Tempo has a choice of two algorithms. The “Use high quality stretching” option is usually much slower than the default algorithm. The actual “sound quality” is highly dependent on the type of audio, and how much you are trying to stretch it.

64-bit processing is not intrinsically faster than 32-bit processing. In many cases it is slower!
The ability to process across multiple cores in parallel can give significant increase in speed, but it requires deep changes in the code that could potentially be destabilizing, so requires a lot of very careful work. This is an area that the developers are working on, but it will be a gradual change, not a quick fix.

Change Tempo takes more time the more you negatively stretch.

If I take a one hour show and change it by -20% it takes around 14 seconds
If it change it by -50% it takes 23 seconds
If it change it by -75% it takes 88 seconds
If it change it by -90% it takes 3 and a bit minutes
If it change it by -99% Audacity hangs

There is a bug logged for the hang/freeze:

You notice a similar slowdown the more you positively change the Tempo - but you don’t get a hang at the positive extreme.

My machine is fast with Audacity because it has a 256 SSD non-spinning disk - I massively notice the Audacity processing speed over my older laptop with its spinning metal disk.

So if you’re working with bigger projects and processing speed is important than it’s worth considering an SSD computer.


Well, I could watch the progress over 10–15 minutes’s time, so I got a pretty good idea how long it’d take. I ended up using an online app to do it, considerably faster. I’d prefer using a local app, especially with music still in production, but maybe this is a good example of the gradual shift from local apps to shared ones.

Yes, I should’ve mentioned I was using the highest quality option, as I needed to preserve the music’s fidelity. (With music, I’m not sure why anyone would use less—unless it’s some of the pop stuff these days where most changes in quality would go unnoticed, as there’s so little there to begin with—LOL.)

I suppose that depends on how the code’s written. But it’d be silly not to at least try to develop a 64-bit version of something like an audio editor.

I’m glad to know they’re working on it, and hope it won’t take too much longer here in the 21st century. :?)

Thanks, but I’m actually using two SSDs—one for source, one for target.

I also have more than enough free RAM to process the entire file in-memory. It seems to me that when speed’s a priority, it’d be faster to do that than to keep writing portions of it to disc during the conversion (in other words, waiting till the conversion’s done to write the file). I’ve seen this option in other audio editors, but couldn’t find it in Audacity… Does it exist?

  1. Because it is much quicker processing time.
  2. Because sometimes it sounds better.

It is better to use the HQ setting when either:

  1. The exact length must be maintained.
  2. If it sounds better.

(See also:

It is better to use the Change Speed effect if either:

  1. The exact pitch is important but the exact tempo / length isn’t important.
  2. The exact tempo / length is important but the exact pitch isn’t/
  3. You specifically want to change the speed affecting both pitch and tempo.
    The sound quality of the Change Speed effect is better than any form of Change Pitch.

If you have equivalent code in 32-bit and 64-bit, the 32-bit version will usually be just as fast as the 64-bit version, and use significantly less RAM than the 64-bit version.

Audacity will eventually be migrated to 64-bit, but not because of performance. The main reason is because Apple are dropping support for 32-bit applications. No-one really wants to maintain 32-bit and 64-bit builds of their software because doing so takes developer and testing time away from more important issues, such as fixing bugs, developing new features, improving performance, enhancing user experience…

64-bit applications have a performance advantage for applications that require a lot of RAM, on systems that have more than 4GB of RAM. 64-bit applications won’t run on 32-bit systems.

Compiling Audacity as a 64-bit application does have one notable advantage - Some “Nyquist” plug-ins need to retain the entire audio selection in RAM. This limits the amount of audio that can be selected (for these specific Nyquist plug-ins) to 2 GB when Audacity is compiled as 32-bit. If Audacity is compiled as 64-bit and if the system has more than 4 GB of RAM, those Nyquist plug-ins are able to process longer audio selections.

Building Audacity on a 64-bit Linux system will produce a 64-bit executable. Similarly it is possible for anyone building Audacity from the source code to build 64-bit executables on Mac or Windows, though doing so is more difficult than on Linux, and is likely to be beyond the ability of anyone that is not an experienced software developer.

I hope I have succeeded in explaining that 32-bit applications are still perfectly valid in the 21sth century, and that for most software, 64-bit offers no benefit. For Audacity, the benefits are marginal, but have the significant disadvantage that a 64-bit build will not run on a 32-bit system, and millions of our users have 32-bit systems.

A two hour stereo show has around 4 GB of data for its current state. As soon as you start working on it, the amount of data increases because Audacity retains an “undo” stack (so that you can “undo”), so a 2 hour show can easily grow to 100 GB or more if you do a lot of processing. I doubt that many users have that amount of RAM available.

For working on small projects, you could create a “virtual disk” (a “RAM disk”). Saving the project to the RAM drive would then retain the entire project in RAM.
Editing operations would then probably be a bit quicker, but for processing (applying effects), the benefit over using an SSD are not likely to be noticeable because the bottleneck is the CPU.

If you choose not to release 64-bit builds in the very near future, you will shoot yourselves in the foot.

There are only two sensible options:

(a) build for both 32-bit and 64-bit architectures
(b) build for only 64-bit, and keep old builds around for those with 32-bit machines

I’m not sure that I agree about who’s foot would get shot :wink: but all being well it will be no-one’s. The developers are working towards 64-bit Mac builds, though no release date has yet been given. A major step toward that is upgrading WxWidgets and the XCode SDK in the next release.

Old versions of Audacity remain available on OldFoss.