INTERACT FORUM

More => Old Versions => JRiver Media Center 20 for Windows => Topic started by: ogs on February 26, 2015, 03:12:56 am

Title: Bug in JR convolver
Post by: ogs on February 26, 2015, 03:12:56 am
There is a bug in JRiver convolver where short files that perform amplitude-only correction is considered 'Not valid' and ignored. There is sound, but it is not corrected. When the filter size is 65k or higher the filter is used, but is treated as low pass so noting much over 50Hz is getting through.(50Hz is guessing, could be lower) The same filters work in brutefir.
Filters which also does time domain correction (all sizes from 8k taps to 132k taps) work as expected in JR convolver.
Title: Re: Bug in JR convolver
Post by: Matt on February 26, 2015, 06:59:26 am
Can you provide a sample that shows the problem to matt at jriver dot com?  Thank you.
Title: Re: Bug in JR convolver
Post by: ogs on February 26, 2015, 09:37:38 am
Can you provide a sample that shows the problem to matt at jriver dot com?  Thank you.

Files sent.
Title: Re: Bug in JR convolver
Post by: Matt on February 26, 2015, 10:32:42 am
The WAV files have a "data" chunk with 0 as the number of bytes in the chunk.

So that's why we say it's an invalid filter.
Title: Re: Bug in JR convolver
Post by: ogs on February 26, 2015, 11:58:22 am
The WAV files have a "data" chunk with 0 as the number of bytes in the chunk.

So that's why we say it's an invalid filter.

OK. I'll pass the info to the Audiolense designer. What about the file that is valid as a convolution filter, but convolution creates a low pass?
Title: Re: Bug in JR convolver
Post by: Matt on February 26, 2015, 01:01:32 pm
What about the file that is valid as a convolution filter, but convolution creates a low pass?

I don't think you sent me that file.

But the convolution algorithm is pretty bullet proof, so I'd guess that the filter just really acts as a low pass.

Title: Re: Bug in JR convolver
Post by: ogs on February 26, 2015, 03:08:26 pm
I don't think you sent me that file.

But the convolution algorithm is pretty bullet proof, so I'd guess that the filter just really acts as a low pass.



I'll resend the file. The same filter works normally in brutefir so it should not be a low pass in MC
Title: Re: Bug in JR convolver [Solved -- Not a bug]
Post by: Matt on February 26, 2015, 03:31:23 pm
Thanks for the file.  I sent by email too, but in case you see this first: that file just shows not valid like the other files.  Presumably because it has a 0 byte data chunk like the other files.  So I don't even know how you're testing that!
Title: Re: Bug in JR convolver [Solved -- Not a bug]
Post by: Matt on March 03, 2015, 10:18:32 am
Just a note that we've fixed a convolution bug in a coming build that may make these filters that weren't working work again.

Thanks.
Title: Re: Bug in JR convolver [Solved -- Not a bug]
Post by: mattkhan on March 03, 2015, 10:22:31 am
Just a note that we've fixed a convolution bug in a coming build that may make these filters that weren't working work again.

Thanks.
speaking of convolution, any chance of a comment on http://yabb.jriver.com/interact/index.php?topic=95806.msg660702#msg660702 ?
Title: Re: Bug in JR convolver [Solved -- Not a bug]
Post by: ogs on March 04, 2015, 06:00:55 am
Just a note that we've fixed a convolution bug in a coming build that may make these filters that weren't working work again.


Good, thanks a lot!
Title: Re: Bug in JR convolver
Post by: Matt on March 04, 2015, 08:38:38 am
The build with the fix is public now.
Title: Re: Bug in JR convolver
Post by: ogs on March 08, 2015, 05:48:33 am
The build with the fix is public now.

Hi
convolver is now accepting files and displaying processing info when working, but with amplitude only files the right channel has little or no mid/treble info while the left channel seems normal. Filters with time domain correction works OK all the way from 8k to 132k length