I’m trying to open a halfway finished podcast edit that was saved as an AUP3 file on my desktop. I keep getting a message: “Audacity failed to read from a file in /User/jbendell/…” I do not have a back up file or a wav file, so this is it. I’ve tried to import it as raw data and I get mostly distortion.
Does anybody have any ideas how to save this corrupted file? I have provided a link via dropbox for any interested parties…
Hi! Having similar issues as others on this thread - please see screenshot below. Was in the middle of editing a podcast episode so any recovery would literally be a lifesaver. Happy to provide any needed info!
Well, your project has thrown quite a curve! I had to run multiple passes on your project in addition to some tweaking (that’s a technical term ). This is the first time I have had to do that with the new tools. Hopefully the “damage” was confined to control information and none of your audio was damaged or missing. In any event, your project now “looks” whole. I just need you to check it that it is OK with you.
I am uploading it now, I’ll send you a link later when I get back from my errands and the upload should have completed.
The file was zipped directly by Windows 10, so I don’t expect that is it malformed. Also, I checked on my machine with a zipping utility called winrar. That did not have any difficulty unzipping the file.
I will try uploading the unzipped .aup3 file directly, but this will take a while.
In the meantime, you can try the following:
try downloading the .zip file again.
try unzipping using “Terminal”.
try unzipping using the free utility “Unarchiver”.
A question came up in this message thread. The repair tools are Windows-Only right? No Macs? Do Macs produce similar errors? If I moved my (normally) damaged AUP3 file from my Mac to a Windows machine, would the repair tools start working?
So we have two different computer types with many different users producing the same error. Doesn’t that reduce troubleshooting to What’s Common?
That means this problem goes away in 3.2.0 or 3.2.1, right? Nobody would issue a stable release which Hindenburgs regularly in a known, expected manner.
I agree, except that the problem in some cases is a user error that the developer’s can’t do anything about.
Things that users can do to keep their projects safe (I think these are all in the manual):
Close all Audacity projects before turning off the computer
If a project says that it is “Compacting” when saving a project, wait for it to complete before shutting down the computer.
Turn off “sleep” / “Hibernate” while working on projects.
(Also recommended for other audio / video editing apps).
Use ordinary internal drives (rather than “cloud” drives or network drives) when saving or opening projects.
(It should be safe to copy / move a project to external storage provided that the project is not open).
Make new unique backups regularly.
No doubt others will have more tips, but these are my top 5 about project safety.
I think that may be a place for extra effort. That failing is not part of regular computer hygiene. It reflects a surprising corporate conflict. Audacity needs internal drives and Cloud Suppliers make their drives appear ordinary and internal.
How about an extra step to make sure when you saved your show to a cloud drive inside a featureless building on the outskirts of Albuquerque that it actually got there? I’m clear that you 'll never get that service to sit still for overdubbing or other precision editing, but having your three part harmony fail is very different from having to tell a client that their production is gone.
That’s a big problem. I don’t think there’s any reliable way that an app can tell if a drive is “normal” or a cloud drive (unless / until the cloud’s synchronisation causes unexpected changes, by which time it is too late).
Interestingly, this is not only a problem for Audacity - there are thousands of reports on the Internet of MS-Office documents being corrupted by cloud storage. Cloud storage seems to be particularly problematic for database-like content, as the file’s time stamp can often lag behind the database’s current state. The cloud server (someone else’s computer) can think that it has a more recent version of the database, when in fact the local state has changed since that snapshot - if the cloud service decides to synchronise at this point, the database is corrupted, and there’s very little that the app can do about it.