I have run into this many times in the past, and I think there is a disconnect between Audacity features, feature names and what users expect. Data internally in Audacity for multi track projects can have non-zero offsets and when you play the project back within audacity sound is “magically aligned” because Audacity knows what the track to track offsets are. If you put the cursor at non-zero starting point and overdub a new track when you play back from the beginning the new track sound plays at the point where the cursor was as the user expects.
From a user perspective “export multiple as WAV” sounds like it will export WAV files time aligned like you hear them when you play the project in Audacity. The expectation is that if you loaded these WAV files in another DAW software there would be no work to align them. I am fooled by this every time I use it for multi-track recording and I think this is something that should be addressed in Audacity features. In fact I can’t think of a multi-track use case where removing the time alignment makes sense but I imagine there must be one?
I don’t mind doing the work to implement this. It’s not hard to look at the track offsets before generating WAV files and inserting silence as necessary for track audio that starts at non-zero time. I actually need to do this now and was going to do it as a stand alone tool that reads .aup and the exported WAV files and writes them out time aligned but if there is interest I can learn how to build Audacity and do it as a menu option in export multiple?
Contributions are welcome. They are best made as pull requests on GitHub.
But you should wait for Steve to reply because I think he was planning a checkbox in all the export dialogues (not just export multiple) for exporting silence before the track starting point or not. I don’t know if he started that.
As Gale hinted, this is one of my bugbears. Go back far enough in history and ancient versions of Audacity did “the right thing” (in my opinion, and the opinion of many that work with multi-track projects). Then one day it changed.
Yes there are practical use cases where this behaviour is desirable. For example, if you are working in Audacity only, you may want WAV backups of the audio data in case (for example) you mess up applying effects. In this case, always including leading silence could massively increase file size / disk space use.
Another use could be splitting an album into separate songs. One way of doing this is to move songs that you want to save onto separate tracks, then Export Multiple based on tracks. In this case you would not want leading silence.
However, the reason that the current behaviour came about was not related to these use cases, but in order to solve a different problem - that of “rendering” tracks. For example, you may have multiple tracks with Envelopes. To “fix” the envelopes you would use “Mix and Render”, but previously this would always render leading white-space (empty space) as silence, which you would probably need to remove manually.
I think what we really want is to be able to render a selection (not just the entire track), and have an option to include leading white-space when exporting. The export option should preferably be quick and easy to get at - in the export dialog rather than buried in Preferences.
Thanks for the use-case description, I did not think of those cases. I spent some time looking at the code and am still willing to work on it if a little concerned about updating something and inadvertently breaking something I didn’t realize people were used to. I suppose that’s how we wound up here anyway, right? Is there a test suite I can use to validate changes?
I prototyped something instead that works for what I need in the short term. If anyone else needs something before it gets into Audacity I posted the solution here, it may work for you:
I think the importance of leading silence was underestimated.
I love the idea of in-browser parsing of AUP files. I’m betting that this idea could be extended for many other uses - we must chat about this sometime.
Basically the idea is that each developer has his own GitHub account and clones the Audacity repository. You can then create a new branch in your cloned copy for each fix / feature you are working on. When the fix / feature is complete, you would ensure that your branch is up to date, and (usually) “rebase” your changes onto the updated code base (this puts your changes as the most recent changes). Then you would send a “pull request”, which is a request for your changes to be pulled into the main Audacity repository.
I love the idea of in-browser parsing of AUP files. I’m betting that this idea could be extended for many other uses - we must chat about this sometime.
I am happy to brainstorm on that - I use it for other things too like when I export tracks after I’ve mixed them in Audacity I flatten and center pan all the tracks so they export mono and I don’t lose data in the export. It’s pretty quick to mock things up that way.
Are you familiar with GitHub?
Yes, most of the pieces used in the prototype are on Github, I’ll look at the Audacity repository.