I record for Librivox and have been running into sluggish recoveries after editing longer files. I’ve posted there, but it seems like others aren’t experiencing the same problem so I thought I ask here:
So, here’s some stats:
Audacity 2.0
Windows Vista SP2
2.5 GHz dual processor PC with 4 GB of RAM)
(defragged! This was one of the Librivox suggestions - I’ve done it.)
The problem occurs after I’ve saved the file and come back in a subsequent session to edit. If I edit during the initial session I have not had problems, but with longer files especially I usually edit over several sessions.
Loading a 58 minute .aup file takes 1:18. If I delete 1/2 second of the file it takes 1:09 before I can continue editing. (Length of the edit doesn’t really matter. I get the same lag if I delete a minute as I do if I delete 1/2 a second.)
If I cache the entire 58 minutes piece into RAM it takes 1:14 for the file to load and another 2 minutes to copy the file into RAM. If I delete 1/2 second of the file it takes 1:09 before I can continue editing.
In other words, caching the file in RAM does nothing to help with editing and I actually lose time during the load.
Comparatively:
A 9:58 file takes :15 seconds to load and :15 seconds to recover before I can continue editing if I delete 1/2 second.
A 25:00 file takes :45 seconds to load and :39 seconds to recover before I can continue.
Conclusion: there appears to be a nearly 1:1 relationship between how long it takes to load the .aup file and how long it takes to recover from an edit.
Following the suggestions on the Librivox forum I saved the file as a FLAC. The FLAC file imported in :50 seconds and recovery from the edit was essential instantaneous.
This reinforces my gut feeling that, once I’ve saved a file, Audacity is reloading the file after an edit, but I really don’t know what’s going on. At any rate it’s clear that, at least for me, the best thing to do with large files, pending a better suggestion from one of you, is to export as a FLAC and edit that in subsequent sessions.