Topic: Native JRiver 64bit fp convolution engine for Room Correction (FIR filters)? (Read 340404 times)

TheLion · « **on:** December 31, 2011, 08:30:09 am »

Christmas is past us and my biggest (JRiver related) wish remains unfullfilled - a high quality convolution engine with tight integration with JRiver MC. In my experience there is no such solution available today.

Many of us use "digital room correction" in form of FIR filters generated by applications such as DRC, Audiolense, Dirac Live or Acourate. I am an Audiolense user myself. I have been using the convolverVST plugin to do the convolution. But this solution is far from being great.

For once I am not aware of any multichannel convolution VST plugin that does 64bit fp processing (convolver is limited to 32fp, and there has not been any development since 2006 (!)). If there ever was a reason for a full 64bit fp pipeline it is convolution of highly complex 65k/130k taps FIR filters.

With MC now integrating "room correction" and a great "Parametric Equalizer" a convolution engine with full 64bit fp processing would be the next/final step. It would also make JRiver THE choice for everybody with "digital room correction". Because, I can tell you, no matter if you look into Audiolense or Acourate Newsgroups - the lack of a proper convolution engine is a main topic. Many giving up on that topic entirely and build dedicated LINUX convolution PCs with bruteFIR...

Matt, I am not sure how much effort such a convolution engine integrated with your great 64bit fp audio engine would be. But the idea of it combined with your idea of making Media Center's audio engine act as a "virtual soundcard" would be a small revolution in the market!

Thank you very much for your consideration! Have a successful year 2012!

Matt · « **Reply #1 on:** December 31, 2011, 10:00:06 am »

Quote from: TheLion on December 31, 2011, 08:30:09 am

Matt, I am not sure how much effort such a convolution engine integrated with your great 64bit fp audio engine would be.

I think the math behind convolution (FIR filters) is simple, unless there's some complexity I'm not aware of.

Here's a nice overview:
http://www.songho.ca/dsp/convolution/convolution.html

FIR filters are the building blocks of the predictor stage of lossless audio compressors, so I've done my share of monkeying with them.

But I've never experienced good results playing with existing convolution systems for listening. Maybe it can only work if you actually do measurements, but it seems like I should be able to load a sample configuration file and hear something that sounds promising. Any tips?

Also, do you know how to convert from the impulse WAV file to a set of convolution coefficients?

TheLion · « **Reply #2 on:** December 31, 2011, 10:39:09 am »

Matt,

thank you so much for your interest!

