On 2021-10-06 07:50, Lee Jones wrote:
> It's almost certainly my fault, but I'm perplexed as to how to fix it.
I'm just guessing, but ...
>> # Trimming all silence to 2 seconds
>> ljkenny:~$ sox -V manchester_app_test.wav
>> manchester_app_test-trimmed.wav silence -l 1 0.1 1% -1 2.0 1%
That effect: silence -l 1 0.1 1% -1 2.0 1%
has parameters -l then 1 0.1 1% then others. According to the
manual:
1 0.1 1%
^ 1 means trim audio from the start of the file
until
it first finds non-silence
^^^ 0.1 means the length of time that non-silence must
be
detected for
^^ 1% means the level sound must have to be treated
as
non-silence
You possibly thought that the "0.1" meant 0.1 seconds. It doesn't. It
means 0.1 samples which seems to me to be meaningless and might cause
sox to think that non-silence is never detected. In that situation I'd
suspect that sox would then "trim" away ALL the contents.
Thanks for your reply Jeremy.
In the opening paragraphs, it seems to suggest that if you use a decimal value then SoX treats the value as seconds instead of samples.
Which seems to be backed-up by the man page:
[[hours:]minutes:]seconds[.frac][t]
A specification of `1:30.5' corresponds to one minute, thirty and ½ seconds. The t suffix is entirely op‐
tional (however, see the silence effect for an exception). Note that the component values do not have to be
normalized; e.g., `1:23:45', `83:45', `79:0285', `1:0:1425', `1::1425' and `5025' all are legal and equiva‐
lent to each other.
sampless
Specifies the number of samples directly, as in `8000s'. For large sample counts, e notation is supported:
`1.7e6s' is the same as `1700000s'.
Ah, but there is a cavat later in the same man page:
I tried these commands, both resulted in the same outcome (full header, no data):