Re: [Audacity-quality] Concatenate files / Append Import
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Steve t. F. <ste...@gm...> - 2013-05-18 00:11:50
|
On 18 May 2013 00:08, Gale Andrews <ga...@au...> wrote: > > | From Steve the Fiddle <ste...@gm...> > | Fri, 17 May 2013 22:52:08 +0100 > | Subject: [Audacity-quality] Concatenate files / Append Import > > On 17 May 2013 21:51, Gale Andrews <ga...@au...> wrote: > > > > > > > > | From Steve the Fiddle <ste...@gm...> > > > | Fri, 17 May 2013 04:00:41 +0100 > > > | Subject: [Audacity-quality] Concatenate files / Append Import > > > > > On 17 May 2013 01:59, Gale Andrews <ga...@au...> wrote: > > > > > | From Steve the Fiddle <ste...@gm...> > > > > > | Thu, 16 May 2013 17:57:09 +0100 > > > > > | Subject: [Audacity-quality] Concatenate files / Append Import > > > > > > Perhaps better to increment trackCount like this (minor > variation on > > > > > > previous patch attached) > > > > > However if the first track is before or after zero, the align > pushes > > > > > that first track to zero and aligns the start of the second track > with > > > > > the new end of the first track. I would expect the first track to > stay > > > > > put, on the basis this feature has more use cases than just append > > > > > import. > > > > > > > > > > > > > This was a design decision on my part. > > > > My reasoning was that the most common use of this feature would be > for > > > > "compiling" a number of tracks, in which case the user will almost > > > > certainly want the first track to be aligned to zero. These "align" > > > > functions are extremely fast, even with very long tracks, so in the > event > > > > that a user wants tracks to be aligned differently there is likely > to be > > > a > > > > combination of align functions that provide the required result. > > > > > > > > I can't actually think of a user case where one would want to align > > > tracks > > > > end to end with the start before zero, but assuming that such a user > case > > > > exists: as the selection is not moved, "Select All" will include the > > > before > > > > zero part, so after aligning end to end, all that the user needs to > do is > > > > to align with the start of the selection (Tracks > Align Tracks > > Align > > > > with Selection Start). If there is a common user case for aligning > before > > > > zero then perhaps this design decision will need to be reconsidered. > > > > > > I doubt "before zero" is (intentionally) common, but the "after > > > zero" case may be useful for people who are exporting > > > synchronised tracks to DAW's for further editing. > > > > > > > I have used Audacity quite a lot in conjunction with DAWs, but I still > > don't see why, when aligning End to End should use track 1 as the fixed > > references point rather than time = 0 as the fixed reference point. > > > > If I asked a person (rather than a computer) to put 20 tracks onto a CD > end > > to end, I'd not expect the CD to start with silence, I'd expect the CD to > > start straight away with the first track. > > Yes but we are merely aligning tracks end-to-end in an audio > editor. The current command name does not imply to me that > the result is going to be realigned with zero. > Neither does it imply that the result is going to be realigned to the first track, which could be any arbitrary position, > > I don't see the sole rationale for align end to end as import > append then export (indeed I have argued that we still need > an easy to use Import Append feature in the future). > I agree with you on that, but I don't see that coming along in the near future. > > Also David will correct me, but I think the first track moving > could be confusing to VI users. > There could be a persuasive argument there, but from a VI perspective I would have thought that making "Align End to End" start at time=0 would be better than potentially leaving some period of silence at the start (or possibly even starting the concatenated tracks before zero with an unplayable start). > > > > > Also if the user has the first track offset after zero but intends > > > the exported audio to start at zero, straight Export and Export > > > Multiple now both remove leading white space in any case. > > > > > > > Yes, but doesn't that undermine the argument about transferring > > synchronised tracks to a DAW? > > If Export preserved leading silence then I would see a stronger argument > > for Align End to End preserving leading silence before the topmost track. > > I support "preserving leading silence" on export being either > a Preference or a checkbox in the export dialogues. > > I understand from Forum discussions that you tend to agree. > Yes I do - in fact I was quite dismayed when the behaviour changed so as to not preserver leading silence on export (apparently with no consultation or QA agreement). > > > > > > > Should there be an equivalent "Align and Move Cursor" item for > this? > > > > > I can see it being useful. > > > > > > > > > > > > > I considered this, but as with Align Tracks Together" it's not really > > > > possible without introducing complicated rules about what will/should > > > > happen. > > > > > > > > The first 7 align functions move all of the tracks together, > therefore > > > the > > > > selection can be moved so that its position relative to the other > tracks > > > > remains the same (this is what "Align and Move Cursor" does). > > > > > > Right, but I think few people realise what it does. When people > > > do realise, I think they welcome Play still playing from the same > > > position as before the align. > > > > > > > It does play from the same position as before the align. > > I mean, they welcome Play still playing the same audio (the cursor > or selection having moved so that it is still in the same relative > position). > > But as you say, the reference point with Align Tracks Together > isn't self-explanatory, so we currently don't have a "Move > Cursor" equivalent for that. > > > > > If we want to change Align End to End so that the first track > > > stays put, then I think that command at least has a clear case > > > for having an "and Move Cursor" equivalent that retains play > > > sync with the first track. > > > > > > > No, because if the first track stays put, and the cursor / selection is > to > > stay synchronised to the first track, then the cursor / selection will > need > > to stay put too (no movement of the cursor). > > Oops, yes. But if the first track does move back to zero > then the Align End to End command does seem to have > some case for a "Move Cursor" equivalent to me. > > For example I was playing with a couple of clips containing DTMF > tones in their own tracks, the first from 1s to 2.5s and the second > from 2s to 5s. > > My cursor was on the final tone in the first track and the third > tone in the second track. > > After aligning end to end, Play just plays the third tone on its > own, instead of what I was expecting, the final tone of the first > track followed by the first and subsequent tones of the second > track. > I expect that "Move Cursor" will still be highly problematic. My thoughts are that we should concentrate first on implementing the much needed "Align End to End", and once that is in place, if we can devise a rational and intuitive way to provide a "Move Cursor" version, then we can implement that. Steve > > > > > Gale > > > |