Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mattkhan]

A default setting per zone?

And then a track specific setting that will over-ride the default?

this approach doesn't work with multiple zones

For example, zones which relate to physical locations with different audio capability (stereo Vs multichannel) may require fundamentally different DSP so you can't override with one other config.

If you then allowed per zone item specific config, it just doesn't scale v well (combinatorial explosion in no of files to manage). For example, change 1 common setting (no track specific) and have to update potentially 000s of track specific configurations. It would be, imo, unusable.

A first step of unloading the custom dsp should help the single zone user though

[Matt]

Small = Allow channel count & mix target to vary independently

It looks like we already have choices like "2 channels (inside a 5.1 container)".

Could we just expand that list a little to give you what you wanted?

Thanks.

[mattkhan]

A big list is fine, 2 drop-downs seems nicer though. i.e. one for channel count which has lots of options, one for mix target which has just a few options (stereo, 5.1, 7.1)

[Matt]

It would be a smaller change to just add to that list.  What are you hoping for?  Thanks.

[mattkhan]

For me personally I would like 5.1 in a X channel container where X is the choices up to 16 (i use 14 today, it may grow slightly soon).

[Matt]

Next build:
Changed: Added several more 5.1 inside channel layouts to the mixer (inside 10, 12, 14, 16 channel container).

[mwillems]

So there are two distinct issues that separating the mixing target and channel count would support, and a larger list would only solve one of them, I think.

So the first issue is a lack of flexibility in mixing targets, and that could potentially be resolved by a big list, but it would be a pretty big list once you take into account the higher channel counts.  In terms of practical issues to be solved:  One issue is that the current 2.1 setting is actually using a 5.1 container behind the scenes, which is fine enough (there's no such thing as a three channel DAC), but folks with four channel DACs can't use the current 2.1 mixing target at all and that's not intuitive.  So you'd want "2.1 in a four channel container" option as well, and maybe 2.1 in a 7.1 channel container too, etc.   I think all of the higher than 8 channel outputs currently use a 7.1 mixing target, but if you have a ten channel DAC and are doing bi-amped speakers you might want to target a 5.1 mixing target to give you four spare channels, etc.  So you'd need different mixing targets for the higher channel counts too (5.1 in a 10 channel container, etc.).  And, this is more niche, but there also aren't any four channel mixing targets with larger containers (i.e. there's just the four channel setting).  So you could solve these issues with a bigger list, but it might be twice as long as the current list. 

But the second issue is custom downmixing/eq processing before the downmix.  If your DAC only has a stereo output and you want to do your own custom down mixing you just can't do that with the current system because all of the x format in y container options require at least y channels on the output device, even if you don't actually "need" that many channels in your planned output.  Similarly, if you have a six channel DAC and want to do your own down mix/pre eq processing from 7.1 that's also impossible.  The x in y container options can't solve that problem because the DSP chain currently needs y channels on the output device and if you don't have a device with that many channels you're just out of luck.

So a big list would solve the second issue, but not the first.  To be able to do custom downmixing and/or pre-processing you need a way to separate the mixing target/number of working channels from the number of output channels.  That might be a larger lift obviously, but separating the two in the UI would be a good step in that direction.  A longer list would certainly solve the first set of issues too, though.

EDIT: There were more posts while I was drafting!  The 5.1 targets for the larger channel counts is definitely a step in the right direction 

[mattkhan]

I think I segregated the second issue into

5) Allow DSP to be applied to the source content independently of the output format

Though the scope of that is wider than just the mixing problem

[mwillems]

I think I segregated the second issue into

5) Allow DSP to be applied to the source content independently of the output format

Though the scope of that is wider than just the mixing problem

That makes sense.  They were just entangled in my head because they might require similar UI changes, but you're right that it's wider in scope.

[Matt]

You really can't apply DSP independent of the output format because it has been converted to the output format at DSP time.  I'm not sure how to get around that?

[mattkhan]

