P2 - Labels should move with all the timeline changing effects
|
|
André Pinto
|
Hi,
With the fix to Reverse I hope I've finished fixing "P2 - Labels should move with all the timeline changing effects. They do not move with Effect > Repeat, Reverse, and Truncate Silence." For this last case (reverse labels) I tried to figure out when it makes sense to reverse a label granting that no references will be lost. So labels are only reversed if the selection (after trim to the track limits) includes all the label (partial wavetracks reverse wouldn't be - in my opinion - intuitively translated into a reversed label). Aditionally my code iterates over all the tracks in the group to check if there is any selected or not selected tracks that make the label reverse impossible, accepting only if all the tracks include all or nothing of the label length. In all the other cases the reverse is done to the track but the label is not reversed. I think this is the most logical behavior, but I accept different opinions and I would like to know if you agree or not. Thanks, André. ------------------------------------------------------------------------------ _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
Gale (Audacity Team)
|
| From André Pinto <[hidden email]> | Sat, 4 Jul 2009 01:27:22 +0100 | Subject: [Audacity-devel] P2 - Labels should move with all the timeline changing effects > With the fix to Reverse I hope I've finished fixing "P2 - Labels should move > with all the timeline changing effects. They do not move with Effect > > Repeat, Reverse, and Truncate Silence." > > For this last case (reverse labels) I tried to figure out when it makes > sense to reverse a label granting that no references will be lost. > So labels are only reversed if the selection (after trim to the track > limits) includes all the label (partial wavetracks reverse wouldn't be - in > my opinion - intuitively translated into a reversed label). Aditionally my > code iterates over all the tracks in the group to check if there is any > selected or not selected tracks that make the label reverse impossible, > accepting only if all the tracks include all or nothing of the label length. > In all the other cases the reverse is done to the track but the label is not > reversed. > > I think this is the most logical behavior, but I accept different opinions > and I would like to know if you agree or not. Hi André I have not tried yet as effects\Reverse.cpp fails to compile in VS2008 at line 33: error C2027 use of undefined type 'LabelTrack' error C2027 left of '->ChangeLabelsOnReverse' must point to class/struct/union/generic type Thanks Gale ------------------------------------------------------------------------------ _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
André Pinto
|
Hi,
I already added the include. I'm not sure why but I was able to compile it here without the include. Can you tell me if this fixes it? Thanks, André. On Sat, Jul 4, 2009 at 6:08 AM, Gale Andrews <[hidden email]> wrote:
------------------------------------------------------------------------------ _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Gale (Audacity Team)
|
| From André Pinto <[hidden email]> | Sat, 4 Jul 2009 14:00:25 +0100 | Subject: [Audacity-devel] P2 - Labels should move with all the timeline changing effects > > I already added the include. I'm not sure why but I was able to compile it > here without the include. Can you tell me if this fixes it? Hi André I'll see, but I already tried adding an include for ../LabelTrack.h and it didn't seem to help on my Vista machine. Will report back. Gale > On Sat, Jul 4, 2009 at 6:08 AM, Gale Andrews <[hidden email]> wrote: > > > > > | From André Pinto <[hidden email]> > > | Sat, 4 Jul 2009 01:27:22 +0100 > > | Subject: [Audacity-devel] P2 - Labels should move with all the timeline > > changing effects > > > With the fix to Reverse I hope I've finished fixing "P2 - Labels should > > move > > > with all the timeline changing effects. They do not move with Effect > > > > Repeat, Reverse, and Truncate Silence." > > > > > > For this last case (reverse labels) I tried to figure out when it makes > > > sense to reverse a label granting that no references will be lost. > > > So labels are only reversed if the selection (after trim to the track > > > limits) includes all the label (partial wavetracks reverse wouldn't be - > > in > > > my opinion - intuitively translated into a reversed label). Aditionally > > my > > > code iterates over all the tracks in the group to check if there is any > > > selected or not selected tracks that make the label reverse impossible, > > > accepting only if all the tracks include all or nothing of the label > > length. > > > In all the other cases the reverse is done to the track but the label is > > not > > > reversed. > > > > > > I think this is the most logical behavior, but I accept different > > opinions > > > and I would like to know if you agree or not. > > > > Hi André > > > > I have not tried yet as effects\Reverse.cpp fails to compile in VS2008 > > at line 33: > > > > error C2027 use of undefined type 'LabelTrack' > > error C2027 left of '->ChangeLabelsOnReverse' must point to > > class/struct/union/generic type > > > > Thanks > > > > > > Gale > > > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > audacity-devel mailing list > > [hidden email] > > https://lists.sourceforge.net/lists/listinfo/audacity-devel > > ------------------------------------------------------------------------------ _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Gale (Audacity Team)
|
| From Gale Andrews <[hidden email]> | Sat, 04 Jul 2009 17:01:10 +0100 | Subject: [Audacity-devel] P2 - Labels should move with all the timeline changing effects > | From André Pinto <[hidden email]> > | Sat, 4 Jul 2009 14:00:25 +0100 > | Subject: [Audacity-devel] P2 - Labels should move with all the timeline changing effects > > > > I already added the include. I'm not sure why but I was able to compile it > > here without the include. Can you tell me if this fixes it? > > Hi André > > I'll see, but I already tried adding an include for ../LabelTrack.h and > it didn't seem to help on my Vista machine. > > Will report back. It compiled OK now on the XP machine after updating. Don't know yet why saving that change to the local file on the Vista machine did not help. However, assume everything's OK unless you hear otherwise. Thanks Gale > > On Sat, Jul 4, 2009 at 6:08 AM, Gale Andrews <[hidden email]> wrote: > > > > > > > > | From André Pinto <[hidden email]> > > > | Sat, 4 Jul 2009 01:27:22 +0100 > > > | Subject: [Audacity-devel] P2 - Labels should move with all the timeline > > > changing effects > > > > With the fix to Reverse I hope I've finished fixing "P2 - Labels should > > > move > > > > with all the timeline changing effects. They do not move with Effect > > > > > Repeat, Reverse, and Truncate Silence." > > > > > > > > For this last case (reverse labels) I tried to figure out when it makes > > > > sense to reverse a label granting that no references will be lost. > > > > So labels are only reversed if the selection (after trim to the track > > > > limits) includes all the label (partial wavetracks reverse wouldn't be - > > > in > > > > my opinion - intuitively translated into a reversed label). Aditionally > > > my > > > > code iterates over all the tracks in the group to check if there is any > > > > selected or not selected tracks that make the label reverse impossible, > > > > accepting only if all the tracks include all or nothing of the label > > > length. > > > > In all the other cases the reverse is done to the track but the label is > > > not > > > > reversed. > > > > > > > > I think this is the most logical behavior, but I accept different > > > opinions > > > > and I would like to know if you agree or not. > > > > > > Hi André > > > > > > I have not tried yet as effects\Reverse.cpp fails to compile in VS2008 > > > at line 33: > > > > > > error C2027 use of undefined type 'LabelTrack' > > > error C2027 left of '->ChangeLabelsOnReverse' must point to > > > class/struct/union/generic type > > > > > > Thanks > > > > > > > > > Gale > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > > > audacity-devel mailing list > > > [hidden email] > > > https://lists.sourceforge.net/lists/listinfo/audacity-devel > > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > audacity-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/audacity-devel ------------------------------------------------------------------------------ _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
André Pinto
|
Thanks Gale.
On Sat, Jul 4, 2009 at 7:01 PM, Gale Andrews <[hidden email]> wrote:
------------------------------------------------------------------------------ _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Gale (Audacity Team)
|
In reply to this post
by André Pinto
| From André Pinto <[hidden email]> | Sat, 4 Jul 2009 01:27:22 +0100 | Subject: [Audacity-devel] P2 - Labels should move with all the timeline changing effects > With the fix to Reverse I hope I've finished fixing "P2 - Labels should move > with all the timeline changing effects. They do not move with Effect > > Repeat, Reverse, and Truncate Silence." > > For this last case (reverse labels) I tried to figure out when it makes > sense to reverse a label granting that no references will be lost. > So labels are only reversed if the selection (after trim to the track > limits) includes all the label (partial wavetracks reverse wouldn't be - in > my opinion - intuitively translated into a reversed label). Aditionally my > code iterates over all the tracks in the group to check if there is any > selected or not selected tracks that make the label reverse impossible, > accepting only if all the tracks include all or nothing of the label length. > In all the other cases the reverse is done to the track but the label is not > reversed. > > I think this is the most logical behavior, but I accept different opinions > and I would like to know if you agree or not. Hi André I made the following comments on the Checklist, from which you'll see this bug isn't fully fixed yet: ** Repeat isn't correct if repeating multiple tracks in a group. Generate default tone, duplicate it, select from 5 seconds to 8 seconds in both tracks, and place a point label at 9 seconds. Effect > Repeat (number of times=2) and observe the label is moved to 20 seconds instead of 15 seconds. ** Similarly Truncate is incorrect if applied to multiple tracks. Remove the two audio tracks above and Generate DTMF (duty 55, tone 2185, silence 1788). Duplicate it and move label track to bottom. Select 5 to 8.5 seconds and Truncate Silence (max 200). Too much audio after the silence is deleted and the label disappears. ** Reverse works well on my assumptions of what is best, except that when the conditions for labels to move are satisfied, they move even if linking is off. I have not kept up with the other fixes you have done with labels André, so like Martyn I'm not sure if all these things are fixed or are behaving correctly (such as the label moving behaviour with speed change). It will probably be after 1.3.8 now, but I'll try and go back through the e-mails and take a look. One other thing I found is that Truncate Silence does not work at all if applied to multiple tracks and at least one track has no silence (nothing happens). Comments please on that? Gale ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
André Pinto
|
Hi Gale,
Thanks for the input. On Wed, Jul 8, 2009 at 10:48 AM, Gale Andrews <[hidden email]> wrote:
I think it is fixed now. It is the "usual" problem with Paste and Clear tracks that work on groups (first call affect others). ** Similarly Truncate is incorrect if applied to multiple tracks. Remove This problem it's more difficult to fix and I'm not sure about any possible logical solution. The problem is the same, but now we have a possible variable Clear. I can fix the double reposition of labels, but the bigger problem is that in this situation the selected tracks can be "deleted" by different amounts (depending on the truncate silence results). That will inevitably cause some kind of desynchronization between the group tracks and I'm not sure about how this should be handled. I would like to know your opinion. ** Reverse works well on my assumptions of what is best, except that Should be fixed now too. I have not kept up with the other fixes you have done with labels I'm not sure if I understand what you mean but Truncate Silence always worked over the output of all the tracks. You can test it on 1.3.7: - Create a tone with 0.1 amplitude - Create another one in a new track with 0.5 amplitude. - Select something on the first track (the one with 0.1 tone) and apply Truncate Silence with default values. Nothing happens. If you remove the track with 0.5 amplitude and call the effect again it will work. Tracks not selected influence the behaviour of Truncate Silence, so your "track has no silence" is probably causing the effect to not be applied. I'm not sure about how should the effect handle this. Thanks again, André. ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
Martyn Shaw-2
|
Hi André
André Pinto wrote: > Hi Gale, ... > I think it is fixed now. It is the "usual" problem with Paste and Clear > tracks that work on groups (first call affect others). There's that reference to the "usual" problem. Can you make it / is it now the "unusual problem"? > ** Similarly Truncate is incorrect if applied to multiple tracks. Remove > the two audio tracks above and Generate DTMF (duty 55, tone 2185, > silence 1788). Duplicate it and move label track to bottom. Select > 5 to 8.5 seconds and Truncate Silence (max 200). Too much audio > after the silence is deleted and the label disappears. > > > This problem it's more difficult to fix and I'm not sure about any > possible logical solution. This isn't worth the brain power, compared to other problems, IMHO. "Truncate Silence" is a pre-processing thing, not something to be doing in a linked multi-track session. OK, it may not be perfect but other more main-stream thing probably aren't as well (like that P2 bug you were just looking at, whatever that was). TTFN Martyn > The problem is the same, but now we have a possible variable Clear. I > can fix the double reposition of labels, but the bigger problem is that > in this situation the selected tracks can be "deleted" by different > amounts (depending on the truncate silence results). That will > inevitably cause some kind of desynchronization between the group tracks > and I'm not sure about how this should be handled. I would like to know > your opinion. > > > ** Reverse works well on my assumptions of what is best, except that > when the conditions for labels to move are satisfied, they move > even if linking is off. > > > Should be fixed now too. > > > I have not kept up with the other fixes you have done with labels > André, so like Martyn I'm not sure if all these things are fixed or are > behaving correctly (such as the label moving behaviour with speed > change). It will probably be after 1.3.8 now, but I'll try and go back > through the e-mails and take a look. > > One other thing I found is that Truncate Silence does not work at all > if applied to multiple tracks and at least one track has no silence > (nothing happens). Comments please on that? > > > I'm not sure if I understand what you mean but Truncate Silence always > worked over the output of all the tracks. You can test it on 1.3.7: > - Create a tone with 0.1 amplitude > - Create another one in a new track with 0.5 amplitude. > - Select something on the first track (the one with 0.1 tone) and apply > Truncate Silence with default values. > > Nothing happens. If you remove the track with 0.5 amplitude and call the > effect again it will work. Tracks not selected influence the behaviour > of Truncate Silence, so your "track has no silence" is probably causing > the effect to not be applied. I'm not sure about how should the effect > handle this. > > Thanks again, > André. > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > > > ------------------------------------------------------------------------ > > _______________________________________________ > audacity-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/audacity-devel ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Gale (Audacity Team)
|
In reply to this post
by André Pinto
| From André Pinto <[hidden email]> | Wed, 8 Jul 2009 13:10:56 +0100 | Subject: [Audacity-devel] P2 - Labels should move with all the timeline changing effects Thanks for fixing the reverse and repeat issues here. See below. > > ** Similarly Truncate is incorrect if applied to multiple tracks. Remove > > the two audio tracks above and Generate DTMF (duty 55, tone 2185, > > silence 1788). Duplicate it and move label track to bottom. Select > > 5 to 8.5 seconds and Truncate Silence (max 200). Too much audio > > after the silence is deleted and the label disappears. > > > > This problem it's more difficult to fix and I'm not sure about any possible > logical solution. > The problem is the same, but now we have a possible variable Clear. I can > fix the double reposition of labels, but the bigger problem is that in this > situation the selected tracks can be "deleted" by different amounts > (depending on the truncate silence results). That will inevitably cause some > kind of desynchronization between the group tracks and I'm not sure about > how this should be handled. I would like to know your opinion. > > > One other thing I found is that Truncate Silence does not work at all > > if applied to multiple tracks and at least one track has no silence > > (nothing happens). Comments please on that? > > > > I'm not sure if I understand what you mean but Truncate Silence always > worked over the output of all the tracks. You can test it on 1.3.7: > - Create a tone with 0.1 amplitude > - Create another one in a new track with 0.5 amplitude. > - Select something on the first track (the one with 0.1 tone) and apply > Truncate Silence with default values. > > Nothing happens. If you remove the track with 0.5 amplitude and call the > effect again it will work. Tracks not selected influence the behaviour of > Truncate Silence, so your "track has no silence" is probably causing the > effect to not be applied. I'm not sure about how should the effect handle > this. I don't know too much about what Truncate Silence tries to do when there are multiple tracks, but I don't think it works "as expected" with multiple tracks of different content, even if you select only one track to apply it to. I'm now looking at two tracks of 26 seconds in 1.3.8, both have a tone at -60 dB, the upper track has a region from 4s to 11s where the tone is amplified to FS, in the lower the FS region is 4s to 6s. If I select the lower track and run Truncate Silence, I end up with 7s of audio almost all of which is FS. If I undo, remove the upper track and reapply the effect I get something looking more like what I expected. I also get what I expect if I now undo, duplicate this single track and apply the effect to both tracks. Also I note that if one channel of a stereo pair has no silence, and one does, truncate has no effect in that case either. That may be only a demonstration case. Now in my example: Generate DTMF (duty 55, tone 2185, silence 1788). Duplicate it and move label track to bottom. Select 5 to 8.5 seconds and Truncate Silence (max 200). this works "as expected" applied to both tracks (the third DTMF tone is still the correct length) if linking is off. If if it is on, the third tone is truncated to half a second. Does that suggest linking is adding its own problem? But the code can handle a manual deletion of silence in one or both tracks fine. I guess Martyn may be right that truncating multiple tracks with a linked label track may be uncommon, but not I think truncating multiple tracks without a label track. I know several people recording vinyl that prefer to work in separate tracks within Audacity, but truncating silence in all those tracks at once clearly wouldn't work as I would intuitively expect. Should we P3 (Release Note) these truncate silence issues with multiple tracks (or even disallow it with multiple tracks) and clear the subject P2? Gale ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
André Pinto
|
On Thu, Jul 9, 2009 at 8:02 AM, Gale Andrews <[hidden email]> wrote:
Hi Gale, Can you please explain a little more this particular case? what should be the expected result? I think Truncate Silence has no logic when applied to multiple tracks in a group, because the analysis process could make different deletions in the tracks, so what would be the resulting group behavior? follow just the first track results and ignore the others? I think maybe Truncate Silence shouldn't be available in this situation... André. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Gale (Audacity Team)
|
| From André Pinto <[hidden email]> | Tue, 28 Jul 2009 16:07:18 +0100 | Subject: [Audacity-devel] P2 - Labels should move with all the timeline changing effects > On Thu, Jul 9, 2009 at 8:02 AM, Gale Andrews <[hidden email]> wrote: > > > > > Now in my example: > > > > Generate DTMF (duty 55, tone 2185, silence 1788). > > Duplicate it and move label track to bottom. Select > > 5 to 8.5 seconds and Truncate Silence (max 200). > > > > this works "as expected" applied to both tracks (the third DTMF tone > > is still the correct length) if linking is off. If if it is on, the third > > tone > > is truncated to half a second. Does that suggest linking is adding its > > own problem? But the code can handle a manual deletion of silence > > in one or both tracks fine. > > > Hi Gale, > > Can you please explain a little more this particular case? what should be > the expected result? > > I think Truncate Silence has no logic when applied to multiple tracks in a > group, because the analysis process could make different deletions in the > tracks, so what would be the resulting group behavior? follow just the first > track results and ignore the others? I think maybe Truncate Silence > shouldn't be available in this situation... > > André. Hi André Sorry to take a while replying but this needs thinking about and taking screenshots. I think the first decision is "is Truncate Silence meant to work on multiple tracks in any case, irrespective of linking issues? That is, would I expect the result of truncating silence on two selected tracks simultaneously to be the same as doing it on each selected track in turn? I appreciate some decision may have to be made about the size of the residual selection region if applied simultaneously. Any input, Phil, or anyone, please ? I believe users want Truncate Silence to work on multiple tracks because of what they see as "greater convenience". Unfortunately, the mere presence of multiple tracks in 1.3.8 either stops Truncate working at all, or gives corrupted results, even if only one track is selected (unless the tracks are duplicates of each other). Several users have told me they're going back to 1.3.7 because of this, so it looks like this will have to be another P2 I'm afraid. To get to André's point, if the silences in the multiple regions to be processed are the same (and if we agree Truncate should work on multiple tracks), then there seems to be a potentially useful result. Here is an initial situation: http://www.gaclrecords.org.uk/1.png Here is what happens if you truncate both tracks with linking off: http://www.gaclrecords.org.uk/2.png Note the tone to the right of the selection is still full width. Here's what happens now if you apply truncate to both tracks with linking on: http://www.gaclrecords.org.uk/3.png Note the tones are truncated and the label has disappeared. Now here is my take on what should happen truncating both tracks with linking on: http://www.gaclrecords.org.uk/4.png This is identical to image 2, except the label moves back to the correct place. So we still have the label in the middle of the tones and they still have the intended width. Now lets try a case where the silences in the selected regions are of different length: http://www.gaclrecords.org.uk/5.png Applying truncation to both linked tracks, what should happen? Here is one suggestion: http://www.gaclrecords.org.uk/6.png This image was created by truncating each track separately in 1.3.7, then moving the label back so that it is still in the middle of the tone in the upper track. I think what happened here in this case is useful, if the point of the label was that it marked the centre point of that tone, and better than if linking was not on. How could you make a rule out of this? Would it be that the last created track before the label track was created determines the label movement? Or always the upper track? Gale ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
Richard Ash (audacity-help)
|
On Mon, 2009-08-03 at 04:54 +0100, Gale Andrews wrote:
> > Can you please explain a little more this particular case? what should be > > the expected result? > > > > I think Truncate Silence has no logic when applied to multiple tracks in a > > group, because the analysis process could make different deletions in the > > tracks, so what would be the resulting group behavior? follow just the first > > track results and ignore the others? I think maybe Truncate Silence > > shouldn't be available in this situation... > I think the first decision is "is Truncate Silence meant to work on > multiple tracks in any case, irrespective of linking issues? That > is, would I expect the result of truncating silence on two selected > tracks simultaneously to be the same as doing it on each selected > track in turn? I appreciate some decision may have to be made > about the size of the residual selection region if applied > simultaneously. Any input, Phil, or anyone, please ? My take would be that there are two logical things to do when silence is being truncated in multiple tracks at once: 1 Process them all at once. This could become the first example of what I'll call a "multi-track effect", which works on all N selected tracks of any combination of mono/stereo. In this case the logical thing to do would be to internally calculate the mix of all the tracks at current settings, then work out the truncation region based on the mix, and finally truncate the offending sections out of all the tracks. Linking would then control whether a label track underneath the audio tracks was subject to the same truncations. I could imagine this being useful in a situation where you had a multi-track mix and wanted to tighten up the gaps between sections before mixing down to stereo (or if you were going to use advanced mixing to export as multi-channel audio). For what it's worth, this is analogous to a multi-channel compressor / noise gate, or multi-channel voice-activated recording. 2 Process them all separately. This is the "default" audacity mechanism, whereby each track is fed through the effect in turn, without reference to the others. This works fine if linking is off, because each track just gets sections blasted out without reference to any other track. The problem scenario is when linking is on and we need to do truncation, because we must then break one of the rules on how linking works. One option (2a) would be to always delete the data: a. go along first track b. find silence c. delete that region from all other selected tracks, regardless. If linking on, delete from all linked tracks (audio and label) regardless. d. when this track completed, start on next track at start, same rules. I don't think this is a particularly helpful option, because lots of things that aren't silent get deleted - in fact for a time period to not get deleted, there must be signal in all the tracks over that period. More helpful might be to delete silence from multiple tracks, but not to delete if there is signal (2b). The rules now go: a. go along first track b. find silence c. check other selected tracks for signal in turn. If any have signal, then don't delete and carry on searching d. if all selected tracks are silent, delete that region from all selected tracks. If linking on, delete from all linked tracks (audio and label) regardless. e. no need to process other tracks as there won't be any silences in all tracks left (it doesn't matter which track you started processing in, the result will be the same). This is a more useful behaviour, and almost the same as behaviour as scenario 1 (the difference is when several tracks are quieter than the "silence" threshold individually, but louder than it when mixed). The implementation is considerably trickier in it's details however, so I couldn't really recommend this as a design. I don't see the behaviour distinction as that significant unless the SNR is very poor, in which case Truncate Silence is unlikely to give anything like decent results. Separately, we need to ask the question what happens to a hypothetical track that is part of the linked group but not selected when Truncate Silence is applied with linking engaged (obviously with linking off, it will be completely unaffected). There are two deletion strategies: A. Don't touch the track. Fits the UI rules in that non-selected tracks aren't affected, but breaks the linking rules in that the linked tracks get out of sync. B. Delete in the linked but non-selected tracks where we are deleting in the selected tracks, regardless of the content of the non-selected tracks. This breaks the UI rules in that non-selected tracks are altered, but keeps the linking rules in that all the linked tracks stay in sync. A. is the same as the linking-off case, for which reason I favour option B., on the basis that if the user wants option A., they just press a button to get it, where as if we opt for A., then there is no way to achieve B. (I prioritise flexibility over ease of guessing in this case, on the assumption that we document these rules carefully for the people who will actively use them). For a use case, let's imagine we have two people talking and an ambience track behind it. The tracks were recorded in sync so that break-through from the ambience to the talkers is in sync, and this needs to be retained (the ambience is quiet, but louder parts will be audible on the speakers mics as echoes if I don't keep them in sync). I want to tighten up the talking by removing silence, but obviously I don't want silence to be left in just because there is a thump in the ambience channel. My suggestion is to achieve this by turning linking on for these three tracks (put labels under them, say on the main questions of the interview), then selecting the two speakers tracks (but not the ambience or the labels) and running Truncate Silence. The result is a shortened interview with an ambience track that is in sync and has been cut to make it stay that way. Provided it's low level, that probably won't be noticeable. > I believe users want Truncate Silence to work on multiple tracks > because of what they see as "greater convenience". Unfortunately, > the mere presence of multiple tracks in 1.3.8 either stops Truncate > working at all, or gives corrupted results, even if only one track is > selected (unless the tracks are duplicates of each other). Several > users have told me they're going back to 1.3.7 because of this, so > it looks like this will have to be another P2 I'm afraid. This is a slightly separate point - if linking is off and I process a single, selected track then nothing else should change. If it does, that's a bug we probably need to resolve before we try to do anything else (audit the code for incorrectly calling internal methods of the linking system?). > To get to André's point, if the silences in the multiple regions to be > processed are the same (and if we agree Truncate should work on > multiple tracks), then there seems to be a potentially useful result. > > Here is an initial situation: > http://www.gaclrecords.org.uk/1.png > > Here is what happens if you truncate both tracks with linking off: > http://www.gaclrecords.org.uk/2.png > > Note the tone to the right of the selection is still full width. independently and happen to line up, or it could be that the sum of the two were processed, and then the same truncations applied to both tracks. Either Option 1 or Option 2 applies. > Here's what happens now if you apply truncate to both tracks > with linking on: > http://www.gaclrecords.org.uk/3.png > > Note the tones are truncated and the label has disappeared. Broken - to me it's fairly obvious that's wrong. > Now here is my take on what should happen truncating both tracks > with linking on: > http://www.gaclrecords.org.uk/4.png > > This is identical to image 2, except the label moves back to the > correct place. So we still have the label in the middle of the tones > and they still have the intended width. Ack, that's the reasonable outcome, and again applies equally to my two models of how the effect could handle multiple tracks. > Now lets try a case where the silences in the selected regions > are of different length: > http://www.gaclrecords.org.uk/5.png > > Applying truncation to both linked tracks, what should happen? > Here is one suggestion: > http://www.gaclrecords.org.uk/6.png > This image was created by truncating each track separately in > 1.3.7, then moving the label back so that it is still in the middle > of the tone in the upper track. I think what happened here in this > case is useful, if the point of the label was that it marked the > centre point of that tone, and better than if linking was not on. But what if the label marked a significant event in the second track? In that case it's been pushed out of sync with it's event. Worse still, if you had lined up the ends of your two tones before the processing, they are out of line now, because different amounts of silence have been truncated in each track. To me this definitively breaks the linking model, because the clip ends that used to line up don't any more. I would regard this behaviour as wrong. If we were to apply behaviour 1 to this selection, then there would be no silence in the mixed track, so no truncation takes place. Quite easy to predict! Supposing that the two silences, although of different lengths, overlapped, then that overlap would be truncated, deleting the same amount from each of the two audio tracks. With linking on, the same amount would also be deleted from the label track, so the labels would still match up to the mythical point later in the track to which they originally referred. So to sum up a very long email, my view is: * The signal in which silences are detected for deletion by Truncate Silence should be the mix (sum) of all the selected tracks (Option 1). * When linking is on, then the deletions made by Truncate Silence (and any other truncating effect if we got them) should be made in all the linked tracks, including unselected audio tracks (deletion strategy B.) * When linking is off then all the selected tracks will be deleted in the same place, by the same amount, but no other tracks (labels, audio etc) will be affected. There are still things that you can't do in a single step with this behaviour (mainly process many tracks independently), but I would view them as better done via scripting/chains/redo, leaving the things that can't be achieved that way to be done in the effect itself. If you can provide a use case that isn't covered by the above, then I would be interested in looking at it. Richard ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
Stevethefiddle
|
On Mon, 2009-08-03 at 20:17 +0100, Richard Ash wrote:
> On Mon, 2009-08-03 at 04:54 +0100, Gale Andrews wrote: > > > Can you please explain a little more this particular case? what should be > > > the expected result? > > > > > > I think Truncate Silence has no logic when applied to multiple tracks in a > > > group, because the analysis process could make different deletions in the > > > tracks, so what would be the resulting group behavior? follow just the first > > > track results and ignore the others? I think maybe Truncate Silence > > > shouldn't be available in this situation... > > > I think the first decision is "is Truncate Silence meant to work on > > multiple tracks in any case, irrespective of linking issues? That > > is, would I expect the result of truncating silence on two selected > > tracks simultaneously to be the same as doing it on each selected > > track in turn? I appreciate some decision may have to be made > > about the size of the residual selection region if applied > > simultaneously. Any input, Phil, or anyone, please ? > My take would be that there are two logical things to do when silence is > being truncated in multiple tracks at once: > > 1 Process them all at once. This could become the first example of what > I'll call a "multi-track effect", which works on all N selected tracks > of any combination of mono/stereo. In this case the logical thing to do > would be to internally calculate the mix of all the tracks at current > settings, then work out the truncation region based on the mix, and > finally truncate the offending sections out of all the tracks. Linking > would then control whether a label track underneath the audio tracks was > subject to the same truncations. I could imagine this being useful in a > situation where you had a multi-track mix and wanted to tighten up the > gaps between sections before mixing down to stereo (or if you were going > to use advanced mixing to export as multi-channel audio). For what it's > worth, this is analogous to a multi-channel compressor / noise gate, or > multi-channel voice-activated recording. > > 2 Process them all separately. This is the "default" audacity mechanism, > whereby each track is fed through the effect in turn, without reference > to the others. This works fine if linking is off, because each track > just gets sections blasted out without reference to any other track. The > problem scenario is when linking is on and we need to do truncation, > because we must then break one of the rules on how linking works. > > One option (2a) would be to always delete the data: > a. go along first track > b. find silence > c. delete that region from all other selected tracks, regardless. If > linking on, delete from all linked tracks (audio and label) regardless. > d. when this track completed, start on next track at start, same rules. > > I don't think this is a particularly helpful option, because lots of > things that aren't silent get deleted - in fact for a time period to not > get deleted, there must be signal in all the tracks over that period. > > More helpful might be to delete silence from multiple tracks, but not to > delete if there is signal (2b). The rules now go: > a. go along first track > b. find silence > c. check other selected tracks for signal in turn. If any have signal, > then don't delete and carry on searching > d. if all selected tracks are silent, delete that region from all > selected tracks. If linking on, delete from all linked tracks (audio and > label) regardless. > e. no need to process other tracks as there won't be any silences in all > tracks left (it doesn't matter which track you started processing in, > the result will be the same). > > This is a more useful behaviour, and almost the same as behaviour as > scenario 1 (the difference is when several tracks are quieter than the > "silence" threshold individually, but louder than it when mixed). The > implementation is considerably trickier in it's details however, so I > couldn't really recommend this as a design. I don't see the behaviour > distinction as that significant unless the SNR is very poor, in which > case Truncate Silence is unlikely to give anything like decent results. > > Separately, we need to ask the question what happens to a hypothetical > track that is part of the linked group but not selected when Truncate > Silence is applied with linking engaged (obviously with linking off, it > will be completely unaffected). There are two deletion strategies: > A. Don't touch the track. Fits the UI rules in that non-selected tracks > aren't affected, but breaks the linking rules in that the linked tracks > get out of sync. > B. Delete in the linked but non-selected tracks where we are deleting in > the selected tracks, regardless of the content of the non-selected > tracks. This breaks the UI rules in that non-selected tracks are > altered, but keeps the linking rules in that all the linked tracks stay > in sync. > > A. is the same as the linking-off case, for which reason I favour option > B., on the basis that if the user wants option A., they just press a > button to get it, where as if we opt for A., then there is no way to > achieve B. (I prioritise flexibility over ease of guessing in this case, > on the assumption that we document these rules carefully for the people > who will actively use them). > > For a use case, let's imagine we have two people talking and an ambience > track behind it. The tracks were recorded in sync so that break-through > from the ambience to the talkers is in sync, and this needs to be > retained (the ambience is quiet, but louder parts will be audible on the > speakers mics as echoes if I don't keep them in sync). I want to tighten > up the talking by removing silence, but obviously I don't want silence > to be left in just because there is a thump in the ambience channel. > > My suggestion is to achieve this by turning linking on for these three > tracks (put labels under them, say on the main questions of the > interview), then selecting the two speakers tracks (but not the ambience > or the labels) and running Truncate Silence. The result is a shortened > interview with an ambience track that is in sync and has been cut to > make it stay that way. Provided it's low level, that probably won't be > noticeable. > > > I believe users want Truncate Silence to work on multiple tracks > > because of what they see as "greater convenience". Unfortunately, > > the mere presence of multiple tracks in 1.3.8 either stops Truncate > > working at all, or gives corrupted results, even if only one track is > > selected (unless the tracks are duplicates of each other). Several > > users have told me they're going back to 1.3.7 because of this, so > > it looks like this will have to be another P2 I'm afraid. > This is a slightly separate point - if linking is off and I process a > single, selected track then nothing else should change. If it does, > that's a bug we probably need to resolve before we try to do anything > else (audit the code for incorrectly calling internal methods of the > linking system?). > > > To get to André's point, if the silences in the multiple regions to be > > processed are the same (and if we agree Truncate should work on > > multiple tracks), then there seems to be a potentially useful result. > > > > Here is an initial situation: > > http://www.gaclrecords.org.uk/1.png > > > > Here is what happens if you truncate both tracks with linking off: > > http://www.gaclrecords.org.uk/2.png > > > > Note the tone to the right of the selection is still full width. > This example is ambiguous, it could be that both tracks were processed > independently and happen to line up, or it could be that the sum of the > two were processed, and then the same truncations applied to both > tracks. Either Option 1 or Option 2 applies. > > > Here's what happens now if you apply truncate to both tracks > > with linking on: > > http://www.gaclrecords.org.uk/3.png > > > > Note the tones are truncated and the label has disappeared. > Broken - to me it's fairly obvious that's wrong. > > > Now here is my take on what should happen truncating both tracks > > with linking on: > > http://www.gaclrecords.org.uk/4.png > > > > This is identical to image 2, except the label moves back to the > > correct place. So we still have the label in the middle of the tones > > and they still have the intended width. > Ack, that's the reasonable outcome, and again applies equally to my two > models of how the effect could handle multiple tracks. > > > Now lets try a case where the silences in the selected regions > > are of different length: > > http://www.gaclrecords.org.uk/5.png > > > > Applying truncation to both linked tracks, what should happen? > > Here is one suggestion: > > http://www.gaclrecords.org.uk/6.png > > > This image was created by truncating each track separately in > > 1.3.7, then moving the label back so that it is still in the middle > > of the tone in the upper track. I think what happened here in this > > case is useful, if the point of the label was that it marked the > > centre point of that tone, and better than if linking was not on. > > But what if the label marked a significant event in the second track? In > that case it's been pushed out of sync with it's event. Worse still, if > you had lined up the ends of your two tones before the processing, they > are out of line now, because different amounts of silence have been > truncated in each track. To me this definitively breaks the linking > model, because the clip ends that used to line up don't any more. > > I would regard this behaviour as wrong. > > If we were to apply behaviour 1 to this selection, then there would be > no silence in the mixed track, so no truncation takes place. Quite easy > to predict! Supposing that the two silences, although of different > lengths, overlapped, then that overlap would be truncated, deleting the > same amount from each of the two audio tracks. With linking on, the same > amount would also be deleted from the label track, so the labels would > still match up to the mythical point later in the track to which they > originally referred. > > So to sum up a very long email, my view is: > * The signal in which silences are detected for deletion by Truncate > Silence should be the mix (sum) of all the selected tracks (Option 1). > * When linking is on, then the deletions made by Truncate Silence (and > any other truncating effect if we got them) should be made in all the > linked tracks, including unselected audio tracks (deletion strategy B.) > * When linking is off then all the selected tracks will be deleted in > the same place, by the same amount, but no other tracks (labels, audio > etc) will be affected. > > There are still things that you can't do in a single step with this > behaviour (mainly process many tracks independently), but I would view > them as better done via scripting/chains/redo, leaving the things that > can't be achieved that way to be done in the effect itself. > > If you can provide a use case that isn't covered by the above, then I > would be interested in looking at it. What should happen to white space within the selected tracks? (has this just been discussed somewhere else?) Steve > Richard > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > audacity-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/audacity-devel ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Martyn Shaw-2
|
In reply to this post
by Richard Ash (audacity-help)
Very clear thinking Richard! Thanks!
Martyn Richard Ash wrote: > On Mon, 2009-08-03 at 04:54 +0100, Gale Andrews wrote: >>> Can you please explain a little more this particular case? what should be >>> the expected result? >>> >>> I think Truncate Silence has no logic when applied to multiple tracks in a >>> group, because the analysis process could make different deletions in the >>> tracks, so what would be the resulting group behavior? follow just the first >>> track results and ignore the others? I think maybe Truncate Silence >>> shouldn't be available in this situation... > >> I think the first decision is "is Truncate Silence meant to work on >> multiple tracks in any case, irrespective of linking issues? That >> is, would I expect the result of truncating silence on two selected >> tracks simultaneously to be the same as doing it on each selected >> track in turn? I appreciate some decision may have to be made >> about the size of the residual selection region if applied >> simultaneously. Any input, Phil, or anyone, please ? > My take would be that there are two logical things to do when silence is > being truncated in multiple tracks at once: > > 1 Process them all at once. This could become the first example of what > I'll call a "multi-track effect", which works on all N selected tracks > of any combination of mono/stereo. In this case the logical thing to do > would be to internally calculate the mix of all the tracks at current > settings, then work out the truncation region based on the mix, and > finally truncate the offending sections out of all the tracks. Linking > would then control whether a label track underneath the audio tracks was > subject to the same truncations. I could imagine this being useful in a > situation where you had a multi-track mix and wanted to tighten up the > gaps between sections before mixing down to stereo (or if you were going > to use advanced mixing to export as multi-channel audio). For what it's > worth, this is analogous to a multi-channel compressor / noise gate, or > multi-channel voice-activated recording. > > 2 Process them all separately. This is the "default" audacity mechanism, > whereby each track is fed through the effect in turn, without reference > to the others. This works fine if linking is off, because each track > just gets sections blasted out without reference to any other track. The > problem scenario is when linking is on and we need to do truncation, > because we must then break one of the rules on how linking works. > > One option (2a) would be to always delete the data: > a. go along first track > b. find silence > c. delete that region from all other selected tracks, regardless. If > linking on, delete from all linked tracks (audio and label) regardless. > d. when this track completed, start on next track at start, same rules. > > I don't think this is a particularly helpful option, because lots of > things that aren't silent get deleted - in fact for a time period to not > get deleted, there must be signal in all the tracks over that period. > > More helpful might be to delete silence from multiple tracks, but not to > delete if there is signal (2b). The rules now go: > a. go along first track > b. find silence > c. check other selected tracks for signal in turn. If any have signal, > then don't delete and carry on searching > d. if all selected tracks are silent, delete that region from all > selected tracks. If linking on, delete from all linked tracks (audio and > label) regardless. > e. no need to process other tracks as there won't be any silences in all > tracks left (it doesn't matter which track you started processing in, > the result will be the same). > > This is a more useful behaviour, and almost the same as behaviour as > scenario 1 (the difference is when several tracks are quieter than the > "silence" threshold individually, but louder than it when mixed). The > implementation is considerably trickier in it's details however, so I > couldn't really recommend this as a design. I don't see the behaviour > distinction as that significant unless the SNR is very poor, in which > case Truncate Silence is unlikely to give anything like decent results. > > Separately, we need to ask the question what happens to a hypothetical > track that is part of the linked group but not selected when Truncate > Silence is applied with linking engaged (obviously with linking off, it > will be completely unaffected). There are two deletion strategies: > A. Don't touch the track. Fits the UI rules in that non-selected tracks > aren't affected, but breaks the linking rules in that the linked tracks > get out of sync. > B. Delete in the linked but non-selected tracks where we are deleting in > the selected tracks, regardless of the content of the non-selected > tracks. This breaks the UI rules in that non-selected tracks are > altered, but keeps the linking rules in that all the linked tracks stay > in sync. > > A. is the same as the linking-off case, for which reason I favour option > B., on the basis that if the user wants option A., they just press a > button to get it, where as if we opt for A., then there is no way to > achieve B. (I prioritise flexibility over ease of guessing in this case, > on the assumption that we document these rules carefully for the people > who will actively use them). > > For a use case, let's imagine we have two people talking and an ambience > track behind it. The tracks were recorded in sync so that break-through > from the ambience to the talkers is in sync, and this needs to be > retained (the ambience is quiet, but louder parts will be audible on the > speakers mics as echoes if I don't keep them in sync). I want to tighten > up the talking by removing silence, but obviously I don't want silence > to be left in just because there is a thump in the ambience channel. > > My suggestion is to achieve this by turning linking on for these three > tracks (put labels under them, say on the main questions of the > interview), then selecting the two speakers tracks (but not the ambience > or the labels) and running Truncate Silence. The result is a shortened > interview with an ambience track that is in sync and has been cut to > make it stay that way. Provided it's low level, that probably won't be > noticeable. > >> I believe users want Truncate Silence to work on multiple tracks >> because of what they see as "greater convenience". Unfortunately, >> the mere presence of multiple tracks in 1.3.8 either stops Truncate >> working at all, or gives corrupted results, even if only one track is >> selected (unless the tracks are duplicates of each other). Several >> users have told me they're going back to 1.3.7 because of this, so >> it looks like this will have to be another P2 I'm afraid. > This is a slightly separate point - if linking is off and I process a > single, selected track then nothing else should change. If it does, > that's a bug we probably need to resolve before we try to do anything > else (audit the code for incorrectly calling internal methods of the > linking system?). > >> To get to André's point, if the silences in the multiple regions to be >> processed are the same (and if we agree Truncate should work on >> multiple tracks), then there seems to be a potentially useful result. >> >> Here is an initial situation: >> http://www.gaclrecords.org.uk/1.png >> >> Here is what happens if you truncate both tracks with linking off: >> http://www.gaclrecords.org.uk/2.png >> >> Note the tone to the right of the selection is still full width. > This example is ambiguous, it could be that both tracks were processed > independently and happen to line up, or it could be that the sum of the > two were processed, and then the same truncations applied to both > tracks. Either Option 1 or Option 2 applies. > >> Here's what happens now if you apply truncate to both tracks >> with linking on: >> http://www.gaclrecords.org.uk/3.png >> >> Note the tones are truncated and the label has disappeared. > Broken - to me it's fairly obvious that's wrong. > >> Now here is my take on what should happen truncating both tracks >> with linking on: >> http://www.gaclrecords.org.uk/4.png >> >> This is identical to image 2, except the label moves back to the >> correct place. So we still have the label in the middle of the tones >> and they still have the intended width. > Ack, that's the reasonable outcome, and again applies equally to my two > models of how the effect could handle multiple tracks. > >> Now lets try a case where the silences in the selected regions >> are of different length: >> http://www.gaclrecords.org.uk/5.png >> >> Applying truncation to both linked tracks, what should happen? >> Here is one suggestion: >> http://www.gaclrecords.org.uk/6.png > >> This image was created by truncating each track separately in >> 1.3.7, then moving the label back so that it is still in the middle >> of the tone in the upper track. I think what happened here in this >> case is useful, if the point of the label was that it marked the >> centre point of that tone, and better than if linking was not on. > > But what if the label marked a significant event in the second track? In > that case it's been pushed out of sync with it's event. Worse still, if > you had lined up the ends of your two tones before the processing, they > are out of line now, because different amounts of silence have been > truncated in each track. To me this definitively breaks the linking > model, because the clip ends that used to line up don't any more. > > I would regard this behaviour as wrong. > > If we were to apply behaviour 1 to this selection, then there would be > no silence in the mixed track, so no truncation takes place. Quite easy > to predict! Supposing that the two silences, although of different > lengths, overlapped, then that overlap would be truncated, deleting the > same amount from each of the two audio tracks. With linking on, the same > amount would also be deleted from the label track, so the labels would > still match up to the mythical point later in the track to which they > originally referred. > > So to sum up a very long email, my view is: > * The signal in which silences are detected for deletion by Truncate > Silence should be the mix (sum) of all the selected tracks (Option 1). > * When linking is on, then the deletions made by Truncate Silence (and > any other truncating effect if we got them) should be made in all the > linked tracks, including unselected audio tracks (deletion strategy B.) > * When linking is off then all the selected tracks will be deleted in > the same place, by the same amount, but no other tracks (labels, audio > etc) will be affected. > > There are still things that you can't do in a single step with this > behaviour (mainly process many tracks independently), but I would view > them as better done via scripting/chains/redo, leaving the things that > can't be achieved that way to be done in the effect itself. > > If you can provide a use case that isn't covered by the above, then I > would be interested in looking at it. > > Richard > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > audacity-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/audacity-devel ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
André Pinto
|
Hi,
Back to this after some work with Automatic Volume and other bugs. Firstly, thank you all for the ideas and test cases. I've committed a possible fix. Now Truncate Silence works with the 2b detection strategy (I've used this one instead of 1 as the effect was already working that way so the changes needed were minimized, it only had some problems with the deletion process that I've fixed now), and B strategy for deletion as suggested by Richard Ash (thanks again for your input). The white space problem reported by Steve is not fixed yet. Besides the white space issue I would like to know if the actual Truncate Silence behavior is acceptable or if it is not, what should be improved? Thanks, André. On Tue, Aug 4, 2009 at 10:51 PM, Martyn Shaw <[hidden email]> wrote: Very clear thinking Richard! Thanks! ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
