Audacity Forum

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...

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!

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.

Gale Andrews wrote:It is "probably" a fairly simple code change if you wish to recompile Audacity yourself.

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 <grin>):

Edgar wrote:

Gale Andrews wrote:It is "probably" a fairly simple code change if you wish to recompile Audacity yourself.

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.

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

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

Here is the current situation: 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.

Gale Andrews wrote: I'm interested in the patch that inserts the new item in an appropriate place.

A patch for a "user" would be a little bit different from a patch for a "Developer" <grin>. 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 <grin>) 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.

Gale Andrews wrote: hh:mm:ss + microseconds? I think that's what most want (what 1.2.6 had).

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.