Edit > Labelled Regions

[steve]

I don't read what you said as "pretty clear" ( http://sourceforge.net/mailarchive/foru ... ty-quality ):

There are over 4700 lines of code in that file and I'm not a C++ programmer so of course it's going to take me some time to work out what it means.

No developers have supported your arguments.

To quote James:
"Cutting labels individually and silencing labels individually make sense."
That is the feature that I am requesting.

[steve]

Another user case.

Here's a "phone-in" recording.

tracks001.png (21.72 KiB) Viewed 2704 times

The conversation has been transcribed in labels. The labels may or may not be touching. In this example some are and some are not touching.

It's clear that "Sarah" is a lot quieter than "John" so we will probably want to amplify the "Sarah" parts.
There may be other processes (such as equalization or noise reduction that we wish to apply to Sarah but not to John.

We can use "Edit > Labelled Regions > Split"
and then duplicate the audio track:

tracks002.png (27.66 KiB) Viewed 2704 times

Then we can quickly go through and delete Sarah from one track and delete John from the other:

tracks003.png (25.71 KiB) Viewed 2704 times

[steve]

Another user case:

I have a live recording and I want to separate the songs.
I mostly want to keep the original spacing between tracks so as to maintain the atmosphere and continuity, but there is a section between 01 and 02 that I'm going to delete.

tracks004.png (19.98 KiB) Viewed 2709 times

With my patched Audacity - "Edit > Labelled Regions > Split"

tracks006.png (20.05 KiB) Viewed 2709 times

Then delete the unwanted section.

tracks007.png (19.8 KiB) Viewed 2709 times

[Gale Andrews]

Thanks for being motivated enough to make a patch, however even if there are more use cases for the behaviour you like than current behaviour (I suspect there could be), it doesn't change the fact that it introduces a regression for people who like it as it is. I don't see why removing the trim of surplus labels is the best solution.

Please explain what you mean by "Split Copy" in your patch comments.

What you've done now doesn't remove the labels between regions that touch. So when you perform a labeled region action over touching labels that had no split lines, and that action adds the audio to the clipboard, then you paste, we now paste the split lines where we did not before. Might some people not be expecting that, given there were no split lines before the labeled region action?

This solution also means that there is no possibility of an extra menu item with alternate behaviour for "Split" (which I think is the item which most lacks what you want to see). So to avoid a regression for someone who likes what we have now, we need a preference (which you don't provide).

To quote James:
"Cutting labels individually and silencing labels individually make sense."

I thought he was talking about the new multiple labels select feature. Even if not, your patch does not silence touching labels individually (if that means adding split lines so that you can then double-click in one of the audio clips). Is that another inconsistency we should address?

The labels may or may not be touching. In this example some are and some are not touching.

In the case of some labels touching and some not, I can probably think of use cases where the current behaviour that splits discrete groups of labels is useful. So that may not be a plus in all cases.

I have a live recording and I want to separate the songs.
I mostly want to keep the original spacing between tracks so as to maintain the atmosphere and continuity, but there is a section between 01 and 02 that I'm going to delete. With my patched Audacity - "Edit > Labelled Regions > Split"

I don't follow that, because you can do that pre-patch. Can you give more steps as to what your patch adds in that case?

Other points:

In your patch, Edit > Labeled Regions > Join no longer works, so that's another regression (no doubt you've exposed some other problem the code had). Pre-patch where we had a group of touching labels, we removed the inner split lines and left the two outer split lines in situ. Edit > Clip Boundaries > Join removes all the split lines. I think that distinction is possibly reasonable, and may be useful in some cases. Agree?

Where there are no previous split lines, and we do a labeled regions action that adds audio to the clipboard where the labels are not touching, we do not paste split lines either pre- or post- patch? Should we? A choice for what we do here could possibly be worked into making these whole group of behaviours into a preference.


Gale

[steve]

I would think that most users would expect that "Labelled Regions > Split" will split each labelled region.

The aim of my patch is to make the behaviour consistent with apply the selected behaviour manually to each labelled region. I believe that this is would be the expected, most useful and "correct" behaviour.

Unfortunately my patch is a little too simplified and fails in some cases.

In your patch, Edit > Labeled Regions > Join no longer works

The behaviour is consistent with applying "Join" to each labelled section. White space and gaps within a labelled region are joined, but only if they occur "within" one labelled region. In this case I agree that this may not be the most useful behaviour.

A more important problem with my patch is that it does not produce intuitively expected behaviour if there are overlapping labels.

This solution also means that there is no possibility of an extra menu item with alternate behaviour for "Split"

I got the impression that no-one wanted the extra complication of alternative behaviours, which is why I would prefer the more "useful" behaviour.
If there is support for alternative behaviours then we should be discussing that.

[Gale Andrews]

I would think that most users would expect that "Labelled Regions > Split" will split each labelled region.

The aim of my patch is to make the behaviour consistent with apply the selected behaviour manually to each labelled region. I believe that this is would be the expected, most useful and "correct" behaviour.

I still disagree with the aim if the aim is to force the behaviour on the users.

In your patch, Edit > Labeled Regions > Join no longer works

The behaviour is consistent with applying "Join" to each labelled section. White space and gaps within a labelled region are joined, but only if they occur "within" one labelled region. In this case I agree that this may not be the most useful behaviour.

I don't even think it's consistent (or at least, intuitive) as it is now. If Labeled Regions > Split splits touching labels, I would think the intuitive thing is for Labeled Regions > Join to join touching labels so they are no longer individual clips.

The only case I found where Join still works is where two clips overlap.

A more important problem with my patch is that it does not produce intuitively expected behaviour if there are overlapping labels.

What behaviour do we want for each Labeled Regions action when there are overlapping regions?

My gripe with your patch here is that when you paste the content of overlapping regions, the overlap is treated as white space, removing the audio that was overlapped. I would have thought that pasting would produce the same split lines that Labeled Regions > Split produces.

This solution also means that there is no possibility of an extra menu item with alternate behaviour for "Split"

I got the impression that no-one wanted the extra complication of alternative behaviours, which is why I would prefer the more "useful" behaviour.
If there is support for alternative behaviours then we should be discussing that.

I think this is about the fifth time I've said there must be alternate behaviours if we are to avoid a regression and possible complaints. I can definitely see people complaining if they paste a bunch of split lines after Labeled Regions > Copy where there were no split lines when they copied.

I found it hard to understand what James meant (I'm not even sure he understood what your issue was) but I do think he was against menu proliferation in the Labeled Regions cascade.

This may also be too simplistic, but as I see it there could be a Labeled Regions preference to "treat joined or overlapped labels as one label". I would set that to "on" for my use cases. You would set it to "off" and maybe the default would be "off". If we wanted that option to be more discoverable, it could be in the Labeled Regions cascade as an item you could toggle on/off by clicking, as with some of the Transport Menu items. I don't regard one item as undue proliferation.

Or would "treating joined or overlapped labels as one" have certain other uses? Try setting this up(A):

What should happen with the labels when we repeat the selection once?

repeat_overlap_of_region_and_labels.png (6.05 KiB) Viewed 2671 times

Then Effect > Repeat with one repeat which produces this(B):

After one repeat

after 1 repeat.png (8.98 KiB) Viewed 2671 times

I am not sure if one would regard that extension of label "e" as a bug or not, but I would think one "expected" outcome would be the same as doing a copy of the region, then a paste at the end of the region, thus(C):

After copy and paste of region at the end of the region.png

after copy and paste of region at the end of the region.png (9.3 KiB) Viewed 2671 times

If (C) was the result of "treat labels as one" being "off", then in that case I would have it "off", so maybe it really is a separate issue.


Gale

[steve]

Some points of general agreement first:

I don't even think it's consistent (or at least, intuitive) as it is now. If Labeled Regions > Split splits touching labels, I would think the intuitive thing is for Labeled Regions > Join to join touching labels so they are no longer individual clips.

+1

I still disagree with the aim if the aim is to force the behaviour on the users.

The current behaviour is forced on the user, so I guess I'm +1 here too

I think this is about the fifth time I've said there must be alternate behaviours if we are to avoid a regression and possible complaints.

I'm aware of your position, but I was meaning "menu proliferation in the Labeled Regions cascade".
I think that we may be able to achieve behaviours that everyone will be happy with with possibly just one more menu option. I'm still working through the options and will post again shortly with details, but if we can keep everyone happy with just one additional labelled region behaviour then I think that will definitely be worth doing (even if it is eventually replaced by something more powerful).


The current behaviour (as documented) where labels are not touching and not overlapping is imho as expected, so +1 for keeping the current behaviour where labels do not touch or overlap.

[steve]

What behaviour do we want for each Labeled Regions action when there are overlapping regions?

I think that it's worth looking at the behaviour for all three cases, separate regions, touching regions and overlapping regions.

Cut
The current behaviour is that each region is cut from the audio track(s) and copied to the clip board.
There are no split lines.
When pasted to new track(s), touching and overlapping regions are pasted as single audio clips (merged). Separate regions are pasted as separate audio clips.
I think this is the expected behaviour.


Delete
As for "Cut" but the audio is not copied to the clipboard.
I think this is the expected behaviour.


Split Cut
Audio within labelled regions is cut, leaving white space. With respect to the copied audio, the behaviour appears to be identical to "Cut".
I don't think that this is the correct behaviour in the case of labels that touch or overlap as the copied audio is not "split".


Split Delete
This behaviour is similar to "Delete" except that white space remains where the audio has been deleted.
I think this is the expected behaviour.


Silence Audio
All labelled regions become silence. There are no splits.
I think this is the expected behaviour.


Copy
All labelled regions are copied. Joining or overlapping regions are treated as one audio clip. There are no splits.
I think this is the expected behaviour.


Split
Separate regions are split at the end of each region. Joining regions are treated as one region.
This is the behaviour that I think is least expected and limits the usefulness of this feature.
I think that there needs to be some way to split each labelled region even if they are touching (several user cases already provided).


Join
This one is a bit peculiar. I'm not sure what the "correct" behaviour should be.
Currently:

• Splits and white space are joined if they are entirely "within" (bounded by) one labelled region or multiple labelled regions that touch or overlap.
• White space is not rendered to silence if it is only partly bound by a region (this probably makes sense as there is nothing within the labelled region for it to "join" to.
• Split lines that occur exactly on the end of a separate labelled region are not joined, which is perhaps surprising as...
• Split lines that occur exactly on the end of a labelled region are joined IF that boundary is shared by another region.
• Split lines that occur exactly on the end of a labelled region are joined if they are bound by an overlapping region.

The number of bullet points that are required to fully define the "Join" behaviour is arguably indicative of inconsistency within labelled region behaviours.
It is probably easiest to see the behaviour with a before and after example:

Before and After "Join"

tracks001.png (18.99 KiB) Viewed 2663 times

Detach at Silence
Any (non-white space) totally silent audio that lies within one or more labelled regions is converted to white space.
There is a marked contrast with "Join" in that the silent audio does not need to be entirely bound by the label but I think this "inconsistency" is because of the slightly strange behaviour of "Join" rather than a problem with "Detach".
I think this is the expected behaviour.


Summary.
The main problem issues in my opinion are the behaviours that involve "Split".
I think the lack of clarity about "Split" and "Split Cut" then has a spill-over effect that makes the behaviour of "Join" confusing.

Proposal for "improved" behaviours to follow.

[steve]

I am not sure if one would regard that extension of label "e" as a bug or not, but I would think one "expected" outcome would be the same as doing a copy of the region, then a paste at the end of the region, thus(C):

+1
I agree that the "expected" result would be "C", though I can see why it isn't.
There are several other peculiarities with pasting labels (and they don't seem to be associated with the same code) so I think it may be better to deal with those as a separate issue.

[steve]

This may also be too simplistic, but as I see it there could be a Labeled Regions preference to "treat joined or overlapped labels as one label".

Yes I agree that is one possible solution, and it only requires one additional item in the menu.
I think that the only question that is left open by this proposal is;
Should "Join" operate on a split that is exactly on the label boundary?
I would suggest "no" (as now).


Another possible solution is that rather than introducing another menu option, introduce a simple rule:
All labelled regions are treated separately unless overlapping.
To put it another way, overlapping regions are treated as one region.

What this would mean in practice - these examples apply this proposed rule to "Labelled Regions > Split". In each case, assume that the audio began as one continuous section and "Labelled Regions > Split" was applied.

Splitting words

tracks003.png (18.81 KiB) Viewed 2660 times

Here we split words. Whether the labelled regions touch or not, each labelled region is split.


To split phrases or sentences we can "tie together" multiple labels by adding one more label across the boundaries that we don't want to split.

Splitting phrases

tracks002.png (21.29 KiB) Viewed 2660 times

The labels used to tie together sections do not need to exactly match other label boundaries, they just need to cross the boundaries that are being tied together, thus providing a simple and flexible method to select which labels create splits:

tied labels

tracks004.png (14.22 KiB) Viewed 2660 times