Dear Audacity Team,
I would like to request this specific feature (possibility of having the logarithmic time scale – at least on spectrograms) as in my [on-going] research it looks like the recorded by our team biological noise, when unrestricted and spread over 24 hours of circadian rhythm is distributed log-normally.
Such a feature, if implemented, would greatly boost the use of Audacity in scientific research.
With kind regards,
Humble Researcher
Are you referring to the Spectrogram Track View: Spectrogram View - Audacity Manual
Logarithmic time scale means, for example, that time ranges 0-100, 100-300, 300-700, 700-1500 are equal width in the screen, right?
Any Nyquist script which resamples the signal by logarithmically increasing speed?
– exactly.
Yes, e.g. with the decimal base it looks like: 0-1, 1-10, 10-100, etc. would have equal width, which, likely, needs the implementation of a “logarithmic” tickbox in the UI
Any Nyquist script which resamples the signal by logarithmically increasing speed?
…will miss the corresponding time marks (but it’s a good idea at least to get some visuals).
No doubt that it “could” be done - Audacity is just a computer program that manipulates data - but I see very little practical benefit for Audacity as an “audio editor” (which is Audacity’s raison d’être).
If you need this type of functionality in the foreseeable future, then you may do better to look at image stretching algorithms (perhaps with MatLab).
M-m… then, following this logic, the existing Spectrogram Track View would be falling in the same category of ‘little practical benefit’, however not. I consider the logarithmic time scale as the extension of functionality for those looking at spectrograms (whose visual appeal makes analysis easier). In turn, this leads to quicker decisions for editing different portions of an audio track, when such is a need. Wasn’t this already the much appreciated benefit of having logarithmic decibels? I’ve already looked at the things like Sonic Visualizer, which doesn’t have this feature (and MatLab actually does have the log time scale in its spectrograms, no need for images, but lacks flexibility, convenience and integration offered by Audacity). So, theoretically, placing somewhere a conditional log() in the code may produce this functionality.
Not at all. Spectrogram view has many uses in audio editing. Probably the most common use being in detecting clicks that need to be repaired.
It’s a lot more complicated than that.
The code for the “Time line” ruler (above the tracks) would need to be rewritten, including rewriting the Quick Play and scrubbing features.
Track spectrogram view uses bitmap caching for efficiency, which would require significant restructuring.
It would also affect how the cursor moves across the screen during playback and recording, so some significant changes to the transport system.
I would have thought that for scientific research you would want something that is quantifiable - data rather than a pretty picture. Why not extract the raw numerical data from FFT analysis, then you could scale that in any way you want?
I totally agree on your last three raised points about restructuring needed. Perhaps, my “placing log() somewhere” was overstretched simplification.
What I was looking for was “ordinal simplification”, yes, still less than full-scaled “over-complication” by extracting the raw numerical data from FFT analysis (no doubt more scientific than a pretty picture, but still a lot of work).
If that could not be implemented in less than a practical amount of time and Audacity developers’ other resources, as well as being not completely the way Audacity is being written, this thread may be considered closed. It is a feature request after all. I’m thankful for all your thoughts and suggestions what were expressed here though.
Extracting raw numerical data from FFT is not particularly difficult - certainly a lot easier than implement a logarithmic time scale for tracks.
Audacity has a built-in scripting language called “Nyquist”, which is an extension of XLISP (a dialect of LISP). Nyquist includes FFT and inverse FFT functions. FFT is one of the more difficult aspects of Nyquist, but there is tutorial here: http://www.audacity-forum.de/download/edgar/nyquist/nyquist-doc/examples/rbd/03-fft-tutorial.htm