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
next prev parent 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).