If you want some sample FIR filters made (basically WAV files with the convolution data and a configuration file for multi channel setup and XOs) I can recommend Audiolense demo (http://www.juicehifi.com/index.html). All you need is some measurement mic (preferably with correction file) and an ASIO mic pre-amp. Then you record the impuls Wav file, which gets filtered by Audiolense to give you an proprietary measurement file. Audiolense is very simple to use. If you have done your measurement and using default TTDC procedure with flat target you will have your first FIR convolution files (in WAV format) in 5 minutes.

Then you have test files to really appreciate what FIR filters are doing. To get the convolution done with the highest possible precision is the important final task - and that's where you come in. I know you have been in contact with Bernt (developer of Audiolense) before - he is very helpful and very much aware of the fact that convolution per convolverVST is a compromise. I am sure he will be delighted to see your interest and will support you with everything he can. It is in his best interest as well to not rely on a 6 year old VST plugin that's not being developed anymore and doesn't run at the precision of the Media Center audio engine.

Another contact is Dr. Ulrich Brüggemann, developer of Acourate (http://www.acourate.com/). I am talking to him regularly lately about convolution and I think he too would be delighted to get multichannel 64fp convolution tightly integrated into MC.

If I can support you in any way - I am all yours!

TheLion · « **Reply #3 on:** December 31, 2011, 10:41:15 am »

btw the last time I was so excited about the prospect of a new feature for Media Center was when I suggested madVR support - and look how that turned out

Without opening a can of worms - if you have ever experienced "proper digital room correction" (Audiolense, Acourate, DRC,...) there is NO way going back. It is a humbling experience. And I was very critical myself coming from "mass market automatic consumer solutions" like Audyssey. This is something very different giving the right tools to build these filters.

Matt · « **Reply #4 on:** December 31, 2011, 10:59:52 am »

How do you scale the impulse filters for different sample rates? Since they're all done in the time domain, it seems like you'd need different filters for different sample rates. Or maybe you only use one sample rate for everything?

TheLion · « **Reply #5 on:** January 01, 2012, 06:58:20 am »

Matt,

sure, I "need" different filters for different sample rates. MC's resampling is good but I still very much prefer playing content in its native sample rate. But the way you describe it is also possible - building a eg. 96khz filter and resampling all content to that sample rate (which is VERY comfortable with MC). It works but isn't optimal.

I do the impuls measurements in all 6 viable sample rates (44.1khz all the way up to 192khz). Based in those measurements I build filters for each sample rate (you can also build all filters based on eg. a single 96khz measurement - the only difference being in the high-end rolloff). A basic comfort function with any convolution engine is to autoselect the appropriate filter based on input sample rate.

So basically you get a filter bank of 6 convolution wav files to suit all content. You scale the input filters when you eg. save a filter in Audiolense - there you choose one or more sample rates for filter output.

TheLion · « **Reply #6 on:** January 01, 2012, 08:17:31 am »

Matt,

Audiolense Demo is propably the easiest und fastest way to get FIR filter files for test purposes. An open source alternative is Denis Sbragion's excellent DRC (http://drc-fir.sourceforge.net/) and and Simple Automated IR Measuring Tool by Denis Sbragion and Edward Wildgoose for creating the impulse response files needed by DRC (http://www.duffroomcorrection.com/wiki/Simple_Automated_IR_Measuring_Tool).

TheLion · « **Reply #7 on:** January 01, 2012, 12:40:35 pm »

Matt,

I sent you a personal message you might be very interested in! Thank you.

mojave · « **Reply #8 on:** January 01, 2012, 06:24:24 pm »

Quote from: TheLion on December 31, 2011, 10:41:15 am

btw the last time I was so excited about the prospect of a new feature for Media Center was when I suggested madVR support - and look how that turned out

Things sometimes take time here.

They had already been working on madVR support for 11 months because I requested it in January, 2010.

I agree that convolution support has a great potential for increased sales for JRiver. I have tried Voxengo Pristine Space (8 Channel Convolution VST plugin) with Audiolense and it worked at the time. However, that was several years ago and Pristine Space hasn't been updated since 2008.

TheLion · « **Reply #9 on:** January 02, 2012, 02:13:15 am »

You win

Matt · « **Reply #10 on:** January 02, 2012, 10:31:13 am »

I'm going to move this to the public board. Please feel free to contact or involve any interested parties.

We'll use this thread to gauge the general interest in native convolution support in DSP Studio.

It would also be helpful for me to have a technical description of how you convert from a WAV / impulse file to a set of FIR coefficients. Is it as simple as using each sample in the WAV file as a coefficient, starting with sample 0 and working up to the length of the filter? Is there any cross-channel communication, and if so, how is that handled?

Thanks.

jmone · « **Reply #11 on:** January 02, 2012, 10:58:23 am »

Quote from: mojave on January 01, 2012, 06:24:24 pm

Things sometimes take time here. They had already been working on madVR support for 11 months because I requested it in January, 2010.

Ha! Newbie, how about April 2009 http://yabb.jriver.com/interact/index.php?topic=51430.0

lasker98 · « **Reply #12 on:** January 02, 2012, 11:36:57 am »

+1 on the native convolution support. I think it would be a fantastic addition. Just searching for "convolver" through the forum shows how many issues have been related to convolver.

Bill

)p( · « **Reply #13 on:** January 02, 2012, 11:57:32 am »

+1 For a native convolver. I use prestine space now in jrmc with filters generated with drc.

Trumpetguy · « **Reply #14 on:** January 02, 2012, 02:20:41 pm »

+1 for native convolution support!
Mr Audiolense himself (Bernt) recommends MC for its superb audio/video and configuration qualities. But Audiolense filters pr today is relying on a no longer in development convolution engine. Native support is an excellent idea!

AudioVero · « **Reply #15 on:** January 02, 2012, 02:54:14 pm »

Quote from: Matt on December 31, 2011, 10:00:06 am

I think the math behind convolution (FIR filters) is simple, unless there's some complexity I'm not aware of.

Here's a nice overview:
http://www.songho.ca/dsp/convolution/convolution.html

Hello Matt,

the basic maths IS pretty simple. Just multiplications and additions.
BUT: if you try to compute long filters (e.g. 65536 taps or even more) then the CPU load will be heavy.
So the solution is to apply a Fast Fourier Transformation. With FFT the convolution process is just a vector multiplication. Then you apply an inverse FFT and get the result back in the time domain.
BUT: also a FFT convolution has its obstacles. Especially if you try to get a low CPU load (to avoid bad influences by CPU jitter) AND still get a low latency. Typically you need to use a buffer (FFT package size), this means you have to collect samples. This causes latency. If the package is too small, then the CPU lod can rise quickly. If the package size is too big, then you get a big latency.
Today there are also zero latency algorithms, but the have to organize a lot of threads with package sizes of different lengths.

If you read about the efforts carried out with Brutefir, see http://www.ludd.luth.se/~torger/brutefir.html, you will get an idea about. You may furthermore start to analyze JConvolver, see http://kokkinizita.linuxaudio.org/papers/aella.pdf or http://kokkinizita.linuxaudio.org/papers/aella-pres.pdf or even the source code, as a zero latency convolver.

You clearly need for each samplerate its own filter according to it. A program like VSTConvolver is working nice but lacks of the automatic switch between music sources with changing samplerates.

In addition you will find fore sure users who like to switch between filter banks for comparison of filters, e.g. blind tests.

And of course you will find requirements where people like to apply multiway solutions = multiple outputs from a single input. Or they like to apply combinations of filtering jobs e.g. filter the left channel and add a filtered right channel. Something like crosstalk cancellation or crosstalk introduction (headphone listening).

So e.g. with a 3-way stereo system and 3 filterbanks and 6 possible samplerates you already have to deal with 108 filter kernels of size 512 kB (65536 taps double precision coefficients) and even more.

Anyway the question brought up by TheLion is interesting and challenging. And there must be some basic program structure. In case of a fixed size partitioned convolution the plugin may read data from two buffers and write to two buffers (bufferswitch) like already known from ASIO interfaces. Of course the plugin must know also about the actua samplerate and the filters to apply. In case of non-partitioned convolution the data stream and the buffer switching will be more complex.

Just as some first comments. Simple solutions are available but users like TheLion will complain about for sure

Uli
www.audiovero.de

nilbor · « **Reply #16 on:** January 02, 2012, 03:08:49 pm »

+1 for this natively supported

JimH · « **Reply #17 on:** January 02, 2012, 03:19:05 pm »

Audiovero. Nice first post! Thanks!

TheLion · « **Reply #18 on:** January 02, 2012, 03:43:25 pm »

Dear Uli,

thank you very much for taking time to participate here. When native JRiver convolution really comes to be I sincerely hope that feature makes many JRiver customers become curious about the potential of FIR based digital room correction.

I can strongly recommend giving applications like your Acourate a try. Hearing your system the first time with linearized frequency response and accurate time domain behaviour is truely an eye opening experience. I will go as far as saying that true "high end" playback is hardly possible without applying such means. And that's what JRiver MC is all about, isn't it ;-)

Matt · « **Reply #19 on:** January 02, 2012, 03:54:53 pm »

Thanks AudioVero for the nice post. Some questions inline:

Quote from: AudioVero on January 02, 2012, 02:54:14 pm

the basic maths IS pretty simple. Just multiplications and additions.
BUT: if you try to compute long filters (e.g. 65536 taps or even more) then the CPU load will be heavy.
So the solution is to apply a Fast Fourier Transformation. With FFT the convolution process is just a vector multiplication. Then you apply an inverse FFT and get the result back in the time domain.
BUT: also a FFT convolution has its obstacles. Especially if you try to get a low CPU load (to avoid bad influences by CPU jitter) AND still get a low latency. Typically you need to use a buffer (FFT package size), this means you have to collect samples. This causes latency. If the package is too small, then the CPU lod can rise quickly. If the package size is too big, then you get a big latency.
Today there are also zero latency algorithms, but the have to organize a lot of threads with package sizes of different lengths.

So setting aside performance considerations, is time based convolution better than frequency based convolution (FFT + iFFT)?

Also, could you step me through the basic flow when using FFT + iFFT? This is how I have it in my head, but I'm still feeling around in the dark:

Code: [Select]

Imagine a window of 1024 samples (so 512 FFT frequencies).

Let's say we keep the results of the last 4 FFT runs (so only 4096 samples): FFT[0], FFT[1], FFT[2], FFT[3]

We would accumulate samples until we have 1024 samples, then process a block using pseudo-code like:

// roll previous FFT results back
FFT[3] = FFT[2]
FFT[2] = FFT[1]
FFT[1] = FFT[0]

// perform FFT on current window
FFT[0] = PerformFFTOnCurrentSamples

// convolute
for (int window = 0; window < 4; window++)
    for(int frequency = 0; frequency < 512; frequency++)
        FFTOutput[frequency] += FFT[window][frequency] * [Constant From Impulse File]

// iFFT to return to time domain
iFFT(FFTOutput) to get output samples

Quote

You clearly need for each samplerate its own filter according to it. A program like VSTConvolver is working nice but lacks of the automatic switch between music sources with changing samplerates.

In addition you will find fore sure users who like to switch between filter banks for comparison of filters, e.g. blind tests.

And of course you will find requirements where people like to apply multiway solutions = multiple outputs from a single input. Or they like to apply combinations of filtering jobs e.g. filter the left channel and add a filtered right channel. Something like crosstalk cancellation or crosstalk introduction (headphone listening).

So e.g. with a 3-way stereo system and 3 filterbanks and 6 possible samplerates you already have to deal with 106 filter kernels of size 512 kB (65536 taps double precision coefficients) and even more.

I don't think handling filter bank switching or sample rate switching would be technically hard. It's more of a user interface issue.

TheLion · « **Reply #20 on:** January 02, 2012, 04:03:27 pm »

Quote from: AudioVero on January 02, 2012, 02:54:14 pm

Just as some first comments. Simple solutions are available but users like TheLion will complain about for sure

Completely uncalled for...

jmone · « **Reply #21 on:** January 02, 2012, 04:29:26 pm »

Dumb Q, what does this do for us?

Hendrik · « **Reply #22 on:** January 02, 2012, 04:31:25 pm »

Quote from: jmone on January 02, 2012, 04:29:26 pm

Dumb Q, what does this do for us?

You know those functions on your AV Receiver using the small mic to "measure" your room and tune the audio to that? That, if done right in a better quality i imagine.
The hard part is the measuring and calculation, not the actual filtering, FWIW.

BradC · « **Reply #23 on:** January 02, 2012, 04:31:54 pm »

+1 for native convolution

jmone · « **Reply #24 on:** January 02, 2012, 04:42:05 pm »

Quote from: nevcairiel on January 02, 2012, 04:31:25 pm

You know those functions on your AV Receiver using the small mic to "measure" your room and tune the audio to that? That, if done right in a better quality i imagine.
The hard part is the measuring and calculation, not the actual filtering, FWIW.

Thanks. Got it, and given Matt's anti receiver passion I'm sure the lion will be pleased!

AoXoMoXoA · « **Reply #25 on:** January 02, 2012, 04:54:34 pm »

+1 for native convolution

J-a-k-e · « **Reply #26 on:** January 02, 2012, 05:28:42 pm »

As someone who's new to this I Hope I don't sidetrack the thread too much here. Can anyone here point me in the right direction as far as a measuring device goes, I'm assuming we're talking about essentially a high quality dynamic microphone for the computer? I have a decent desktop microphone here with a usable frequency response of up to 8khz although I know I'd have to be joking if I even began to think that this would make for a usable substitute.

hulkss · « **Reply #27 on:** January 02, 2012, 10:58:01 pm »

Quote from: J-a-k-e on January 02, 2012, 05:28:42 pm

Can anyone here point me in the right direction as far as a measuring device goes

I have been using digital XO, multi-amped speakers, and digital room and/or speaker correction solutions for many years. These solutions offer such vast improvements in audio quality that you can not go back once you hear a good implementation.
I use an Earthworks M30 microphone (http://www.earthworksaudio.com/our-microphones/m-series/m30/
and a Rane MS 1S Mic PreAmp http://www.rane.com/ms1s.html#gpm1_1
It is critical that your measurement mic has good behavior in the time domain.
The amplified mic signal is digitized by a Lynx Aurora converter http://www.lynxstudio.com/product_section.asp?i=1

Just to keep some perspective, I'm sure the audibility of errors caused by cheap measurement hardware greatly exceed the difference between 32 and 64 bit processing of the FIR filters.

I definitely would like to see a good stable low latency convolver solution. I'm getting by OK with ConvolverVST since MC supports video delay to match the audio

. For sure I need to develop a set of low latency filters to make game play possible.

jdubs · « **Reply #28 on:** January 03, 2012, 12:26:57 am »

A BIG +1 for native convolution support!! This would be huge for the audiophile community.

Jim

TheLion · « **Reply #29 on:** January 03, 2012, 12:59:08 am »

Quote from: J-a-k-e on January 02, 2012, 05:28:42 pm

As someone who's new to this I Hope I don't sidetrack the thread too much here. Can anyone here point me in the right direction as far as a measuring device goes, I'm assuming we're talking about essentially a high quality dynamic microphone for the computer? I have a decent desktop microphone here with a usable frequency response of up to 8khz although I know I'd have to be joking if I even began to think that this would make for a usable substitute.

To extend on what Hulkss suggested: Of prime importance is using a ->calibrated<- omnidirectional mic and a decent mic-preamp with ASIO driver. Calibrated means that the mic has been measured against a reference and correction tables to its frequency response are delivered with it. This brings to results of any decent mic (a Behringer ECM8000 will suffice if calibrated) in the ballpark of each other.

hulkss · « **Reply #30 on:** January 03, 2012, 01:15:05 am »

Quote from: TheLion on January 03, 2012, 12:59:08 am

To extend on what Hulkss suggested: Of prime importance is using a ->calibrated<- omnidirectional mic and a decent mic-preamp with ASIO driver. Calibrated means that the mic has been measured against a reference and correction tables to its impuls response are delivered with it. This brings to results of any decent mic (a Behringer ECM8000 will suffice if calibrated) in the ballpark of each other.

I have only seen frequency response correction tables for a mic like the ECM8000. Where can a person get correction files for phase response?

TheLion · « **Reply #31 on:** January 03, 2012, 01:28:55 am »

Quote from: hulkss on January 03, 2012, 01:15:05 am

I have only seen frequency response correction tables for a mic like the ECM8000. Where can a person get correction files for phase response?

I certainly meant frequency response correction tables ;-)

How do you apply your FIR filters for general audio streams (WDM/DirectX streams like your mentioned computer games -> not that I would insist on using it for such ;-))?

hulkss · « **Reply #32 on:** January 03, 2012, 01:52:51 am »

Quote from: TheLion on January 03, 2012, 01:28:55 am

I meant frequency response correction tables ;-) How do you apply your FIR filters for general audio streams (WDM/DirectX streams like your mentioned computer games)?

Good time domain behavior is why I bought the Earthworks M30.

In the past I used DEQX processors to apply FIR filters. Now with JR Media Center I'm going to try to play a PS3 into a Hauppauge Colossus video capture card. For computer games you can setup a stand-alone FIR filter host using soft water like:

Virtual Audio Cable: http://software.muzychenko.net/eng/vac.htm#features
ASIO4ALL: http://www.asio4all.com/
Bidule: http://www.plogue.com/?page_id=56
SAVIHost: http://www.hermannseib.com/english/savihost.htm
Console: http://console.jp/en/about/about_1.html
Jack: http://jackaudio.org/jack_on_windows
AudioMulch: http://www.audiomulch.com/

Trumpetguy · « **Reply #33 on:** January 03, 2012, 02:12:26 am »

Quote from: J-a-k-e on January 02, 2012, 05:28:42 pm

As someone who's new to this I Hope I don't sidetrack the thread too much here. Can anyone here point me in the right direction as far as a measuring device goes, I'm assuming we're talking about essentially a high quality dynamic microphone for the computer? I have a decent desktop microphone here with a usable frequency response of up to 8khz although I know I'd have to be joking if I even began to think that this would make for a usable substitute.

