From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jan Stary Newsgroups: gmane.comp.audio.sox,gmane.comp.audio.sox.devel Subject: silence problems Date: Tue, 18 Mar 2014 12:09:21 +0100 Message-ID: <20140318110920.GA16536@www.stare.cz> Reply-To: sox-users@lists.sourceforge.net NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1395140980 7837 80.91.229.3 (18 Mar 2014 11:09:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Mar 2014 11:09:40 +0000 (UTC) To: sox-users@lists.sourceforge.net, sox-devel@lists.sourceforge.net Original-X-From: sox-users-bounces@lists.sourceforge.net Tue Mar 18 12:09:48 2014 Return-path: Envelope-to: gcas-sox-users@gmane.org X-ACL-Warn: Mail-Followup-To: sox-users@lists.sourceforge.net, sox-devel@lists.sourceforge.net Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1WPrtm-0001fu-8t X-BeenThere: sox-users@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sox-users-bounces@lists.sourceforge.net Xref: news.gmane.org gmane.comp.audio.sox:5500 gmane.comp.audio.sox.devel:358 Archived-At: Received: from lists.sourceforge.net ([216.34.181.88]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WPrtz-0006VG-AA for gcas-sox-users@gmane.org; Tue, 18 Mar 2014 12:09:47 +0100 Received: from localhost ([127.0.0.1] helo=sfs-ml-1.v29.ch3.sourceforge.com) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WPrts-0000oH-Ku; Tue, 18 Mar 2014 11:09:40 +0000 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WPrtq-0000o8-W5; Tue, 18 Mar 2014 11:09:39 +0000 Received: from mx.toposym.cz ([79.98.77.229] helo=www.stare.cz) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WPrtm-0001fu-8t; Tue, 18 Mar 2014 11:09:38 +0000 Received: from www.stare.cz (localhost [127.0.0.1]); by www.stare.cz (OpenSMTPD) with ESMTP id 9c5efd5d; Tue, 18 Mar 2014 12:09:22 +0100 (CET) There seem to be problems with the silence effect. I believe it has been brought up some time ago, but here is a (longer) complete story with examples. This is the test file I will be testing on, using 14.4.1: sox -D -n -c 1 file.wav synth 3 trap 440 sin 480 gain -6 pad 1@0 1@1 1@2 1@3 That makes it three seconds of a dial tone, interpadded with four seconds of silence: "silence TONE silence TONE silence TONE silence", seven seconds in total. First, basic silence trimming at the beginning of the file: When above-periods is non-zero, you must also specify a duration and threshold. Duration indications the amount of time that non- silence must be detected before it stops trimming audio. I think it would be an improvement if the manpage said explicitly that the non-silence that is detected (and stops the trimming) remains itself in the output stream; as opposed to only starting the output with samples that come _after_ that non-silence. At least that's how I understand what the manpage says, and it is what any of the following commands does, resulting in six seconds starting with the first tone. sox file.wav out.wav silence 1 0.1 10% sox file.wav out.wav silence 1 0.5 10% sox file.wav out.wav silence 1 1.0 10% There seems to be some rounding (buffers?) involved, e.g. sox file.wav out.wav silence 1 1.01 10% produces the same, although there is no occurence of a non-silence of length 1.01 in the source file. On the other hand, sox file.wav out.wav silence 1 1.02 10% already does the expected thing, i.e. results in an empty file. However, SoX does not fill in the zero length in the header: Input File : 'out.wav' Channels : 1 Sample Rate : 48000 Precision : 32-bit Sample Encoding: 32-bit Signed Integer PCM Now, trimming up to the _second_ non-silence already presents a problem for me: sox file.wav out.wav silence 2 0.1 10% I would expect this to trim the leading "silence TONE silence" and result in an output file starting with the second TONE (as the second above-period). That's the intended behaviour, right? For example, if you had an audio file with two songs that each contained 2 seconds of silence before the song, you could specify an above-period of 2 to strip out both silence periods and the first song. That's my situation. But no, the result is a 00:00:05.90 file where the first silence and the first 0.1 second of the first tone are removed. If this is the intended behaviour, the two-songs example is wrong. It seems that instead of the first TONE counting as the first above-period (to be trimmed) and the second TONE counting as the second above-period (to start the output), only the first 0.1 seconds if the first TONE count as the first above-period (trimmed), and after that the output begins. That's what the above command seems to do. But is that intended? With the above two-songs example from the manpage, specifying "silence 2 3 2%" would just trim the first silence and the first 3 seconds of the first song, as in my example, right? Let's try: sox -D -n -c 1 songs.wav synth 60 trap 440 sin 480 gain -6 pad 2@0 2@30 That's 00:02 of silence, 00:30 of song, 00:02 of silence, 00:30 of song, as in the manpage example. Now running sox songs.wav out.wav silence 1 3 10% does the expected thing: trims the first 00:02 of silence away, and leaves the rest as 00:30 + 00:02 + 00:30 of output. Now running "sox songs.wav out.wav silence 2 3 10%" should trim the first silence, the first song, and the second silence - right? That's what the example says, but that's not the case: the result is the same as before, i.e. only the first 00:02 of silence is removed. That seems wrong, and is also inconsistent with the previous example: if it was to do the same, the first 00:03 above-period (i.e. the first 00:03 of the first song) would be removed and the rest would go in the output, right? Whichever the expected behaviour is, there seems to be a bug. Or am I missing something in what the manage says? There are other problems with the silence effect (trimming from the end), but let's resolve this first. Thank you for you time Jan ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech