Here is what was happening:
When Audacity 3.0 or 3.0.2 used (on Win10 or win7 same result) and my project had many (60 up) parts labeled and marked, it started lagging to any click, even deleting a simple track marker line would take first a minute to respond and the time would increase with every new click.
25 minute audio would take up to 20 min to save and close.
What I did is export the audio to mp3 file.
I re installed Audacity 2.4 and imported this file. I put back all the markings and labels to this and saved it. It works like a charm. No lag nothing.
Now I have also imported this mp3 file to Audacity 3.0 and works fine. I have done all the markings and labels and works fine. The original .au3 project had a lot of edits like volume changes, deletions, insertions, but lagging started to apear when clip fix was used once or twice.
What I observed is that 2.4 uses a different method to save the edits, has lots of subfolders associated with each project and projects have .aup extension where 3.0 has only 3 files associated with each project with .au3 extension. Older version projects are not compatible with new Audacity.
IF any of you have a .aup3 project that is currently experiencing these moderate slowdowns, AND IF the project is not yet totally unusable due to excessive slowness, I would like to take a look at it. Please zip it up and upload it to a public file server, then post or PM me a link. Thank you.
Thank you Jademan for your response.
As far as Neos (me) project is concerned I tried to recreate to Audacity 3.0.2 from the file saved by the earlier Audacity version(.aup) and put most of the missing clip boundaries back. This worked fine and quick.
I saved the new file (.au3) and reopened it and seems that is working fine.
What I observed now is that this file is 772mb and is only one with .au3 extension,
Previously project saved with 3.0.2 was around 600mb and had two associated files with extensions .au3-shm and .au3-wal. These seem to not be here on my this attempt.
Unfortunately I deleted the original offending project so I can not send.
I’ve also encountered extreme slowdown since I upgraded from Audacity 2.4.2 to 3.0.4.
For me, the slowdown also exists when I simply open the Audacity program with an empty session. After clicking the icon in the Windows toolbar to launch Audacity, it takes 10-15 seconds before the window appears. With version 2.4.2, the window would open almost instantly.
I did a completely clean install of (64-bit) Audacity 3.0.4 - so, all settings are default. And I’m running this on a brand new laptop, which has an 11th gen Intel i7-11800H CPU, 16GB of RAM, and a 2TB Samsung 980 Pro SSD. In other words, it’s a blazing fast computer. Yet Audacity opens at a crawl. I think I may have to downgrade back to 2.4.2 as a result…
Thanks for the suggestion - I just tried that (deleting the folder at \AppData\Roaming\audacity), but it didn’t make any difference to the startup time.
However, I’ve since solved it - I found this thread, which contains the solution that worked for me (see the last post):
On my computer it’s very slightly different - my microphone devices (there are 2 of them) don’t have an Enhancements tab as shown in that thread - rather, mine have a checkbox called “Enable audio enhancements”. So this is exactly what I did:
Go to Sound in the Control Panel
Go to the Recording tab, select the microphone, click Properties
Go to the Advanced tab and deselect “Enable audio enhancements”
Repeat for other microphone device(s)
After doing this, the average startup time of Audacity was reduced from ≈12 seconds to ≈3 seconds!!!
I’ve tried a number of things for this same issue. What works for me is to close the project and open it again. I am speculating that the issue is how Audacity remembers edits. The more you edit the more it has to remember not only the edit but, the order in which the edits occur. Closing the project, which in my case also closes the application compacts the project and erases the “un-do, re-do” history. When I fire the application back up, it returns to it’s original quick response. I have looked for a way to control this memory but so far, nothing. Hope this helps.
What I did is export the audio to mp3 file.
I re installed Audacity 2.4 and imported this file. I put back all the markings and labels to this and saved it. It works like a charm. No lag nothing.
Now I have also imported this mp3 file to Audacity 3.0 and works fine.
That may have been a side issue of using smaller sound files. But:
DO NOT DO PRODUCTION IN MP3!!
MP3 gets its small, convenient sound files by scrambling musical tones in the show and deleting some of them. It’s pretty clever about it and you can’t usually hear what it did. That’s why MP3 is designed as a final product. Put one in your music player and you’re done.
If you have one in the middle of your edit, you might want to make a new MP3 when you’re done. Making a new MP3 causes more scrambling and deletions. Depending on the MP3 quality you picked, you may be able to hear sound distortions.
Certainly by the third MP3, you will be able to hear the damage, and it’s permanent.
Producing work for a client can cause serious problems. ACX demands audiobook submissions to be in MP3. If you started out with your raw voice work in MP3, that may destroy your audiobook career.
Use Perfect Quality WAV files for all your raw recordings, backups, and Archive Masters. You can use Audacity Projects, too, but those can be brittle. Do that in addition to the WAV files.
Thanks for this update. There were some bugs in early versions of 3.0.x that could have contributed to extreme slowdowns. These were corrected in 3.0.5. (Other unrelated issues introduced in 3.2.0 should be resolved by 3.3 when it comes out this quarter). Glad to hear things are working swimmingly for you.
Thanks for sharing this. I’ve noticed that when I do my final close after a long editing session it can take quite a while. So I may do an “intermediate” close as you do. Perhaps this is is a behavior someone should benchmark.
Peter, do you have any way to benchmark, say, an amplify operation on a 1 hour track, repeated say a dozen times to see if the time increases on each pass ? And compare it with 2.4.2 ?
I can when I’m back in Manchester in the latter half of March (I’m in Zurich right now - and skking in the Alps next week).
I would do this by creating a Macro with the dozen passes of Amplify. All versions post 2.4.2 have a time recordg and reporting mech that can be activated in the Macro. Leland did this ffor me when I wanted to test the performance of AUP versus AUP3 to unsure that we did not get degaradation of processing with the nove to Unitary project.
Leland did build me a retrofit 2.4.2 after 2.4.2 release with this mech in too - BUT I only have that on my PC back in Manchester and not on this Zurich PC, sorry.
That would work. I thought you might have done something similar before. I did some manual testing and I got significant wall clock time variations from run to run. Some runs seemed to take 3 times longer than others in my test so it seems something unexpected is going on here and it is difficult to make any conclusions.
I’ve been conversing online with Leland - he’s been reminding me how to run the Macro-Trace for logging timings.
So I’ve been having fun reviving the skills needed for this - I have already buit (and tested) a 12 x Amplify Macro with timings output.
Not sure whether or not Leland can still get (or remake) the old modified 2.4.2 with Macro-Trace - but anyway I’m off to the Alps at the weekend for a week’s skiing - so will be mostly very off-line/off-grid for a while.
But I can possibly run the tests on 3.2.5 and 3.3.0 alpha over the next couple of days - so stay tuned -in …
Peter.
P.S. It make me realize that I should find some time to document the Macro-Trace which right now is purely very much an easter-egg
Ok So I ran my 12 x Amplify Macro in 3.3.0 alpha on a project with a one-hour stereo track (a generated chirp). I hade to use the alpha build as there is a moonphase issue that sometimes stops the Mac-Trace data being sent to the lastlog.txt log file.
I observed no discernible increase in processing times in the later applications of the Amplify effect:
And before you ask, I have no idea whet the Poll and Yield figures are all about …
I see you have a 5.65 second operation next to a 11.49 - double. Mine was more like 15 seconds next to a 45 second difference. And then it seemed to trail off. But the lag seems more noticeable when you are watching it. As does yours. But why is your trail so far away from the 2nd and 3rd runs (7.36 and 8.23 vs. 5.65 and 6.50) ? That is one of the things I was wondering about.
I decided it was time to document this “hidden” “easter egg” feature:
a) so that I could remember how to do this in the future,
b) so that you (and others) could use this tool for yourselves.
I was lazy, for true test conditions you need to:
a) disconnect from t’interweb, bluetooth abd any other networking,
b) ensure no other apps are running (even inactive).
Me, too. But here’s what I got for amplifying a 2-hour mono track by .01 15 times:
3:16.322
4:03.049
2:02.148
5:08.834
5:24.733
4:08.599
4:26.321
5:00.588
5:24.861
4:12.817
4:28.295
5:05.983
5:26.035
4:14.287
4:26.826
It is curious that the quickest and slowest differ by as much as a factor of 2.5.
The original poster of this topic was logan_carroll. Are you logan_carroll ?
