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?
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?
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.
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:
Your Audacity .au files should be in a directory structure like this:
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.
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?
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.
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).