Proposal Unitary Project
|Proposal pages help us get from feature requests into actual plans. This proposal page is about managing Audacity Projects.|
Proposal pages are used on an ongoing basis by the Audacity development team and are open to edits from visitors to the wiki. They are a good way to get community feedback on a proposal.
- Note: Proposals for Google Summer of Code projects are significantly different in structure, are submitted via Google's web app and may or may not have a corresponding proposal page.
To provide a single "container" for Audacity Projects rather than the AUP file and data being separate.
- Bill: I support #1 under Details below. It seems to me this could be done easily and would provide good protection for new users. This does not preclude developing a format along the lines of James' proposal.
- Cliff: I agree with Bill. I assume that the Open command of an Audacity project would then point to the project folder and not to the .aup file.
There are a number of approaches that may be taken to achieve the purpose of this proposal:
- Save the AUP file inside the Audacity Project folder.
- When a new project is created the user would be prompted to name the project and set the location where it will be saved. At that point a "Project Folder" will be created containing an AUP file and a _data folder.
- There will also be a File menu option to "Close and Delete" the project in case the user decides that they do not want a saved Project. "Close and Delete" would automatically produce a warning.
- For users that do not want to save the Audacity Project, there will still be the facility of creating a "Temporary Project" which will be exactly the same as how projects currently work.
- Benefits of this approach:
- It helps new users to learn the important distinction between Projects and Audio files.
- Losing the data folder for a project becomes difficult. This is particularly relevant if the user saves all of their projects in the same directory. Rather than having dozens of AUP files and dozens of _data folders, they will have each project neatly packaged in its own sub-folder.
- Power users will often use this method of Project management already, but need to manually go through the steps of creating a folder and saving the new project into that folder.
- In the event of a system crash, all of the data files are already safely written into the Project Folder and not at risk of being deleted if the Temp folder is emptied. This is particularly important on Linux as the Temp folder is automatically emptied when the system is rebooted.
- Accidentally closing Audacity will not delete the data files.
- Dependent files could also be kept in the "Project Folder", allowing easy re-connection to the project if/when there is a feature to find missing dependencies.
- Save Audacity Projects in an "file archive" format (similar to how Nero handles disk images)
- The idea here is to save Audacity projects in some form of Interchange File Format that allows Audacity to read directly from the file without needing to extract the file before use.
- (I have no idea about the technical implications of this approach).
- To keep Audacity Projects as they currently are, but provide an additional feature to "unify" the project into a single archive file.
- The idea here is that on Save, Audacity copies all files that are used in the project into a single archive file (like Zipping the project).
- This is probably the most simple approach but carries a severe time overhead for saving and opening large projects.
James' Proposal (a new format, not AUP based)
Properties we want
- One file rather than multiple.
- Inserts and deletes are localised and do not require rewriting the whole file. Ditto recording (even if adding recording into the middle).
- Stutterless playback - we are not jumping about in a large file like a mad Jack rabbit, which would lead to the disk not being able to keep up.
- Guarantees about low wasted space. E.g. less than half the space is wasted.
The essential change is to manage malloc/free of blocks of data ourselves, within one file, rather than as now implementing blocks as separate files and thereby delegating the management of blocks to the OS running the disk.
We could achieve the above using wav file format and meta data. Or perhaps more naturally using vorbis/flac
- A player application that could not interpret the custom Audacity meta data would still play audio
- Raw recorded audio and imported audio would play correctly.
- Choppiness elsewhere would depend on the amount and fineness of editing and effects.
- On Save, we could untangle the audio and get a normal playable file with minimal meta data.
- New users will frequently move or delete the _data folder without realizing that it is part of the Project. A unified Audacity Project will avoid this pitfall.
- As long as all dependencies are resolved, projects can be moved and transported safely.
Moving an Audacity Project to another machine:
Copy the unified Project to the new machine That's all - no more searching around to find the _data folder that goes with the .AUP file.
Clean-up old unused files:
No more mistakes of accidentally deleting the _data folder (there may still be a danger of deleting dependencies)
Saving Projects for later use
Long term storing of Audacity Projects is currently unsafe as the multiple file format makes it far too easy for project files to become detached from their data.
If a version control system is employed to store projects, the addition and deletion of AU files in the project's _data folder needs special handling.