From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: ** X-Spam-ASN: X-Spam-Status: No, score=2.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,NO_RECEIVED,NO_RELAYS,T_DKIM_INVALID shortcircuit=no autolearn=no autolearn_force=no version=3.4.0 Path: news.gmane.org!.POSTED!not-for-mail From: Jan Stary Newsgroups: gmane.comp.audio.sox.devel Subject: Re: [SoX-users] how to interpret tell_off, and the right way to use sox_seek Date: Tue, 7 Nov 2017 09:50:36 +0100 Message-ID: <20171107085036.GA34760__16427.189744036$1510049149$gmane$org@www.stare.cz> References: <20171106111001.GA80730@www.stare.cz> <20171106190645.GA61378@www.stare.cz> <20171106210932.GA41280@www.stare.cz> Reply-To: sox-devel@lists.sourceforge.net NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1510049150 17026 195.159.176.226 (7 Nov 2017 10:05:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 7 Nov 2017 10:05:50 +0000 (UTC) User-Agent: Mutt/1.7.1 (2016-10-04) To: sox-users@lists.sourceforge.net Original-X-From: sox-devel-bounces@lists.sourceforge.net Tue Nov 07 11:05:40 2017 Return-path: Envelope-to: gcasd-sox-devel@m.gmane.org Original-Received: from lists.sourceforge.net ([216.34.181.88]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eC0lG-0003yL-O0 for gcasd-sox-devel@m.gmane.org; Tue, 07 Nov 2017 11:05:38 +0100 Original-Received: from localhost ([127.0.0.1] helo=sfs-ml-2.v29.ch3.sourceforge.com) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.89) (envelope-from ) id 1eC0lM-0004oP-Ca; Tue, 07 Nov 2017 10:05:44 +0000 Original-Received: from sfi-mx-2.v28.ch3.sourceforge.com ([172.29.28.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eC0lL-0004oI-JO for sox-devel@lists.sourceforge.net; Tue, 07 Nov 2017 10:05:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:To:From:Date:Resent-To:Resent-Message-ID:Resent-Date: Resent-From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Sender:Resent-Cc:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=y9vvWbzgm7BZQat6oD4iGd2Wp8khBwEoo/cCfOQ7O3s=; b=jTYn/RO1ytvSWq7GhYzSPYB7NE gf72scqhBPDhDRm8H+6/n8y3bWLyWHqwLt+7XBfrd1eC+w8g/2PDDOEaPorKn/HQm+qkMIHieWLW+ FXAdjpsLHjYoJ/7RyXgOGegk92E1lbEcZPlwTQdExGokb2u+J8MXzL56qbwf42M1iO7s=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To: From:Date:Resent-To:Resent-Message-ID:Resent-Date:Resent-From:Sender:Reply-To :Cc:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Sender: Resent-Cc:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=y9vvWbzgm7BZQat6oD4iGd2Wp8khBwEoo/cCfOQ7O3s=; b=i jEwi9TT2iSw5H652RVoutOOpZKhb6Yxk1TzdqWbcRP3MGTCZTejzBEs5wPmZtdT02GLY9ZLTXZFvj FlglT7AB6aduYt0eVLjfkidGon2n88SM5URgr2DgdQY72ZSVYlsvH0NqSIzbKTfAuF3rsthlaBwcU 9ZUnoWsFdT9aRDJY=; Original-Received: from mx.stare.cz ([79.98.77.229]) by sfi-mx-2.v28.ch3.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) id 1eC0lJ-0000X2-Ti for sox-devel@lists.sourceforge.net; Tue, 07 Nov 2017 10:05:43 +0000 Original-Received: from www.stare.cz (localhost [127.0.0.1]) by www.stare.cz (OpenSMTPD) with ESMTP id fd55aeea for ; Tue, 7 Nov 2017 11:05:34 +0100 (CET) Resent-From: Jan Stary Resent-Date: Tue, 7 Nov 2017 11:05:34 +0100 Resent-Message-ID: <20171107100534.GA31914@www.stare.cz> Resent-To: sox-devel@lists.sourceforge.net Mail-Followup-To: sox-users@lists.sourceforge.net Content-Disposition: inline In-Reply-To: X-Headers-End: 1eC0lJ-0000X2-Ti X-BeenThere: sox-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sox-devel-bounces@lists.sourceforge.net Original-Sender: "SoX-devel" Xref: news.gmane.org gmane.comp.audio.sox.devel:533 Archived-At: > First, it reads (which presumably moves the file pointer forwards), > then it seeks back to where it was. > I've verified in gdb that it actually does call sox_seek() (again and > again and again, but not forever). I have also verified in gdb that > it is reading the same samples. Ah, I see what your problem is now. > So sox_seek() is definitely being called, and definitely working. > But nevertheless, the reading done after the seeking eventually fails. Here is my slight rewrite of your example: #include #include #include #include int main(int argc, char **argv) { sox_format_t *s; int32_t buf[1024]; ssize_t r; int i; if (argc < 2) errx(1, "usage: ./soxseek input"); if (sox_init() != SOX_SUCCESS) errx(1, "Cannot init libsox"); if ((s = sox_open_read(*++argv, 0, 0, 0)) == NULL) errx(1, "Cannot open `%s'", *argv); for (i = 1; (r = sox_read(s, buf, 1024)) > 0; i++) { printf("[%04d] %zd samples, starting with %0x\n", i, r, *buf); if (sox_seek(s, 0, SOX_SEEK_SET) != SOX_SUCCESS) errx(1, "Cannot seek"); } /* No way to test for sox_read() error */ return 0; } (Note how I don't use sox_site_t for the sox_read() return value, because it does not exist, eventhough that's what libsox(3) documents.) $ sox -n /tmp/file.wav synth trim 0 $((1024 * 1000))s $ cc -o soxseek soxseek.c -lsox -I/usr/local/include/ -L/usr/local/lib $ ./soxseek /tmp/file.wav [0000] 1024 samples, starting with 0 [0001] 1024 samples, starting with 0 [....] [0999] 1024 samples, starting with 0 [1000] 1024 samples, starting with 0 So I think you are right. It does seek back to the begining of the sine wave (thus reporting 0 as the first sample value in the buffer), but it gets exhausted at EOF anyway. I suspect now it is a bug in sox_seek() if we are calling it right. > Certainly if you do analogous coding with calls to fread() and > fseek(), it would not terminate. Yes, the following will read the same file forever: #include #include #include #include int main(int argc, char **argv) { int fd; int32_t buf[1024]; ssize_t r; int i; if (argc < 2) errx(1, "usage: ./seek input"); if ((fd = open(*++argv, O_RDONLY)) == -1) err(1, NULL); for (i = 1; (r = read(fd, buf, 1024)) > 0; i++) { printf("[%04d] %zd samples, starting with %0x\n", i, r, *buf); if (lseek(fd, 0, SEEK_SET) == -1) err(1, NULL); } return (r != 0); } > What i'm trying to do now is to determine the correct way to use > sox_seek() if i am using it incorrectly. If i'm using it correctly, > then i would like confirmation of my characterization (that it has > some internal counter which is decremented until it hits zero). I share your suspition now. > (I did have a signal processing problem that i was considering > earlier, but that's not relevant now because i avoided the sox_seek > issue by rearranging the computation. So i can do my dsp, but i do > wonder about correct usage of sox_seek.) Should we move this to sox-devel? Jan ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot