If I make a handful of editing changes to a .wav file and save the file, when the file is reopened does Audacity store anywhere a list of the edits I made?
When you save an Audacity project, the current state of the project is saved. The “undo history” is not saved and there is no record saved of what has been done prior to the save.
Thanks very much for the quick response and answer.
Just to be clear, Steve is answering your specific case of closing the project (whence the Undo History is discarded) and to the fact that the Undo History is not saved in any physical file.
If you start a new project, record something then cut a bit out and normalise it to -1 dB, the Undo History for those changes is visible at View > History…, and is retained in that window after saving the project. Until you close the project you can view the changes you made in the Undo History window.
Would it be useful to export the Undo History as a text file, or have a preference for Audacity to do that on closing the project? I have reservations about storing the undo history in the AUP unless it is actually going to store the data to act on the undo history from the last session when reopening the project. Users opening the AUP file to see their past changes is fraught with the danger of making an unwanted change to the file.
Gale
I, for one, would greatly appreciate an option to save the undo/redo history. I searched the forums but this is the closest topic I have found. Is there a better place to request this feature?
To provide some detail: the data need not always be present in the AUP file. It could be (1) an optional checkbox in the save dialog labeled “Include Undo/Redo History and Related Data (makes project larger)” or (2) a completely separate file (e.g. with a different extension) and separation of related data (so that the project could be loaded with or without the undo history).
In either case, the user should definitely be given some sort of crash-protection auto-save setting, so that both the project and its undo/redo history would be saved every N minutes, as specified by the user.
The use case is quite simple: wanting to close the project (or crashing) but wishing to resume work later, and not being sure about the most recent adjustments. Currently this requires saving multiple states of the project–with tons of redundant data. An undo/redo history would therefore actually reduce overall space consumption.
Thanks for your input.
This feature request is already logged, so I’ve added your vote on the wiki.
There is already a significant amount of time (and CPU cycles) spent on writing the current state. I’m not sure that I’m keen on the idea of writing even more data while the project is being worked on as doing so is likely to make working on large projects even slower than now. I do see your point about crash protection, but personally I think it would be a better use of developer time to reduce the likelihood of crashing.
I’m in favour of an option for saving the undo history (my vote has already been counted).
I’m not against the undo history being restored after a crash, if it can be accomplished without slowing down the normal work-flow.
Of course we are all in favour of improving stability - that is always on the agenda 
Just a query - Steve added your vote to “Save undo history into the project file(s) - useful for picking up on a project at a later time” but those votes are not considering crash recovery - they are just a method to save the history in the AUP as text when you close the project cleanly, explicitly without the ability to act on the history when you reopen the project. I assume (though it is not clear) that the old history would be listed in View > History but greyed out.
There is a related request “Not just save, make undo active across sessions” (so you could also properly close a project, reopen it then undo things that were done when the project was last open). That feature requires storing old audio data (AU block files) when saving the project.
In the case of crash recovery, the audio data is still there, but are you asking for the recovered history to be actionable? This may require a little more than just writing text, because the Undo History would have to be taught to recognise history references saved to disk rather than reading them from memory.
Can you clarify if you want to act on the old history when reopening the project normally?
Autosaving used to be done if there had been changes in the last N minutes, but it was a flawed implementation that did not always recover data correctly. We now autosave “on demand” whenever an action that we want to autosave occurs, but in order to improve project responsiveness a number of actions that used to be autosaved no longer are (such as moving the cursor or dragging a selection).
So especially now, there will be a number of actions that are in the history but not autosaved, such as gain or mute/solo changes on the Track Control Panel. Any autosave can cause a brief hangup in an extremely long project as the autosave scans all the data. This may be something that can be made more efficient, but we wouldn’t want to start adding to autosaving again while there is this inefficiency.
As you suggest, it may be possible to periodically save the undo references from memory as text, without the costly entire scan of the project data. I assume that periodic save would be sufficient to allow the history to be actionable, but as above I expect it may require more work to actually make the action happen.
Gale
Yes, I would definitely support the Undo History being actionable–that is, the behavior should be as if the user never closed Audacity (or it never crashed). Correct me if I’m wrong, but storing the history as text alone (without capability of using it) seems like another matter/use-case entirely.
As I mentioned, I understand that storing the extra (old) audio data would increase the filesize substantially, but as I also mentioned, this is far better than the current method of saving multiple instances of the same project at different states. I admit, however, that this feature may not be something most people would need, but I don’t see a reason why it can’t be optional.
The same goes with any auto-save feature–leave the choice with the user as to whether he/she prefers “incessant saving” or “no lag interface.” (My philosophy in general is: “when at all possible, let the user decide,” but I do understand that this is not always the best way to program, and can make bug-tracking a nightmare.)
I don’t claim to know the inner-workings/methods of Audacity, but if the option(s) can be added without major foundational modifications, I think it should be. It seems “state saving” (which is really what either of these suggestions are about) is becoming more and more in demand these days, and hopefully it can be done with Audacity.
Yes. I’ve updated the votes about Undo history and made completely separate votes for the history being actionable or not: http://wiki.audacityteam.org/wiki/Feature_Requests#undo .
So you (Jinx) have voted for “Make Undo active across sessions” and “Autosave history, so it can be restored after a crash”.
As you can see, twice as many users want to merely view the old history from closed project sessions as those that want to also action it.
Gale
I don’t see much point in an Undo history that cannot undo. Are you sure that is what those 14 voters wanted?
Yes, positive. The distinction between “can and cannot undo” was already there and being used, though not as clear as it might have been (obviously, the seven of the 14 who want a text file export don’t envisage being able to undo).
Some of the users realised actionable undo would take extra disk space and explicitly said they don’t want that.
Gale
Apologies for “necro-bumping” here, but I was wondering if there has been any progress on auto-save and/or history save (actionable). I read the wiki here, but I’m not sure if the presence of the item there definitely indicates that nothing has been done in that area.
I’m still running into many occasions where it would be helpful to have the undo/redo history saved with the AUP (or even exportable as a separate–but actionable–file).
Thanks in advance for any information.
We are currently in the run up to a new release.
We are limited by our available volunteer resources, however if you are a developer, feel free to submit a patch.
Gale
Thanks for the reply, Gale. Sadly, I am not a developer. My coding experience begins and ends with “Hello World.”
Hopefully one day there will be a good push for the history save and/or auto-save features. Until then, I guess I’ll just be saving multiple copies of my project.