sox-users@lists.sourceforge.net unofficial mirror
 help / color / mirror / code / Atom feed
From: Jan Stary <hans@stare.cz>
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 20:06:46 +0100	[thread overview]
Message-ID: <20171106190645.GA61378@www.stare.cz> (raw)
In-Reply-To: <CAOphizKhERDQ-H_Xh0VSGPjKHnWBFgYc1UFQ7Ozk508WmDGTeg@mail.gmail.com>

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

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

Well, that changes the whole premise.
Is there anything left of the original problem then?

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

Using the same data again does not imply any buffering by itself.
You sox_read() into an array and then use it as you wish
(such as play it seven times).

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

> (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"?

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

I still have no idea about what you want to do, eventually.
You are asking about technicalities; what are you actually _doing_ ?

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

I still have no idea about what you want 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

  reply	other threads:[~2017-11-06 19:06 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
2017-11-06 19:06     ` Jan Stary [this message]
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=20171106190645.GA61378@www.stare.cz \
    --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).