I would not recommend taking shortcuts on the measurement side. Aside from physical acoustik treatment of your room, the measurement itself is the most challenging step when doing digital room correction. You will need a calibrated mic+mic preamp, as well as a very low latency audio output/input device. I was using M-AUDIO Mobilepre earlier (=affordable), but got hickups in the sine sweeps. Also, someone told me that this device is not sufficiently frequency linear for room calibration. I now use EMM mic and pre-amp from IBF Akustik (http://www.content.ibf-acoustic.com/catalog/product_info.php?cPath=30&products_id=35). The set is calibrated to adjust for nonlinearity both in the preamp and mic. I use a LynxTwoB for ASIO audio sweeps in/out, and Audiolense software as sine generator and recorder (I guess REW is a good alternative). Works really fine.

TheLion · « **Reply #34 on:** January 03, 2012, 04:19:12 am »

I agree. I am using a simular mic from IBF Akustik (http://www.content.ibf-acoustic.com/catalog/product_info.php?cPath=21_23&products_id=59) and use my Prism Orpheus as mic pre-amp.

To get best possible measurement data is the basis for any good filter.

Trumpetguy · « **Reply #35 on:** January 03, 2012, 05:20:59 am »

Quote from: hulkss on January 03, 2012, 01:15:05 am

I have only seen frequency response correction tables for a mic like the ECM8000. Where can a person get correction files for phase response?

You can't just get calibration tables for a given mic, that would be a contradiction in terms. Calibration means just that a specific microphone needs to be calibrated using measurement equipment of sufficiently high precision. E.g. if you want to know the measured response of a certain mic at different frequencies, your requirement would be to know the response within +/-0.1dB. You would then need to put your mic into an anechoic chamber and impose a sound with known energy (sound pressure) at given frequencies, and you would need to know the imposed energy at typically 10 times the precision of the calibration precision (i.e. 0.01dB). This is usually performed by professionals. IBF Akoustik does this at a reasonable price, I am sure there are others too. You would need to either buy their kit (it comes with the calibration table on a floppy disk!!!!), or send your mic there to be calibrated.

EDIT: hulkss, I just realised I wrote a long answer for something you did not ask

. Anyway, if my memory is correct, my EMM mic came with both frequency and phase calibration. As far as I know, it is only the frequency table that is being used by Audiolense. Correct me if I'm wrong.

TheLion · « **Reply #36 on:** January 03, 2012, 06:33:30 am »

That's right, IBF Acoustic provides amplitude and phase response data for their mics. Mine came with a report like: http://www.content.ibf-acoustic.com/catalog/ddownload/CAL-CCP-sample.pdf

Audiolense only uses the frequency table, as do all DRC apps I am aware of.

There is a big difference between individual calibration and bulk calibrated mics. For latter the calibration file lists the "typical response" for that kind of mic - and with value mics variation is usually so big that it is pointless. E.g. Audyssey mics that come with receivers are "bulk calibrated". Look e.g. at http://www.cross-spectrum.com/measurement/calibrated_behringer.html for calibration services.

Trumpetguy · « **Reply #37 on:** January 03, 2012, 07:06:13 am »

Good point. My first mic (Behringer ECM8000) came with a "typical frequency responce" graph printed on the box. Not very useful other than it showed the typical increased discrepancy from linearity at low frequencies. The same is true for the much used RadioShack SPL meter. As far as I know, a lot of people (including myself a few years ago) use any calibration curve found on the net assuming anything is better nothing. The only thing to be sure of then is that you get a result, and that you do not have any control of the actual result at all, since the discrapancy in the low bass region can be several dB.

Is it really true that receiver mics are only bulk calibrated? If so, I am even more satisfied with my preamp/receiver-free setup :-)

TheLion · « **Reply #38 on:** January 03, 2012, 09:51:19 am »

You should be ;-)

