When trying to export a project with a large number of separate audio clips, Audacity freezes during the export process and I have to quit it via the Win Task-Manager. Don’t know if it would eventually unfreeze, didn’t have the time to wait for it…
I have a stereo track with 36 separate audio clips, a total length of 1m 38 sec. There’s a second track with some background music on it, but that one doesn’t seem to be relevant to my problem. As I said, trying to export the chopped up clips results in a freeze, but when i copy / paste everything and glue the clips into one large clip, the export works. The number of separate clips seems to cause some trouble.
The freeze happens on different computers, so I don’t think system specs have anything to do with it.
There’s no crash report generated since the app doesn’t technically crash before I kill it with the Task-Manager.
I would upload the project file, but it’s to large to attach here even when Zipped.
Audacity 3.1.0
Win10 Pro, version 20H2, Windows Feature Experience Pack 120.2212.3920.0
Intel(R) Core™ i5-6200U CPU @ 2.30GHz 2.40 GHz, 8GB RAM
currently 60/404 GB free disk space
If Windows pulled the rug out from under Audacity before it gracefully exited, then it crashed.
to large to attach here even when Zipped.
The forum doesn’t support content postings larger than 2MB. Sometimes Jademan will offer to look at a broken Project and tell you to post your Project on a file management service such as DropBox. Since he’s the only one with the ju-ju to bring a Project back from the dead, we should wait for him.
However, rescuing a badly damaged Project isn’t your problem. You want to know why Audacity seems to refuse to edit what should be a perfectly well-behaved show.
I don’t know. Someone else may post.
However I note you do seem to have a way to make Audacity mis-behave on cue, I can imagine that the Developers may want to chat with you.
thanks for your answer, that’s the first thing I tried.
Copy/paste into a new project didn’t solve it and then exporting everything in shorter chunks didn’t point towards any single clip as this method worked perfectly. To clarify, I’ve already found a workaround and my problem is solved. But again, I appreciate your reply. I just posted this here to inform the devs. Is there a specific subforum for this? I’m new around here and I must admit I didn’t do a whole lot of looking around before this post. And yes, I have the project file ready for them as soon as they show up
Actually, can you send me the project file (maybe DM me a link to a dropbox/google drive/…)? I think that’d be helpful to figure out whether our fix actually fixes your problem.
I’m afraid so. 3.1.1’s primary was concern was to fix FFMPEG imports (it only was importing the left channel), with a secondary goal to improve performance with clips. We also fixed some crashes on the way, but unfortunately, your crash wasn’t fixable by what we attempted.
Your project is weird. You somehow have clips with negative lengths (around 1m09s), and your crash isn’t related to any performance problems we tried to fix: I can get your project to crash by just exporting the last and first sample of the cut around 45.5s, for example. Also, if you try to merge all of the clips by clicking the black lines between clips, you’ll note that around 16s, you have two clips which cannot be merged, but also there’s one of those yellow snap-lines at 13s. If you attempt to resize the left clip, it’ll jump to 13s, so you somehow managed to expand a clip beyond its borders.
All of these bugs do need to get fixed, but were out-of-scope for 3.1.1.
You somehow have clips with negative lengths (around 1m09s)
And that snaps us back to: where did you get the clips from? Were they actually produced by a sound recorder or other audio device, or did you make them up from other digital services or bitstreams.
There’s a note from your first post.
There’s a second track with some background music
These clips aren’t sound, are they? or at least they didn’t start out that way.
What’s the show or job? Describe why we’re doing this.
The cut up audio with the strange behaviour is a voice track recorded in our radio studio directly with Audacity. No processing at all.
The background music is an ordinary mp3.
These clips aren’t sound, are they?
I don’t know what you mean. What else would it be?
Cut up or edited so tightly they’re not good sound any more.
According to LWinterberg who analyzed the clips, some of them reported ending before they started. That means a part of the file (header??) was damaged.
Audacity will not always do every job and some of the posted failures have to do with non-sound applications.
So what’s your job? There may be ways to do it other than what you’re doing.
That would be a fault in Audacity’s internal book keeping. Each audio clip has “properties” of start time and end time, and “end time” should always be greater than “start time”.
