Audacity failed to read from a file (Mac)

Hi all -

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…

Thank you for listening.

  • Justin

I’ll take a look at it. :smiley:

See also: Corrupt or Otherwise Broken Audacity Project Recovery

Note that this recovery tool will not run on MacOS.

Thank you!

You are welcome. :smiley: I have PM’d you a link to the recovered file. :smiley:

jademan – you are a wizard. i owe you a thermos of coffee & 1000 mini-muffins.

Next time we meet I’ll take you up on the offer. :wink: A thousand? :smiley:

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!


Also, if it’s helpful the message I keep getting is “failed to open database” “database disk image is malformed”

If you care to upload the .aup3 project to a public file sharing service, then post (or PM me) a link, 'll take a look at it. :smiley: However, I’ll be out of town, so I can’t get to it until much later today.

Note that if you access to (or a friend with) a Windows machine you can fix this problem yourself: Corrupt or Otherwise Broken Audacity Project Recovery

This recovery tool will not run on MacOS.

The file is in the folder linked here: Audacity Image - Google Drive

Thanks so much!

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 :smiley: ). 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. :smiley:

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. :smiley:

So the upload just finished! I have PM’d you the link. :smiley:

Thank you so much! One last question: I’m having some trouble opening the Zip file I keep getting an “Inappropriate file type or format” message. Do you have any advice? Thanks again!


The file was zipped directly by Windows 10, so I don’t expect that is it malformed. :open_mouth: Also, I checked on my machine with a zipping utility called winrar. That did not have any difficulty unzipping the file. :slight_smile:

I will try uploading the unzipped .aup3 file directly, but this will take a while. :smiley:

In the meantime, you can try the following: :ugeek:

  • try downloading the .zip file again.

  • try unzipping using “Terminal”.

  • try unzipping using the free utility “Unarchiver”.

  • wait for another .aup3 upload/download cycle. :smiley:

So the uncompressed upload has completed. I have PM’d you the link. I hope this works better for you. :smiley:

Hello! I am having the same issue with a corrupted file on a Mac system. Trying to get ahold of a Windows computer so I can fix it myself but I am really in need of recovering this file!

I would be so so grateful for help if possible in repairing the corrupted file if anyone is able to help. Thank you in advance!!

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.

Use ordinary internal drives

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.