You really can't apply DSP independent of the output format because it has been converted to the output format at DSP time.  I'm not sure how to get around that?

you can't in MC no but that is just a function of how DSP Studio is designed (and/or how the MC audio engine works)

in general terms, mixing and resampling (and the other stuff in output format) is just another stage in your audio pipeline & I can't think of a reason why it has to go first. For example, another pipeline could be

7.1 channel 96kHz content from source -> PEQ -> convolve -> PEQ -> mix to 5.1 -> resample to 48kHz -> map to output channels

to my mind specifying the output format at the end is more logical/intuitive but it could happen at any point in this process really

[mattkhan]

with the limiter at -17 playing a -20dBFS signal at 100% internal volume & no other DSP, analyser reports -23dB rms levels and output frequency response is flat

same setup but with limiter at -20 and there is clear compression of the signal, the scope view here shows the captured waveform of a log sine sweep, waveform would be same size throughout without compression but you can see the dip

is it expected? I assume this is some attempt to avoid hard clipping so it gradually compresses as it reaches the limit? I don't think I've seen a description anywhere of the behaviour though so would be worth clarifying that.

[mattkhan]

the all pass filters seem ok though degrade badly as they go above 5kHz at 48kHz (so about nyquist / 4), this might be expected behaviour for a straight biquad implementation though (I don't recall off hand, will double check this). The phase response at v low frequencies also had an oddity in it so I'll check that too (need to compare against some other implementation to be sure).

[mattkhan]

here's a pic of the APF at 48kHz, fc at 20Hz 1kHz 5kHz and 15kHz

response matches that of an APF with Q=1, is it intentional? it would be a useful enhancement to make that user adjustable

you can see the warping problem as you go beyond nyquist / 2, this is normal behaviour for cookbook based biquad filters though so nothing unusual in MC here. It is something you could decide to fix though. I suppose people who care about such a thing can choose to resample to a higher sample rate to push that warping well beyond the audible range.

[mattkhan]

on the increased channel options, I thought it might be useful to put it in perspective of actual users who aren't served by MC today

stereo: setups with multiple, independent, mono subs + active multiway LR
* e.g. 3 way LR has max 2 subs, 4 way LR has no subs, 2 way LR can have 4 subs
* 4 independent subs is commonly referred as the point beyond which returns really severely diminish
==> add stereo in 10 and 12 channel containers

film watchers who don't have surrounds, i.e. 3.1, but do have >1 sub
* for passive speaker users
==> 3.1 in a 6 or 8 channel container
* for active speaker users
==> 3.1 in a 10 / 12 / 14 channel container (allows for upto 3 way mains + 4 subs)

I think this covers the setups I can think of people using while fitting into the provided quick solution.

[mattkhan]

Thanks for adding everything so far, much appreciated!

[mattkhan]

on convolver cfg file reloading, a few comments

* changes to the cfg file do appear to be picked up consistently
* changes to wav files referenced by the cfg file are *not* detected unless the cfg file changes

it would be nice to fix the latter case as well, are you doing something like "only reload if cfg file modtime/content has changed?". If so can you change that so it simply *always* reloads?

it's still slightly confusing in terms of knowing whether it has reloaded or not, one simple/cheap suggestion is to add a bit of content to the status window in the convolver page? I suggest 2 timestamps, one for the last time the file was loaded and one for the modtime of the file itself. This would give obvious feedback to the user that clicking reload did something.

[Matt]

* changes to wav files referenced by the cfg file are *not* detected unless the cfg file changes

I'm not able to reproduce that.  The audio file gets reloaded each time I click "Reload".

I tried both a WAV file and a CFG file and both did a reload.

Any other tips?  Thanks.

[Matt]

I made DSP profiles unload after the file finishes in the build that's out now.  I had wanted that too.  There's a little bug right now if you play multiple presets in a row that I've fixed for the next build.

I also added more channel layouts based on suggestions in this thread to the output channels.

[mattkhan]

I'm not able to reproduce that.  The audio file gets reloaded each time I click "Reload".

I tried both a WAV file and a CFG file and both did a reload.

Any other tips?  Thanks.

are you using a wav file directly or a cfg file that references a wav file? I am referring to the latter

[Matt]

are you using a wav file directly or a cfg file that references a wav file? I am referring to the latter

I tried both.

[mattkhan]

I tried both.

I'll try it again to be sure

[mattkhan]

I had another idea for a (hopefully) small new feature.... show the total delay incurred in the audio pipeline in Audio Path. I am assuming you know this value because you are able to keep audio/video in sync

[Matt]

I had another idea for a (hopefully) small new feature.... show the total delay incurred in the audio pipeline in Audio Path. I am assuming you know this value because you are able to keep audio/video in sync

That's a pretty good idea.  I'll work on it today.  Thanks.

[Matt]

Just released the latency stuff.  Cheers.

[Matt]

mattkhan, I updated your post with some comments.

[JimH]

We could use advice on this topic from anyone.  Thanks.

mattkahn's original list is here:  https://yabb.jriver.com/interact/index.php/topic,131934.msg914653.html#msg914653 

Matt has made many changes already.  His comments are in bold in that post.

[mwillems]

So to answer some of Matt's questions from the post:

Missing Features:

2) Raw Biquad filters
* i.e. allow user to input a0/a1/a2/b0/b1/b2
* useful to power users, lets them enter literally any biquad they like without having to ask for support from J River
* user interface will be ugly and/or tricky because coefficients vary by sample rate (i.e. you'd need to make user enter the coefficients n times (once per valid sample rate based on Output Format config)
Under consideration -- what things would you use this for?

Biquads are very flexible and can be used to do all sorts of custom DSP shapes.  Like JRiver already implements a Linkwitz Transform, but it's just a special kind of biquad.  A generalized biquad filter would offer significant additional flexibility for folks who know how to use them.

4) Extend range of High/Low Pass filter types
* any order for BW, LR or Bessel as low or high pass
Low pass and high pass already allow picking the slope and Q.  What else are you looking for?