yoshi_1 · « **Reply #39 on:** January 03, 2012, 02:28:13 pm »

+1 for native convolution in MC. This will definately be a great addition to an already excellent product. Currently, and until another option becomes available, I rely on ConvolverVST running my Audiolense generated filters in MC.

Matt · « **Reply #40 on:** January 03, 2012, 05:36:08 pm »

I got a little smarter about convolution today.

I sketched together a partitioning, frequency-based convolution system. It uses 64bit precision for all calculations, and runs at about 80x real-time (roughly 1% CPU usage) on a stereo file with 65k taps.

I also played with time-based convolution, and saw that it's impossible even on a fast computer. It hits the wall around 15,000 taps using the FPU and about 25,000 taps using SSE with a stereo file. Even if the speed was improved 10x from threading or better assembly, it'd still be much too slow.

We have some other higher priorities than convolution right now, so I can't say when we might put this work into a real build.

hulkss · « **Reply #41 on:** January 03, 2012, 08:08:56 pm »

If there was a "proper" convolver in JRiver MC the tools below could be used to develop filters for it.

Here is Bohdan coaxing square waves out of a multi-way dynamic loudspeaker:
http://www.bodziosoftware.com.au/Square_Wave.pdf

And a home theater example:
http://bodziosoftware.com.au/Ultimate_Equalizer_Technology.pdf

