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 091D520281 for ; Tue, 7 Nov 2017 09:14:00 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=sfs-ml-3.v29.ch3.sourceforge.com) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.89) (envelope-from ) id 1eBzxG-0000Ej-Ss; Tue, 07 Nov 2017 09:13:58 +0000 Received: from sfi-mx-1.v28.ch3.sourceforge.com ([172.29.28.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eBzxF-0000Ed-6g for sox-users@lists.sourceforge.net; Tue, 07 Nov 2017 09:13:57 +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=bQVpQYqcX9Bot3Fi3BWneWTDa4kiQkNkZ1is6xz89LY=; b=hWlI2zCJwXU1623vbSzk4WyA9e WdWrKd2aoQy2gd2Aw+jQcB7u080Slh0yMDSqdpcNQS7rPznnLSkPvcG5a3UsoTmX3CH6DNDeGr0dO E0pbbbINT0i8x/GY3hWWIldDkB+sI7eaFM4HAmQMov7DZw5dt6Ghdgnr7R3p84QEAvg8=; 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=bQVpQYqcX9Bot3Fi3BWneWTDa4kiQkNkZ1is6xz89LY=; b=OrGB9aT1tmQFPd616irLFAqgPT gJLfz+82pBGtSQW2kL45CpH38D/lI+U0rU2jEFkDLyHXPoM8EPo/ywspHv233tEhb8S4ASTeiG3bh RlK47sj5KjxlIxZCNpZRhlbmcYKSZiobbnjLV3uu4AhZc+rkywiUSyzpQYmp7kr2EKP8=; Received: from mx.stare.cz ([79.98.77.229]) by sfi-mx-1.v28.ch3.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) id 1eBzxE-0005bs-6Y for sox-users@lists.sourceforge.net; Tue, 07 Nov 2017 09:13:57 +0000 Received: from www.stare.cz (localhost [127.0.0.1]) by www.stare.cz (OpenSMTPD) with ESMTP id c6b3ef18 for ; Tue, 7 Nov 2017 10:13:48 +0100 (CET) Date: Tue, 7 Nov 2017 10:13:48 +0100 From: Jan Stary To: sox-users@lists.sourceforge.net Message-ID: <20171107091348.GB10645@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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20171107090140.GA10645@www.stare.cz> User-Agent: Mutt/1.7.1 (2016-10-04) X-Headers-End: 1eBzxE-0005bs-6Y 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 07 10:01:41, hans@stare.cz wrote: > On Nov 07 09:50:36, hans@stare.cz wrote: > > 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. > > Much as I like sox, I don't trust this code very much: > > int sox_seek(sox_format_t * ft, sox_uint64_t offset, int whence) > { > /* FIXME: Implement SOX_SEEK_CUR and SOX_SEEK_END. */ > if (whence != SOX_SEEK_SET) > return SOX_EOF; /* FIXME: return SOX_EINVAL */ > > /* If file is a seekable file and this handler supports seeking, > * then invoke handler's function. > */ > if (ft->seekable && ft->handler.seek) > return (*ft->handler.seek)(ft, offset); > return SOX_EOF; /* FIXME: return SOX_EBADF */ > } This is wav's handler's seek() from src/wav.c (14.4.2): 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. That seems wrong, but I am not sure if that is exactly our problem. This is the lsx_seeki() (in src/formats_i.c) that eventually does fseeko() on the underlying (FILE*)ft->fp /* Implements traditional fseek() behavior. Meant to abstract out * file operations so that they could one day also work on memory * buffers. * * N.B. Can only seek forwards on non-seekable streams! */ int lsx_seeki(sox_format_t * ft, off_t offset, int whence) { if (ft->seekable == 0) { /* If a stream peel off chars else EPERM */ if (whence == SEEK_CUR) { while (offset > 0 && !feof((FILE*)ft->fp)) { getc((FILE*)ft->fp); offset--; ++ft->tell_off; } if (offset) lsx_fail_errno(ft,SOX_EOF, "offset past EOF"); else ft->sox_errno = SOX_SUCCESS; } else lsx_fail_errno(ft,SOX_EPERM, "file not seekable"); } else { if (fseeko((FILE*)ft->fp, offset, whence) == -1) lsx_fail_errno(ft,errno, "%s", strerror(errno)); else ft->sox_errno = SOX_SUCCESS; } return ft->sox_errno; } 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