For this one, I think the goal is to support higher filter orders, but also to have options/presets for the common low/highpass filter slopes (butterworth, bessel, and linkwitz-riley) for each of the relevant orders.  Currently all the slopesWhile we can dial in the slopes if we know the right Q, most users don't know how to calculate the Q of a given order of filter so it would make the feature more accessible/usable to be able to just select a 2nd order bessel high pass or a 4th order linkwitz-riley low pass, instead of trying to figure out that they need a Q of .5774 to approximate a 2nd order Bessel, or .707 for a 4th order Linkwitz-Riley, etc.  I'll be honest, I have to look it up every time myself!


Thanks for all the improvements so far, you've covered a bunch of ground!

[Matt]

Missing Features:
Biquads are very flexible and can be used to do all sorts of custom DSP shapes.  Like JRiver already implements a Linkwitz Transform, but it's just a special kind of biquad.  A generalized biquad filter would offer significant additional flexibility for folks who know how to use them.

What if there was some type of biquad file that could be loaded?

It would have stages, then a0, a1, a2, b0, b1, b2 for each stage.  I would think just numbers, but maybe it would need to support math somehow?

The interface might be a little overwhelming, so just a text format might be easier.

Thoughts?

[mattkhan]

2) Raw Biquad filters
* i.e. allow user to input a0/a1/a2/b0/b1/b2
* useful to power users, lets them enter literally any biquad they like without having to ask for support from J River
* user interface will be ugly and/or tricky because coefficients vary by sample rate (i.e. you'd need to make user enter the coefficients n times (once per valid sample rate based on Output Format config)
Under consideration -- what things would you use this for?

it means that power users will never have to ask you to add a new filter type again, they can just load their own filters as they like

as mentioned above though, it has some user interface complexity because the coefficients will vary by sample rate so the user has to be able to provide coefficients for every sample rate specified by output format (e.g. if user resamples everything to 48kHz then only need to supply 1 set of coefficients per filter.

I would agree that accepting some text format would be the way to manage this (either directly via MCWS or via a file)

3) Allow channel count & mix target to vary independently
* to make J River more attractive to users with active multiway speakers, particularly for multichannel setups
* e.g. 5.1 target with 12 channel output (2 way mains with 2 subs) or 2.1 target with 10 channel output (e.g. 3 way L + R with 4 subs)
* NB: MC DSP configuration already includes an "Output Padding Channels" which plays this role
This is basically a rewrite of how audio is processed so we're not very keen on it.  The mix target can be any number of channels you choose.

if a big static list is implementable then that seems ok

4) Extend range of High/Low Pass filter types
* any order for BW, LR or Bessel as low or high pass
Low pass and high pass already allow picking the slope and Q.  What else are you looking for?

