Will 2.0.03 measure seconds to 6 decimal places?

In the past my students and I have used Audacity to experiment with speed of sound studies. After updating to the lastest version of Audacity we noticed that the program will only measure recording times out to 3 decimal places as the older version we used would mearsure to 6 deciamal places. My question is, has the new version reduced the accuracy offered or are we just missing how to configure the software to measure with that accuracy?

Believe it or not the 4th decimal place does make a big difference in getting accurate results.

version 2.0.3
win XP

Thanks for any help

This came up once before on the forum.
Audacity is now more accurate than the old 1.2.x version, but the greatest precision in the Selection Toolbar is in “samples” rather than fractions of a second. The other teacher thought it was a bit too complicated to require that the students divide the number of samples by 44100, so the best solution that we came up with is to set the project sample rate to 100,000 and display the time in hh:mm:ss+samples.
To change the project sample rate to 100,000, type 100000 in the Project Rate box (bottom left corner of the main Audacity window).

We can add your vote to reinstate microseconds. I’m not clear why this was omitted except for space reasons. It is “probably” a fairly simple code change if you wish to recompile Audacity yourself.



Gale

The other teacher thought it was a bit too complicated to require that the students divide the number of samples by 44100…

:smiley: :smiley: That must be one of our public school teachers here in California! You don’t need to understand the details of the math or science as long as you feel good about yourself! :smiley: :smiley:

Thanks for the help. I am sorry I missed the discussion in my search and FAQ. I must have not understood what I was reading.

I probably would vote for the milliseconds measurement to return as it was convenient, but my students will do what they are told and dividing samples by Hz should be simple enough for them. If not “I give up!” 8 more years and my job will be going fishing. :smiley:

It is only a few lines of new code if you are willing to add it to the bottom of the list but re-ordering the list so that the new choice “fits in” to its proper place adds a tiny bit more change.

Foxman - I would be happy to supply the code change (patch) so that you may compile it in or provide you with a patched executable (or both).

Personally I only need 2 or 3 decimal places but more is trivial (well - I don’t know what to call it ):

What have you added - hh:mm:ss + microseconds? I think that’s what most want (what 1.2.6 had).

I’m interested in the patch that inserts the new item in an appropriate place.


Gale

Here is the current situation:
sel203.png
You will see that I have added a couple of additional “seconds + …” entries and reordered the list so that they fall in the “appropriate” place. The actual number of decimal places displayed is simply a matter of adding zeros to the format string to match the number of decimal places you desire.

A patch for a “user” would be a little bit different from a patch for a “Developer” . The current code makes it more difficult than necessary to insert new entries in the list because all of the ordinal list positions are hardcoded with an integer value (1, 2, 3 etc.). This means that if you insert a new item in the list every item thereafter must have that hardcoded integer position changed. This makes a lot of sense when the list is very short, rarely likely to change, or the code is running on a PDP 11 or slower CPU (i.e. 25 or more years old). Given the current length of this list, the likelihood of acceding to the users’ desire to add more items and the possibility that this list could be tailored to suit an individual user’s needs (via a GUI editor – quite easy to do ) it makes sense to change this code so that it looks vaguely like:
int listPosition = 0;
place item at list position listPosition;
listPosition = listPosition + 1;
… Do it again as many times as necessary…
Or even:
int listPosition = 0;
if (user wants to see the item on the list) then
_____place item at list position listPosition;
_____listPosition = listPosition + 1;
endif
… Do it again as many times as necessary…

For proof of concept (because the Development Team would need to decide whether they wanted it done “right” or “quick and dirty”) I would propose giving you a simple two-line patch which tacks the new item on the bottom. Then if there was any Developer support for adding the item the Developers could choose which way they wanted it done.

Therein lies the rub! My guess is that anyone interested in examining the seconds out to six decimal points will not be looking at audio that is many hours long. My personal choice would probably be mmmm:ss + micro (i.e. 4 places for the number of whole seconds). Note that by choosing hh:mm:ss we limit the ability to display more than 99 hours + 59 minutes + 59 seconds – probably a most reasonable limit.

Index: src/widgets/TimeTextCtrl.cpp
===================================================================
--- src/widgets/TimeTextCtrl.cpp	(revision 12198)
+++ src/widgets/TimeTextCtrl.cpp	(working copy)
@@ -400,6 +400,10 @@
    /* i18n-hint: Format string for displaying time in frames with CD Audio
     * frames. Translate 'frames' and leave the rest alone */
    BuiltinFormatStrings[15].formatStr = _("01000,01000 frames|75");
