sox-users@lists.sourceforge.net unofficial mirror
 help / color / mirror / code / Atom feed
From: Dan Hitt <dan.hitt@gmail.com>
To: sox-users@lists.sourceforge.net
Subject: Re: how to interpret tell_off, and the right way to use sox_seek
Date: Mon, 6 Nov 2017 10:08:24 -0800	[thread overview]
Message-ID: <CAOphizKhERDQ-H_Xh0VSGPjKHnWBFgYc1UFQ7Ozk508WmDGTeg@mail.gmail.com> (raw)
In-Reply-To: <20171106111001.GA80730@www.stare.cz>

Hi Jan,

Thanks for your mail!  And thanks for your activity in SoX!

I appreciate your help, and i will try to list my answers below.

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!!
:)

Now, in answer to your three questions and suggestion about libsndfile:

(1) In fact, i didn't need to read the same samples multiple times, i
just needed to use them multiple times.  And it was possible for me to
implement my own buffering scheme.   And that's what i ended up doing,
because in this particular case there is a pattern of access that
repeats.  So it was possible to code around not being able to seek
freely.

However it would have been easier not to do any buffering, and just
seek, and use the implicit buffering of the system.

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.

And it's sort of similar in this case too: the file on the other side
of the SoX interface already has the data buffered, so if unlimited
seeking were possible, then there would presumably not be much file io
overhead.

(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.)

(3) I'm using SoX to do this because it is so good :) :).  I also have
experience programming in SoX, although obviously i'm still learning.

(4) libsndfile would definitely have been a possibility, but every
library has trade offs.  As i understand it, libsndfile does not yet
support mp3, although that is on the road map.  And it is possible
that there would be some other move that i was making that wouldn't
work in libsndfile.  So i'd have to recode to see --- although as far
as i can tell, libsndfile and SoX are both excellent pieces of
software.

Thanks again for providing me information, and if anything i said is
wrong, please correct me! :)

dan


On Mon, Nov 6, 2017 at 3:10 AM, Jan Stary <hans@stare.cz> wrote:
> On Nov 04 00:26:37, dan.hitt@gmail.com wrote:
>> I'm on a debian stretch box, using what i imagine is version 14, 4, 1
>> based on sox.h (SOX_LIB_VERSION(14, 4, 1)).
>>
>> I need to seek back and forth in a file, ultimately reading the same
>> samples multiple times.
>
> Why do you need to reread those same samples multiple times?
> Why do you need to do that programatically, in C?
>
> Why are you using SoX for this?
> This might be easier using libsndfile.
>
>         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

------------------------------------------------------------------------------
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

  reply	other threads:[~2017-11-06 18:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-04  7:26 how to interpret tell_off, and the right way to use sox_seek Dan Hitt
2017-11-06 11:10 ` Jan Stary
2017-11-06 18:08   ` Dan Hitt [this message]
2017-11-06 19:06     ` Jan Stary
2017-11-06 20:14       ` Dan Hitt
2017-11-06 21:09         ` Jan Stary
2017-11-06 21:47           ` Dan Hitt
2017-11-07  8:50             ` Jan Stary
2017-11-07  9:01               ` Jan Stary
2017-11-07  9:13                 ` Jan Stary
2017-11-07  9:22                   ` Jan Stary

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.sourceforge.net/lists/listinfo/sox-users

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOphizKhERDQ-H_Xh0VSGPjKHnWBFgYc1UFQ7Ozk508WmDGTeg@mail.gmail.com \
    --to=sox-users@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/sox.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).