in beqdesigner, and using just the existing filter types you support, I added support for higher order butterworth + linkwitz riley as well as a couple of bessel variants

you can see the code in

https://github.com/3ll3d00d/beqdesigner/blob/f2991ac3b78669ec237826ef18ca4f2afa885648/src/main/python/model/iir.py#L1208

the q factors for the bessel filters are brute forced (which I took from https://gist.github.com/endolith/498278)
the approach to calculating Q for higher order bw was taken from http://www.earlevel.com/main/2016/09/29/cascading-filters/

I don't know how you approach filter design atm though so not sure if these are relevant

3) Known convolver bugs
* https://wiki.jriver.com/index.php/Convolution#Known_Issues
A reload was added.  The channel bug I thought was fixed a while ago.  If there are more, please start a thread.

the reload wasn't working for me reliably, I need to retest as it was for you

3) Improved granularity in Room Correction
* allow choice of units (ft/m/cm)
The distance changes to m if you select that in MC.  Look at Tools > Language.
* allow delay to be specified in ms
Delay comes from the distance away, so I'm not clear why you would want to set in another format.

it's more direct/less ambiguous, particularly if you measure this externally (e.g. using REW)

[mattkhan]

What if there was some type of biquad file that could be loaded?

It would have stages, then a0, a1, a2, b0, b1, b2 for each stage.  I would think just numbers, but maybe it would need to support math somehow?

The interface might be a little overwhelming, so just a text format might be easier.

Thoughts?

I think the most user friendly implementation is to support minidsp format biquad text files, this is just comma delimited key=value pairs like

biquad1,
b0=1.000744204966523,
b1=-1.9984866417835156,
b2=0.997760299915597,
a1=1.9984866417835156,
a2=-0.99850450488212,
biquad2,
b0=0.9997439483092558,
b1=-1.999143157101479,
b2=0.9994052301550241,
a1=1.999143157101479,
a2=-0.9991491784642799

[mattkhan]

one thing I mentioned in some thread.... it would be v useful to make the Q of the APF user controlled, particularly as the current fixed Q=1 is slightly unusual I think

[Hendrik]

3) Allow channel count & mix target to vary independently
* to make J River more attractive to users with active multiway speakers, particularly for multichannel setups
* e.g. 5.1 target with 12 channel output (2 way mains with 2 subs) or 2.1 target with 10 channel output (e.g. 3 way L + R with 4 subs)
* NB: MC DSP configuration already includes an "Output Padding Channels" which plays this role
This is basically a rewrite of how audio is processed so we're not very keen on it.  The mix target can be any number of channels you choose.

if a big static list is implementable then that seems ok

Seperating mix target and channel container into separate options would not be a big deal, we already store those separately. And definitely favorable to one exploding list of uncountable combinations.
Matt, that definitely seems like a better idea then making the dropdown basically unnavigatable with dozens of options.

What is beyond the scope right now is changing how the processing works, or a second stage of channel conversions. So at the end of the day you would still be limited here to a channel container that your DAC can accept.

[Matt]

