Roll back to older version?

Does anyone know whether it is possible to roll back to an older version of Audacity while keeping things like macros? Where can I safely download the files (windows)?
Unfortunately 3.0.0 is unusably unstable for me, although I’m sure future versions will be great.

Macros should be mostly compatible between Audacity 2.4.2 and Audacity 3.0.0.

Project made in Audacity 3.0.0 can not be opened by Audacity 2.4.2.

Audacity 2.4.2 can be downloaded from FossHub: Old Audacity versions download


Why, what’s the problem?

I think he is refering to this post: Failure to open database - #4 by BernieH

If you have steps that can help to replicate this problem, please share them. Thank you.

Trying to open a file (mp3 or wav) sometimes gives the Failed to open project database error.
Sometimes running a macro on a set of files just stops part way through without any error, but without processing all the files.
Sometimes running a macro stops with the Failed to open project database error partway through.
Sometimes trying to run a high pass filter on a file just stops at/near the end of % processing without giving any error but without doing the filter.
I have a suspicion there has been something else too, but I don’t remember now - these are the main ones!

There doesn’t seem to be any consistency to these errors - sometimes immediately retrying a failed operation on exactly the same file succeeds, but often not.
I normally run a macro on 3-8 files per day, but have found it impossible to do this successfully within 4-5 attempts most days since v3.0.0, at which point I have lost patience and lost time compared to doing it manually …
So I was doing all the processing manually instead, but then realised a couple of days ago that the high pass filtering was sometimes failing too (there are no signs except for noticing the waveform didn’t look different on the screen and then that I didn’t have options to undo/redo the filter - whereas a failed macro doesn’t produce an output file), making it impractical to do even this.

This is working perfectly for me again - thanks.
Hopefully a future update to 3.x.y will work well too, even if I can’t provide any helpful bug tracing insights.

We’re finding it very difficult to reproduce this problem. We know that it is real because we have multiple reports of the same thing, but not for us.

The next version will be Audacity 3.0.1 and is scheduled for release next month. Several bugs have been fixed, but this one is still doubtful. Additional logging has been added for 3.0.1 so that if the bug does still happen we may be able to work out what’s causing it. It would be immensely useful for us if you could test the next release and help us with some bug hunting. Would you be willing to do that?

Yes, when the behaviour is inconsistent on my machine I can see how it’s difficult to diagnose.

The next version will be Audacity 3.0.1 and is scheduled for release next month. Several bugs have been fixed, but this one is still doubtful. Additional logging has been added for 3.0.1 so that if the bug does still happen we may be able to work out what’s causing it. It would be immensely useful for us if you could test the next release and help us with some bug hunting. Would you be willing to do that?

Will it be possible to install it alongside 2.4.2? Then I can always try to use 3.0.1 every day but if it fails I can still get my processing done on the old version while sending you the logs, and try again the next day?
If I have to replace 2.4.2 then I will try 3.0.1 at least once but won’t keep installing/rolling back/installing etc. every day, so you won’t get nearly as many logs.

We can give you instructions for how to run the new version as a self-contained “portable” version, so that the two versions don’t interfere with each other. Our regular testers are usually running multiple versions at the same time, so plenty of advice on hand to help.

One “possible” problem that may occur from doing this is that effects may be duplicated due to Audacity seeing the effects in the other version. This is a minor inconvenience that is easily fixed if it happens.

Could you please share instructions for running a different version in parallel? On one of my systems I have 3.0.0 installed which shows some odd behavior when loading a (2.x) project. I’d like to switch between this and my previous 2.4.2 to compare the behavior - preferably preserving the “Main” 3.0 installation and having 2.4.2 portable (Win8.1, other systems Win10)
Thanks.

Here you go: Portable Audacity - Audacity Manual

BTW, Audacity 3.0.2 has been available for a while and contains important fixes over 3.0.0: Audacity ® | Downloads

Thanks for the instructions and pointer to latest version.
With 3.0.0 I observed frequent crashes of my Outlook (2010) apparently linked to Audacity loading a large (> 1GB) FLAC file, leading to 100% busy time on the system SSD (response time climbing up to ~4s).
v2.4.2 seems to less heavily utilize the SSD.
First tests however showed that v3.0.2 does not cause such crashes. It looks as if load time is faster. Will still keep an eye on this and report back if any problems.

There is one item that’s handy to know. Audacity doesn’t edit MP3, FLAC, or other compressed or processed sound files. It converts them to its own super high quality internal sound format for editing. That helps prevent effects, filter, and processing distortion.

That means your (> 1GB) FLAC file is going to be much larger in Audacity than you think. Also, under some editing conditions, Audacity saves the whole show as UNDO. So let’s say your show inside Audacity is really 2.5GB (MP3 files can make this much worse) and you do two processing edits. That’s 7.5GB that Audacity now has to manage.

(response time climbing up to ~4s)

So this isn’t the piffle job you might think it is.

It’s also handy if there’s nothing else running on your machine while you work. If you’re on Windows, Shift+Shutdown will clear out Windows processes and may make this editing session easier and faster. And makes the shutdown take longer.

If you’re on a Mac, actually Shut Down, not Restart, and pay attention to how long it takes to actually go down. If it takes a really long time, wait a bit for the machine to settle down and do it again.

Koz

Audacity doesn’t edit MP3, FLAC, or other compressed or processed sound files.

This is understood and I am aware that the >1GB FLAC file represents quite a big chunk (some 90min of music).
I did a test with a vinyl that I ripped before, represented by

  • LP.aup + LP_data with 820 MB
  • LP.aup3 with 821 MB (when closed) (created from the *.aup project)
    After opening the aup3 project, adding a 217MB FLAC and again removing it, all project files (incl. temporary) together take about 2,7 GB.
    I do follow your comment on UNDO requiring a lot of space and I never looked into the _data folder for size changes with v2. So just out of curiosity: how did v2 handle this, did it “blow” the _data folder temporarily as well?
    OK, I guess I can answer this myself: v2 DID blow up the _data folder (to ~1,6 GB) in this example.
    So it seems the major extra space requirement with v3 comes from the temporary aup3-wal file (~1 GB in my example).

Is there any rule of thumb to what extent we can expect the temp files to grow during an edit session?
If v3 now has a significant higher requirement for temporary space, it would be good to know, so we can reserve enough work space.

In my tests I’ve not found that to be the case. What I have noticed is that AUP3 project (including the WAL file) will frequently show a bigger size temporarily. With the old “pile of files” format, any “Undo history” that no longer referenced the project would be deleted immediately, whereas the new format may hang onto that data a bit longer, but overall the total size of a project is pretty similar.