Audacity Forum

smeezekitty wrote:So Audacity crashed after I just completed a 4 hour recording. More than a little annoying.

Are you still on Windows Vista? Are you using Audacity 2.0.6 from http://audacityteam.org/download/windows?

smeezekitty wrote:I opened it up and selected "Yes" to recover. It recovered okay and I went ahead and hit save. But while it was saving, I realized I was saving to the wrong disk drive and hit "cancel" which caused Audacity to crash again!

Was that a cancel during save project data? That doesn't crash for me on Windows 7/Audacity 2.1.0-alpha, after having recovered a deliberately crashed recording.

smeezekitty wrote:This time autoreceovery didn't work and the "recovered" file has no tracks.

Have you looked at the AUTOSAVE file Audacity was trying to recover from? Assuming you are on Vista or later it's at Users<user name>AppDataRoamingAudacityAutoSave. Post the AUTOSAVE file in case there is a simple error we can correct in it. Please see here for how to attach files: http://forum.audacityteam.org/viewtopic ... 49&t=64936.

Also if there is a TMP file in the AutoSave folder it may be possible to rename the TMP file to AUTOSAVE then see if Audacity can recover from that.

smeezekitty wrote:Manual recovery is next to impossible thanks to the randomly named temporary files.

Not impossible with an unedited recording, but definitely some work is needed to time sort and rename the files. See http://manual.audacityteam.org/o/man/re ... ually.html if you have not already looked at that.

smeezekitty wrote:Audacity should really crash less

But what version of Audacity and where did you get it from? Have you checked your sound card drivers: http://wiki.audacityteam.org/wiki/Updat ... ce_Drivers?


Gale

steve wrote:

smeezekitty wrote:Is there ANY benefit to the highly convoluted file naming?

The current "highly convoluted" system is actually very simple in terms of code (which does the work). Picking an unused random number is both easy and very fast and avoids needing to track which number was used last (and avoids other complexities such as handling "wrap around" when the available numbers are used up, or other possible causes of file name collision which would cause the project to fail).

Well that may be the official line, but Audacity never puts more than 256 files in a folder and every folder path is unique even if files are moved to another subfolder when editing.

Still as Koz says it would be better to move to a new unitary project format without the _data folder than try to reinvent the random file name system.


Gale

kozikowski wrote:Someone will correct me, but if you start the night by saving a project, it arms Audacity so it can do future saves very rapidly. It doesn't have to do all the housekeeping and file management. It just has to change a tag here and there.

There isn't any speed difference between recording into an unsaved project and recording into an already saved one, but if you record into a saved project you avoid the wait that you would otherwise experience while Audacity moves the recording from the temp folder to the _data folder for the project.

In the next 2.1.0 version of Audacity, recording a Timer Record into a saved project will automatically save the project when the recording ends or if you stop the recording early.


Gale

All the programming talent will be working on the Unitary File Format.

Save a one file Project instead of the current system of XML text files, _DATA folders full of hierarchical directories, snippets and graphic files, etc., etc.

The goal is a single "photoshop" file which opens up with all your layers, channels, paths, colors etc. intact from when you saved it.

That sounds like a good idea. Just as long as there is a recovery system.

I don't know that anybody is really excited about that. You can do that with FireWire drives. They're high-speed, bi-directional/full duplex. No negotiating. No delays. I used to run machines fully on external FIreWire drives instead of internal drives. Doesn't work with USB. Or it didn't.

Huh? USB works fine. Saving can be a little slow but I have never had data dropouts or anything

The current "highly convoluted" system is actually very simple in terms of code (which does the work). Picking an unused random number is both easy and very fast and avoids needing to track which number was used last (and avoids other complexities such as handling "wrap around" when the available numbers are used up, or other possible causes of file name collision which would cause the project to fail).

That doesn't make much sense. Considering the additional code complication for things like name collision detection, I find it hard to believe random names would be faster or easier.

Are you still on Windows Vista? Are you using Audacity 2.0.6 from http://audacityteam.org/download/windows?

Yes still using Vista. I am using Audacity 2.0.5 downloaded from the official page on sourceforge. I didn't realize there was a 2.0.6

Was that a cancel during save project data? That doesn't crash for me on Windows 7/Audacity 2.1.0-alpha, after having recovered a deliberately crashed recording.

