Regular Interval Labels enhancements

In response to the feature request here: https://forum.audacityteam.org/t/regular-interval-labels-improvements/18970/2
I’ve added a couple of new features to the “Regular Interval Labels” plug-in.

New Features:

Label numbers may be before or after the label text.
For example;
1_label, 2_label, 3_label …
or
track_1, track_2, track_3…

User defined start number.
Some users may prefer to start numbering at “1” rather than at “0”.
Also, if splitting two recordings, one from the “A” side of an album and one from the “B” side, it may be useful to start numbering for the B-side so that the numbers follow on from the A-side.

Numbers with preceding zeros
If there are more than 9 songs exported with “Export Multiple” (based on labels), the exported tracks would not previously have been in alphanumeric order.
For example with 12 tracks the alphanumeric order would be:
0, 1, 10, 11, 12, 2, 3, 4, 5, 6, 7, 8, 9

By setting the minimum number of digits to 2, single digit numbers will be give a preceding zero, so the numeric order will now be:
00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12

The user may select:
No numbers - label text only
Minimum 1 digit - same as original version.
Minimum 2 digits - one preceding zero for single digits.
Minimum 3 digits - two preceding zeros for single digits.

I’ve also partially refactored the code to make it more readable and easier to work on. Most of the (profuse) commenting has been left in place.

I have temporarily renamed this plug-in “Regular Interval Labels 2…” so that it can be installed alongside the original “Regular Interval Labels…”

Please test and reply with comments in this thread.

Latest Version

Thanks… these are excellent improvements to this plugin!

I’ve noticed that there is no error message for invalid time intervals or invalid number of labels.
I’ll need to tidy up the error checking in the next version (but that won’t be tonight :wink: )

If you choose a negative number to start, it will work fine. If you put a letter in instead of a number it just starts at zero!

I can’t find any bugs though!

Thanks again

Yes I’ve got that one covered, but (silly example) try typing “hello” into the “Label interval [seconds]” box, then click the “Debug” button. This error occurs even if the “Label placement method” is set to “Number of Labels”.

BTW, this is not a bug in the new code - it’s always been in this plug-in, but I might as well fix it now.

I think I’ve covered all possible user input.
Unusual, but valid user input is allowed (such as starting numbering from a negative number).
Labels before zero are prevented by shifting the start time to zero.
Any other invalid input will produce an error message (I hope).

Please let me know if you can break it.
equalabel2.ny (5.99 KB)

The only thing I can find is that it still allows negative numbers for the Begin Numbering From.

Thanks

Thanks for testing it.

Yes I’m aware that it can start numbering from a negative number, but it does not cause a problem, so I think that users should be allowed to do that if they want to.
Someone may want to make 10 equal interval labels that go:
track-10, track-09, track-08,… track-01.

I’ve only disallowed things that can cause problems, for example;
A negative number of labels would cause a “division by zero error”, but the user would just see “Nyquist did not return audio”. Rather than that (which is not very helpful), the error is now caught and the user will see an error message saying what they have done.

Ok, then the only other thing I can find, is that when you choose a negative Begin Numbering From number, it calculates the negative sign as one digit, so when you choose “1 digit” or “2 digits” you get this:
track-11, track-10, track-9, track-8, etc

and when you choose “3 digits” you get this:
track-11, track-10, track0-9, track0-8

So in these two scenarios (only starting from a negative number), you still would have track names that do not order properly in Windows.

Good catch jsherk.
It would have been easier to just disallow negative start numbers, but I kind of like it as an “unofficial bonus feature”, so here’s the fixed version
equalabel2.ny (6.07 KB)

Yep, that seems to have fixed that as well! Not that I can think of any reason I would ever use that negative numbers, but I am sure somebody somewhere will be grateful that you left it in there as a bonus feature!

Thanks so much for fixing the plugin and adding these features!

My thoughts exactly :smiley:

Gale Andrews has noticed an issue with Regular Interval Labels:

If you choose “number of labels” for label placement method and “include final label”, the labels are spread out along greater than the selected length.
For example, with a 30 seconds mono tone,
10 labels and including the final label, the label interval becomes 4 seconds instead of the expected 3 seconds, and the final label is at 40 seconds.

As this bug has always been present in Regular Interval Labels, I’m a bit surprised that it has not been commented on previously, though I guess it is an uncommon scenario.

