how to use Truncate Silence
Posted: Wed Oct 14, 2009 6:46 am
what's the meaningof "Min silence duration","Max silence duration","silence compression"?
For questions, answers and opinions
https://forum.audacityteam.org/
Good question. I believe this version of Truncate Silence is new in 1.3.8 and has not yet been documented. Also there were some diffuculties with it in 1.3.8 that were supposedly corrected, see here.kfzhs wrote:what's the meaningof "Min silence duration","Max silence duration","silence compression"?
John, those aren't the default parameters. Tone duration and silence duration depend on the sequence and the duration chosen. On a fresh cfg, the sequence is "audacity" and duration is 1 second which gives a tone duration of 72ms and silence duration of 59 ms. You would have to tell me what sequence and duration you are using for me to test those parameters, but using default truncate silence parameters on an "audacity" DTMF sequence of 30 seconds length (which gives a tone duration of 2185 ms and silence duration of 1788 ms), the truncated silences were of equaljademan wrote:(sent to feedback:@)
On Windows, XP HE SP3, I used Audacity 1.3.9 to Generate DTMF tones with
the following default settings:
55% duty ratio
3278 ms tone duration
2682 ms silence duration
amplitude .8
I then ran Truncate Silence with the default settings of 200, 1000, 4,
-40. After I did this, I measured the resulting silences between the
tones. The first three silences were: 404 ms, 659 ms, 820 ms
respectively. One might expect them all to be the same.
I can report identical results (within 2 or 3 ms) on Mac with 1.3.10-alpha-Oct 19 2009.jademan wrote: OK, here is what I did:
...
First 4 interval durations
404 ms
659 ms
820 ms
820 ms
WCC,WCC wrote:Does anybody have information on the cause of these short periods of silence in a recorded track. The sound monitored on the speakers while recording does not contain this annoying silence periods. I'm using Audacity 1.3.9 with Windows XP.
John, it's a known P3 bug that truncate silence doesn't keep labels in synchronisation. It seems the fact that adding a label track causing unequal truncation was some kind of aberration. Almost always, I can replicate unequal truncation with a 30 seconds "audacity" DTMF followed by default truncation. One other time too, it produced equal silences of 596 ms. Every other time it produced silences of 596ms but the third one much shorter at 408ms.jademan wrote:Gale,I repeated the above tests with label tracks. I placed 8 labels in seemingly random locations, but I put individual labels on tones and on silent spots. After applying Truncate Silence, I seemed to have the identical discrepancies to the waveform as in the above test. When the label track was not linked, the label track was not changed. When the label track was linked, the label track was truncated. The labels did not move with the waveform, as I might have expected. Note that I did not record or verify the label locations with great accuracy.
Gale, when I originally reviewed your reply, I was confused, because although you covered the material, it wasn't apparent that you were responding directly to the complaint, or to Bill's verification that the identical problem occurs on a MAC:Gale Andrews wrote:John, it's a known P3 bug that truncate silence doesn't keep labels...jademan wrote:Gale,I repeated the above tests...
jademan wrote:...
OK, here is what I did:
1) In audacity.cfg, deleted all lines except:
NewPrefsInitialized=1
2) Started Audacity 1.3.9
3) Language=English
4) Welcome: OK
5) Generate > DTMF Tones
6) Duration: 45 seconds
7) OK
8) Effect > Truncate Silence > OK
9) Here the periods of silence between the tones are visibly different, increasing slowly in size.
10) Up to this point, no labels are involved.
11) First 4 interval durations (I created labels to measure them):
404 ms
659 ms
820 ms
820 ms
Total number of intervals: 7.
Length of last interval: 820ms
Total clip length: 31.39 seconds.
7 intervals...
The problems that we have measured do not seem to be related at all to label tracks. When, at your request, I have used labels in conjunction with truncate, what I have noticed is the labels are not moved at all. Instead, some are simply deleted.billw58 wrote:I can report identical results (within 2 or 3 ms) on Mac with 1.3.10-alpha-Oct 19 2009.jademan wrote:...
404 ms
659 ms
820 ms
820 ms
-- Bill
Without using labels, I am also able to reproduce this problem. The 1.788ms silence is reduced to 596ms, but on the third it is 408ms.Gale Andrews wrote:...Almost always, I can replicate unequal truncation with a 30 seconds "audacity" DTMF followed by default truncation. One other time too, it produced equal silences of 596 ms. Every other time it produced silences of 596ms but the third one much shorter at 408ms.
When I tried sandwiching a 10s silence between two 10s tones, I got in your first case:Gale Andrews wrote:...
Imagine 10 seconds of silence in a 30 seconds track:
Settings of min 100, max 5000 give you:
compression 1: 5s
compression 2: 5s
compression 4: 2.5s
compression 10: 1s
Settings of min 2000, max 5000 give you:
compression 1: 6.888s
compression 2: 6.888s
compression 4: 5.416s
compression 10: 4.499s
Settings of min 2001, max 2001 give you:
compression 1: 3.889 seconds
Settings of min 1, max 2001 and min 1000, max 2001 both give you:
compression 1: 2.000 s
compression 4: 529 ms (why not 500)? ...
Thank you for this tip. This has proven to be helpful to me.Gale Andrews wrote:...
I've measured resultant silences by Edit > Detach at Silences and snapping the selection to the whitespace between clips.
Yes. This helps. So inputs that are shorter in length than min are ignored (left alone). And inputs that are longer than min are compressed but only by the extent that they exceed the minimum (ignore) length. And the output is not to exceed the maximum specified.Gale Andrews wrote:...
I'm not a mathematician, so I've asked Phil (the author) if he can drop by and comment on the above findings, in particular the 529/500 ms discrepancy in the last example above, and whether the unequal truncation is expected in the scenarios quoted. If it helps, Phil quotes the maths as follows:
(output) = ((min) + (input - min)/compression) with the constraint that output < max