similar to: squelch-1.0beta5 ready

<ad> .q.u.e.l.c.h is an audio player dedicated to Ogg Vorbis. This is a bugfix release. RPMs available for i386, i486, i586, i686 and Athlon. Source available as tar.gz, tar.bz2 and src.rpm. http://www.geoid.clara.net/rik/squelch.html Tested on Linux, may work elsewhere. Requires only Vorbis, libao and Qt (compiled with thread support.) </ad> Have fun ;) Rik --- >8 ----

Hi, I released Squelch 1.0beta9. It's a multi-platform Ogg Vorbis player, if you haven't heard of it. [1] Find it here: http://www.geoid.clara.net/rik/squelch.html Differences from beta8: * Vorbis comment editor ! [2] * More intelligent re-initialisation of output driver. * Stupid bugs in auto-update of master track list resolved. * Some bugs fixed, some more introduced ;) In theory,

I've written an Ogg Vorbis (only !) player, which some may like to play with. It works for me (tm) and I like it. If you don't, well, you know what you can do with it ;) I leave it running 24/7 and it plays my music without problems and without annoying me. That's all it's for, really. You can get it from http://www.geoid.clara.net/rik/arch/squelch.tar.gz The README follows ...

I decided to write a changelog for once. Here's the text for this release: * Fixed repaint of last column in master track list. * Turned radio buttons into combo box in config dialog, used Qt Designer to make it instead of hand-coding. * Now plays sample rates other than 44100 and channel count other than 2, so you can play 22050Hz monaural recordings if you're that

Jean-Marc Valin wrote: > Andy Ross wrote: > > Uh, production applications almost always require squelch, no? > > Some do, some don't. In general, distinguishing between a keyboard > and a speech transient is next to impossible based only on a few ms > of speech. That is true for distinguishing it by waveform, but not by amplitude. As I mentioned, these transients are

Jean-Marc Valin wrote: > The noise suppressor will only attempt to remove stationary noise, > such as thermal noise, fans, ... The AGC can indeed do strange > things in these cases, but it's been improved in svn (compared to > 1.2beta1). OK, then the problem is that I misunderstood the feature. I assumed that dynamic squelch was part of it, but it's really something more

I've written a vorbis tag editor. It does everything but save. I'll wait until there's support in the vorbis libs for that. If you want to read vorbis tags, you could of course use ogg123 -d null but I thought I'd get a nice front end ready anyway. The major part of the code is the logic ("When is the 'Save' button enabled ?", etc.) The UI is easy to change,

I also added a .desktop file for Gnome/KDE so that you can click on squelch from your panel etc. No icon right now - tmake doesn't support installing, so it's quite difficult to get that to work. Also I put a tiny script called 'squelch_wrapper' in the dist, which sets your LD_LIBRARY_PATH before running squelch - this way, you get the right Qt library loaded. Rik --- >8

There are many ways to implement a VAD. What you described is actually perfectly equivalent to the most trivial (and least robust) VAD algorithm. Jean-Marc Andy Ross wrote: > Ton Grandgent wrote: >> Andy Ross wrotte: >>> I wrote a trivial squelch feature* in 10 minutes that works >>> basically 100% of the time. >> Could you please explain how this differs from

Hi, I've written an ao plugin for aRts, the soundserver that comes with KDE. Any chance of including this in the ao distribution ? Pretty please ? :) Sources and patches attached. This is a very simple plugin because it uses the easy-to-use 'artsc' C wrapper that aRts installs. configure.in.diff is for ao/configure.in Makefile.am.diff is for ao/src/plugins/Makefile.am Makefile.am

I'm having trouble with the preprocessor's noise reduction feature. The basic issue is that it simply doesn't work very well. With my laptop (whose microphone is otherwise quite capable) I routinely hear transient background noise, typing, and other "quiet" sounds leaking through to the speex stream. Even worse, the AGC feature is blowing these things up into just awful

Hi! There are some little inconvenience in libao-0.8.5. - The biggest is may that: the documentation and the header file declare the ao_file_extension function, which give a hint for the file extension where the device is realy a sound file. This function is missing. -An other: the alsa 0.5 and the alsa 0.9+ drivers short name. It will be better if the alsa 0.5's name will be alsa05 and the

Dear list, I have a problem with nested functions and I don't manage to get it solved. I know I should be looking in environments, and I have tried a lot, but it keeps on erroring. An easy version of the problem is as follows: innerfunction<-function() { print(paste(a, " from inner function")) print(paste(b, " from inner function")) setwd(wd) }

Andy Ross <andy@plausible.org> wrote: > > I wrote a trivial squelch feature* in 10 minutes that works > basically 100% of the time. > > * Zero the sample data if the maximum sample in a frame is less than > 4% of saturation or 20% of the maximum sample yet seen. It's about > 8 lines of code. Could you please explain how this differs from VAD? Tom

Any votes for/against? ----- Forwarded message from Rik Faith <faith@alephnull.com> ----- Date: Wed, 28 Nov 2001 12:55:29 -0500 From: Rik Faith <faith@alephnull.com> To: mbp@samba.org Subject: rsync patch X-Mailer: VM 6.96; XEmacs 21.1; Linux 2.4.16 (light) Here is a patch that adds rate information (e.g., kB/s) to the --progress display. I just noticed that 2.4.7pre4 is coming

Why has ao been changed so that there are now two open() functions ? IMHO the original ao_open() was fine - if you wanted to set the filename for output, you could add an option via ao_append_option and if you wanted to avoid overwriting an existing file, you could stat() it yourself. Having ao_open_live() and ao_open_file() just makes more work for the user of the library for no gain, AFAICT.

Why has ao been changed so that there are now two open() functions ? IMHO the original ao_open() was fine - if you wanted to set the filename for output, you could add an option via ao_append_option and if you wanted to avoid overwriting an existing file, you could stat() it yourself. Having ao_open_live() and ao_open_file() just makes more work for the user of the library for no gain, AFAICT.

Hi, On 2018-03-07 16:35, Ondrej Valousek wrote: > Why do you need to replace your existing solution? > If you don't need to scale out due to the capacity reasons, the async > NFS server will always outperform GlusterFS The current solution is 8 years old and is reaching its end of life. The reason we are also looking into gluster is that we like that it uses standard components

Is there packaged code to convert geographical coordinates (e.g., longitude, latitude, elevation) to Cartesian coordinates in 3-space? I can see how to do this using 1. a spherical-to-Cartesian conversion like pracma::sph2cart(tpr) http://cran.r-project.org/web/packages/pracma/ 2. a geographical-to-spherical conversion. This seems to involve (in roughly increasing order of difficulty or

Hi Rik, Nice clarity and detail in the description. Thanks! inline... On Wed, Mar 7, 2018 at 8:29 PM, Rik Theys <Rik.Theys at esat.kuleuven.be> wrote: > Hi, > > We are looking into replacing our current storage solution and are > evaluating gluster for this purpose. Our current solution uses a SAN > with two servers attached that serve samba and NFS 4. Clients connect to