Where does Audacity store 'recovered project' information?

I keep getting the message ‘Audacity closed unexpectedly, do you want to recover projects’ when I start Audacity after intentionally killing the process… even though I’m rm -rf’ing the contents of the Audacity temp directory before restarting Audacity.

Where else might Audacity be storing information that leads to the ‘found some projects to recover’ message?

Try this:

rm ~/.audacity-data/AutoSave/*.autosave

Thanks! That did the trick.

…random side question. Right now the script is using a sleep timer to guess when Audacity is done generating a spectrogram. Is there any way for it to hear from Audacity itself when the spectrogram is done?

(I guess I could try some kind of loop that uses pattern-matching to watch the CPU/memory usage using top… unfortunately I don’t know enough about pattern matching or…)

Audacity is a pure GUI program that is controled via mouse clicks or keyboard shortcuts. Audacity has no built-in support for command line shell scripting. The reason is that Audacity is multiplatform software, what means that for every supported operating system (Windows, Mac, Unix, Linux, etc.) a different command line interface would need to be implemented in Audacity.

For Unix and Linux there exist a lot of command line audio programs. If you tell what you want to achieve then maybe I can tell a command line solution.

  • edgar

edgar,
I just need to generate spectrograms of a bunch of different audio files in a folder and save them as images.

Something like this - YouTube: Create a Spectrogram with SoX ?

SoX is a standard command line audio editor that is part of every linux distribution. Really everything in SoX can be controled from the command line. For a description of the spectrogram parameters see Effects and scroll down to “spectrogram”. The effects are sorted alphabetically, but unfortunately no direct link to the “spectrogram” section is possible, and the text is too long to copy it here into a text box.

Is this what you need? (first watch the video where you can see how the spectrogram looks like)

  • edgar

Thanks, that looks perfect!

It amazes me sometimes how so many authors on given projects completely underestimate the power of their utility, pointing people elsewhere. The power of Audacity is unmatched in its simplicity and range of native abilities. The issue many people have (myself included) is the clumsy GUI as the only interface. No internal scripting language, no batch conversion, no consolidating console (such as having 10 audacity windows open where I want to do the exact same thing with all of them, such as I loaded .ogg files and want to convert them to .mp3 because my Sansa music player won’t play ogg without skipping, but will play mp3 all day without issue). Instead, I have to wait one by one for each one to be converted, when I could just kick off a batch and be done with it.

The CLI wouldn’t be that hard to implement. Just accept even a single command line parameter prefixed with an at sign (all C languages use an “int main(int argc, char* argv)” style startup which retrieves the individual parameters no matter the platform) which accepts a single reference like @myfile where myfile is a disk-based file containing the known scripting form:

[command: doRecord, 30 seconds]

Or whatever. Then, Audacity itself could implement this scripting code internally to allow a series of batch jobs to be created and executed one by one.

The point is, a series of simple commands could be created which are a type of Audacity-like scripting language accessing all of those features available internally through the GUI (by a common name that relates to each menu item, and then each editable option on the following GUIs if there are UIs beyond the menu option selection). The user of an external application using this Audacity CLI could seek out the correct form using trial-and-error, manually testing configurations before they automate from their other app.

Who knows what they will use Audacity for? But you shouldn’t pigeon-hole your users. You should allow them to fly, to sail to wherever their imagination wants to take them.

I’m even willing to write this code for the project if the developers are not interested in doing so.

Best regards,
Rick C. Hodgin

The problem is not that the developers are not interested, the problem is more that there are not enough developers to do all the work.

I also do not really understand why a GUI program needs a scripting interface. If I want to batch-process audio files then I use command-line tools that can do this much faster because they do not need to carry around all that GUI bloat.

However, please ask on the audacity-devel list for coordination with the rest of the project if you want to help with writing code.

Thanks,

  • edgar

I also do not really understand why a GUI program needs a scripting interface. If I want to batch-process audio files then I use command-line tools that can do this much faster because they do not need to carry around all that GUI bloat.

That’s the thing about releasing free software … you never know what other people will use it for. By creating a scripting language, one that doesn’t have to display the GUI, but is still designed to use the GUI-based menu options by name, for example, then all of the features of Audacity’s editing abilities are available directly without having to manually do the work by hand. This makes routine processing possible using Audacity, even running filters and assembling multiple sources into a single file. All kinds of things.

Plus, I’ve found that Audacity has better control over some features of even basic audio processing. It’s a tool I use to do my manual work. Why would I want to learn and use a different tool to do batch work (if Audacity also had the ability to do batch work)? One tool. One happy customer. :slight_smile:

Will post to the developer’s list. Thanks, Edgar. :slight_smile:

Best regards,
Rick C. Hodgin

Audacity has some experimental scripting support. You can find some information about it in the manual: http://manual.audacityteam.org/man/Scripting

Awesome. Thanks, Steve!

Best regards,
Rick C. Hodgin

Note the word “Experimental”. That means that it is probably quite buggy.
Also read the “Known Issues & Missing Features” at the bottom of that page.

If you’re a C+ programmer, this could give you a start on something to get your teeth into. Audacity is always in need of good and enthusiastic programmers. :wink: