Bug 459 – Selection Toolbar: previous whole second value displayed if Start/End or Length is close to a whole second

••• Introduction •••
••• Keywords •••

Audacity 3.0.3 development began 19th April 2021

Audacity Bugzilla

Bug 459 - Selection Toolbar: previous whole second value displayed if Start/End or Length is close to a whole second


Summary:	Selection Toolbar: previous whole second value displayed if Start/End or Leng...

Status:	RESOLVED FIXED

Product:	Audacity
Classification:	Unclassified
Component:	User Interface
Version:	1.3.15
Hardware:	PC Other

Importance:	P3 Repeatable
Assigned To:	Default Assignee for New Bugs

URL:
Keywords:	Cherry

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2011-12-14 18:34 UTC by Gale Andrews
Modified:	2018-08-20 11:45 UTC (History)
CC List:	5 users (show)

See Also:
Steps To Reproduce:	1 New Project, set Selection Format to hh:mm:ss + milliseconds 2 Generate 30s tone 3 Click just after 5s, as close to 5s as you can 4 Zoom in six times and use left arrow to nudge the cursor back towards 5.000s. Observe that every other left arrow press moves the ms digits back by one digit in "Selection Start" in Selection Toolbar 5 Press slowly when you reach 5.001s, so that the second press still shows 5.001s. Left arrow again to see 5.000s, 4.000s, then 4.999, 4.999 and so on. 6 Move the cursor back to right of 5.000s then zoom out one step and repeat step 5. 4.000s may or may not occur, as it seems one arrow press may move the counter by 1 ms or 2 ms (rounding?). Also 1 New project, 44100 Hz, Selection Toolbar set to hh:mm:ss + samples 2 Generate > Tone of 59 seconds + 44099 samples 3 Length displays as 59.000 seconds
Release Note:	GROUP:Toolbars '''When using Selection Toolbar in a selection format in less than whole seconds, an inaccurate value for length or cursor position may display when zoomed in.''' The displayed value will be the nearest whole second below the true value (for example, 59.000 seconds where the true value is 59.999 seconds). This can occur when clicking on or moving the cursor across a boundary for whole seconds, in which case you can use right arrow to show the correct value. It can also occur when generating a few samples less than a whole second or when expanding or contracting a selection.
First Git SHA:
Group:	---
Workaround:
Closed:	2018-08-20 00:00:00

Flags:	gale: Regression+

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Gale Andrews 2011-12-14 18:34:53 UTC

Only tested on Windows 7 with HEAD (wx 2.8.12). Could be Widgets bug. Regression on 1.3.13 (2.8.11). If not a Widgets bug it is possible that the fix for bug 286 is relevant. 

Reproduces in forwards direction with hh:mm:ss + milliseconds
and hh:mm:ss + hundredths (4.999 increments to 4.000). 

Also reproduces by zooming in three times after generate and 
click at 5s with format set to hh:mm:ss + hundredths.

Can't reproduce it with hh:mm:ss + samples. 

Does not reproduce if incrementing digits with up or down arrow in Selection Toolbar.  

It's possible to click in the waveform at 5s and see 4s in Selection Toolbar. Confusing, but if you move cursor a further press, correct value shows. Starting at P3 (without release note yet) and await comments.

Comment 1 Gale Andrews 2011-12-16 11:56:47 UTC

(In reply to comment #0)
> Could be Widgets bug. Regression on 1.3.13 (2.8.11).
Seems not. The Ubuntu PPA "nightly" which uses 2.8.11 has the same issue.

Comment 2 Steve Daulton 2011-12-21 21:32:33 UTC

(In reply to comment #0)

Another way to observe the effect:
1) Select exactly 1 minute of an audio track.
2) Set the time units to hh:mm:ss + milliseconds
3) Zoom in close on the end of the track
4) Slowly reduce the length of the selection by dragging the right hand edge to the left.

The time rolls over from 00h 01m 00.000 to 00h 00m 59.000

Similar problem with hh:mm:ss + hundredths and hh:mm:ss + frames (any sort of frames)

Comment 3 Gale Andrews 2011-12-22 14:57:57 UTC

Another reword. 

> Similar problem with hh:mm:ss + frames (any sort of frames)
I can't repro the problem with frames. Does it go to 00s + 00 frames when you increment back from the 1s position? Or 01s + 29 frames?

Comment 4 Steve Daulton 2011-12-23 09:18:35 UTC

(In reply to comment #3)
Example using film frames (24 fps)

Moving the selection back from 1 second produces:
01s + 00
00s + 00
00s + 23
00s + 22

Comment 5 James Crook 2012-03-25 14:10:59 UTC

Caused by rounding up of 4.9995 not being propagated to the 4, so it showed as 4.000.  Fixed.

I'm not actually convinced that rounding should be being done at all.  Truncation seems better, but other code (for increment decrement time text control) seems to rely on rounding, so I have preserved it and corrected it to propagate.

Comment 6 Gale Andrews 2012-06-20 21:45:40 UTC

RESOLVED - FIXED .

(In reply to comment #5)
> I'm not actually convinced that rounding should be being done at all. 
> Truncation seems better
Do you mean e.g. 0s 44099 samples at 44100 Hz should never display in Selection Toolbar as 1 second when you change to a coarser selection format? That would seem more intuitive to me.