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=-2.7 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 72BD320A10 for ; Mon, 6 Nov 2017 20:15:10 +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 1eBnnY-0004gJ-Q0; Mon, 06 Nov 2017 20:15:08 +0000 Received: from sfi-mx-4.v28.ch3.sourceforge.com ([172.29.28.194] 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 1eBnnX-0004g6-GZ for sox-users@lists.sourceforge.net; Mon, 06 Nov 2017 20:15:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Type:To:Subject:Message-ID:Date:From: References:In-Reply-To:MIME-Version: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=t9neuRA0wOwSxPLC1oqCTutYQa46DfyH54HSDvM162c=; b=aTpL7PajXeXIhNXsuIwQGnx/r lKjub6/4JAOD7yX5ft7KF84/yZlliaC0HieVHVPPPYIXzjqMTSPNMo4Suoa2NrJjPEoKhdYNZexLj BFzoxUB811Iu6vtAJWxEVnOAJpjwOzrNcLI9hBk8dCoYuvdUXPsStnoDHHIcOmAiS3Y2Y=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Type:To:Subject:Message-ID:Date:From:References:In-Reply-To: MIME-Version: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=t9neuRA0wOwSxPLC1oqCTutYQa46DfyH54HSDvM162c=; b=Q3k9Jv6pGY+LPRj1YQnMsPqQ/B OeI/XbiF77kC1qpttQBgqUF1uPuQlKSYXtLvMZMQsIK0SikHNOvIPRNTlJieN/mPb+U+eUMMrpAXB bGf9zjOo3TEVuxWn65snGBUG13qXfg6zywcEec6lVmadsnpEbBRzV/SygxUD6QF9sFGQ=; Received: from mail-ot0-f173.google.com ([74.125.82.173]) by sfi-mx-4.v28.ch3.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) id 1eBnnW-0003q6-AM for sox-users@lists.sourceforge.net; Mon, 06 Nov 2017 20:15:07 +0000 Received: by mail-ot0-f173.google.com with SMTP id q99so10132974ota.2 for ; Mon, 06 Nov 2017 12:15:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=t9neuRA0wOwSxPLC1oqCTutYQa46DfyH54HSDvM162c=; b=sPqqtfM6oeLOydM12E6imoD6LmZ1hJLe9aaU2I5jNcINg8TpHXQ5ZvsWm40cXjC0eD Piku17/eAVJ5+GVrsYzxRRh5Vcr7HmNK18wQlxD28W7KpXQ7uSU9mtITtGtLT76ffzHn zlJ71C+0f+V6/6lHaSbA9rW3YjyZ66ZK8W+5PCLX9u0mLmkW5gZ96cneWZ0D3aJm8sDT ymggrBr4fmIi8cueq3cZi8QIzCwUbJOjLQeNf0/Aflfj1STbaC9RLARu/BqLNVMILGOk JD2JuQWPDyhkZ3vgdAkb/wQN0REBxwdCwVfcFUG1BLyMGAnkydidaJ+KNaqxJUMut/1A EKyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=t9neuRA0wOwSxPLC1oqCTutYQa46DfyH54HSDvM162c=; b=P+UC1aCDxv0QoiiFU4DPv3v7MKZ8wJ07Yv/GgZB+FGlIS2oCKiK4Z36z3hDE23yk5u ponpcG/AqRs45PpXkC6HgsUyZpRzi8Pe/MoqUGEegf6WibD5brzrtSd34iLP7TxJ+x2D KZgcGcdjqX8n9+YXx2RfcBEg2ikVv3/3Pg75+K4ztVaofHW/PoVSOdrF4eU8BkGOeVXv 2Mkpo6z/v0U6HbhYwTXESPYTkgnTrpzM/zHAfbQ4aziRzrFK7/pXf2JoEvG+j5NUCt7s 9t4TAv0uiJXkW5/uwy1FvuYao3hq13Hph69wyH+HSN0HBtLgyIjVcB3xYOYux4XcmdZs rHzw== X-Gm-Message-State: AJaThX4QMkaIYGrrHkexIxQVxu0AWp1wwxDmNasSZWMBK9BtpaC8ISdV 0v//SeqciSQoL/tzC720MXh0qj3A3TPjyG6yut1mYA== X-Google-Smtp-Source: ABhQp+SC65CcSeNaHl3wgImdIZeF0fv1Sw1KysIRgI6KL4hG2U4S7aMWNkrUfuFRO+E2E1w7dh1mwyoSkVsMh3OgM+Y= X-Received: by 10.157.89.25 with SMTP id t25mr11767499oth.47.1509999300490; Mon, 06 Nov 2017 12:15:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.162.36 with HTTP; Mon, 6 Nov 2017 12:14:59 -0800 (PST) In-Reply-To: <20171106190645.GA61378@www.stare.cz> References: <20171106111001.GA80730@www.stare.cz> <20171106190645.GA61378@www.stare.cz> From: Dan Hitt Date: Mon, 6 Nov 2017 12:14:59 -0800 Message-ID: To: sox-users@lists.sourceforge.net X-Headers-End: 1eBnnW-0003q6-AM 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 Hi Jan! Thanks for your mail. Answers interspersed below, hopefully simple to read. 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 } It compiles and links without error or warning (link with -lsox). I ran it on a file a few megabytes long, and it did a few thousand seeks, then failed on the read. (It's amazing with modern hardware how fast something like this runs.) 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. For me, that's the most important point: to try to have an exact characterization of the behavior of the library under these circumstances. > > ... (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. > ... (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. > >> (2) I'm doing this programmatically because i anticipate running the >> program many times, and i want to be as sure of correctness as i can. >> (In fact, i'm not actually programming it in C, but i'm using the C >> calling conventions, and in principle i could certainly do this in C.) > > What makes you think that writing your own code will make > your use of SoX more "correct"? Well, i don't think that at all!!! :) :) :) Or more exactly, correct or not it may very well not be very idiomatic. I think the best, simplest way to obtain the same samples over and over would be to seek to them, and read them again. That may even be possible, by executing some kind of a reset, however i don't know. Thanks again for your help, and if anything i've said is wrong, i'd appreciate any correction, clarification, or references. dan ------------------------------------------------------------------------------ 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