Sweep

Thorsten Wilms wrote:

> Hi!
> 
> Opening a 44100, Float32 wav and saving it as PCM16 
> results in clicks. The same opertaion via sndfile-convert 
> does not.

Try this. Load in the file, select all (ctrl a), normalize (shift n)
and then save. 

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
"Copyrighting allows people to benefit from their labours, 
but software patents allow the companies with the largest 
legal departments to benefit from everyone else's work."
-- Andrew Brown
(http://www.guardian.co.uk/online/comment/story/0,12449,1387575,00.html)

On Wed, Nov 08, 2006 at 04:05:45AM +1100, Erik de Castro Lopo wrote:
> > 
> > Opening a 44100, Float32 wav and saving it as PCM16 
> > results in clicks. The same opertaion via sndfile-convert 
> > does not.
> 
> Try this. Load in the file, select all (ctrl a), normalize (shift n)
> and then save. 

Thanks, worked, no more clicks. So does that mean I have > 1 values in 
that file? It's straight out of Jamin and should be limited ...


--
Thorsten Wilms

Thorsten Wilms wrote:

> Thanks, worked, no more clicks. So does that mean I have > 1 values in 
> that file? It's straight out of Jamin and should be limited ...

I think that might be the case.

What does sndfile-info say?

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
"Whenever the C++ language designers had two competing ideas as to
how they should solve some problem, they said, "OK, we'll do them
both". So the language is too baroque for my taste." -- Donald E Knuth

On Wed, Nov 08, 2006 at 06:48:53AM +1100, Erik de Castro Lopo wrote:

> What does sndfile-info say?

Version : libsndfile-1.0.17

========================================
File : test_44100_float32.wav
Length : 69152952
RIFF : 69152944
WAVE
fmt  : 16
  Format        : 0x3 => WAVE_FORMAT_IEEE_FLOAT
  Channels      : 2
  Sample Rate   : 44100
  Block Align   : 8
  Bit Width     : 32
  Bytes/sec     : 352800
fact : 4
  frames  : 8644108
PEAK : 24
  version    : 1
  time stamp : 1162929661
    Ch   Position       Value
     0   5019729        1.01405
     1   7119457        1.01682
data : 69152864
End

----------------------------------------
Sample Rate : 44100
Frames      : 8644108
Channels    : 2
Format      : 0x00010006
Sections    : 1
Seekable    : TRUE
Duration    : 00:03:16.011
Signal Max  : 1.01682 (0.14 dB)


The original file was 48000, resampled in Sweep, because 
I only knew I had clicks after both resampling and bitrate 
conversion.

--
Thorsten Wilms

Thorsten Wilms wrote:

> Signal Max  : 1.01682 (0.14 dB)

There's your problem :-).
 
> 
> The original file was 48000, resampled in Sweep, because 
> I only knew I had clicks after both resampling and bitrate 
> conversion.

Yep, resampling does that:

    http://www.mega-nerd.com/SRC/faq.html#Q001

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
"If you think C++ is not overly complicated, just what is a
protected abstract virtual base pure virtual private destructor
and when was the last time you needed one?" -- Tom Cargill

On Wed, Nov 08, 2006 at 07:43:19AM +1100, Erik de Castro Lopo wrote:
> Thorsten Wilms wrote:
> 
> > Signal Max  : 1.01682 (0.14 dB)
> 
> There's your problem :-).
>  
> > 
> > The original file was 48000, resampled in Sweep, because 
> > I only knew I had clicks after both resampling and bitrate 
> > conversion.
> 
> Yep, resampling does that:
> 
>     http://www.mega-nerd.com/SRC/faq.html#Q001


I don't have that problem using sndfile-resample.
Sweep should restart on peaks the same way, I guess.


--
Thorsten Wilms

On Tue, 2006-11-07 at 17:33 +0100, Thorsten Wilms wrote:

> Something else: I sometimes get an
> Xlib: unexpected async reply (sequence 0x5a943)!
> after saving. That means the progress bar freezes 
> at 100%, the file is usualy saved and not corupted, 
> but sweep just hangs there until Ctrl-C

just testing some changes on an unrelated matter and
experienced a shitstorm of these pesky critters.

it seems like sweep is using gtk functions from outside
the GUI thread in some cases. it should be an easy fix
but it's tricky to verify that it works correctly given
that it doesn't always crash even when it isn't.

tarball soon

pete.