Recovering .au files after crash

I was in the middle of an important recording when my computer suddenly froze, seemingly because of an audacity crash.

I rebooted my computer hoping that I would at least be able to recover what was recorded up to that point, but after clicking recover project I received the “file inconsistencies error” and was told to check the log, which said " Warning: Project check replaced missing audio data block file(s) with silence and “Warning: Project check found file inconsistencies inspecting the loaded project data.”

Consequently the entire project is silent. I quickly went to the boards to try to find a solution, but would like a more direct answer as most posts I’ve seen have not been helpful to me. I have not saved the project yet, as most posts have said that once that happens all hopes to recover are lost. I found the temp folder and .au files associated with the project, so now I’m just looking for next best steps to get the project fully recovered. Can someone please help as soon as they can? :unamused:

Are you really on Mac? Please give us the model number of the Mac and the version of OS X and Audacity (see the pink panel at the top of this page).

Are you using a USB recording device? If so, connect it to an empty USB port, not to a USB hub that connects to the USB port.

If you are on Mac, I recommend opening Finder, Go > Utilities > Disk Utility. Select your system drive and Verify Disk and then when that’s done, Repair Permissions.

Yes, you must either leave Audacity open, or force quit it until you have solved the problem. You must not save the project with silent data and must not close the project without saving changes.

The log shows you the location the AU files should be in, so I would check the folder structure in the temp folder. The data should be in d* folders inside one or more e* folders, maximum 256 AU files per d* folder.

If that does not work, please see Recovering crashes manually - Audacity Manual. That gives you steps to timesort and rename the AU files then use a recovery utility to make new WAV file from the recording.


Gale

log.txt (2.7 KB)
Hi Gale,

Thanks for the response!

I do have a Macbook Pro. The Model number is MD101LL/A, the version of OS X is 10.9.5, and my version of Audacity is 2.0.5.

I was using a four channel Akai USB mixer to record the audio. I have since disconnected the cable linking my computer to the mixer. I’ll go ahead and Repair Permissions in Disk Utility as you have suggested.

The log changed when I reopened and now shows different errors. Here it is attached for you to have a look.
log.txt (2.7 KB)
As stated I was able to find the temp folder via the Finder. It looks like all the data is there, but how do I check the folder structure to make sure Audacity is reading from the right place? I must add that I created a copy of the folder to my desktop to facilitate the audacity autorecovery process since Audacity could not read the data from the original file path to my temp folder. Should I delete the copied folder since I still have access to the data via the original temp folder?

-Erick

Quick Update:

I was literally just in the middle of a separate recording and Audacity crashed again. My computer didn’t freeze this time so I didn’t have to manually reboot. When I was asked to reopen Audacity it once again took me to the recover projects prompt and I hurriedly clicked recover projects. This time, the recording I was working on minutes earlier was able to be fully recovered up to the point where it shut down. However, the recording from Monday popped up as well and it was unfortunately still silent. Not sure if that can give you any additional insight into my issue, but I’m fairly certain that the data from Monday is still sitting in the temp folder begging to be retrieved. Please assist at your earliest convenience!

-Erick

Did you do Verify Disk as well?

So you force quit? All that log shows of possible relevance is the “Error: Failed to get file system statistics (error 2: No such file or directory)”.

Did you look in the log after you recovered the silent project the second time (when you were recovering the later recording)? If the Log says files are missing, are those files in exactly the correct path to the folder stated in the Log, not just in the correctly named folder?

Audacity is trying to recover the projects from the “AUTOSAVE” files at ~/Library/Application Support/audacity/AutoSave. The data folder Audacity is looking for is shown as “datadir” in the AUTOSAVE file and is an absolute path.

If the only times you quit Audacity you force quit, the temp data for your first recording should still be there, otherwise it won’t be.

If you want to point the AUTOSAVE folder to your copied folder, you could carefully change the “datadir” to your copied folder. The top folder(s) in that copied folder should be e00 and perhaps e01 and so on, then in “e00”, there should be d00, d01 folders and so on.

Attach the AUTOSAVE file for the troublesome project if you are not sure.

However if your latest recording that crashed was never saved as a project, it seems Audacity can read the temp directory OK in that case. For new recordings, I suggest saving a project before starting to record, so leaving the temp folder alone until you have sorted the problem out.

And yes you will have to force quit again having recovered silence in the troublesome project. :frowning: If you drag some of the AU files from that temp folder into the Audacity window, are they silence?


Gale

I verified the system disk. Should I verify and repair the Audacity disk image as well?

I did force quit via Command+Option+Esc so not to lose the data files.

I just opened the log again and I’m still getting “Error: Failed to get file system statistics (error 2: No such file or directory)”

See below:
log111914.txt (4.94 KB)
Attached here is the AUTOSAVE file:
New Project - 2014-11-19 13-27-02 N-1.autosave (492 KB)
And yes, when I drag the AU files into Audacity they are still silent :cry:

-Erick

I think the file paths might be messed up? Is there a way to correct it?

See Attached:
Screen Shot 2014-11-19 at 9.12.24 PM.jpg
-Erick

I don’t think so. Just re-download the DMG from Audacity ® | Download for Mac OS if you are in doubt.

When you force quit Audacity and attempt to recover this project now, are you getting a dialogue about consistency errors that invites you to look at the log?

