We recorded 32 tracks in one Project called “maik_olove29052021.aup3” and closed audacity 3.0.2 on Windows 10 – after reopening audacity days later and minimizing the tracks to get a clear overview audacity crashed and I ended it by taskmanager in Windows 10.
The crash happened after clicking on “Ansicht → Spurgröße → an Höhe anpassen (CTRL+Shift+F)” after minimizing the tracks by hand.
After reopening audacity again after the crash the following dialog appears to recover the corrupted project:
[compare attachment: “audacity_3.0.2_windows10_corrupt_project_recovery_freeze.pdf”]
Then it takes forever after clicking “Ausgewählte wiederherstellen” while audacity is reporting “not responding” or in german: “Keine Rückmeldung” in Windows 10.
So nearly 1 GB of recorded sound is lost.
Can I somehow recover the “maik_olove29052021.aup3” project with other tools or tricks ?
Beste regards and thanx anyway for this great tool!
Success is unlikely, but you can ‘try’ downloading the current alpha build from here to see if it recovers your project: https://github.com/audacity/audacity/actions/runs/899225659 - For Windows, you will want to download the item: Windows_32bit_9f1d5d5
Note that alpha builds are available for testing purposes only. They likely contain errors/bugs, they are not supported, and should NEVER be used for production work - work on a copy! I would recommend waiting a little bit first, to see if a developer responds…
Hi Peter.
I don’t know exactly why audacity crashed but it did while just toggling with the view of the project (32 tracks) recorded some days earlier.
The audacity process wasn’t responding anymore (no more interaction possible) afterwards so i killed it via taskmanager.
After that the project file (.aup3) seemed to be corrupted and the integrated recovery tool (compare attachment: audacity_3.0.2_windows10_corrupt_project_recovery_freeze.pdf) also results in audacity not responding anymore.
Nevertheless I left audacity open to give the recovery process a chance for about 2 hours, but nothing happened, except that the audacity process RAM usage rises up to 600 MB and then freed it and startet over again to allocate RAM up to 600 MB and so on…
I installed audacity 3.0.2 (https://www.fosshub.com/Audacity.html/audacity-win-3.0.2.exe) short before starting the recording last saturday.
To be precise I installed it over an older version of audacity which I installed some years ago - I think it was audacity-win-2.0.5.exe
I just hab a look into the C:\Users[username]\AppData\Roaming\Audacity\audacity.cfg
I states “Version=2.0.5” in the first line.
But before recording I checked via GUI “–> Help → ~Version” and it stated 3.0.2
During that recording day we had no problems with audacity 3.0.2 - neither recording the 32 tracks nor exporting a single track in .wav format.
After each recording we saved the project and all went well.
I tried to recover the corrupted project with both 64Bit (Windows_64bit_9f1d5d5) and 32Bit (Windows_32bit_9f1d5d5) version of audacity 3.0.3-alpha-20210602. Both result in the same behaviour as audacity 3.0.2.
At first I tried the 64Bit version (because I have a 64Bit Windws 10) and let it “calculate” (or better “freeze”) up to 3h with no successful completion of the recovery process.
The second try with 32Bit version I terminated after 30 minutes of freezing.
I uploaded “taskmanager_details.pdf” with two screenshots of windows taskmanager.
I’m getting involved, but please don’t be too hopeful that this will work.
I’ve worked with two corrupted projects that have been sent in, and got one back with some drop outs (not good as even a few drop outs can wreck a recording), and one recovered back to a slightly earlier stage than when it was saved.
First thing is to make a copy of the file, and only work with these tools on the copy. Make a copy of the aup3, call it broken.aup3.
Unzip in some directory, and put broken.aup3 in the same directory.
[If this is or gets too complex or unclear, say so and we’ll do something different].
Now run a command prompt. (Click the magnifier in Windows task bar at bottom left, and type cmd to do this).
When the command prompt appears, change to the correct directory where sqlite3 is, by clicking in the command prompt window and typing for example:
cd C:\Misc\Sqlite\
Then type
sqlite3 broken.aup3
We’re aiming for something like this:
You can see other commands I’ve typed in like ‘.tables’.
This will tell me how many rows there are in each of the three tables. This tells me something about how the project is broken, and will help me know what to do next.
If these instructions are too complex, we’ll find another way instead.
If you had 32 tracks, then those 904 audio blocks are for about 3 minutes worth of audio, or half that if the tracks were stereo. There’ll be a hopeless amount of missing audio.
There is therefore very low chance of being able to recover something useful from this.
Please though try this:
Again open the command prompt, and this time type:
(The ‘|’ symbol is to the left of Y on a German keyboard)
If that completes without an error message, it may take about two minutes to do so, then do the previous steps to see how many sampleblocks there are now, this time for unblock.db:
(Mine shows 17 sampleblocks because I’m demonstrating with a tiny project.)
Do not rejoice if there are now many more than 904 audio blocks. They in all probability are not useful ones. If there are some more blocks, we can though do some steps to see if they match up with the blocks that are needed.
If there is a table called lost_and_found, then also do a select count(*) for that table too. That could have ‘lost blocks’ in it too.
I’d hoped for a lost_and_found table, and some more audio blocks.
As it is, too many blocks have been lost for recovering the 904 to be useful. The likelihood is that they are randomly located, making them useless.
How big is the unblock.db file?
Purely out of interest, make a copy of unblock.db called unblock2.aup3 (do not just rename it).
Having done that, attempt to open unblock2.aup3 in Audacity.
I’m interested in whether it hangs or gives a message or other diagnostic.
I think at this point actual recovery is off the cards and at best we are trying to understand more about what went wrong, so we have more chance of preventing this kind of disaster happening to other people. For example, I would expect unblock2.aup3 to be a lot smaller than maik_olove29052021.aup3, and I would also expect it not to hang when opening Audacity. If it is large, or if it hangs, then that gives a clue to what went wrong.
Next time I give audacity another chance by probably better exporting raw data (e.g. wav) of each track after successful recording and saving the project, to have something to recover from
Here are the results of the last analysis attempt:
→ After trying to open the “unblock2.aup3” audacity says:
~“Error opening project - this is not a audacity project-file”
Show protocol:
14:24:50: Retrieving FFmpeg library version numbers:
14:24:50: AVCodec version 0x373466 - 55.52.102 (built against 0x373466 - 55.52.102)
14:24:50: AVFormat version 0x372164 - 55.33.100 (built against 0x372164 - 55.33.100)
14:24:50: AVUtil version 0x344264 - 52.66.100 (built against 0x344264 - 52.66.100)
14:24:50: Returning PATH to previous setting: [DELETED PATH INFO FOR DATA AUSTERITY];
14:24:50: FFmpeg libraries loaded successfully.
14:25:02: DBConnection SetError
ErrorCode: 0
LastError: This is not an Audacity project file
LibraryError:
Oh that makes sense. I’d forgotten that the “.recover” thing makes the file forget that it is an Audacity project.
maik_olove29052021.aup3 is about 0.9GB. If you want to upload it to (say) Dropbox and share with me I can see what is in the 904 block files, and understand better why it does not open in Audacity. Almost no use to you, but maybe helps progress understanding of problem(s).
Thanks you so much for sticking with us through the steps, for sharing your corrupted project and for the description of how the project got broken in the first place. I’m really glad that this had a good outcome for you of full recovery of the file, in the end.
The reason it was possible to recover was that the database was fully intact. What had gone wrong was that a value for the height of a track had reached an astronomical number, and Audacity was trying to draw a track several miles high and taking a long long time about it - hence the ‘not responding’. This was an overflow error in Audacity when dealing with a negative value for height. The bug number, if you are curious, is here https://bugzilla.audacityteam.org/show_bug.cgi?id=2803 and this is fixed in version under development 3.0.3 which Dmitry is release manager for, and which we don’t have a definite date for yet, but I am guessing within a month from now.
Again thank you, and I’m glad it had a good outcome.