I'm implementing several requests from this thread for the next build.  First, you will be able to select the number of unused channels in Output Format.  This way we no longer need a combination of channels and unused channels.  Next, I made the all pass filter support the Q parameter.  I also switched the base class the all pass derived from to hopefully move more code to the parent class.  Testing appreciated.  Finally, I added support for custom biquad filters in the minidsp format.  It's simply another line item you add to Parametric Equalizer.  Thanks for all the suggestions and help

[JimH]

mwillems, mattkahn, or Matt

We need a NEW topic for the set of new features, and I don't understand it well enough to write it.  It would be great if you could write it or even start it.

NEW:  Additional DSP Features

Some of it can perhaps be copied from this thread.

It should be on this board for now and I'll move it when we start to put out public builds  (March 10th to 15th is the target.)

[mattkhan]

how about this

NEW:  Additional DSP Features

Improved Support for Active Speakers
* Output Format no longer ties the output format to the number of channels in the output

Playback Improvements
* Track specific DSP configuration is now unloaded when the track finishes

PEQ Improvements
* Added an All Pass Filter with user selectable Q
* Support for loading user defined custom biquad filters (in minidsp text file format)
* Removed non standard definitions for Q used by Variable Q High/Low Pass filters and Shelf filters
*** NB: existing filters of this type may need to be updated manually ***
* Removed the small boost applied by the subwoofer limiter when it was not limiting
* Convolver now has a reload button to force a reload of the current filter

[JimH]

That's great, mattkahn.  Thank you!  You could post it on the MC29 board now and I'll link to it from the NEW in MC29 thread.  Much appreciated.

[mattkhan]

done - https://yabb.jriver.com/interact/index.php/topic,132284.msg917016.html

[mattkhan]

v minor point, there's a layout oddity with the APF, the fields are moved further down (see attached, the blank space above the edit fields) than all the other editable types

[mattkhan]

how is the custom biquad filter handling multiple sample rates?

[mattkhan]

custom Q APF seems to be working as expected from a brief test, thanks for adding this

[mattkhan]

custom biquad option is not working for me at all, it just does nothing. There are a number of problems here

1) format of the file is undefined, it's definitely not minidsp format and I tried a few other variants but no joy
2) there is no feedback at all as to whether the content is valid (or even loaded), strongly recommend showing some information here, minimally similar to the convolution window. For example, I would at least show a) file is loaded (inc mod time of file), b) no of biquads loaded, c) whether any biquads were invalid
3) could be achieved via point 2 above but provide some feedback if the file is invalid in any way
4) have well defined behaviour if a single biquad is invalid (NB: I would reject the entire file if any biquad is invalid to avoid surprises)
5) storing a filename in the DSP config means it's not possible to use this option with the MCWS call (unless both client and server have access to a shared filesystem which is quite clumsy at best), being able to paste the content in directly would be fine by me
6) behaviour in the face of multiple sample rates is undefined (I would bake it into the content so make the user add biquads for each sample rate they want to use)

I suspect these are all fairly simple to fix but I can't test it at all without knowing the answer to 1, perhaps you can share a file you used for testing?

[Matt]

Hi Matt.  I sent you an email this morning.  Let's discuss there for a bit.  Thanks.

[mattkhan]

sure, thanks for looking & I've sent you some info via email

for reference, I made about minidsp format

1) only 5 coeffs are listed and they are listed as b0,b1,b2,a1,a2, a0 is always 1.0
2) a1/a2 are inverted
3) there is no trailing comma (to a minidsp, that trailing comma can be meaningful in a way that's very specific to how a minidsp is implemented)

if you want to generate your own valid minidsp format then you can use https://beqdesigner.readthedocs.io/en/latest/ui/export_biquads/ , just plug some filters in and then go to this dialog and save that as a file. It means a valid way to test this is

1) open beqd
2) add some filters
3) go to the export biquad dialo
4) save that to some file
5) open MC, add that file as a custom biquad
6) measure the resulting frequency response
7) compare this to frequency response shown in BEQD, should be the same

