Thread: [ReZound-users] Removing radio interference?
Status: Beta
Brought to you by:
ddurham
From: Steffen K. <kl...@do...> - 2003-07-01 18:48:40
|
Hi all, I'm not sure whether this is the right forum to ask this, but I want to restore recordings of classical music made from radio programmes that have, besides noise, bad interference effects. Is there any way of removing those with tools like ReZound? I'm quite ignorant when it comes to audio restoration, and I'm afraid it'll take a professional hand, but maybe one of you guys can give me a pointer. I've got a sample here: http://www.dotnet.org/rezound/radio-sample.html Thanks Steffen. |
From: R P. <rt...@ya...> - 2003-07-01 19:05:19
|
--- Steffen Kluge <kl...@do...> wrote: > Hi all, > I'm not sure whether this is the right forum to ask > this, > but I want to restore recordings of classical music > made from radio > programmes that have, besides noise, bad > interference effects. The degree to which you can remove undesirables can only be determined with trial and error. I think the tool you want to work with is the Arbitrary Fir Filter. Basic strategy is to highlite an area, setup an extreme filter apply the filter (to the highlite) roll the transport through unfiltered material and into the filtered material. That will tell you how much damage you're causing. Then you basically start refining the filter until you're satisfied that A the undesirables have been acceptably masked and B the damage isn't worse than having the undesirables. With some problems it's very possible to filter. For example digital clips. What distinguishes a clip from the problem you describe is that a clip could occur within a small fraction of one second. Within that small time space you can apply a very extreme filter. In your task it sounds like you'll be applying filters to very wide areas of the timeline and likely accross the entire timeline. Rezound is a good tool for this if your source is 16bit which all CD sources are. AFAIK, Rezound doesn't handle 24bit files. ron > Is there any way of removing those with tools like > ReZound? > I'm quite ignorant when it comes to audio > restoration, and I'm > afraid it'll take a professional hand, but maybe one > of you guys > can give me a pointer. > > I've got a sample here: > http://www.dotnet.org/rezound/radio-sample.html > > Thanks > Steffen. > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are > available now. > Download today and enter to win an XBOX or Visual > Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > ------------------------------------------------------- > ReZound-users mailing list > ReZ...@li... > Subscribe/Unsubscribe and change options > https://lists.sourceforge.net/lists/listinfo/rezound-users > ReZound-users mailing list archive > http://sourceforge.net/mailarchive/forum.php?forum=rezound-users __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
From: Davy D. <dav...@ar...> - 2003-07-02 15:56:19
|
On Tue, 2003-07-01 at 14:01, R Parker wrote: > Rezound is a good tool for this if your source is > 16bit which all CD sources are. AFAIK, Rezound doesn't > handle 24bit files. > Correct, at this point if you load a 24bit file audiofile should convert it to 16bit, but then you have lost that extra information. The file is editable, but with a reduction in quality. Sometime in the near future (post LADSPA, MAN I need to get to work on that) I'm going to make the native format 32bit floating point. Hence, editing a 24bit file and saving it will retain the quality. Something else needed is a dialog when saving files needs to be a choice of formats (bit rate, compression, etc). 'Save As' should bring up this dialog, just a 'Save' should use the same parameters that the loaded file had. My only hangups about 32bit floating point are 1) that the working files suddenly become twice as big 2) and hence processing takes longer because more disk I/O is required to work with the working files and float point math has to occur (however I think floating point arithmetic on an modern Intel processor (maybe AMD too, haven't tested it) is in general as fast as integer arithmetic.) Most of the actions that aren't trivial already use floating point math internally anyway though, so the conversion to and from ints is slowing us down already. I guess the file size is the biggest issue. -- Davy |
From: R P. <rt...@ya...> - 2003-07-03 00:41:02
|
--- Davy Durham <dav...@ar...> wrote: > On Tue, 2003-07-01 at 14:01, R Parker wrote: > > Rezound is a good tool for this if your source is > > 16bit which all CD sources are. AFAIK, Rezound > doesn't > > handle 24bit files. > > > > Correct, at this point if you load a 24bit file > audiofile should convert > it to 16bit, but then you have lost that extra > information. The file is > editable, but with a reduction in quality. > > Sometime in the near future (post LADSPA, MAN I need > to get to work on > that) I'm going to make the native format 32bit > floating point. Some of us in the JAMin (jamin.sourceforge.net) crowd are very interested in seeing this development. We're concerned with professional audio production. Rezound is an excellent user interface and combined with JAMin we have a very good professional audio mastering environment. Obviously 16bit will not make the grade. Hence, > editing a 24bit file and saving it will retain the > quality. > > Something else needed is a dialog when saving files > needs to be a choice > of formats (bit rate, compression, etc). 'Save As' > should bring up this > dialog, just a 'Save' should use the same parameters > that the loaded > file had. > > > My only hangups about 32bit floating point are > > 1) that the working files suddenly become twice as > big From my perspective the increased storage use is entirley irrelevant. > 2) and hence processing takes longer because more > disk I/O is required > to work with the working files and float point math > has to occur A jackd; rezound -> jamin -> ardour chain works for me but I have beefy hardware. This chain is less successful for those with more modest hardware. One of the JAMin guys did look at the Rezound realtime thread and commented that it needs to be worked on. I'm not qualified to tell you anything about that but he might be monitoring this thread. > (however I think floating point arithmetic on an > modern Intel processor > (maybe AMD too, haven't tested it) is in general as > fast as integer > arithmetic.) I have dual amd 2600+. > Most of the actions that aren't trivial already use > floating point math > internally anyway though, so the conversion to and > from ints is slowing > us down already. I guess the file size is the > biggest issue. File size might be an issue to people that aren't concerned with professional audio but for those of us who are it seems to be a no brainer. My conclusion for Rezound is it's a tool with great potential and if a couple core issues are worked out it'll become a very popular choice. I really like Rezound alot but for a good deal of my work, I won't be able to use it. Even though my mixes are good enough that most people wouldn't know I wasn't mastering in 24bit. Hmmm, maybe they're so bad people wouldn't notice. :) Hat's off to you Davy, I was thrilled the first time I fired up your app. ron > -- Davy > __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
From: Davy D. <dav...@ar...> - 2003-07-03 14:49:05
|
On Wed, 2003-07-02 at 19:41, R Parker wrote: > Some of us in the JAMin (jamin.sourceforge.net) crowd > are very interested in seeing this development. We're > concerned with professional audio production. Rezound > is an excellent user interface and combined with JAMin > we have a very good professional audio mastering > environment. Obviously 16bit will not make the grade. > Oh cool, I'll have to check that out. > > 2) and hence processing takes longer because more > > disk I/O is required > > to work with the working files and float point math > > has to occur > > A jackd; rezound -> jamin -> ardour chain works for me > but I have beefy hardware. This chain is less > successful for those with more modest hardware. One of > the JAMin guys did look at the Rezound realtime thread > and commented that it needs to be worked on. I'm not > qualified to tell you anything about that but he might > be monitoring this thread. > Yeah, the realtime issue shouldn't be too difficult to overcome. But it will require some work. > > Most of the actions that aren't trivial already use > > floating point math > > internally anyway though, so the conversion to and > > from ints is slowing > > us down already. I guess the file size is the > > biggest issue. > > File size might be an issue to people that aren't > concerned with professional audio but for those of us > who are it seems to be a no brainer. > I agree. I will still allow a choice (at least at compile time) of what the internal format will be for those who can't afford the extra disk usage. To allow a choice at runtime would be non-trivial, and I don't think it would be that beneficial. > My conclusion for Rezound is it's a tool with great > potential and if a couple core issues are worked out > it'll become a very popular choice. I really like > Rezound alot but for a good deal of my work, I won't > be able to use it. Even though my mixes are good > enough that most people wouldn't know I wasn't > mastering in 24bit. Hmmm, maybe they're so bad people > wouldn't notice. :) > > Hat's off to you Davy, I was thrilled the first time I > fired up your app. > Thanks, thanks.. I hope everyone can find it useful. And I do plan to get to these 'core issues' like you mention in due time. But time is the issue always anyway :) Thanks, Davy |
From: Jack O'Q. <jo...@io...> - 2003-07-03 16:45:35
|
Davy Durham <dav...@ar...> writes: > On Wed, 2003-07-02 at 19:41, R Parker wrote: > > > A jackd; rezound -> jamin -> ardour chain works for me > > but I have beefy hardware. This chain is less > > successful for those with more modest hardware. One of > > the JAMin guys did look at the Rezound realtime thread > > and commented that it needs to be worked on. I'm not > > qualified to tell you anything about that but he might > > be monitoring this thread. > > > Yeah, the realtime issue shouldn't be too difficult to overcome. But it > will require some work. I was the one having realtime problems with rezound. I work on the realtime scheduling parts of jamin. So, I tend to test at lower latencies and with higher system load than most other folks. I generally use alsaplayer as my test driver, since jamin does no file I/O. Alsaplayer is fairly reliable on my system down to -p128 or so. It will even run for a little while at -p32 which is about the limit of my hardware and software right now. I spent a little time looking at the alsaplayer source code a couple of months ago, but can't claim to really understand what's going on. The main paths look realtime-clean, but there are some odd corners that I suspect. This stuff is hard. I'm pretty sure we've got at least one realtime bug in jamin, too. It only shows up running overnight, and I have yet to track it down. I tried using rezound to drive jamin, instead of alsaplayer. On my system, it kept getting kicked out of the JACK graph even at fairly high latencies (-p1024). The test I run looks like this... rezound -> jamin -> alsa_playback Jamin is using a fair amount of CPU, mostly running Fourier Transforms. But, even at very low latencies, my CPU utilization is generally below 50%, with the JACK "CPU load" around 30% or less (an estimate of the time used by the whole JACK process cycle). My system is an AMD Athlon 1800+ XP uniprocessor with 256MB memory and an M-Audio Delta 66 audio card. I run Debian woody (mostly). The kernel is 2.4.19, with low latency and capabilities patches. I run JACK in realtime mode as an ordinary user, using capabilities. Looking at rezound sources, I found this comment in the process() callback... /* * I know the documentation said to avoid any indeterminate system * calles (which would include file i/o or dynamic allocation) But the * way I read sound data is by keeping it always on disk and caching * some in memory. And the way I see it, any access to memory could * page fault and cause disk access. (same goes for the recorder too) */ This is incorrect. When running in realtime mode, jack_activate() calls mlockall() for the client address space. After that, it will only fault on pages not already allocated. The trick is to carefully touch any storage allocated after that point if the process() callback touches it. If you do this right, there will be no page faults in the realtime code path. At low latencies, any such fault will be readily apparent, JACK will kick the client out. Rezound is a wonderful program. I'd love to see it used as part of a professional mastering chain. For that, it appears to need some serious realtime work. This is specialized programming, with rules unlike those for almost any other user-level application code. Kernel device driver interrupt handlers are the closest analogy. I am familiar with most of these issues due to my recent work on jamin. I would be glad to help with design discussions, testing, even some code, if you want tackle this, Davy. Regards, -- Jack O'Quin Austin, Texas, USA |
From: Davy D. <dav...@ar...> - 2003-07-03 17:47:56
|
On Thu, 2003-07-03 at 11:45, Jack O'Quin wrote: > This is incorrect. When running in realtime mode, jack_activate() > calls mlockall() for the client address space. After that, it will > only fault on pages not already allocated. The trick is to carefully > touch any storage allocated after that point if the process() callback > touches it. If you do this right, there will be no page faults in the > realtime code path. At low latencies, any such fault will be readily > apparent, JACK will kick the client out. > Sheesh, that's a pain. :-/ (but necessary I guess) It still seems as though, in theory, that it might not be possible to hold in physical RAM what you need (unlikely, but theoretically possible I guess). Of course there needs to be a reasonable amount of hardware capabilities for jack to run properly. Is page swapping a real issue? Can you even know all the memory pages that need to be swapped in? What about code pages? I'm sure all of this has been discussed on the jack lists so this is probably not the time to discuss such issues (and I'm not prepared/qualified at this point to do so). > Rezound is a wonderful program. I'd love to see it used as part of a > professional mastering chain. For that, it appears to need some > serious realtime work. This is specialized programming, with rules > unlike those for almost any other user-level application code. Kernel > device driver interrupt handlers are the closest analogy. I am > familiar with most of these issues due to my recent work on jamin. > > I would be glad to help with design discussions, testing, even some > code, if you want tackle this, Davy. Yes, thank you. And ReZound is already pretty much set up (I think) to work properly with jackd, but not just yet completely set up for it. ReZound is threaded. There is a main thread, and a thread for every sound loaded (src/backend/CSoundPlayerChannel). And depending on the audio output implementation there may even be another thread running for audio output (OSS has a thread constantly writing to the open file descriptor, except it's most of the time in a wait-state in the write() system call) The thread for every sound loaded is constantly prebuffering data to be played (if the sound is in a playing state of course), writing that to a TMemoryPipe using the blocking write() method (which uses pthread rwlocks to nicely put the writing thread into a real wait-state) The other end of the pipe is being read every time CSoundPlayerChannel::mixOntoBuffer() is called... I simply call that from jack's call back method. I'm doing a call to TMemoryBuffer's read() method, but only after having peeked to see if any data was available so it shouldn't block. And I also already removed a call to a mutex lock to get some routing information by just saving a copy of that routing information and parallel it to the prebuffered audio when I wrote it to the TMemoryPipe. The issue now is a mutex lock on chunkObjectsMutex in CSoundPlayerChannel::mixOntoBuffer() which protects the memory allocated holding the prebuffered data from being deallocated by another thread while mixOntoBuffer is running. This could probably be changed to try-lock to avoid that indeterminism, yet a gap in the audio would result. However, this should not be a problem because the only time the other thread locks that mutex in order to deallocate that memory is on cleanup and whenever the number of channels in the audio file changes. So it's a rare occurance and probably won't happen while you're actually playing sound. Of course it still remains to somehow lock those pages of memory (holding the prebuffered data) from being swapped, but that memory is being allocated in only one places and whatever needs to be done to lock it into RAM can be done there (CSoundPlayerChannel::createPrebufferChunks() ). That's what I can think of off the top of my head without looking back at the code too much. And there may be something major that I've neglected. The research should begin at CJACKSoundPlayer::processAudio() and trace backwards. But I'm just glad I threaded the audio output the way I did because that should make it easy to simply make that smaller audio processing path on the unbuffering side realtime-safe and not all the code. -- Davy |
From: Jack O'Q. <jo...@io...> - 2003-07-06 17:17:06
|
Davy, I'm going on a two week vacation in a few days. I don't have time to study your code in enough detail right now to be useful. But, I want to respond to the design ideas in your earlier message before leaving. Davy Durham <dav...@ar...> writes: > On Thu, 2003-07-03 at 11:45, Jack O'Quin wrote: > > This is incorrect. When running in realtime mode, jack_activate() > > calls mlockall() for the client address space. After that, it will > > only fault on pages not already allocated. The trick is to carefully > > touch any storage allocated after that point if the process() callback > > touches it. If you do this right, there will be no page faults in the > > realtime code path. At low latencies, any such fault will be readily > > apparent, JACK will kick the client out. > > > Sheesh, that's a pain. :-/ (but necessary I guess) It still seems as > though, in theory, that it might not be possible to hold in physical RAM > what you need (unlikely, but theoretically possible I guess). Of course > there needs to be a reasonable amount of hardware capabilities for jack > to run properly. Is page swapping a real issue? Can you even know all > the memory pages that need to be swapped in? What about code pages? Yes, it *is* a pain, and easy to get wrong. For realtime, you have to be willing to dedicate the needed hardware resources to do the job. If you do not have enough, the best you can do is report that fact quickly and clearly. The mlockall() system call goes to the Virtual Memory manager in the kernel. It knows *all* the pages allocated to your address space, including code. That's its job. :-) The only catch is what I call "first reference faults". These occur for pages that have not yet been allocated to the process. When they are touched, usually after a malloc() or sbrk() call, the VM manager will allocate an empty page frame full of zeroes. Since this could end up waiting for page outs before an empty frame becomes available, it is a realtime bug if it happens in the JACK process() thread. The jack_activate() function touches a large number of stack pages while creating the process() thread, to avoid first reference faults in the call/return stack. So, you don't need to worry about that. But, if you malloc() any storage that will be used by the process() callback, you must touch all the pages in the allocating thread *before* process() sees them. Using memset() or bzero() on the newly allocated space is sufficient. > The thread for every sound loaded is constantly prebuffering data to be > played (if the sound is in a playing state of course), writing that to > a TMemoryPipe using the blocking write() method (which uses pthread > rwlocks to nicely put the writing thread into a real wait-state) Beware of pthread locks. You have to be careful to avoid waiting on locks held by non-realtime threads. Even short-duration locks can cause trouble due to "priority inversion". If a SCHED_FIFO thread waits on a SCHED_OTHER thread, it can be delayed indefinitely when the kernel scheduler finds other higher-priority processes to dispatch, instead. This is why lock-free ringbuffers are so popular for realtime audio programming. They allow a single reader thread to gather data from a single writer thread without using locks. There is a C implementation in the JACK example-clients directory, used by capture_client. It is based on the C++ implementation, in the ardour sources. You may want that, instead. > The other end of the pipe is being read every time > CSoundPlayerChannel::mixOntoBuffer() is called... I simply call that > from jack's call back method. I'm doing a call to TMemoryBuffer's > read() method, but only after having peeked to see if any data was > available so it shouldn't block. And I also already removed a call to a > mutex lock to get some routing information by just saving a copy of that > routing information and parallel it to the prebuffered audio when I > wrote it to the TMemoryPipe. Sounds good. > The issue now is a mutex lock on chunkObjectsMutex in > CSoundPlayerChannel::mixOntoBuffer() which protects the memory allocated > holding the prebuffered data from being deallocated by another thread > while mixOntoBuffer is running. This could probably be changed to > try-lock to avoid that indeterminism, yet a gap in the audio would > result. However, this should not be a problem because the only time the > other thread locks that mutex in order to deallocate that memory is on > cleanup and whenever the number of channels in the audio file changes. > So it's a rare occurance and probably won't happen while you're actually > playing sound. I'd probably go with pthreads_mutex_trylock(). My philosophy on underruns is that a gap in the output, while bad, is better than blowing the realtime deadline. That gets you kicked out, and stops the show. The gap probably means you needed a bigger buffer. If you think of the process() thread as "hardware" from the perspective of the other threads, it makes sense. > Of course it still remains to somehow lock those pages of memory > (holding the prebuffered data) from being swapped, but that memory is > being allocated in only one places and whatever needs to be done to lock > it into RAM can be done there > (CSoundPlayerChannel::createPrebufferChunks() ). All you have to do is touch the pages allocated, as descibed above. You may be doing that already. But, make sure you do it in some non-realtime thread. > That's what I can think of off the top of my head without looking back > at the code too much. And there may be something major that I've > neglected. The research should begin at > CJACKSoundPlayer::processAudio() and trace backwards. But I'm just glad > I threaded the audio output the way I did because that should make it > easy to simply make that smaller audio processing path on the > unbuffering side realtime-safe and not all the code. Yes, that is helpful. Yet, there are still many tricky issues with using multiple threads. Regards, -- Jack O'Quin Austin, Texas, USA |
From: Jack O'Q. <jo...@io...> - 2003-07-02 19:18:25
|
Davy Durham <dav...@ar...> writes: > Sometime in the near future (post LADSPA, MAN I need to get to work on > that) I'm going to make the native format 32bit floating point. Hence, > editing a 24bit file and saving it will retain the quality. > My only hangups about 32bit floating point are > > 1) that the working files suddenly become twice as big > 2) and hence processing takes longer because more disk I/O is required > to work with the working files and float point math has to occur I think this is a very good idea. Many current audio cards have 24-bit resolution. JACK encourages applications to exchange audio using float values. Most PC processors do floating point calculations very quickly these days. As you say, disk overhead is the main disadvantage. And that is less of a problem than it used to be. Providing options to save at other resolutions handles this problem adequately. And, libsndfile supports almost any file format you could ever want to use. -- Jack O'Quin Austin, Texas, USA |
From: Davy D. <dav...@ar...> - 2003-07-02 20:31:27
|
On Wed, 2003-07-02 at 14:17, Jack O'Quin wrote: > > As you say, disk overhead is the main disadvantage. And that is less > of a problem than it used to be. Providing options to save at other > resolutions handles this problem adequately. And, libsndfile supports > almost any file format you could ever want to use. Yes, but when I mentioned disk I/O, I'm referring to the working file that it creates while your editing. All the operations on it will take some bit longer since the temporary working files will be larger. Sure, if someone wants to save a .wav as 24bit it's going to obviously take more space for them. |
From: Davy D. <dd...@ne...> - 2003-07-02 00:03:42
|
Also, have you tried: http://gwc.sourceforge.net I have been dicussing moving the gwc functionality into ReZound at some point, but haven't been focusing on that at the moment. Maybe in the future though. Steffen Kluge wrote: >Hi all, >I'm not sure whether this is the right forum to ask this, >but I want to restore recordings of classical music made from radio >programmes that have, besides noise, bad interference effects. > >Is there any way of removing those with tools like ReZound? >I'm quite ignorant when it comes to audio restoration, and I'm >afraid it'll take a professional hand, but maybe one of you guys >can give me a pointer. > >I've got a sample here: http://www.dotnet.org/rezound/radio-sample.html > >Thanks >Steffen. > > > > >------------------------------------------------------- >This SF.Net email sponsored by: Free pre-built ASP.NET sites including >Data Reports, E-commerce, Portals, and Forums are available now. >Download today and enter to win an XBOX or Visual Studio .NET. >http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 >------------------------------------------------------- >ReZound-users mailing list >ReZ...@li... >Subscribe/Unsubscribe and change options >https://lists.sourceforge.net/lists/listinfo/rezound-users >ReZound-users mailing list archive >http://sourceforge.net/mailarchive/forum.php?forum=rezound-users > > > |
From: Marc R.J. B. <mr...@dn...> - 2003-07-02 12:14:33
|
On 2 Jul 2003, Steffen Kluge wrote: > I want to restore recordings of classical music made from radio > programmes that have, besides noise, bad interference effects. > > Is there any way of removing those with tools like ReZound? Thanks for including a link to a sample in your question, really helped to clarify the matter. Removing the noise shouldn't be too much of a problem, although currently Rezound does not (yet) have a noise reduction module. To clean the noise, you have a few options. Davy already mentioned the gnu wave cleaner (gwc.sourceforge.net), which is probably your best bet, another possibility is cooledit 96 running under wine (search the web for c96setup.exe). The radio interference is an undesirable of a different nature, being audible mostly in higher volume levels rather than lower ones. I'm not aware of a known technique to resolve this, but I'll take a look at the wave form, maybe I can come up with some useful suggestions. grtz MRJB |