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 0E97520281 for ; Tue, 7 Nov 2017 09:23:00 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=sfs-ml-4.v29.ch3.sourceforge.com) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.89) (envelope-from ) id 1eC05z-0002xj-0U; Tue, 07 Nov 2017 09:22:59 +0000 Received: from sfi-mx-3.v28.ch3.sourceforge.com ([172.29.28.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eC05y-0002xL-0e for sox-users@lists.sourceforge.net; Tue, 07 Nov 2017 09:22:58 +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=qXkJJCuIm0DAiQJ+ENTq9Qp8xxUVQi8VDfB1478RZBw=; b=hLKeUYgKYAR9R4kdGLWD+Hwe9S ui3yMhy1MPI7eT12IzLFlxBLWk5VeBOGY4DgNMaM+tF488+ngn49BHyIup2Er07cJoG+UKlKMXIEP W6Xt2J9xMRmqZiRT62cdUgg9T+Go1sIXEZh+uy0ij50lpO1ssxPT6iiiUzhgleo9/RGo=; 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=qXkJJCuIm0DAiQJ+ENTq9Qp8xxUVQi8VDfB1478RZBw=; b=FhPUy9ecYEAxJ9XmHSYEGDGxut aX0OejugSogiBU0/cMM5K89Yg8nEDAvreSwWFGWK5INVxIa+QAI7ko/CBxPtvCiLgM8nC64rEhNk1 Bt7Tz5+4G/5VJAT08ijMcUZNgCSyVFUbOOY4MvPptHo5/Ffz/+pCU70bL33MxA+nZvBQ=; Received: from ns.stare.cz ([79.98.77.229] helo=mx.stare.cz) by sfi-mx-3.v28.ch3.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) id 1eC05x-0003wa-54 for sox-users@lists.sourceforge.net; Tue, 07 Nov 2017 09:22:57 +0000 Received: from www.stare.cz (localhost [127.0.0.1]) by www.stare.cz (OpenSMTPD) with ESMTP id 941360bd for ; Tue, 7 Nov 2017 10:22:50 +0100 (CET) Date: Tue, 7 Nov 2017 10:22:50 +0100 From: Jan Stary To: sox-users@lists.sourceforge.net Message-ID: <20171107092250.GA9955@www.stare.cz> Mail-Followup-To: sox-users@lists.sourceforge.net References: <20171106111001.GA80730@www.stare.cz> <20171106190645.GA61378@www.stare.cz> <20171106210932.GA41280@www.stare.cz> <20171107085036.GA34760@www.stare.cz> <20171107090140.GA10645@www.stare.cz> <20171107091348.GB10645@www.stare.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20171107091348.GB10645@www.stare.cz> User-Agent: Mutt/1.7.1 (2016-10-04) X-Headers-End: 1eC05x-0003wa-54 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 > static int seek(sox_format_t * ft, uint64_t offset) > { > priv_t * wav = (priv_t *) ft->priv; > > if (ft->encoding.bits_per_sample & 7) > lsx_fail_errno(ft, SOX_ENOTSUP, "seeking not supported with this encoding"); > else if (wav->formatTag == WAVE_FORMAT_GSM610) { > int alignment; > size_t gsmoff; > > /* rounding bytes to blockAlign so that we > * don't have to decode partial block. */ > gsmoff = offset * wav->blockAlign / wav->samplesPerBlock + > wav->blockAlign * ft->signal.channels / 2; > gsmoff -= gsmoff % (wav->blockAlign * ft->signal.channels); > > ft->sox_errno = lsx_seeki(ft, (off_t)(gsmoff + wav->dataStart), SEEK_SET); > if (ft->sox_errno == SOX_SUCCESS) { > /* offset is in samples */ > uint64_t new_offset = offset; > alignment = offset % wav->samplesPerBlock; > if (alignment != 0) > new_offset += (wav->samplesPerBlock - alignment); > wav->numSamples = ft->signal.length - (new_offset / ft->signal.channels); > } > } else { > double wide_sample = offset - (offset % ft->signal.channels); > double to_d = wide_sample * ft->encoding.bits_per_sample / 8; > off_t to = to_d; > ft->sox_errno = (to != to_d)? SOX_EOF : lsx_seeki(ft, (off_t)wav->dataStart + (off_t)to, SEEK_SET); > if (ft->sox_errno == SOX_SUCCESS) > wav->numSamples -= (size_t)wide_sample / ft->signal.channels; > } > > return ft->sox_errno; > } > > > It seems you are right: wav->numSamples get decremented no matter what. Hm, not true; but I don't understand the computation either. Is the double there so that the integer count does not overflow? And is that related to the problem you are seeing? 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