What happens if you do the following test? Force quit Audacity. Rename the AUTOSAVE file you want to recover to AUTOSAV extension or something else then Audacity will not try recover it. Launch Audacity, record a few minutes then force quit Audacity. When you launch Audacity and recover the project, do you see “Failed to get file system statistics” in the log?

Do you see that message if you close Audacity normally then launch it without trying to recover projects?

If the message persists try force quit of Audacity if it is running, then in Finder, use Go > Go to Folder and type:

~/Library/Application Support/audacity

Using TextEdit, edit the “audacity.cfg” file. Select and delete all the text and replace it with just this single line:

NewPrefsInitialized=1



The AUTOSAVE file looks OK structurally to me, but most of the volume levels of the AU files are at -50 dB or below. This would look like silence in Audacity’s Waveform view. Might you have recorded that low? What happens if you Effect > Amplify… the recovered project?

That said, if all the AU files were automatically replaced with silent block files in the first attempted recovery, the fact that the AUTOSAVE file has the correct amplitude values doesn’t help. This contrasts to the situation where if you open a saved project that Audacity thinks has missing AU files, Audacity gives you the option to ignore the missing files and not to permanently replace them with silence.

If your issue was that Audacity could not read the disk when you first recovered the project, an option to ignore the missing files so you could try again would prevent your data being silenced. This should be raised with the developers I think, but please try amplifying the recovered project as above.

You would have to double-click the “e00” folder so we can see what is in that.

Was the second recording that crashed also made with the AKAI mixer? We should try to prevent the crashes happening in the first place. What is the model number of the mixer? Does it have drivers or firmware for OS X that you can download?

And can you find the Audacity crash reports? Open Finder, Go > Go to Folder and type:

~/Library/Logs/DiagnosticReports/

Gale

I’m no longer getting a dialogue prompt about consistency errors. The project simply opens and is still fully silent.

Now my log says this. See attached:
Failed FFmpeglog.txt (2.61 KB)
When i change the name of the AUTOSAVE file the session no longer opens up in Audacity at all.

I just recorded a few minutes, force quit, then launched again. I’m now getting " Error: Failed to find compatible FFmpeg libraries," as stated in the log I attached above.

I haven’t tried closing it normally since Monday. I’ve been force quitting via the Command+Option+Esc shortcut. Are you saying that I should quit Audacity as I normally would?

Attached are two examples of the “e00” folder.
Screen Shot 2014-11-20 at 10.33.27 PM.jpg
Screen Shot 2014-11-20 at 10.32.46 PM.jpg
The second recording was with the Akai mixer. I have been using it since Monday with minimal issues. The model No. is A102.

For some reason the forum won’t let me attach the crash report…not sure why.

Should I change the AUTOSAVE file back to its original name? Let me know what else I can provide. Thanks a bunch for your help and patience thus far!

So using Effect > Amplify on the recovered project or on any of the AU files makes no difference - the audio is still silence? When you open Amplify on the project or on an AU file, does “New Peak Amplitude” say “-Infinity”?

That is normal if you have not installed FFmpeg.

Yes. That is expected if you change the extension to something other than AUTOSAVE. I wanted to see if you did that whether you see any log messages except for FFmpeg.

OK so you no longer have the error about “Failed to get file system statistics”. That is good.

You have to keep force quitting so that Audacity doesn’t remove the temporary data.

Structurally that looks OK.

That model seems to be obsolete. You would have to contact Akai directly for help with drivers and firmware.

I have added the “.crash” extension to the allowable uploads so please try again. You can also rename the crash log to have “.txt” extension (without the quotes).

If you do that Audacity will offer to recover the project.

But to be honest, I’m afraid if the AU files in the temp folder and in the copy you made are reported as “infinity” by Amplify there is nothing to useful to recover. I assume Audacity could not read the temp folder for whatever reason so silenced the AU files without asking. The only consolation is that the recording was at a hopelessly low level according to the AUTOSAVE file, so would be noisy when you amplified it.


Gale

Here is the crash report:
Audacity_2014-11-19-115753_Ericks-MacBook-Pro.crash (43.7 KB)
I’m afraid the AU files are reporting as “infinity” I’m assuming all hope is lost at this point? Is there a reason why Audacity would silence without asking?

Really appreciate all the help.

Thanks for that. The crash seems to be to do with the Snap To checkbox at the bottom of the Audacity window. Had you enabled that box or were you changing it when Audacity crashed?

If you get the latest 2.0.6, Snap To has changed to a dropdown menu, and whatever the problem is might not occur in that version.

I fear so, short of TIme Machine having backed up those files and having had time to do so. It does not backup what it regards as temporary files but I can’t (without testing it) give you a definitive answer on whether it would back up the default Audacity temp folder.

Not fully sure without discussing it with the developers. If you reopen a saved project and there are missing AU files or “orphan” AU files that should not be present, Audacity provides a dialogue that lets the user choose what to do.

For recovery of unsaved changes, no such dialogue is provided. Missing files are replaced with silent files immediately, and orphans are deleted when the project is saved (the latter makes sense because 99% of the time orphans are redundant files that were meant for Undo/Redo).

The dialogues were worked on as part of trying to fix bugs that caused project errors when reopening projects. In contrast, recovery is usually very reliable - if it can read the data.


Gale