Personally, I now use Audiolense with ConvolverVST: http://www.juicehifi.com/index.html

Dennis shows his stuff here: http://drc-fir.sourceforge.net/doc/drc.html

And Acourate: http://www.acourate.com/

TheLion · « **Reply #42 on:** January 04, 2012, 03:48:43 am »

Quote from: Matt on January 03, 2012, 05:36:08 pm

We have some other higher priorities than convolution right now, so I can't say when we might put this work into a real build.

Matt,

I really appreciate it that you have this topic "on your radar". I am sure when you release that feature it will be a quality implementation and a great asset to your customers. The last two days showed that general interest is quite strong and present DRC users aren't satisfied with existing convolution plug-ins. Thank you!

Hendrik · « **Reply #43 on:** January 04, 2012, 06:12:54 am »

DRC = Dynamic Range Compression

Get another acronym, this one is used already.

TheLion · « **Reply #44 on:** January 04, 2012, 06:44:28 am »

Quote from: nevcairiel on January 04, 2012, 06:12:54 am

DRC = Dynamic Range Compression

Get another acronym, this one is used already.

I was really hoping nobody would be using something like Dynamic Range Compression by now. So I consider the acronym DRC to be free from bad meanings ;-)

btw in your country it has a great meaning: http://www.drc.de/

