The milliseconds in the label editor rounds up

I was segmenting a file and for a while, it was great. Then, it just started rounding my milliseconds. They need to be exact. For example, I need 38.398 and it rounds up to 38.400. Is there a setting I need to change?

MacOs Ventura 13.1
Audacity 3.2.4

Check that “Snap To:” is set to “off”. See: https://manual.audacityteam.org/man/selection_toolbar.html

Snap to is set to off and it’s still happening

Update:
I tried again using my husband’s computer (pc) and it still started rounding up at the exact same spot. I checked the setting from the post above and they’re all the way they’re supposed to be.

So two different computers with two different operating systems and the file rounds up at the exact same time on both.

Please provide precise steps that allow me to reproduce the issue.

I right click the label, change the start time to what it needs to be. Then I click ok. Then the start time rounds up to the next hundredth of a second.

Where / how are you seeing that?

For what it’s worth, it seems to be working correctly for me.

I’m so glad it working for you Steve. It’s not working for me.

It seems to work fine on Windows:


Perhaps you would like to provide additional details.

What happens when you Export > Labels, and edit the file with a text editor? On my computer I can edit 6 decimal places in the text file.

I may have something here. This may not be what is happening to bkholch8, but I think it may be a bug. This is complicated …

Steps to reproduce

  1. generate 1 second of audio (we’re going to zoom way in)
  2. in the Selection Toolbar, set the selection format to hh:mm:ss + milliseconds
  3. click somewhere in the audio track
  4. zoom in until about 0.05 seconds is visible
  5. use the left and/or right arrow keys to move the selection so that the displayed selection start does not end with zero (I set it to 0.437)
  6. create a label at that point
  7. change the selection format to hh:mm:ss + hundredths
  8. right-click in the label to open the label editor
  • note that the times in the Edit Labels dialog are displayed using the format used in the Selection Toolbar
  • in my case they display “00h 00m 00.44 s”
  1. move the Edit Labels dialog so you can also see the project window
  2. in the Start Time field of the Edit Labels dialog, set the selection format to hh:mm:ss + milliseconds
  • note that the rounded value is displayed rather than the actual value set in step 5
  • in my case they display “00h 00m 00.440 s”
  • also note in the project window that the position of the editing cursor has changed to the rounded time value displayed in the Edit Labels dialog
  1. click Cancel in the Edit Labels dialog
  2. in the Selection Toolbar, set the selection format to hh:mm:ss + milliseconds
  • if you weren’t zoomed in you’d think the label had moved, but it hasn’t
  1. click in the waveform and press Option + right-arrow (or left-arrow as needed) to select the label
  • note that the reported position of the label is the same as at step 5
  1. in the Selection Toolbar, set the selection format to hh:mm:ss + hundredths
  2. right-click in the label to open the label editor
  3. in the Start Time field of the Edit Labels dialog, set the selection format to hh:mm:ss + milliseconds
  • note that the rounded value is displayed rather than the actual value set in step 5
  • in my case they display “00h 00m 00.440 s”
  • also note in the project window that the position of the editing cursor has changed to the rounded time value displayed in the Edit Labels dialog
  1. click OK in the Edit Labels dialog
  • note that the label has moved to the rounded time

The bug is at step 10 (or step 16). When changing the selection format the dialog should refresh using the actual stored value of the label. Also, why does the position of the editing cursor change when changing the selection format in the Edit Labels dialog?

bkholch8, what is the selection format have you selected in the Selection Toolbar?

– Bill

Testing on W10 with 3.2.4 In confirm Bill’s results - also in latest 3.3.0 alpha audacity-win-3.3.0-alpha-20230220+7ed07a8-x64-msvc2022

Both step 10 and step 16 look like bugs to me (or both manifestations of the same underlying issue)

The big learnings for me (after many years use and QA testing of Audacity):
a) the time format in the labels editor, on launch, mirrors the format in the selection toolbar,
b) one can change the time format in the labels editor independently of the format in the selection toolbar.

The ability to change format in the labels editor came as a total surprise - an real easter-egg for me. Although a careful RTFM does show this is documented, but easy to overlook:
https://alphamanual.audacityteam.org/man/Labels_Editor
UPDATE: I added some bullet pointing for readabilty and clarity


I’m not sure what the underling design issue or solution might be. Perhaps the label editor should always have its format governed by the setting in the Selection toolbar and remain in lock-step with it.

One thing that does cross my mind is that moving to a lower resolution format in the Selection toolbar can result in a loss of accuracy - in Bill’s use case this however is a mere 1-4 thousandths of a second.

Perhaps the Labels editor should always work in hh:mm:ss + milliseconds (regardless of what is used in the Selection toolbar, or Time toolbar) in order to retain fine accuracy.

But I’m a at loss really as to what is the best for this situation.

Peter.


Further update
Note carefully that changing the time format in the Labels Editor is strictly temporary, it does not persist. The next time you launch it the time format will be set to whatever is in use in the Selection toolbar at that time.