Yes. I canceled saving and there was an error to effect of "Cannot write file" and something about the disk being "full or write protected" (I didn't get the exact error)
But there was no disk problem and it wasn't full. Seconds after "oking" the error, Audacity crashed.

But what version of Audacity and where did you get it from?

Sourceforge

So if I save the project FIRST, does it increase chances of recovery?

I attached the autosave file. Since it doesn't have any of the .au file names, I don't think there is much chance of recovery.

"Cannot write file" and something about the disk being "full or write protected"

That's one of the errors you get when you put punctuation marks in the filename. Windows goes charging off looking for a drive, folder or directory that doesn't exist.

That happens when people put dates in a filename. Today is not 2/15/15. It's 2015-02-15 the ISO version. The one with the slashmarks is a Windows directory structure or option identifier. I forget which.

Koz

smeezekitty wrote:That doesn't make much sense. Considering the additional code complication for things like name collision detection, I find it hard to believe random names would be faster or easier.

See DirManager.cpp::MakeBlockFileName()

smeezekitty wrote:

Was that a cancel during save project data? That doesn't crash for me on Windows 7/Audacity 2.1.0-alpha, after having recovered a deliberately crashed recording.

Yes. I canceled saving and there was an error to effect of "Cannot write file" and something about the disk being "full or write protected" (I didn't get the exact error)
But there was no disk problem and it wasn't full. Seconds after "oking" the error, Audacity crashed.

Well you say there was no disk problem, but how do you know? Windows reported a problem. You may want to do a SMART check: http://superuser.com/questions/154337/u ... ive-health.

smeezekitty wrote:So if I save the project FIRST, does it increase chances of recovery?

It could make it easier if there is a crash when first saving the project. If such a crash happened you could get some of the data moved to the new _data folder for the project and some still left in the temporary folder.

smeezekitty wrote:I attached the autosave file. Since it doesn't have any of the .au file names, I don't think there is much chance of recovery.

If there was no TEMP file in the AutoSave folder, I agree you can't do anything there.

But if the AU data files still exist you can always do manual recovery: http://manual.audacityteam.org/o/man/re ... ually.html.


Gale

Well you say there was no disk problem, but how do you know? Windows reported a problem. You may want to do a SMART check: http://superuser.com/questions/154337/u ... ive-health.

A disk problem is unlikely because the crash happens almost every time I cancel a long running save.

smeezekitty wrote:I attached the autosave file. Since it doesn't have any of the .au file names, I don't think there is much chance of recovery.

If there was no TEMP file in the AutoSave folder, I agree you can't do anything there.

The other .tmp files are for other projects and some are zero bytes so no help there either.

But if the AU data files still exist you can always do manual recovery: http://manual.audacityteam.org/o/man/re ... ually.html.

The .au files still exist and I backed them up. What is the technical format of the .AU?
Are they raw 16 bit samples or something else? I think I may be able to write a program to rename the files for recovery.

smeezekitty wrote:

Well you say there was no disk problem, but how do you know? Windows reported a problem. You may want to do a SMART check: http://superuser.com/questions/154337/u ... ive-health.

A disk problem is unlikely because the crash happens almost every time I cancel a long running save.

I already tested that and did not get a crash (with local hard drives).

smeezekitty wrote:

But if the AU data files still exist you can always do manual recovery: http://manual.audacityteam.org/o/man/re ... ually.html.

The .au files still exist and I backed them up. What is the technical format of the .AU?
Are they raw 16 bit samples or something else? I think I may be able to write a program to rename the files for recovery.

See http://forum.audacityteam.org/viewtopic ... 85#p217485 for some information about the Audacity AU format.

But why not simply use xplorer2 as per the instructions on http://manual.audacityteam.org/o/man/re ... ually.html?

Also is your USB drive formatted with FAT32 or NTFS? Usually USB drives are FAT32, but If yours is NTFS and you get the pro version (free trial) of xplorer2 and use View > Raw Contents, it should use the internal NTFS time stamps to time sort the files. The NTFS time stamps are accurate enough to identify which AU file of a stereo pair was written first, so you should avoid the issue of a stereo recording being recovered with left and right channels transposed here and there.


Gale

But why not simply use xplorer2 as per the instructions on http://manual.audacityteam.org/o/man/re ... ually.html?

Because I wasn't aware of it. Also, I was concerned about the stereo separation problem.

Also is your USB drive formatted with FAT32 or NTFS? Usually USB drives are FAT32, but If yours is NTFS and you get the pro version (free trial) of xplorer2 and use View > Raw Contents, it should use the internal NTFS time stamps to time sort the files. The NTFS time stamps are accurate enough to identify which AU file of a stereo pair was written first, so you should avoid the issue of a stereo recording being recovered with left and right channels transposed here and there.

Unfortunately, it is exFat. Does that mean I am out of luck?

The time stamps allow 10mS precious but I don't know if any software can make use of it.