If the lead-in is quiet enough and long enough (but not too long), and one sets “longer than” and “label placement” at .04 and .08 respectively (which usually results in the label being placed about halfway between tracks for me) is possible for SilenceFinder to create a label which exists somewhere in time before the beginning of the track.
Assuming that my zip file uploads correctly (it is a Audacity project with about 5 min. of audio – two songs), open it up and zoom in until about 1.8 seconds of the very beginning of the track is displayed in the whole window. At that point a small portion of the label’s text editing region is visible; carefully zooming in and out by very tiny increments can expose more or less of the editing region and it is quite clear that the actual label insertion point is somewhere just before zero.
Ah well that did not work I guess the zip file is too big. If someone wants a copy of the Audacity project let me know.
In a new project generate .047 seconds of silence, generate 30 seconds of noise, just make sure silence finder is working generate 3 seconds of silence at about 15 seconds into the audio. Make sure that there is no selection or that everything is selected and run Silence Finder version 1.1 with the audio threshold set at 27, “detect longer than” at .04 and “label placement” at .08.
After running the silence finder, two labels will appear; zoom in until about .01 seconds fill the entire project– you should see about half silence and half noise and you will note that the label is before zero and its text editing box is barely displayed.
I am not sure whether this is a bug report, a design feature or if I am asking for a enhancement which does not allow things to occur before “zero” time. Personally, I would like a test in the label generation code to ensure that a newly created label’s time is not less than zero. I think there may be other cases besides labels were extremely rare events might place the start time for something (a clip for instance) before zero.
It’s the same “feature” as described by Gale.
In the test described;
the end of the silence is detected at approximately t=0.047
the label is then placed 0.08 seconds before this, which is at approximately t= -0.033
I think an “enhancement” to prevent labels before zero would be a good idea. My proposal would be that any labels created before zero should be placed at zero.
The only down-side that I can see is that it would be possible in some obscure situations to produce multiple labels at t=0 (rather than multiple labels before t=0)
If this is agreeable with everyone then it’s an easy fix:
change line 87 to:
(add-label (max 0 (- (/ n s1-srate) labelbeforedur)) "S")
I’d also like to rename the variable “l” if that’s OK?
That does the trick, thanks! I’m just too old and set in my ways to learn (is it lisp?) the language these are written in. I wrote the same code in C++ so that I could call it while unattended but it was no faster so I did not use it in my working attended Audacity. I failed to allow for negative time as well so will need to revisit my code. Thanks again for the quick response!
I did notice some “ill effects” which was what led me to find the labels before zero but which I would not necessarily blame on those pre-zero labels. In the code which I wrote as an addendum to Audacity for selecting between labels and especially deleting between labels it was most hazardous. What led me to the discovery was Export Multiple failing to export the “first track” because I had set it to ignore audio before the first label – of course since the first song’s label was before zero it ignored it. Offhand, that’s the only potential trap that I can imagine but there may be others.
I don’t understand that - if you had starting silence that got labelled behind zero and you do not export a file for the audio before the first label, export multiple will give you a file for the audio following the first label which is presumably the audio you are interested in. In fact unlike Export, Export Multiple will actually include silence for that part of the label before zero.
However if you do export a file for the audio before that first (behind-zero) label, that sometimes seems to prevent the export of the remaining files. Not quite figured out what the scenario for that is yet, but the mistake of putting a label at zero then including audio before the first label doesn’t seem to prevent the export multiple.
Looking at the other built-in Analyze plug-ins, Regular Interval Labels can place a label before zero if you prefix “Time to place first label” with a minus (that could be done in error given “-” is next to “0” on keyboards). If we don’t allow labels before zero in Silence Finder probably we ought to make the same change in Sound Finder.
In Sound Finder it’s also possible to create a label in which the end of the label is before the start of the label (by putting a minus sign before the “Label Ending Time”). This then causes really weird stuff to happen on Export-Multiple.
A small change to the “add-label” function resolves both issues.
Change:
;Define a function to add new items to the list of labels
(defun add-label (l-starttime l-endtime l-text)
(setq l (cons (list l-starttime l-endtime l-text) l))
)
To:
;Define a function to add new items to the list of labels
(defun add-label (l-starttime l-endtime l-text)
(setq label (cons (list (max 0 l-starttime)(max 0 l-starttime l-endtime) l-text) label)))
The issue in “Regular Interval Labels” can be resolved by adding one line after line 33:
; convert start string to a number
(setf start (first (string-to-list start)))
(setq start (max 0 start)) ; disallow negative label time
I raised the issue a while ago that many of the Nyquist plug-ins available from Audacity could benefit from being updated. Hardly any of them contain any error checking and some contain actual errors. I realise that (as Vaughan pointed out) it is low priority, but I don’t think that should mean that they don’t get fixed. So could we get some sort of work-flow in place for updating Nyquist plug-ins?
If you would be so kind as to attach a v.1.3 others might appreciate it. For myself I do not mind hacking the code as per your instructions but a casual user might find it difficult to even figure out how to effectively edit a .NY file.
I think we have an effective work-flow in place, I complain, Gale chips in four cents worth (allowing for inflation and quality) and you fix the problem. What we might be missing is peer review of the code changes which you make (I have not seen any other poster who programs in this language). Another area which might need a little improvement is expanding our beta testing – right now I think it is you, Gale and myself – at least no one else seems to be posting.
I’m still at 1.1 for Sound Finder and adding that code gives “Nyquist does not return audio” for me, so I’d appreciate that too. Then I’ll try and make time to commit that and Silence Finder with their wording and greater accuracy changes (and Regular Interval Labels, the fix for which is fine). Thanks.
Sorry, I wanted to say quite a bit in reply to your post on -quality but not had time before now. I have replied now. As stated there I think fixing the old plug-ins is lower priority than making the latest ones available, and fixing the old should be targeted first on an assessment of which are still most useful.
I was a bit short on time, which is why I just posted the essential change.
The code is starting to look very “hacked”, which is not surprising as it is an adaptation of an adaptation of an adaptation of an original script by Alex S. Brown. Consequently rather than just hacking it some more I’ve largely rewritten it.
To avoid confusion I’ve started a new topic for “Sound Finder” Updated Sound Finder
Brilliant, thanks Bill.
Not sure why that should be, it works fine here. If you have any problems running Sound Finder 1.3, please post details in the new thread.
Thanks Gale - I’ll reply there when I get a few moments, but in brief I’m in agreement with the points that you raise.
Back to “Sound Finder” and “Silence Finder” - these are so closely related that I think as far as is practical we will want consistency between the two. So rather than making multiple modifications to both versions I propose that we focus on one (Sound Finder) and then bring the other (Silence Finder) in line with it.