No, because people may be working to sample accuracy. But always working to “hh:mm:ss + samples” would not suit everyone because sample times are awkward to work with. In my opinion it needs to be user selectable.

This is why the “bug” occurs, but imo it isn’t a bug, it’s user error. If you want to work to ms accuracy it’s crazy to select hundredths at this point (other than for testing purposes :wink:)

At this point, the label editor opens with the same time units as the Selection Toolbar, which I thing is totally reasonable, but obviously the precision of time value is limited by the units (which the user selected in step 7).

The confusion is because you are expecting the editor to automatically update its data, by re-reading the labels, when you change the time units in the editor, but the editor doesn’t do that. The editor is populated with label data when launched, and opens as a modal window so the labels cannot be altered outside of the editor.

If you want the label editor to update its data when the units are changed, that would be a feature request, but I’m not sure how it could be done The design goal of the label editor is for the editor to update the labels, not for the labels to update the editor. If updating occurred in both directions (editor → label and label → editor) you may end up with an infinite loop.

I expect the chance of this being “fixed” is close to zero, even if the developers agree that there is something broken (I don’t think there is), unless of course their leader decides that “fixing” this would be a major usability improvement (as this behaviour has been the same for years, I don’t thing it’s much of an issue at all - just ensure that you don’t reduce the time precision before opening the editor).

I can only agree with this - a crazy edge case


I’m strongly minded to agree

So not worth the effort of logging methinks - but good and fascinating forensic work from Bill :ugeek: :sunglasses:

Peter

Indeed :slight_smile:

A few points …

  1. Does this help the OP with their problem? This all started with me trying to find a way to reproduce the issue.

  2. The only reason I’m flipping between selection formats in the Selection Toolbar is to demonstrate what’s happening to the label position. What if the user was in hh:mm:ss + hundredths and left it there? They open the label editor and want millisecond precision so they change the selection format in the Edit Labels dialog. They set it to what they want, edit the label value and click OK. Opening it again it appears that the label position has been rounded. But is hasn’t been rounded it is just displayed to the rounded precision. Cancelling the dialog shows that the rounding does not actually occur but is an artifact of the selection format.

  3. If the selection format in the Selection Toolbar was hh:mm:ss then the rounding would be to the nearest second.

  4. Why does the position of the editing cursor change in step 10? There appears to be some communication from the Edit Labels dialog to the project window.

  5. Label positions are stored in the AUP3 file to crazy precision (6 decimal places?). Why can’t the Edit Labels dialog read and store this value locally, then use that stored value to repopulate the selection widget when the format is changed? I don’t see a need to re-read the label value from the AUP3 file and no chance of an infinite loop. This would be my suggestion to fix this anomaly, but I agree it would be very low priority . The argument for this being user error is persuasive - if you want millisecond precision, set the selection format in the Selection Toolbar appropriately.

– Bill

having thought about this some more I would:

a) remove the ability in the Labels Editor to change the time format
b) always have the Labels editor time format take its setting from the Selection toolbar value

This way if the user wants greater or less precision the change the Selection toolbar setting. I see no real benefit in enabling the user to have different time formats in the Selection toolbar and the Labels editor.

Come to that I don’t see much benefit (apart from a neater-looking and less frantic, clock) for the Time toolbar to have a different time format from the Selection toolbar - but James obviously thought differently.

However the user will still possibly get rounding of label precision if they change Selection toolbar time format to a higher granularity (or at least I think that would be the case).

Peter

A further thought: why is the rounding based on then display format necessary at all, surely the rounded display can be different from the actual value.

Excel does this all the time - take fn =1/3 at 4 decimal places this is 1.3333, change that to 2 and it becomes 1.33, change it again to 6 and it becomes 1.333333 - so the precision is always retained just the display alters. Excel runs out of accuracy after 15 decimal places, after that it becomes 1,33333333333333300000…

Sure if the user was working in hh:mm:ss + milliseconds and then changed their time format to hh:mm:ss and then entered a value into start/end field in Labels editor then the precision for that change would be limited to seconds - but all the other pre-existing labels can surely retain their fill precision, just be displayed with less precision.

Peter.

I hope that it helps the OP. I failed to find a way to reproduce their issue, but this looks possible. We’ll just have to wait for the OP to fill in the gaps.


Times will display as rounded values when you look at them.
If you set a time value, it is set to the value that you set it to (which is a rounded value to whatever units you use when you set it).

A “nice to have” feature that we don’t have (a feature request) would be for the Label Editor to hold exact* time values when it opens.
(* I think Audacity uses 64-bit float internally for time values).
You would then be able to switch to different time formats with no loss of precision.

I’m thinking that it could be worthwhile to have this issue logged, because it’s likely to get much worse when Audacity gets “bars and beats” time.

Because of this: Audacity: NumericTextCtrl.cpp Source File
(Handling time format conversions in the NumericTextCtrl’s is complicated.)