As part of my usual workflow I often start with a project that contains a whole recording. This project necessarily will be huge, simply because the track is, say, 60min long.
I will sequentially repeat the following steps:
I mark and copy a fraction from this track, e.g. a movement of a symphony.
From the Audacity project already open I create an empty Audacity project.
I paste the fraction copied in the other project into the new, empty project.
I save the new project.
I noticed that even if the fraction copied and pasted is very small, e.g. only about 15sec, the resulting project file will be about the same size as the 60min original file.
My Audacity version is 3.1.3.
For comparison: With Audacity 2.4.2 the project data directory of the copy containing only a small fraction of the original project has been much smaller than the data directory of the original project.
Thank you! There’s one decision, however: The 4th item in the bug you pointed to reads different from what I reported: I did not see the whole original being pasted to the new project instead of just the snippet copied; I can only infer that more than that got copied from the file size.
I appreciate non destructive editing. However, in my opinion there must be ways to somehow remove the editing history, and one of the more intuitive ways seems to be copying to a new project.
Yes, as billw58 says, you can expand the edges of the smartclip.
Or, copy the snippet to a new track in the original project, then mix and render the track; that way, far less audio has to be copied.
You might think. The developers are working on redefining this behavior now.
BTW, if you want to to decrease the size of a “smartclip”, you can do this by dragging the bottom half of the edge to remove what you want, then pressing the delete key.
Yes, that works and is faster than mix and render. The problem is that the user has probably copied exactly what they want and deleting audio from the edges would obviously change the snippet.
It occurs to me that it might be useful to have, in the right-click context menu for a clip, “Convert to dumb clip” or “Remove hidden audio”.
You can mitigate that by labelling the clip with a (temporay) range label before dragging out the hidden audio in the smart clip. Then the yellow snap-guides help ensure accuracy for the deletion
Sounds like a good idea to me - why don’t you suggest that to Muse on GitHub as an enhancement request Bill ?
The developers are working on redefining this behavior now.