headers
Chris Bagwell | 1 Jul 2008 05:37

SoX 14.1.0 Release Candidate 2

Hi all,

I found out I just released a few months old snapshot of source code in 
the sox-14.1.0-rc1.tar.gz file.  I'm sorry to have wasted peoples time 
that tried the tar file out.

To recover from this, I'm releasing a new Release Candidate 2 of the 
source code only.

Source: http://downloads.sourceforge.net/sox/sox-14.1.0-rc2.tar.gz

The cygwin RC1 file was based off the correct source file so any tested 
there was valid.  Also, using CVS would have also been fine.

Chris

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
Permalink | Reply | 0 comments |
headers
Rob Vance | 10 Jul 2008 05:20
Picon

Sox 13.0.0 buffer repeat problem

I am using SoX 13.0.0 on Ubuntu Gutsy Gibbon.

When recording a file (in Sox) and playing it back (with SoX) I get
fragments, or artifacts of the other part of the recording near the end
as thought there are "lost bits" in a buffer or something like it.  Is
there something I can do to eliminate this problem?

I have attached below the screen output of the record and play sessions.

The recording stream:
rob <at> tubby:~$ rec /home/rob/tlf/sounds/F1.ogg

Input File     : 'default' (alsa)
Sample Size    : 16-bit (2 bytes)
Sample Encoding: signed (2's complement)
Channels       : 1
Sample Rate    : 8000

Time: 00:05.12 [00:00.00] of 00:00.00 (  0.0%) Output Buffer:  40.96K
Skipped.

Done.

The playback stream:

rob <at> tubby:~$ play /home/rob/tlf/sounds/F1.ogg -V5
play auto: Detected file format type: ogg

Input File     : '/home/rob/tlf/sounds/F1.ogg'
Sample Size    : 16-bit (2 bytes)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pascal Giard | 10 Jul 2008 05:32
Picon
Gravatar

Re: Sox 13.0.0 buffer repeat problem

On Wed, Jul 9, 2008 at 11:20 PM, Rob Vance <n6rob <at> comcast.net> wrote:
> I am using SoX 13.0.0 on Ubuntu Gutsy Gibbon.
>
> When recording a file (in Sox) and playing it back (with SoX) I get
> fragments, or artifacts of the other part of the recording near the end
> as thought there are "lost bits" in a buffer or something like it.  Is
> there something I can do to eliminate this problem?

IIRC, this has been fixed in 14.0.0.
Can you update to the packages in hardy or intrepid?

-Pascal
--

-- 
Homepage (http://organact.mine.nu)
Debian GNU/Linux (http://www.debian.org)
LACIME: École de technologie supérieure (http://lacime.etsmtl.ca)

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
Permalink | Reply | 0 comments |
headers
Rob Vance | 11 Jul 2008 02:30
Picon

Re: Sox 13.0.0 buffer repeat problem

 
> I recommend that you also install libsox-fmt-all.
> Amongst others, that will automatically install libsox-fmt-alsa .

Yes, I had a hunch that was the issue.  Did that but it still had
problems.  I ended up installing/upgrading to Hardy for the entire
operating system and now SoX is operating again.

I am still getting "artifacts" (sound like partial syllables) at the end
of a playback on SoX.  I am using ogg format.  The file was recorded in
Sox and played back in SoX.  When I play the file back in Audacity there
are no artifacts at the end of the playback.  Also, seems to affect
recordings of less about 2 seconds.  The recording I am having a problem
with in particular is just over 2 seconds.  I have a 4 second recording
that gives only a click at the end.  Also, when recording a file I use
Ctrl-C to stop; sometimes it cuts the recording short, so I leave some
silence (0.5 second or so) at the end before doing a Ctrl-C.

Is there something else I should be doing?

Thanks for the help.  (BTW I moved this back to the list for the benefit
of others).

Regards,

Rob

On Thu, 2008-07-10 at 07:14 -0400, Pascal Giard wrote: 
> On Thu, Jul 10, 2008 at 12:00 AM, Rob Vance <n6rob <at> comcast.net> wrote:
> > I was able to load v14 and the libsox.
(Continue reading)

Permalink | Reply | 1 comment |
headers
jbachman | 8 Jul 2008 21:26

Using SoX to get basic audio info


Is anyone aware of a way to use SoX to get basic audio info out of a wav file
for instance.  Audio duration, bit depth, sample frequency.

If not are there any other tools out there that do this?
--

-- 
View this message in context: http://www.nabble.com/Using-SoX-to-get-basic-audio-info-tp18347099p18347099.html
Sent from the SoX mailing list archive at Nabble.com.

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
Permalink | Reply | 2 comments |
headers
Pascal Giard | 12 Jul 2008 06:36
Picon
Gravatar

Re: Using SoX to get basic audio info

On Tue, Jul 8, 2008 at 3:26 PM, jbachman <jason <at> safesoundarchive.com> wrote:
>
> Is anyone aware of a way to use SoX to get basic audio info out of a wav file
> for instance.  Audio duration, bit depth, sample frequency.
>
> If not are there any other tools out there that do this?

If you're using SoX 14.1.0 release candidates or current CVS version,
there's soxi that does exactly that and more.
e.g. soxi /path/to/file.ogg

If you don't have such a recent version of SoX and don't mind playing
a very small amount of the song, you may use play which comes with
SoX.

hope this helps,

-Pascal
--

-- 
Homepage (http://organact.mine.nu)
Debian GNU/Linux (http://www.debian.org)
LACIME: École de technologie supérieure (http://lacime.etsmtl.ca)

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
Permalink | Reply | 0 comments |
headers
Michael Chapman | 12 Jul 2008 07:20

Re: Using SoX to get basic audio info

On Tuesday 08 July 2008 7:26 pm, jbachman wrote:
> Is anyone aware of a way to use SoX to get basic audio info out of a wav
> file for instance.  Audio duration, bit depth, sample frequency.
>
> If not are there any other tools out there that do this?

I could not see a way, so I wrote Ambinfo (aimed at identifying ambisonic 
sould files, but it gives you the basic info on (almost) any wav file).
<http://mchapman.com/amb/soft/ambinfo> (the output is much more succinct; 
now ---the screenshots are a bit dated).
It only requires Perl, so is cross-platform.

Since writing it I discovered :
" sndfile-info  will display basic information about a sound file such as
       its format, its sample rate, and the number of channels. This  informaâ
       tion  is  obtained  using  libsndfile 
       (http://www.mega-nerd.com/libsndfile/)."
which gives a better, generic solution!

SoX uses libsndfile so the chances are you have it, not sure about 
libsndfile-info.

Michael

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Chapman | 12 Jul 2008 10:29

Re: Using SoX to get basic audio info

On Saturday 12 July 2008 5:20 am, Michael Chapman wrote:
> <http://mchapman.com/amb/soft/ambinfo> (the output is much more succinct;
> now

sorry, should have said, and now gives durations.

> ---the screenshots are a bit dated).

MC

E.g. (see the last two lines):
<<
	$ ambinfo test4-1sec.wav
test4-1sec.wav
AMBINFO 0.5.2, 2007/11/02 - Copyright (c) 2007 by Michael Chapman.

This is an experimental early release. The output is
not finely tuned!.

WARNING: This does not look like a B-format file.
	 It may be, but it does not have the correct id tag.

SUMMARY; (run with -v for more details)
     Channels: 4
                           Implicitly a first order file
                           channels (I am guessing) are WXYZ

          48 KHz  /  16 bits  /  PCM  /  WAVEX
                 estimated duration 1 second.
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
robs | 12 Jul 2008 17:06
Picon
Favicon

Re: Sox 13.0.0 buffer repeat problem

There've been a few buglets affecting alsa playback, hopefully now all fixed in http://downloads.sourceforge.net/sox/sox-14.1.0-rc2.tar.gz

/Rob

--- On Fri, 11/7/08, Rob Vance <n6rob <at> comcast.net> wrote:

> From: Rob Vance <n6rob <at> comcast.net>
> Subject: Re: [SoX-users] Sox 13.0.0 buffer repeat problem
> To: "Pascal Giard" <evilynux <at> gmail.com>, sox-users <at> lists.sourceforge.net
> Date: Friday, 11 July, 2008, 1:30 AM
>  
> > I recommend that you also install libsox-fmt-all.
> > Amongst others, that will automatically install
> libsox-fmt-alsa .
> 
> Yes, I had a hunch that was the issue.  Did that but it
> still had
> problems.  I ended up installing/upgrading to Hardy for the
> entire
> operating system and now SoX is operating again.
> 
> I am still getting "artifacts" (sound like
> partial syllables) at the end
> of a playback on SoX.  I am using ogg format.  The file was
> recorded in
> Sox and played back in SoX.  When I play the file back in
> Audacity there
> are no artifacts at the end of the playback.  Also, seems
> to affect
> recordings of less about 2 seconds.  The recording I am
(Continue reading)

Permalink | Reply | 0 comments |
headers
robs | 25 Jul 2008 22:04
Picon
Favicon

Re: sox-14.0.1 w64 format incompatibility

Thanks for this---I've added it to the patch tracker on the website.
Hopefully, not too long before we get round to integrating it.
/Rob

--- On Fri, 2/5/08, Tim Munro <ornum <at> access-ohio.net> wrote:

> From: Tim Munro <ornum <at> access-ohio.net>
> Subject: [SoX-users] sox-14.0.1 w64 format incompatibility
> To: sox-users <at> lists.sourceforge.net
> Date: Friday, 2 May, 2008, 6:13 PM
> SoX appears to be reading and writing something other than
> IEEE 
> floating-point data when dealing with w64 files.  I
> discovered this 
> while attempting to use SoX to convert the w64 files
> produced by 
> TimeMachine into something more universally readable. 
> Other 
> sndfile-linked applications handled these files without a
> hitch.
> 
> SoX would correctly read any w64 files that it produced, so
> checking SoX 
> against itself hid the problem.  Other programs could not
> correctly read 
> SoX-produced w64 files.
> 
> I verified the problem by preparing a simple wave file
> (pcm16, 2 
> channel) and converting it with both SoX and sndfile:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane