Re: [Audacity-quality] Bug 1839 - Inconsistent recording into selection
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
|
From: Steve t. F. <ste...@gm...> - 2018-02-27 18:55:26
|
On 27 February 2018 at 17:26, Peter Sampson <pet...@gm...> wrote: > > > On Tue, Feb 27, 2018 at 2:58 PM, Steve the Fiddle <ste...@gm...> > wrote: >> >> Re. http://bugzilla.audacityteam.org/show_bug.cgi?id=1839 >> >> The behaviour has changed since I last looked. >> >> There appears to be three issues, one of which is definitely a bug, >> and the others looks like they probably aren't. >> >> 1) The bug is when the recording cursor stops and recording continues. >> I think I've found the fix for this. >> >> The other two issues are: >> >> 2) When "should" recording stop at the end of the selection? >> My take on this is: >> Whenever the selection start is at or beyond the end of the track. > > > > Record Below > Not sure I agree with this for record below > > Consider the use case where the user makes a fluff in the middle of a > recording > and goes back to repair it > > 1) User carefully identifies the fluff section and range labels it > 2) select the range labelled region > 3) record onto new track If they are recording into a new track (as in this example), the new track is empty, so any selection in "positive time" is beyond the end of the track. In this case, the recording will use the selection. Perhaps I should have been more verbose: "Whenever the selection start is at or beyond the end of the track that is being recorded into". There is a tricky case of recording into white-space between audio clips on the same track. Currently we don't support that, and I'm not proposing to change that now. > > Surely in this use case the user might rightfully expect to record for just > exactly the > fluff repair length - so they can patch repair it directly time-for-time? Yes, and I'm proposing that should happen consistently (in 2.2.2, it does this already IF "Overdub" is enabled). > > Also why would the user expect to see different behaviors just because the > selection > end is before the end of the track? That would not seem intuitive or > discoverable. > > If you're gonna have record into a selection length it should surely obtain > for all selections > regardless of position. Recording into white-space between audio clips on the same track as being recorded, would have to be treated as a "special case". A simple example, if the cursor is placed between clips, and you record into the current track - what happens when the new recording hits the next audio clip? We could stop the recording at that point - but that is still a "special case" that does not apply to recording as we do it now. > > > Record Beside > I can see that your 2) makes eminent sense when the user continues > recording on > the same track (default behavior). > > I might even be inclined to tighten this up further and do it only if the > selection starts > right at the end of the current track Say you are recording backing vocals for the choruses of a song - you have one starting at 45 seconds, then next at 1:45, and another at 2:45. It may be a lot more convenient if you can do all of these on one track. > Empty Track > Consider the use case too where the user has an empty track and makes a > selection > in that track (in order to record for just that elapsed time) - recording > should then be > just for that selection. > > Right now it: > a) pads with silenceto the selection start > b) starts recording at the slection start > c) does not stop at the selection end - but blithely carries on recording Yes, I agree, but currently, if we don't pad, Export Multiple will strip the leading white-space. What I think "should" happen, is that it records just the selection, without padding, but then we need at least an option to include leading white-space in exported tracks. Steve > > > Peter > > > >> >> >> 3) When "should" padding (silence) be added? >> My initial take on this was - "never". >> However, I think the intention is that padding is added whenever using >> "append record" (default). >> >> 3a) I can see a benefit of padding in this case, in that noob users >> are likely to be more comfortable with seeing one continuous track >> rather than separated clips. >> >> 3b) I can also see a downside, in that if you want to adjust the >> position of the new clip, you have to remove the padding before the >> clip can be shifted to the left. >> >> 3c) This is the killer at the moment - We don't export leading >> whitespace (a mistake imo), so if we don't pad and a user wants 10 >> seconds of leading silence to their recording, 10 seconds of white >> space won't do it. >> >> Upshot: >> My current intention is to fix issues 1 and 2, and leave issue 3 for >> now (primarily because of 3c.) Item (3) could be logged as an >> enhancement, but I think we would need to "fix" exporting leading >> whitespace first. >> >> Steve >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Audacity-quality mailing list >> Aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-quality > > |