+   /* i18n-hint: Name of time display format that shows time in seconds and microseconds */
+   BuiltinFormatStrings[16].name = _("seconds + microseconds");
+   /* i18n-hint: Format string for displaying time in seconds and microseconds. */
+   BuiltinFormatStrings[16].formatStr = _("010000.01000000 s");
 
    mDigitBoxW = 10;
    mDigitBoxH = 16;
Index: src/widgets/TimeTextCtrl.h
===================================================================
--- src/widgets/TimeTextCtrl.h	(revision 12198)
+++ src/widgets/TimeTextCtrl.h	(working copy)
@@ -134,7 +134,7 @@
     *  needed to create that format output. This is used for the pop-up
     *  list of formats to choose from in the control. Note that the size will
     *  need adjusting if new time formats are added */
-   BuiltinFormatString BuiltinFormatStrings[16];
+   BuiltinFormatString BuiltinFormatStrings[17];
    double         mTimeValue;
 
    wxString       mFormatString;

microTTC1.zip (646 Bytes)
sel12198.png

Now that the index isn’t hardocded I tried adding ss + microseconds and hh:mm:ss + microseconds but it certainly does not work as well as it did in 1.2.6.

In an empty 44100 Hz project window we see that TimeText controls start at 1 microsecond instead of 0 (as per your image above), and start at 3 microseconds at 1000000 Hz.

Generate doesn’t let you generate exactly 1.000000 seconds when the selection format is in microseconds.

Is this expected?


Gale

Gale, this thread is a year old and the underlying code has changed drastically in the last couple weeks. Are you trying to patch SVN HEAD or are you seeing strange results with SVN HEAD and no patch? There’s a much more current thread ( https://forum.audacityteam.org/t/add-a-new-time-display-format-seconds-milliseconds/36269/1 ) which discusses adding a new format; on that thread suizokukan offers to submit a patch - is that the code you’re discussing?

HEAD doesn’t include microseconds. Yes I tested Suizokukan’s patch to add seconds and milliseconds (which is fine) and also added seconds and microseconds and hours, minutes, seconds and microseconds (attached).

Gale
NumericTextCtrl_secs_and_ms_and_2_microseconds_formats.patch (2.47 KB)

Thanks Gale

It occurred to me that there is another format that is actually missing: Percentage
This is especially useful for “Player” mode.
It is arguable though if it should apply to the track’s length or the project length.

Yet another thing, why has the Audio position to show a value of 0 in stop mode? In this case, it should take the value of the left boundary of the selection in my humble opinion.
In my accessibility extension, it always reports the maximum of those two values. Thus, one hotkey less to belay.

There’s an infinite number of formats “missing”.
Julian days : hh : mm
tP x 10^nn
ss + nanoseconds
moments
beats at 120 bpm
4/4 bars + 120 bpm
3/4 bars + 120 bpm
5/4 bars + 120 bpm
6/6 bars + 120 bpm
4/4 bars + 121 bpm
3/4 bars + 121 bpm

I don’t believe that adding this one or that one in an ad hoc manner is the correct approach because there will always be some situation that requires units that are not available. Imo what we need is a general solution that allows the user to define “ticks” and “tick multipliers”.

Percentage can’t be defined like that.
The actual problem is that the entire project length or the total length of a track are nowhere available on the screen (e.g. in the status bar).
Of course, I can simply take the selection length and calculate the percentage according to that. This makes at least sense for a (screen reader) real time report of the audio position per hotkey.
However, the decoding is only simple when the format is whole seconds or samples.

You did not answer the second question, any opinion on that?

Well one could say it is a lottery what requested formats get added. Are the “ticks” the ticks on the Timeline and is the “tick multiplier” a sliding scale of some sort?

Isn’t the left edge of the selection displayed by Selection Start?


Gale

Sure it is, I don’t say that any of these controls should be removed.
However, the 000000 values are absolutely meaningless.
Audio Position should somewhat represent the cursor position, shouldn’t it?
This would mean that it takes the same value as the left edge of the selection.
There’s one exception to this rule: the left selection edge can start before zero, whereas the audio position can not.

By the way, the display for negative time values is broken in the 2.0.7 alpha builts (not related to the patch). The screen reader reports only dashes.
This worked before, at least with NVDA.

I’m unsure what you are observing. As far as I can see it appears to be working correctly. Could you give steps to reproduce the issue (I have NVDA installed on a virtual machine with Windows XP)

I think NVDA is reading what is displayed correctly.

On Windows 7 If I have exactly one second of audio behind zero, 2.0.0 shows for Selection Start:

00h 00m -1.-00s

2.0.6 shows

00h 00m -1.000s

2.1.0-alpha shows all dashes

--h --m --.---s

Gale