I've got this really noisy audio file I'm trying to clean up, and
I was thinking, it would be really cool if I could run a clip of
the file that was just the noise(it's a recording of a discussion
for a TV broadcast, so when no one's talking, it should be
silent) and have the program output an average frequency content,
in some sort of format that another program could take it as
input and create a filter that would filter out those
frequencies. It seems like brutefir would be able to do the
latter part, but is there a way to automatically generate the
filter definition from the frequency content of a file? Is this a
feasable method of noise reduction? If it seems like it could
work, but there isn't a program to do it, I would be interested
in writing it, if anyone has any input.
Thanks!
-spencer
hi everyone!
i just read dave's latest musings and stumbled upon stefan westerfeld's
notice that he is no longer maintaining arts.
many of you have probably already read about it. however, if you want to
see a really graceful and stylish way of abandoning a project and
changing one's mind, here are stefan's remarks:
http://www.arts-project.org/doc/arts-maintenance.html
even though arts will probably become obsolete in the near future, i
think it should be pointed out that just like the often-bashed open
sound system it has been a crucial step in bringing linux audio to the
mainstream, and the community owes much to stefan in that respect (not
to mention his many contributions to ladspa and other projects).
at a time when there was hardly anything else than esound, stefan
tackled the job of giving desktop users what they want: multiple source
playback and an elegant user interface.
even though arts turned out not to be feasible for high-end applications
(a fact that stefan now acknowledges, contrary to his former "mission"
;), it has certainly increased the momentum behind linux audio a great
deal.
kudos, stefan.
best,
jörn
http://www.notam02.no/arkiv/src/
CERES
*****
"Ceres is a simple program for displaying sonograms and for sound effects
in the frequency domain."
Except that its not that simple anymore...
0.41 -> 0.42
-------------
-Actually apply the fix for the (horrible) bug that caused
ceres to crash on newer linux distributions. (Sorry!)
MAMMUT
******
Mammut will FFT your sound in one single gigantic analysis (no windows).
These spectral data, where the development in time is incorporated in
mysterious ways, may then be transformed by different algorithms prior to
resynthesis. An interesting aspect of Mammut is its completely
non-intuitive sound transformation approach.
0.17 -> 0.18
------------
-Fixed a (horrible) bug that caused mammut to crash on newer linux
distributions.
-Simplified the install process a lot. pygtk1, libglade and sndlib
is now included in the distribution and is/can be installed
automatically if needed.
-Added undo for load&multiply
--
Well, its time for another release of Ardour. This release is another
milestone: it marks the end of all bugs that were slated to be solved
before the 1.0 release. The plan from here is to wait for about a few
days to allow testing of this release and minor (cosmetic) bug fixing
to continue, and then ardour 0.99 will be released. After that,
release engineering (install process, new user experience) will be all
that stands between us and release 1.0rc1, which will hopefully be the
last release before 1.0.
Please note: there is no claim that Ardour is bug free. The bug list
for 1.0 was drawn up with the goal of making sure that the vast
majority of new (and existing) users of Ardour will have a rewarding,
powerful and largely problem-free experience recording, mixing and
producing music. There are still substantive (as well as trivial)
issues that require solutions, but the development team is anxious to
move on to the GTK2 port so that we can make Ardour look as shiny
(shinier?) as Rosegarden :)
This is an important release for people who work in locales that do
not use the period (".") as a decimal separator (i.e. decimals written
as "1,5" rather than "1.5"). It is the first version that we believe
is now truly locale-safe against data corruption caused by
LC_NUMERIC's affect on stored data formats.
Enjoy, there's more to come :)
--p
* fix a truly appalling coding error in all uses of LocaleGuard
- people who run ardour with LC_NUMERIC set to something
other than en_US.UTF-8 will probably have continued to
suffer from locale-based problems because of this
problem.
* fix nesting of LocaleGuard objects to provide yet more fixes
to LC_NUMERIC problems
* add new flag for custom canvas items that do not require
an automated redraw when arguments are set.
* rework canvas "simple rect" item to optimize redraws
as resizes occur, and use FAST_PAINT_BOX to speed
up drawing slightly. it is possible (likely?) that
this will help some system performance issues
when recording multiple tracks at once.
* rationalize how the "s" (split) operation works.
- if the mouse pointer is inside a regionview, that region
is split
- if the region was part of the selection, then
a) all regions covering the mouse pointer time position
are also split
b) the selection is cleared after the split
- if the region was not part of the selection, then
the selection is left unchanged after the split
* if auto-connect inputs is in use, only connect the first N
inputs where N is the number of physical inputs found by JACK
* fix grotesque error in use of STL reverse iterators
that messed up any use of AutomationList::truncate_end(),
causing horrible corruption of the control points.
* fix long-standing problems with region gain line visibility
(as-is, plus after-trimming)
* reimplement Route::_reset_plugin_counts() to use a slightly
simpler algorithm and allow zero-input plugins
("instruments") as the first in the chain
* fix problem with metering when using zero-input plugins
* fix problems with failed remove of redirects
* make region editor clocks insensitive at the right times
* store relative names in session file for connections,
allowing re-establishing internal connections when
connected to JACK using a different client name
* fix major thinko bug with Curve::spline_eval() that
caused a complete failure if the Curve had 0, 1
or 2 control points.
* Karsten's fixes for crossfades, plus a modified
version of his TimeAxisViewItem "selected" fix.
* automation track "controls context menu" now includes
"clear" and auto-state submenus, so that full control
even using a small track height is possible.
* require inserts/plugins to either be mono-input or match
the active streams at that point in the route. this
means you cannot insert a 2in plugin on a mono track
without a 1in/2out splitter preceding it.
we will change this in a future (post-2.0) version of
ardour so that the splitter is added automatically
in a hidden way.
* fix naming of sends/inserts to avoid duplications.
* removed redundant expansion arrow from TimeAxisView
* when a region overlaps another region but is wholly within
the other, create hidden, immutable 64-frame xfades
at both boundaries. (works, but some more work
needed on corner cases and thoroughly testing normal
overlap xfades)
* fix off-by-1 errors in drawing canvas rect objects
(affects rubber band selection, range selection and more)
* corrected off-by-1 error in position of fade out polygon
within regionviews
* expanded height of per-track selection rects to
full track height
* muted regions never write silence, whether they
are opaque or not.
* added "Mute" and "Unmute" to region ops menu
* fix bug in Editor::cursor_to_selection_{start,end} that
prevented the function from working in range mode
* delete AudioEngine at exit (and thus call jack_client_close())
* make "active" check menu item on mixer strip "name" context menu
be in correct state at startup
* popup error message if clone or copy of redirects fails
* prepend "!" to the displayed name of a muted region
* newly created regionviews follow the current "show waveforms"
setting
* relevant internal-overlap xfades are invalidated by layering changes
* all (relevant) xfades are invalidated by muting changes
* another almost-complete reimplementation of plugin count handling
- no visible changes intended
- we now compute counts before changing the counts
- if the configuration is impossible, things are left unchanged
- if the configuration is possible, we set the counts
- all failed reset_plugin_count() calls should leave
the redirect lists in their original state
* reimplement region layer changes to avoid visible "illegal" state
with two regions in the same layer
* fix bug with soloing that would cause solo states of
tracks|busses in the incorrect state if busses|tracks were
also soloed while a track|bus was un-soloed.
* make "active" check menu item in track controls context menu
be in correct state at startup
* use nick mainsbridge's brilliantly simple "later regions are
on higher layers" idea
* remove all explicit control over layering from ardour/gtk
* fix nasty thread/race condition bug when building peakfiles
for imported/embedded audio. two threads could be
reading from the same file at the same time, and under
some circumstances could stomp on each others activities.
* fix potential (suspected) race condition associated with
peakfile request submission and handling. may affect
some reported "hangs" when importing/embedding audio.
* actually use two-stage regionview creation (rects first,
waveforms later) by refactoring SndFileSource's use of
its primary mutex. makes regionviews
* fix attempt to access an illegal column of the file selector
in the library/file browser.
* add pthread id to "posix signal received" message
* require use of --new/-N flag to create new sessions from the
command line
* remove "exiting foo thread" and "stopping bar thread" messages
* from shutdown, don't kill the GUI thread if its not running
* add EnvelopeChanged Change to AudioRegion, playlist saves
state when this or *any* region change occurs. this fixes
a class of bugs where undo after a region was removed
fails to fully restore the region's state.
* remove debug output from Gtkmmext::NewSaveDialog
Hi all,
this comes somewhat late, but we are still happy to finally have the
proceedings of the last Linux Audio Conference (April 2004) online.
Short after the conference, we asked the speakers to send papers about their
talks so we could put together these proceedings. Well, collecting those
papers _after_ a conference was probably not such a good idea :-), but we
still got a fine small collection of 6 papers which we have then put together
into one PDF, together with a list of the all people who helped in making
the conference possible (sorry to anyone we might have forgotten).
Get it while it's still warm: http://on1.zkm.de/zkm/stories/storyReader$4477
A lot of thanks go out to those who wrote and submitted these papers!
Greetings,
The LAC organization team:
Götz Dipper
Matthias Nagorni
Frank Neumann
PS: On a sidenote, the OGG files of the presentations which were unavailable
for several weeks are now back online again:
http://www.linuxdj.com/audio/lad/contrib/zkm_meeting_2004/
Hi,
as the owner of a firewire audio card (Motu 828mkII) I was disappointed when
trying to use it under linux. Asking Motu to provide tech docs and/or linux
drivers is useless: "We will possibly release linux drivers in the future,
but we never release any kind of technical documentation."
Is there any effort to join forces for putting pressure on the manufacturers
yet? I am willing to create an address list ordered by audio card
manufacturer/model to make the manufacturers realize there is a need for
linux support.
Any comments?
Olaf
On Thursday 18 November 2004 14:01, derek holzer wrote:
> Of course, the Firewire subsystem for Linux works fine. But AFAIK there
> are no drivers existing for any firewire audio cards. Bug the various
> manufacurers to release more technical info and they might eventually
> show up.
>
> d.
>
> Victor LaLoggia wrote:
> > Hello Frank;
> >
> > Thank you for your response, and I do not mean to be contrary, but what
> > about the work the folks at http://www.linux1394.org/ are doing?
> >
> > I see that their subsystem has been included Linux kernel sources since
> > version 2.3.40. Does the subsystem not work?
> >
> > Thanks,
> > vic
> >
> > -----Original Message-----
> > From: Frank Barknecht <fbar(a)footils.org>
> > Sent: Nov 15, 2004 12:14 PM
> > To: linux-audio-user(a)music.columbia.edu
> > Subject: Re: [linux-audio-user] Using Linux Laptop for Live Performance
> >
> > Hallo,
> >
> > Victor LaLoggia hat gesagt: // Victor LaLoggia wrote:
> >> I am just beginning my research into the available software and
> >> hardware, and would greatly appreciate any information. Especially
> >> on hardware - what would be the best usb/ firewire interface for
> >> live performance?
> >
> > No Firewire audio yet on Linux. The best in your case is PCMCIA, which
> > has the lowest latency. VX-Pocket or RME cards are good choices. Also
> > try, if your internal soundcard is enough.
> >
> > Ciao
Hello,
I decided to give kernel 2.6.10 a try, so I installed it in combination
with Con Kolivas system system responsiveness patch. But when I try to
run the latencytest (0.5.5), I run into the following problem:
$ modprobe latency-test
WARNING: Error inserting rtc (/lib/modules/2.6.10-ck2-ck2-pentium4/kernel/drivers/char/rtc.ko): No such device
FATAL: Error inserting latency_test (/lib/modules/2.6.10-ck2-ck2-pentium4/misc/latency-test.ko): Unknown symbol in module, or unknown parameter (see dmesg)
$ dmesg
latency_test: Unknown symbol rtc_register
latency_test: Unknown symbol rtc_unregister
latency_test: Unknown symbol rtc_control
Any suggestion?
Maarten
Tom Szilagyi wrote:
>>Hey Tom,
>>
>>Attatched is a patch that creates a 1in / 2out version of TAP Stereo Echo. It would need a
>>new ladspa ID and better name possibly. Ardour now has a strict policy regarding plugin
>>connections, requiring a mono to stereo splitter to preceed TAP S.E. on a mono track. The
>>popular opinion with the ardour guys is that plugins be made available in various forms
>>instead of trying to make the host too complex or having to use combinations to acheive
>>the desired results.
>>
>>I can do the others as well, like reverberator, etc too if you would like.
>
>
> Hi,
>
> What if I released a stand-alone mono->stereo splitter plugin ASAP?
> That would solve this issue completely, no?
>
> Of course, users will have to explicitly use it, but if I agree to make split versions of
> all my stereo plugins, then 1) users still have to decide which one to use and 2) duplicated
> code to maintain arises (and many Ladspa ID-s get wasted) etc etc.
>
> OK, I see you wrote "having to use combinations to achieve the desired results" is ungood,
> but I still think this is a cleaner solution from an engineering p.o.v.
>
> So, what's your opinion? Splitter-plugin vs plugin-splitting? :)
At first I agreed that the splitter was the solution, and I wrote one,
only to find one already exists in the SWH package. The argument is
that this is clumsy and not an optimal solution. After hearing this
argument, it does seem like a cleaner, faster solution to have available
plugins in various connection formats instead of building the
connections from lego's. I am in no way an authority on this though, so
I am going to forward this to LAD, as I think it pertains to all the
plugin projects. There was recently a thread on ardour-dev regarding
connections and plugin counts that is probably going to start all over
again, but discussions are fun anyway, arent they? :)
Doug
--
http://nostar.net/
New to the group. Please forgive any unintended breaches of protocol.
I just built a house and had it prewired for stereo speaker pairs in 6
rooms / zones in addition to cat5 in each zone. My intention was to
purchase a
multisource / multizone audio system from a high end integrator. After
reviewing several options - Crestron and Niles primarily - I ended the
review dismayed
with the cost and overall approach of the "main stream" solution providers.
I'm a UNIX guy going back to 1983 - Altos8600 running a 5Mhz Intel 8086
with 512Kb RAM, 20Mb 8" Winchester hard drive and Microsoft's version of
Xenix.
I'm wondering if the present state of the Intel/AMD powered PC with
Linux is robust enough to control multiple sources (4, 6 or 8) like
digital cable box,
directv receiver, XM radio, CD player(s), etc. and route the output to
multiple zones/rooms (4, 6 or 8) in an effective and cost efficient manner.
The Crestron approach would cost me around $10K - so I've got some money
to invest on development if necessary.
Once again, my apologies if I've breached any list/group protocol with
this post.
Hi all,
just a short reminder: The deadline for paper, music etc. submission for the
3rd Linux Audio Conference (LAC, April 21st-24, 2005) is coming closer -
if you plan to hand in a paper, project note, composition, workshop topic
etc, be sure to send it off until
January 10th, 2005
Believe it or not, we have a tight time plan for the remaining time til
the conference, and we need that time for preparations - so we are not going
to accept material that gets sent in too late!
For more information, please see the web page at http://www.zkm.de/lac
Thanks,
The LAC05 organization team:
Goetz Dipper (ZKM)
Matthias Nagorni
Frank Neumann
PS: And please do not confuse this with the "LCA" that Conrad Parker is
organizing, also in April, however not in Germany, but on the other side
of the globe! :-)