From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3561 216.34.176.0/20 X-Spam-Status: No, score=-3.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS,T_DKIM_INVALID shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from lists.sourceforge.net (lists.sourceforge.net [216.34.181.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 736AA20A10 for ; Mon, 6 Nov 2017 21:09:56 +0000 (UTC) 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 1eBoeZ-0005oR-6G; Mon, 06 Nov 2017 21:09:55 +0000 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 1eBoeY-0005oL-1L for sox-users@lists.sourceforge.net; Mon, 06 Nov 2017 21:09:54 +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:Sender:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=yeNCWiKUA4cgWEOOjfy2fby18KCQcapvQmNn4Mg+dk4=; b=bB5dwhyhe1ODRLt5PIVPuPUKeE XSpXuRd+n6pw9UN5MJNF1vn3X/YJUNzgxcVlMA2Cb70s2DrguUPZ4+LRBvVK6g9uBhDSaSm3bnU9Z LAWYEreaQP+JGTz13YnT495SBhSA3CBNJdArV+AIF7IwWbFeyv6ZctNRdXdFz9rG8f+M=; 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:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=yeNCWiKUA4cgWEOOjfy2fby18KCQcapvQmNn4Mg+dk4=; b=QhdDm1xL6wLrCvqfSyQ9BOME1F kO7xDWQyHhoJtBATh+jmjCfgqEWyrtZW+cKW/RrUNm/7RbhGJ6drU1He5aBvMN/86QkiPk8Bc/bK6 t6/CWRPFKjyqSYGYZnt5E8/ywnLgNkgNaG73CbTGql1shTBeyiOWVbB4JyTfdpKlwz88=; Received: from [79.98.77.229] (helo=mx.stare.cz) by sfi-mx-2.v28.ch3.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) id 1eBoeW-0005mx-9Z for sox-users@lists.sourceforge.net; Mon, 06 Nov 2017 21:09:53 +0000 Received: from www.stare.cz (localhost [127.0.0.1]) by www.stare.cz (OpenSMTPD) with ESMTP id 44b528f9 for ; Mon, 6 Nov 2017 22:09:35 +0100 (CET) Date: Mon, 6 Nov 2017 22:09:35 +0100 From: Jan Stary To: sox-users@lists.sourceforge.net Message-ID: <20171106210932.GA41280@www.stare.cz> Mail-Followup-To: sox-users@lists.sourceforge.net References: <20171106111001.GA80730@www.stare.cz> <20171106190645.GA61378@www.stare.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Headers-End: 1eBoeW-0005mx-9Z Subject: Re: how to interpret tell_off, and the right way to use sox_seek X-BeenThere: sox-users@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: sox-users@lists.sourceforge.net Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: sox-users-bounces@lists.sourceforge.net On Nov 06 12:14:59, dan.hitt@gmail.com wrote: > On Mon, Nov 6, 2017 at 11:06 AM, Jan Stary wrote: > >> I do take your message to imply that SoX will read no more samples > >> than the number of in a file total, so that, e.g., if you read the > >> same 10 blocks of samples and sox_seek() to the beginning of them > >> repeatedly, eventually your reads will fail. And in fact, if the > >> length of the file is 50 blocks, those reads will fail as soon as you > >> have done this 5 times. If this is not correct, please let me know!! > >> :) > > > > There is a difference between SoX the utility and libsox the library. > > I am not sure if SoX itself ever reads a block of audio more than once > > (I can imagina situations where it would), but that's not a constraint > > on what the libsox library can do. If it has a sox_seek(), then I suppose > > it does what the name says; in particular, it lets you read the same > > block of audio over ano over again as long as you keep seekign back. > > (Disclaimer: I have never used libsox directly, > > I only use SoX the binary.) > > This is the crux of the matter, and appears not to be the case. > > I wrote a little program to test exactly this assertion, that you > cannot repeatedly > call sox_seek(). > > The answer here appears to be that indeed you cannot. > > Here's the test program: > > #include > #include > #include > > int main( int argc, char** argv ) { > if ( argc < 2 ) { > fprintf(stderr,"Call with one arg, the name of a sound file.\n" ); > exit(1); > } > int istat = sox_init(); > if (istat != SOX_SUCCESS ) { > fprintf(stderr, "Failed to initialize sox, error %d.\n", istat); > exit(1); > } > char* infile = argv[1]; > sox_format_t* s = sox_open_read( infile, 0, 0, 0 ); > if ( ! s ) { > fprintf(stderr,"Failed to open `%s' .\n", infile); > exit(1); > } > int buf[1024]; > int count = 0; > while ( 1 ) { > int rcnt = sox_read( s, buf, 1024 ); > if ( rcnt <= 0 ) { > printf( "Failed on read, attempt %d\n", count ); > exit( 0 ); > } > int status = sox_seek( s, 0, SOX_SEEK_SET ); > if ( status ) { > fprintf(stderr,"Failed on seek.\n" ); > exit(1); > } > count++; > } > return 0; // not reached > } > $ cc -o soxseek soxseek.c -lsox -I/usr/local/include/ -L/usr/local/lib $ sox -n /tmp/file.wav synth trim 0 $((1024 * 1000))s $ ./soxseek /tmp/file.wav Failed on read, attempt 1000 That makes me suspect it's just an end of file. To quote the outdated and incomplete libsox manpage: sox_read and sox_write return the number of samples successfully read or written. If an error occurs, or the end-of-file is reached, the return value is a short item count or SOX_EOF. TODO: sox_read does not distiguish between end-of-file and error. Need an feof() and ferror() concept to determine which occured. > I ran it on a file a few megabytes long, and it did a few thousand > seeks, then failed on the read. The above does exactly 1000 reads of 1024, which is exactly how many samples the file contains. So ( rcnt <= 0 ) does not mean there was an error. > So it behaves as though there's some kind of internal counter > initialized to the length of the file, and each read decrements that > counter by the amount read; when the counter runs out, then reads are > no longer permitted. Yes. If I am reading your code right, it does not seek at all. It just reads up to EOF. Which might be an error in sox_seek(). As I said, I haven't used libsox before, so I don't know if this is a correct use of sox_seek(), but beware: not every input is seekable (a regular file on disk should be, though). > For me, that's the most important point: to try to have an exact > characterization of the behavior of the library under these > circumstances. There is no good documentation of libsox. The libosx(3) man page is both incomplete and outdated, and it has been for years. You might want to look an the src/example*c files. > > > > ... (cut) > > Is there anything left of the original problem then? > > No. > > That's been solved. > > But it would be useful to have confirmation that this behavior is > intentional, or information on how to avoid the phenoomenon, but for > now i've dealt with it, although perhaps unnecessarily given the right > combination of function calls and arguments. I still suspect that it is first of all unnecessary to read the input again and again while seeking back again and again; but I can't be sure, because I still have no idea about what you are doing. > > ... (cut) > >> A sort of analogous situation is with the file system and linux: if > >> you're reading through a file the OS will keep it in memory so you > >> don't have too much overhead just relying on the OS itself to seek > >> back and forth in a file --- the caching has already been done. > > > > You already _have_ the data in memory once you have sox_read() them, > > so I fail to see the analogy. Why would you seek back and read it > > again _from_the_file_ once you have it in an array? > > Not necessarily, as you may be reusing the storage you've set aside. So don't reuse it: keep the copy of what you have read so that you don't have to read it over again. > I think the best, simplest way to obtain the same samples over and > over would be to seek to them, and read them again. Why do you think that? Just sox_read() it into an array, then keep reading that array, instead of reading from a file. > Thanks again for your help, and if anything i've said is wrong, i'd > appreciate any correction, clarification, or references. I staill have no idea about what you are actually trying to do. Jan ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Sox-users mailing list Sox-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-users