the last point can be done easily on windows by changing your audio device to write to a file and play a measurement sweep then import the resulting file into BEQD, invert the filters (i.e. reverse the gain sign) and it should result in a flat FR

example (2 * LS 20Hz Q=0.707 +5dB at 48Khz)

Code: [Select]

biquad1,
b0=1.0005348824226694,
b1=-1.996791374306088,
b2=0.9962656170633784,
a1=1.9967933711631727,
a2=-0.996798502628964,
biquad2,
b0=1.0005348824226694,
b1=-1.996791374306088,
b2=0.9962656170633784,
a1=1.9967933711631727,
a2=-0.996798502628964,
biquad3,
b0=1.0,
b1=0.0,
b2=0.0,
a1=-0.0,
a2=-0.0,
biquad4,
b0=1.0,
b1=0.0,
b2=0.0,
a1=-0.0,
a2=-0.0,
biquad5,
b0=1.0,
b1=0.0,
b2=0.0,
a1=-0.0,
a2=-0.0,
biquad6,
b0=1.0,
b1=0.0,
b2=0.0,
a1=-0.0,
a2=-0.0


[Matt]

Please test again with the build that just went out.  Made lots of changes with your help (thanks!).

[JimH]

Any news? We're planning to post it on the MC29 public board this Thursday.

[mattkhan]

I should get time to test tomorrow

[JimH]

Thanks.

[mattkhan]

ran a quick test using a single filter (LS 80Hz +2dB Q=0.707) and then repeating that n times, was fine til I tried it with more than 6 biquads which resulted in a burst of 0dBFS high frequency content. Tweeter and ear melting stuff basically hence I think feature is currently unsafe to use til that bug fixed (I run these tests silently as I've nearly melted my ears more than once in my life doing this sort of thing!)

i.e. with this at 48kHz, it goes bad but remove biquad7 & biquad8 and it's ok (independent of internal volume)

Code: [Select]

biquad1,
b0=1.0008534559678395,
b1=-1.9860043906796208,
b2=0.9852731227640296,
a1=1.9860169559958216,
a2=-0.9861140134156682,
biquad2,
b0=1.0008534559678395,
b1=-1.9860043906796208,
b2=0.9852731227640296,
a1=1.9860169559958216,
a2=-0.9861140134156682,
biquad3,
b0=1.0008534559678395,
b1=-1.9860043906796208,
b2=0.9852731227640296,
a1=1.9860169559958216,
a2=-0.9861140134156682,
biquad4,
b0=1.0008534559678395,
b1=-1.9860043906796208,
b2=0.9852731227640296,
a1=1.9860169559958216,
a2=-0.9861140134156682,
biquad5,
b0=1.0008534559678395,
b1=-1.9860043906796208,
b2=0.9852731227640296,
a1=1.9860169559958216,
a2=-0.9861140134156682,
biquad6,
b0=1.0008534559678395,
b1=-1.9860043906796208,
b2=0.9852731227640296,
a1=1.9860169559958216,
a2=-0.9861140134156682,
biquad7,
b0=1.0008534559678395,
b1=-1.9860043906796208,
b2=0.9852731227640296,
a1=1.9860169559958216,
a2=-0.9861140134156682,
biquad8,
b0=1.0008534559678395,
b1=-1.9860043906796208,
b2=0.9852731227640296,
a1=1.9860169559958216,
a2=-0.9861140134156682


[mattkhan]

I know I go on about it but a small anecdote on useability (of DSP studio) can be found in  https://www.audiosciencereview.com/forum/index.php?threads/rew-filters-into-jriver-convolution.21693/#post-1112882

People buying, or thinking they need to pay for, software like ekio http://www.lupisoft.com/ekio/ in order to get an active speaker setup going with jriver. $150 for something MC can already do but is somewhat obscured by an unfriendly interface.
 
On the one hand clearly such people have already paid for MC without that feature, on the other people are prepared to pay quite a bit of money to make life easier via an easier to use UI.