Good Day!
Im working on a recording…
saved it on a folder… when i opened it again, its gone…
however i dont know what happened…
when, i tried to open it, the .aup file was not there anymore.
although the _data file folder is still there…
is there any way i can recover my .aup file?
or maybe merge the files in the _data into a single .aup file?
please help… thanks…
Try looking in the Recycle Bin.
If not, please see: http://wiki.audacityteam.org/index.php?title=Crash_Recovery#Automatic_recovery_tools . This means you will have to do sorting and renaming of the AU files in the _data folder, then use the 1.2 Recovery Utility to make a new WAV file or files, then piece together the recovered WAV files if you have a very long recording.
Or, if you don’t mind installing python 2.7.6 , there is a script you can try which would attempt to create a new AUP file from the data, then you would just open the recreated AUP file. See: https://forum.audacityteam.org/t/alternative-recovery-tool/30964/6 .
Gale
thanks gale, tried the python thing… it did merge the .au files but to an unusable file… it didnt restored back… it skips and skips… thanks though… guess i have to do this recording all over again…
Or, if you don’t mind installing python 2.7.6 , there is a script you can try which would attempt to create a new AUP file from the data, then you would just open the recreated AUP file. See: viewtopic.php?p=223406#p223406 .
How about we install and run the recovery tool that comes with Audacity?
Koz
This is Hollywood sense of humour, right?
Gale
Had you edited the recording? If so, the python script has the same limitations as the manual resort and rename - the AU files sorted by time modified won’t remain in the correct timeline order.
Gale
This is Hollywood sense of humour, right?
Their stuff is usually a lot funnier.
there is a script you can try which would attempt to create a new AUP file from the data
So somebody did the concept, structure, programming, troubleshooting, bug fixes and posting of a Python script to produce the holy grail of Project Rescue, but it’s not an Audacity-wide product? Isn’t fully 80% of the work done?
Correct me, but a native tool would directly impact the ability of the average user to produce a show under the stress of a damaged or missing AUP file.
Isn’t Audacity’s raison d’être to produce a show?
Koz
Do we expect users to install python now, as well as LAME and FFmpeg?
Do we assume they understand how to open a command prompt at the folder where the python program and the _data folder is?
Do we expect them to know what command to type to call the program?
If they got that far, would the average user understand this:
C:Python27aa_data>python aup_recover.py
Your Audacity .au files should be in a directory structure like this:
<basepath>/<projname>_data/e*/d*/*.au
The current directory = C:Python27aa_data
Please enter <basepath>. If it is the current directory, just press enter.
:
Have you (Koz) used this tool yet after consigning the AUP to digital oblivion?
Obviously the tool is not suitable for release. It would need to include or dll-embed the required python libraries and have an interface, like the 1.2 Recovery Utility. Until then, resorting and renaming the AU files then use the 1.2 Recovery Utility will be what most users need to do.
I’m only now judging if the tool is good enough to mention on wiki. The tool did not work in the above case, but I’m still assuming this is because gptns had edited the project.
If this tool still tests fairly well then I’ll ask pjaytycy if he can make it at least self-contained, not requiring to install python. Unless of course you’re going to do that for us.
Only an unedited mono recording would open completely correctly, as per the limitations already mentioned.
Gale
Obviously the tool is not suitable for release.
It’s not, but the suggestion was whoever designs a “finished” recovery product has to start from dead zero. That’s incorrect. Some of the philosophy and proof-of-concept programming has been done. The development ball is rolling.
Unless of course you’re going to do that for us.
In my dreams. I go to some measures to avoid giving anybody extra work, but it seems to me the ability to conveniently turn accidental trash into a working show should be very near the top of development efforts, given that producing a show is Audacity’s Mission Statement.
I understand anybody who creates any edits is dead. There is no way to recover from that, convenient or not. But given the development team wrote the live capture file structure, having a computer go to never-never land during a recording should not spell the end of the world, stereo or not.
What’s the difference between sorting by time/date and what the script does?
Does auto recovery really fall that often, or we just get the piles of rubble on the forum?
Koz
I would much prefer that those developer hours went into developing a robust unitary project format.
From personal experience, auto recovery is surprisingly/delightfully effective. Now if they could just stop Audacity freezing so frequently with PulseAudio then I would not need to use auto-recovery so often.
Which for me makes the tool unsuitable for release as part of Audacity. I don’t think that we should be shipping tools that are more likely to fail than to succeed (no need to discus “Vocal Remover” here). Not a problem for a stand-alone application or optional plug-in.
I’ve not tried it, but this looks like a possibility: http://www.pyinstaller.org/
I’m inclined to agree.
Audacity does sometimes fail to produce an AUP file when saving a project. These aren’t all user errors or disk flakiness. We should probably do internal checking that the AUP file was present and correct when saving the project, if not go back and do it again. There’s no need to fix that exact issue if there was a unitary project format.
Bug 137 ( Unreliable project re-opening with orphaned and missing blockfile errors) still exists and has the ability to delete AU files or move them to other projects. Bug 137 itself is very rare but not fixed and given its rarity, probably never will be. A new unitary format would probably fix Bug 137.
I’m inclined to agree here also. Even with the current AUP and _data folder system, Audacity ought to be able to recover edited projects and unedited stereo recordings when the AUP file or autosave file is missing. It ought to be possible by including some kind of metadata in the AU file that tells Audacity where that file goes in the project.
Any new project format should have that kind of recoverability built into it.
There is only a need for file renaming while sorted by timestamp when the files are fed to the 1.2 Recovery Utility which expects a consistent naming sequence.
The new script just assumes that whatever the file names are, the way the OS timestamp orders the files is their order in the project.
If you want perfect recovery of an unedited stereo recording, the only current way on Windows seems to be a manual time sort and rename using xplorer2 pro or PowerShell (comes with Windows 7 and later). Those methods can (if it’s a NTFS system) get accurate enough timestamps to determine which AU of the stereo pair came first (the left channel is always written before the right channel).
Thanks, Steve. I might try that on Windows.
Gale
There is only a need for file renaming while sorted by timestamp when the files are fed to the 1.2 Recovery Utility which expects a consistent naming sequence.
OIC.
Applescript appears to be still available on every Mac (except possibly the stripped-down ones).
Python comes pre-installed on Mac OS X, but due to Apple’s release cycle, it’s often one or even two years old.
I don’t think that’s going to be much of a hinderance.
Koz