Buried in the original code is this section;

; choose between user-selected label interval or number of labels
(cond 
((= placement 1) ; number of labels
(setf time (if (= include 0)
(float (/ dur label-number)) (1+ (float (/ dur label-number)))))
(setf labels (if (= include 0) label-number (1+ label-number)))
) ; end placement 1

The problem is in the 5th line;
If a final label is included, then the interval duration “time” is set to

(1+ (float (/ dur label-number)))

which means that 1 second has been added to each time interval.

The (float) function is not required as “dur” is already a float, so (/ dur label-number) will automatically be a floating point number.
(In the new version this section has been separated out into a function at line 68 ; function to calculate ‘time’ based on number of labels).

I think that the logical behaviour would be that if a final label is to be included, then the time interval between labels should remain unchanged, and a final label added at a time interval equal to all of the others.

In this case, time should be set to

(/ dur label-number)

regardless of whether a final label is included or not.

However, this then makes the option “Include final label” somewhat ambiguous.

If a specific number of labels are to be set (say 10 labels), then the spacing between labels will be (length-of-selection / number-of-labels), which is written in the code as (/ dur label-number). This means that the 10 labels will be spaced to exactly fit the duration of the selection (regardless of whether “Final audio segment equal with others?” is set or not).

The question is, if “Include final label” is selected, what should happen?
Should an extra label be added to the end, making a total of 11 labels?

I think this is a reasonable expectation, but then the wording would probably be clearer if it said "Add final label, rather than “Include final label”.

I have applied this solution in this updated version.
equalabel2.ny (6.06 KB)

Thanks Steve, perhaps this should be equalabel 2.1 or 3 to distinguish it?

I think it’s much better to restrict labels to the selected length as per your change. With the previous versions, even a
“5 min 30 seconds track, 10 labels with a final label” placed label 10 a full 9 seconds after the correct point, so it was never acceptable (or at least, never logical). I assume from this that hardly anyone bothers with the “final label”.

Rather than confuse slightly by having a “final label” and a “final segment” in the wording, how about

“Add label at endpoint?”

“Equal segments for label interval method?”

Just to be awkward I found another unusual scenario where the result isn’t really what I would expect. Use “Label interval” method, but make the label interval > half the selected length.Then you get only the first label at time zero and no second label at all. Not sure it matters though.


Gale

I actually did notice this, but just assumed it was how it was supposed to be.

For my purposes, I set Final Label to No and never really thought about it anymore!

Thanks

I agree that it looks odd, but I think it is correct.
Say that the selected track is 10 seconds long.
With intervals of 3 seconds there can be 3 segments of 3 second duration (+ 1 second left over), hence 3 labels.
Interval = 4 seconds => 2 segments of 4 seconds (+ 2 seconds left over) => 2 labels.
Interval = 6 seconds => 1 segment of 6 seconds (+ 4 seconds left over) => 1 label.

would not be quite accurate.
The final label will only be at the “endpoint” (i.e. at the end of the selection) if either (a) “Final audio segment equal with others” is selected, or (b) the label spacing fits exactly into the selected region.
If “Final audio segment equal with others” is not selected and the label spacing does not fit exactly into the selected region, then if a final label is added it will be before the end of the selection.

Example:
10 second selection, 3 second interval, “Final audio segment equal with others” = No, “Add final label” = Yes
Labels will be placed at 0, 3, 6 and 9 seconds.

I think that’s an improvement, but it’s a bit long for the interface.
How about “Adjust ‘Label interval’ for exact fit”

As the interface automatically adds a colon, I think I prefer the control text without question marks.

Add final label: [No/Yes]
Adjust ‘Label interval’ for exact fit: [No/Yes]

rather than

Add final label?: [No/Yes]
Adjust ‘Label interval’ for exact fit?: [No/Yes]

I’ve named this version “Regular Interval Labels 2.3…”
If this replaces the old version, would it be best to just call it “Regular Interval Labels…”
equalabel2.ny (6.12 KB)

Agreed.

I think it’s legitimate to see the final label as an “endpoint” given the segment it creates is a leftover which is shorter than the requested interval (and is zero length if they request “equal segments”). “Endpoint” is clearer for equal segments, but less so otherwise. “Add final label” as now is clearer overall.

I like the “Adjust Label interval” but not keen on “for exact fit” which I think is less clear than my idea.
Can we agree on “Adjust label interval to fit length” ?

What is our policy on code-commenting the minimum Audacity version where plug-ins are distributed in Audacity? I think we are going to list such plug-ins at the bottom of Wiki Download Nyquist Plug-ins, but people who must use legacy versions of Audacity for one reason or another may still wish to know if they can use that plug-in.

We know Regular Interval Labels is version 3 so won’t be visible in Audacity 1.2, but it looks like the “min version” (for all platforms) would be 1.3.5. Although it’s functional in 1.3.3, the interface formatting is messed up with most controls not lining up. Is that generally true for v3 plug-ins?



Gale

Yes, that sounds good.

I don’t know what changed between 1.3.3 and 1.3.5, but it may be the double line ;control name for “Label numbering:n(minimum number of digits)”
If you have Audacity 1.3.3 installed, could you try changing that to “Label numbering” to see if the formatting then looks “normal”.
That will make line 26:

;control labelnum "Label numbering" choice "None - text only,1 digit before,2 digits before,3 digits before,1 digit after,2 digits after,3 digits after" 2

I’m not proposing that we do change the name of this control, but it would be useful to know.
If you can think of a shorter (single line) description for this control that is as clear or better, then we can change it.
The full description would be something like: “Minimum number of digits. Shorter numbers will be prepended with zeros. If used, numbers will be added before or after the label name.”

I guess there are some “key” versions that some users may need to use.
Would you be able to make a post saying what those key versions are and which users they apply to. If I know the key versions I can go through them and see which Nyquist features are unavailable for each of those key versions. (I don’t want to go through every version of Audacity.

As it stands it looks like the minimum Audacity version for this plug-in is 1.3.5

Doesn’t help. David’s Equalabel and the new (v3) High Pass have the same issues, so I figure 1.3.5 rather than 1.3.x is the real cutoff for v3 Plug-ins (or we say, they work in 1.3.3 - 1.3.4 but the interface displays incorrectly). I’ve verified v3 plug-ins are invisible in 1.3.0b, so the previous belief that they might at least work in 1.3.x is incorrect.
equalabel_in_1.3.3.png

I think the problem is that we must say “minimum number of digits”, unless we decide the minimum number to be used so only give a choice for “none”, “before” or “after”.

For example, Export Multiple gives you two digits minimum. So only one label is “01”, but the hundredth label is “100”. No-one I’ve seen has complained (yet).

Otherwise, “Minimum number of digits in labels” is the best I can think up.

Based on OS support, yes. But a user who wanted some specific feature such as Effect Categories could be interested in just about any version, so a “min version” that only really meant for example “between 1.3.3 and 1.3.7” may not be fine-grained enough.

Another approach rather than go through every Audacity version may be to review code changes just in lib-srclibnyquist, then match significant dates with releases by looking at release notes. And express “min version” as “won’t work with < x. may not work fully with < y”.


Gale

That looks like a bug in Audacity 1.3.3.
In both of those screen shots the interface has failed to start a new line after an empty “right text” for “multiple choice widgets”.

The release notes say that in Audacity 1.3.4 “Nyquist plug-ins reviewed and enhanced”, so it may have been fixed by then.
There’s no mention of Nyquist in the release notes for 1.3.4, so version 1.3.4 may be the cut-off.
[Update: Tested in “1.3.4 Windows (Unicode)” and it works OK]

I’ll start a new topic regarding compatibility with old versions rather than discussing it further here.

The only other solution that I can think of (but I’m unsure if it’s more or less clear):

Label number format:

(options)
None - text only
single digit/label
2 digits/label
3 digits/label
label/single digit
label/2 digits
label/3 digits

Some may find this slightly misleading as the forward slash is not written in the label, but others may find it clearer than “before” and “after”.
These options could also be used with “Minimum number of digits in labels” as the ;control text.

I don’t have a strong preference, so we just need a decision. If anyone would like to state a preference, now is the time.

Summary of changes needed before final release:

  • File name and plug-in name. Will these be the same as the current “Equal Labels”?
  • Change final ;control text to “Adjust label interval to fit length”
  • Decide on ;control text and options for “Number format”
  • Add in comments: “Supported Audacity versions: 1.3.4 or later”