2.1.3: Label times don't agree with rest of GUI

SUMMARY

The start and stop times for labels in the label editing dialog are inaccurate for times some minutes into a project, and appear to become increasingly inaccurate for larger time values.

VERSION TESTED

Audacity version: 2.1.3, installed from DMG (Dragged application from DMG into “Applications” and ran from “Applications”).
OS: Mac OS X 10.10.5


TO REPRODUCE

  1. Create a new project.
  2. Set the project sampling rate to 96000 Hz. (96kHz)
  3. Change the Selection Start: display format to “samples”.
  4. Generate a 10 minute long silence track. (Generate->Silence…, Duration: 00h10m00.000s)
  5. Place the selection cursor roughly at 8 minutes into the project.
  6. Note the sample number of the selection point in the “Selection Start:” field of the project window. In my example the value is “046,158,904 samples”.
  7. Create a new label at the selection position. (Tracks->Add Label at Selection).
  8. Set the label name to the sample position so that you can clearly compare it later. (“46,158,904” in my example).
  9. Bring up the label editor. (Tracks->Edit labels…)
  10. Observe the Start Time for the label you created. Notice that the start time (which should be shown in “samples”) does not match the actual selection start of the label.

EXPECTED BEHAVIOR, ACTUAL BEHAVIOR

In my example the value “046,158,912” is shown; the correct value should be “046,158,904”).

ADDITIONAL OBSERVATIONS

The bug here appears to be solely related to the display of label points. If I export the labels for the project and examine them in the exported text file, the timing values, which are exported in fractional seconds, appear to be correct. For example, the label I created above gets exported as:

480.821918      480.821918      46,158,904

The value “480.821918” seconds, when converted to samples at 96kHz, is 46158904.128, which matches the value shown in the “Selection Start:” field of the project window whenever the selection cursor is placed or snapped to the label position in the label track. Perhaps there is an issue in the NumericEditor class or its interaction with the LabelDialog class.

Thanks for the detailed bug report. I can confirm that the bug also occurs with a 44,100 Hz sample rate.

I’ll pass this on to the developers.

– Bill

Thanks for the detailed report. I strongly suspect that it is a rounding issue - the labels times in the editor being represented with insufficient decimal places to achieve exact sample numbers. The actual labels are saved as seconds with 10 decimal places, which is sub-sample accurate even at the highest sample rates. With a bit of luck we may just have enough time to fix this before the next release.

I also suspected a rounding error, but I was puzzled why the “Selection Start:” widget at the bottom of the project window has no problem showing the correct value, yet the cell for the start time in the editor dialog shows something different. From my perusal of the code, it seems that they should both be using the same code (NumericTxtCtl?). I couldn’t see why one instance would work fine while another would have problems.

Nonetheless, it does seem that the code converts label times from “double” to wxString via a “%g” format, and then back to double, where it is then displayed according to the project timing format. I can see how this roundabout conversion could cause problems.

Thanks!

Yes, that’s it.
I’ve also noticed that in the current development code, there must be an audio selection in order to open the label editor. That looks like an unnecessary restriction, and my guess is that it was not intended.

and someone else also noticed and has fixed that.

Unfortunately it looks to be a bit more complicated than I first thought. In addition to the “%g” representation, there is rounding to hundredths of a second occurring somewhere else.
I think that the basic problem is that once the label times have been initially read by the editor, the editor then uses its control values rather than repopulating from the actual LabelStruct regions (which are ‘double’ seconds).

This bug is logged here: The Label Editor may display incorrect (inaccurate) label times · Issue #1904 · audacity/audacity · GitHub