lbstyling · « **Reply #45 on:** January 04, 2012, 06:59:40 am »

This has been my dream for the last 10 years!
I am currently running filters in J river that were measured in REW and manually typed in to j river. If you could interface with REW and import filters straight in (REW can build targeted filters), then have an easy way to apply crossover filters within J river, and output duplicate channels on more than one sound card- that would be awsome!

For a start, the entire diy audio community would emigrate here, thats everyone on partsexpress, diy audio, diy hifi, loads from home theatre shack/forum, and on and on.

I think having the eq and the crossovers separate would help keep it all easy for average joe, and encorage people to play with active speakers as a future improvement- creating the most technically accurate sound system possible, and saving thousands of dollars. This would render all high end processors obsolete!

Going active alone drops distortion by around 2% because of inductor saturation.

Do it- be a steve jobs- change the world!

gvanbrunt · « **Reply #46 on:** January 04, 2012, 07:24:22 am »

Well thanks a lot guys. I've been putting off looking into this type of correction for some time now. With the amount of interest and links here I can no longer ignore this. You've just forced me to do a lot of reading....

TheLion · « **Reply #47 on:** January 04, 2012, 08:08:53 am »

Quote from: lbstyling on January 04, 2012, 06:59:40 am

This has been my dream for the last 10 years!

For a start, the entire diy audio community would emigrate here, thats everyone on partsexpress, diy audio, diy hifi, loads from home theatre shack/forum, and on and on.

And I thought it was only me

Make them post here and this feature might get more priority from Matt, Jim, et all

I have started with REW myself. Giving your background I would strongly recommend you take a closer look at Uli's Acourate! Coming from REW you will be more than pleased

lbstyling · « **Reply #48 on:** January 04, 2012, 08:15:58 am »

Thats just awsome!!!!

I have no doubt that you wont regret it.

Does the plan include active speaker setup (crossovers/multiple channels outputting the same audio)??

lbstyling · « **Reply #49 on:** January 04, 2012, 08:36:18 am »

Quote from: TheLion on January 04, 2012, 08:08:53 am

And I thought it was only me Make them post here and this feature might get more priority from Matt, Jim, et all

I have started with REW myself. Giving your background I would strongly recommend you take a closer look at Uli's Acourate! Coming from REW you will be more than pleased

much of the community that I mention are not aware of what J River really is over another player like wmp. I think a bit of marketing over that way wouldnt be a bad idea. The community is slowly coming round to the idea that computers can play quality audio, but theres a whole lot of marketing thats battling the change (cables for example) who pay big money for a good magazine review. Ill admit that at one point I was one of them.

Ive been on a mission to build the most acurate/best audio system for 15 years, (thats how I got here) most of my efforts are in building speakers and amplifiers though. I have £50k in drivers ready to build my ultimate active speaker. (it is a private cinema though)

Proper EQ combined with JMLC profile 90 deg corner horns on beryllium compression drivers, and active crossovers = no early reflections, and eq'ed late ones + sub 0.2% distortion at reference level across the whole spectrum. Its audio nervana if I can do it.

INTERACT FORUM

Author Topic: Native JRiver 64bit fp convolution engine for Room Correction (FIR filters)? (Read 340404 times)