INTERACT FORUM
More => Old Versions => JRiver Media Center 29 for Windows => Topic started by: JimH on February 02, 2022, 10:20:41 am
-
mattkahn and mwillems,
Would you accept responsibility for vetting the ideas in this thread?
https://yabb.jriver.com/interact/index.php/topic,99096.msg686024.html#msg686024
Whatever you think should be done, we'll try to do. Any help you can provide would be appreciated.
Thanks,
Jim
-
I think mattkhan was editing the first post in that thread (https://yabb.jriver.com/interact/index.php/topic,99096.msg685880.html#msg685880) as the thread went along to try and capture all the asks in one place and remove them as they were done, but it's been a few years and I know that some of the items on that list have since been implemented.
Under PEQ/Crossover Flexibility I think items 1) and 4) have both effectively been implemented. Item 1 was effectively implemented by allowing for adjustable Q's on the low pass and high pass filters, although I think the Q values reported are non-standard, which makes the feature slightly more challenging to use (that might be a good new thing to add to the ease of use list). Item 4 was directly implemented as part of the "too easy" efforts, I think. Items 2, 3, and 5 have not (to my knowledge) been implemented, but all of those would, IMO, be helpful additions to the DSP functionality.
On the items under Ease of Use & Interoperability item 1) has been implemented (I just used it a few days ago actually!), although mattkhan has written some software that relies on the text output so he may have some additional thoughts on the implementation. I think item 2) may also have been implemented, but I don't spend much time in that DSP block, so I could be wrong. As far as I know items 3-6 in this section are still open, and would be helpful additions.
I invite correction on any of these points from mattkhan, though, as he's been tracking DSP issues and has done some heroic work documenting the DSP and PEQ functions on the JRiver wiki. Thanks for giving us a chance to provide some input Jim!
-
Thanks for considering improvements in this area.
I can take a bit of time in a day or so to consolidate outstanding feature requests/suggestions in one place. Would you like that in this thread or should I start another one in the 29 forum to cover it?
-
Thanks for considering improvements in this area.
I can take a bit of time in a day or so to consolidate outstanding feature requests/suggestions in one place. Would you like that in this thread or should I start another one in the 29 forum to cover it?
Thanks. Let's keep it here until later.
-
I compiled a list from various threads, tried to group them in some sensible way and provide links where possible
Missing Features
1) All Pass Filter
Added in MC 29.06
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?
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.
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?
5) Allow DSP to be applied to the source content independently of the output format
* https://yabb.jriver.com/interact/index.php/topic,98492.0.html
* allow output format to be specified later in the dsp pipeline so that you can apply DSP to the source content, e.g. for a custom downmix
* might have to be implemented by duplicating all current DSP blocks (except output format but including Analyser) and inserting the duplicates before the current output format
Similar to "Allow channel count & mix target to vary independently" and is a really big change.
DSP Bugs
1) Variable Q High/Low Pass filters specify Q incorrectly
* the value has to be scaled by 2 ** 0.5
* see https://yabb.jriver.com/interact/index.php/topic,127946.msg889106.html#msg889106
This has been corrected in MC29.
2) Shelf filters specify Q incorrectly
* the value provided is used as S not Q
This has been changed in MC29.
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.
4) Subwoofer limiter applies boost instead
* https://yabb.jriver.com/interact/index.php/topic,114574.0.html
Limiter no longer does anything until it limits. Changed for MC29.
DSP Improvements
1) Improve bass management filters to avoid cancellations
* https://yabb.jriver.com/interact/index.php/topic,127245.0.html
2) Genuinely fast/transparent filter switching for A/B testing
* https://yabb.jriver.com/interact/index.php/topic,131945.0.html
Small(ish) User Experience Improvements
1) Rework the PEQ window
* keyboard shortcuts
* bulk select + delete + move up/down
2) Analyser tweaks
* Add labels to tick marks on y axis
* Allow user control of y axis limits
* Allow user selection of displayed channels
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.
4) Ability to rename channels
The channels are pretty fixed in MC, so I'm not sure how to make the changes carry through everywhere.
5) Create named blocks of PEQs
* can be approximated using the text "filters"
Bigger UX Changes
1) Visual PEQ editor and/or visualisation of current DSP
2) Ability to manage DSP configuration from another MC instance
3) Provide custom views tailored for common uses of mixing
* channel routing via a matrix mixer
* crossover design
Playback Improvements
1) Make per track DSP genuinely usable
* provide a mechanism to load/unload a configuration on a per track basis
* allow for overriding/extending a base configuration (e.g. to add just a few PEQ filters on top of existing configuration)
* allow for configuration to vary on a per zone basis
MC29 now unloads the DSP when the track finishes. This should make it a lot better.
(more details in https://yabb.jriver.com/interact/index.php/topic,127946.msg887809.html#msg887809)
-
there are a few things listed here which are already implemented in my app using the Load/Save DSP MCWS call - https://beqdesigner.readthedocs.io/en/latest/ui/manage_mc/ - which means for me personally I would put assorted UX things on this list as a lower priority :) they are still obviously valid improvements to make to MC itself though (as I wouldn't have implemented those features if MC had them already). The app above is free so you can download it and try it out yourself to see how that is designed if you like.
I suspect "Make per track DSP genuinely usable" is the most broadly useful feature though it's also probably the most complex and/or difficult to do.
For smaller things, I feel like "Raw Biquad filters" and "Allow channel count & mix target to vary independently" would be good (and hopefully relatively simple) additions because they make MC that much more flexible.
I also suspect there are other features out there that are audio pipeline related but the below is what I could easily find through search
-
I compiled a list from various threads, tried to group them in some sensible way and provide links where possible
Missing Features
1) All Pass Filter
* implemented in 29.0.6
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)
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
4) Extend range of High/Low Pass filter types
* any order for BW, LR or Bessel as low or high pass
DSP Bugs
1) Variable Q High/Low Pass filters specify Q incorrectly
* the value has to be scaled by 2 ** 0.5
* see https://yabb.jriver.com/interact/index.php/topic,127946.msg889106.html#msg889106
2) Shelf filters specify Q incorrectly
* the value provided is used as S not Q
3) Known convolver bugs
* https://wiki.jriver.com/index.php/Convolution#Known_Issues
4) Subwoofer limiter applies boost instead
* https://yabb.jriver.com/interact/index.php/topic,114574.0.html
DSP Improvements
1) Improve bass management filters to avoid cancellations
* https://yabb.jriver.com/interact/index.php/topic,127245.0.html
2) Genuinely fast/transparent filter switching for A/B testing
* https://yabb.jriver.com/interact/index.php/topic,131945.0.html
Small(ish) User Experience Improvements
1) Rework the PEQ window
* keyboard shortcuts
* bulk select + delete + move up/down
2) Analyser tweaks
* Add labels to tick marks on y axis
* Allow user control of y axis limits
* Allow user selection of displayed channels
3) Improved granularity in Room Correction
* allow choice of units (ft/m/cm)
* allow delay to be specified in ms
4) Ability to rename channels
5) Create named blocks of PEQs
* can be approximated using the text "filters"
Bigger UX Changes
1) Visual PEQ editor and/or visualisation of current DSP
2) Ability to manage DSP configuration from another MC instance
3) Provide custom views tailored for common uses of mixing
* channel routing via a matrix mixer
* crossover design
Playback Improvements
1) Make per track DSP genuinely usable
* provide a mechanism to load/unload a configuration on a per track basis
* allow for overriding/extending a base configuration (e.g. to add just a few PEQ filters on top of existing configuration)
* allow for configuration to vary on a per zone basis
(more details in https://yabb.jriver.com/interact/index.php/topic,127946.msg887809.html#msg887809)
These all look good and jibe with my understanding of what's missing/might need fixing.
Just to clarify, can you be more explicit about what Missing Feature 4) means? I assume you mean, at minimum, offering filter slopes above 8th order? But do you mean something else too? I think we can currently dial in LRs and Bessels by specifying the Q (after conversion of course), or am I confused on that? Maybe you mean offering labelled "pre-sets" for those filter types that will set the Q appropriately? Or some combination of higher orders and labelled presets?
I think both would be helpful improvements, but the first is definitely missing functionality but the second is QOL (unless I'm mistaken, obviously). I just wanted to make sure the "ask" is clear :-)
there are a few things listed here which are already implemented in my app using the Load/Save DSP MCWS call - https://beqdesigner.readthedocs.io/en/latest/ui/manage_mc/ - which means for me personally I would put assorted UX things on this list as a lower priority :) they are still obviously valid improvements to make to MC itself though (as I wouldn't have implemented those features if MC had them already). The app above is free so you can download it and try it out yourself to see how that is designed if you like.
I suspect "Make per track DSP genuinely usable" is the most broadly useful feature though it's also probably the most complex and/or difficult to do.
For smaller things, I feel like "Raw Biquad filters" and "Allow channel count & mix target to vary independently" would be good (and hopefully relatively simple) additions because they make MC that much more flexible.
I also suspect there are other features out there that are audio pipeline related but the below is what I could easily find through search
For my part, "Allow channel count & mix target to vary independently" is a longstanding wish of mine and has no good workarounds right now.
Also, I know that Visual PEQ Editor is a heavier lift, but every time that's come up it's a very popular idea. That said, I agree with mattkhan that BEQDesigner is a good solution for that right now, so it might make more sense to focus on the missing features and or outright bugs first.
-
Thank you!
-
Just to clarify, can you be more explicit about what Missing Feature 4) means? I assume you mean, at minimum, offering filter slopes above 8th order? But do you mean something else too? I think we can currently dial in LRs and Bessels by specifying the Q (after conversion of course), or am I confused on that? Maybe you mean offering labelled "pre-sets" for those filter types that will set the Q appropriately? Or some combination of higher orders and labelled presets?
I just mean named filters up to some reasonable order (upto 24th perhaps which is pretty much a brick wall) limit. I called it a missing feature from the perspective of a typical MC user and was ignoring workarounds.
I.e. you can do it today using the variable Q filter but realistically no one can do that accurately without using a computer (e.g. beqdesigner), partly because how to calculate the required Q is not common knowledge and partly because of the Q bug in pass filters. I think even if you fixed the Q bug it would still be practically impossible for any normal user.
-
I just mean named filters up to some reasonable order (upto 24th perhaps which is pretty much a brick wall) limit. I called it a missing feature from the perspective of a typical MC user and was ignoring workarounds.
I.e. you can do it today using the variable Q filter but realistically no one can do that accurately without using a computer (e.g. beqdesigner), partly because how to calculate the required Q is not common knowledge and partly because of the Q bug in pass filters. I think even if you fixed the Q bug it would still be practically impossible for any normal user.
Got it! Thanks for clarifying.
-
Is adding an A/B switch like asked for here important:
https://yabb.jriver.com/interact/index.php/topic,131945.0.html
Thanks.
-
Is adding an A/B switch like asked for here important:
https://yabb.jriver.com/interact/index.php/topic,131945.0.html
Thanks.
No. Let Mitchco have the business.
-
Is adding an A/B switch like asked for here important:
https://yabb.jriver.com/interact/index.php/topic,131945.0.html
Thanks.
So there's two related issues in that thread: there's interest in a new feature (a/b buttons) and a longstanding bug/issue in the convolution DSP user interface (listed in mattkhan's link above).
In re: the bug, the current behavior of the convolution UI is kind of counterintuitive in that unlike most of JRiver's DSP (which can be changed on the fly during playback) the convolution block doesn't detect changes to the config files on the fly. Currently when changes are made to the underlying convolution configs or filters MC silently ignores changes until you completely restart MC, which is unexpected (stopping and starting playback is not enough). This has the practical effect of making convolution configs or filters very hard to test or tune on the fly because MC silently ignores changes to the configuration until MC is restarted.
So I think the issue with convolution configs or filters requiring a restart of JRiver to pick up changes is important to fix. Especially because the fact isn't obvious from the interface at all so it leads to confusion/frustration. Like mattkhan mentioned in the A/B thread, either watching the underlying file so that when it changes JRiver respects the changes, or including a manual "reload" button would probably resolve the issue.
As to the feature request, I think a seamless DSP A/B switch (whether convolution specific, or more general) would be very nice to have for testing or critical listening. But I suspect (as mattkhan alluded to in the A/B thread) fixing the convolution reloading behavior might need to happen first, and would help get people closer to being able to do some limited A/Bing on their own using the tools available.
-
I added a reload button to the Convolution DSP for the next build. I've done one of the requests in this thread! Thanks.
-
I think it is a valid feature request but I think it is hard to see that as important to jriver unless you were going to seriously go after that sort of market.
I think there are steps in this direction you could take, probably quite cheaply, and which would be more generally useful. Two spring to mind
1) LoadDsp mcws call does result in an audible gap as the new config takes over, eliminate this
2) allow for a some keyboard shortcut to switch between DSPs quickly (e.g ctrl+some other keys+Fnn)
I know that 2 could be done through zones, but i think that does not play nicely with zoneswitch (NB: generally speaking I would overhaul zones, zoneswitch and DSP configs but I realise that is a big, disruptive, lift) so some hotkey based system for a single zone would still be useful.
-
btw the above shows there are a class of DSP related problems that are more about playback then DSP per se, I (mostly) stuck to DSP itself in my earlier post otherwise thread scope is out of control :)
-
No. Let Mitchco have the business.
I really appreciate that Jim, thank you.
Re: spalmgre's comment: He has after all been using JRiver for years and developed this competing software from a need of features that he can not get by using existing JRiver software.
It is true that I am a long time JRiver user for years, listening to tunes right now on MC :-) But no, I did not develop HLC as a competing product, lol! It is just another complimentary plug-in for JRiver with a specialised purpose as described here: https://yabb.jriver.com/interact/index.php/topic,129475.0.html
Kind regards,
Mitch
-
another mentioned thread is https://yabb.jriver.com/interact/index.php?topic=98492.0 . It's a slightly hard to follow thread but I think the concrete feature request is to be able to move output format (as opposed to pinning it at the top) which would allow some DSP stages to be applied to the input signal as opposed to the output. I can see one concrete use for this would be a custom downmix (which is currently impossible unless you have a device with as many channels as the input).
I would think this would potentially mean duplicating the existing dsp studio so you could have all the blocks available to work on the input then feed that into the output (and be able to repeat them again). No doubt a snazzier UI could be implemented for this but the above sounds correct from the point of view of a processing pipeline.
added as item 5) under Missing Features in the earlier post
-
I think the concrete feature request is to be able to move output format (as opposed to pinning it at the top) which would allow some DSP stages to be applied to the input signal as opposed to the output.
Output Format is not a DSP in the sense of the others, its configuration is just included in the list for convenience. Its hard-wired into the audio engine and moving it would be a major change with lots of caveats (eg. rather unrealistic), for seemingly minor advantages.
If you want eg. a custom downmix, it would be easier to let DSPs change the channel configuration afterwards.
-
I don't think I understand the distinction drawn, perhaps because I have no clue how MC is implemented internally.
If a new DSP block is added that allows for changing the channel configuration downstream of output format then it means changing the parameters of the audio device (eg channel count) which is currently driven by output format. If you can decouple this then what else is output format doing that is baked into the audio engine?
-
Its just an architectural point, you cannot run anything before it, since its basically the entry point of the audio engine, after which all processing gets delegated to where it needs to go.
-
Hendrik is right. What's the end goal? Couldn't you pick the proper number of channels and mix with Parametric?
-
conceptually it doesn't seem that hard, implement a fake audio device which the audio engine can write to while also giving it an audio stream like interface (however your actual content looks to the audio engine), but I leave that to you :)
Hendrik is right. What's the end goal? Couldn't you pick the proper number of channels and mix with Parametric?
the use cases in that thread are concerned with being able to operate on the source content before up/down mixing (particularly down), for example to implement a custom downmix. This is impossible at present unless your audio device is capable of operating on the no of channels in the source content. I think the minimum required to support such a use case is
* add another PEQ block
* move mixing related configuration from output format to a separate dsp block
* change output format so it just controls the actual output format (no of channels, sample rate, output encoding)
I would think the new mixing block would have to be mandatory and the options available might be best constrained by whatever is selected in output format.
-
What if you could push all the channels through MC but then tell the ASIO plugin to use less? Not sure how hard that might be.
-
For the next build I'm going to try labeling the low and high shelf filters with "S" instead of "Q".
Please test and let us know if you think that's right.
Thanks.
-
For the next build I'm going to try labeling the low and high pass filters with "S" instead of "Q".
Please test and let us know if you think that's right.
It's not right. S applies to shelf filters only. Technically this would be correct for shelf filters but practically it doesn't help because almost no other filter design tool outputs S
I really think you need to change your implementation for both shelf filters and variable Q pass filters, the latter is just wrong after all (albeit it is at least wrong in a predictable way so easy enough to work around)
-
Sorry, I said pass but should have said shelf. Updated my post.
-
I would change your definition of alpha, if you look at the cookbook then you can see alpha is defined at sin omega / 2Q rather than the more complex definition for S
Obviously it is a breaking change though so you may want to add a new Q parameter to go with the existing new one (or recalculate for people automatically?)
-
I'm trying to reproduce your subwoofer limiter adding a boost, but I'm not able to.
I'm playing volume calibration pink noise through the subwoofer channel and looking in the "Analyzer" DSP.
If I turn the limiter on and off it makes basically no changes.
It's splitting the signal into two and adding them back together. It should be lossless and looks like it to me.
Any tips? Thanks.
-
I'm playing volume calibration pink noise through the subwoofer channel and looking in the "Analyzer" DSP.
that is band limited pink noise (20Hz at low end) as far as I recall whereas I used full bandwidth noise, have you tried with full bandwidth noise? you can use the REW generator to create such noise or generate it yourself
the analyser is much too jittery for signal analysis of pink noise anyway so I doubt you could see anything there
-
I tried full bandwidth and don't see it there either.
Could you mail me a file to show it? I'm matt at jriver.
Thanks.
-
I can reproduce this measuring as per https://wiki.jriver.com/index.php/Verifying_DSP_Studio using REW RTA
play signal in MC, 100% internal volume, is flat in RTA
add limiter at -5, small (~2dB) boost around 40Hz
add some gain in MC, response progressively becomes a 40Hz BW LPF
basically the limiter is not transparent in the face of full bandwidth content
I emailed you the pink pn content I'm using for this
-
repeated this with band limited pn (10Hz and 20Hz), same boost around 40Hz is visible so this is not a function of infrasonic content
-
In the build that's out now, we switched the high and low shelf filters to use "Q" instead of "S". This was widely requested.
An all pass filter was recently implemented.
Today I looked at the subwoofer limiter. It splits the signal into low and high at 40 Hz. If it's not limiting, it adds the split together and outputs. It should be transparent, but it produces a couple dB gain for some reason. We could try attenuating by a couple dB, but I'm not clear if that would be a win.
I'll look at the Q factor for the high and low passes soon. It sounds like the value needs to be scaled. We might just make the change and tell people to update. We'll see.
Thanks for the help so far.
-
We also added a reload button to Convolver.
-
Today I looked at the subwoofer limiter. It splits the signal into low and high at 40 Hz. If it's not limiting, it adds the split together and outputs.
These aren't brickwall filters that snip the spectrum like a scissor, there is a roll-off on both sides. If you do it like that without any further considerations, you'll get a bump in the center - which is exactly what is being reported here. The entire concept basically cannot work like this.
Perhaps an EQ-style filter based on FFTs could work instead. Or just use the low-pass to measure the sub, and use a lowshelf to adjust it as needed, leaving the signal entirely untouched otherwise.
-
The described behaviour of the limiter is that it uses an LR4 on each side so will introduce large phase shift normally but should sum to flat. Clearly it doesn't so something is wrong there.
However I think the implementation of fundamentally flawed because it actually eliminates the bass instead of limiting it. I can't imagine why anyone would want this behaviour.
I think the actually useful feature here is a compressor with configurable attack/release/ratio/threshold, ideally a multiband one so you can adjust different frequency bands independently. I would discard the current implementation in favour of that.
-
I'm working on a couple requested changes today.
First, I'm scaling the Q factor for high and low pass filters by sqrt(2.0). It was reported that this was needed.
Second, I'm making the subwoofer limiter lossless until it's limiting. I don't have a great test bed for the limiter, so hopefully somebody here will be willing to test once the build ships.
Thanks for the help.
-
I don't have a great test bed for the limiter, so hopefully somebody here will be willing to test once the build ships.
happy to test it for you as required, it's a good incentive to make a linux build btw as testing this stuff is simpler for me on linux :)
I usually refer people to https://wiki.jriver.com/index.php/Verifying_DSP_Studio which explains how to measure MC output quite easily without needing any external hardware. If you want to try that yourself & need any help then happy to provide guidance.
-
happy to test it for you as required, it's a good incentive to make a linux build btw as testing this stuff is simpler for me on linux :)
Ditto! I'm happy to kick the tires when a new build lands, but its much easier for me to test on Linux (I've only got one windows box left in the house!)
-
thanks for the linux build, not sure if it's a problem with that build but the all pass filter is completely broken. The analyser goes bonkers and the output appears to be full scale throughout.
-
thanks for the linux build, not sure if it's a problem with that build but the all pass filter is completely broken. The analyser goes bonkers and the output appears to be full scale throughout.
I reproduced and we'll try to fix it in the next build. In the old code I had the signs flipped. I unflipped them, but that causes problems. I'll play a little more on Monday. Thanks.
-
The build that's out to beta now implements several changes talked about here.
The AllPass filters should now be working.
We adjusted the Q for low and high pass filters based on the suggestions here.
The subwoofer limiter should now be lossless until it is limiting.
Testing and feedback appreciated. Thanks :)
-
If you were to pick one or two things from your request list as highest priorities, what would you pick?
I've been chipping away, and am wondering what a good next step would be.
Thanks.
-
For me personally
Small = Allow channel count & mix target to vary independently
Big(ger) = making per track DSP work properly
-
What doesn't work with per track DSP like you want?
-
What doesn't work with per track DSP like you want?
Linked thread has lots of comments - https://yabb.jriver.com/interact/index.php/topic,127946.msg887809.html#msg887809
There have been other threads though
The short answer is that it needs to "unload" after the track ends and you need to be able to compose a dsp configuration, eg specify just a track specific part to merge into the zone specific part. It also needs to respect zones as they may have different capabilities.
I think what you actually want is much like what has been discussed for jrvr tbh
-
Linked thread has lots of comments - https://yabb.jriver.com/interact/index.php/topic,127946.msg887809.html#msg887809
There have been other threads though
The short answer is that it needs to "unload" after the track ends and you need to be able to compose a dsp configuration, eg specify just a track specific part to merge into the zone specific part. It also needs to respect zones as they may have different capabilities.
A default setting per zone?
And then a track specific setting that will over-ride the default?
-
I agree about unloading the DSP after playing a file. I have a hopefully pretty good idea about how to implement it for tomorrow's build.
-
Small = Allow channel count & mix target to vary independently
This would also be my next pick.
I've been a bit stuck in at work which has limited my test time. So far I've tested the convolution reload button and it seems to be working correctly so far, but I'm hoping to do more serious testing on the weekend.
-
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
-
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.
-
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)
-
It would be a smaller change to just add to that list. What are you hoping for? Thanks.
-
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).
-
Next build:
Changed: Added several more 5.1 inside channel layouts to the mixer (inside 10, 12, 14, 16 channel container).
-
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 :)
-
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
-
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.
-
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 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
-
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.
-
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).
-
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.
-
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.
-
Thanks for adding everything so far, much appreciated!
-
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.
-
* 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.
-
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.
-
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
-
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.
-
I tried both.
I'll try it again to be sure
-
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
-
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.
-
Just released the latency stuff. Cheers.
-
mattkhan, I updated your post with some comments.
-
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.
-
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!
-
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?
-
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)
-
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
-
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
-
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.
-
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 :)
-
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.)
-
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
-
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.
-
done - https://yabb.jriver.com/interact/index.php/topic,132284.msg917016.html
-
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
-
how is the custom biquad filter handling multiple sample rates?
-
custom Q APF seems to be working as expected from a brief test, thanks for adding this
-
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?
-
Hi Matt. I sent you an email this morning. Let's discuss there for a bit. Thanks.
-
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)
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
-
Please test again with the build that just went out. Made lots of changes with your help (thanks!).
-
Any news? We're planning to post it on the MC29 public board this Thursday.
-
I should get time to test tomorrow
-
Thanks.
-
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)
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
-
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.
-
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!)
Darn! But thanks for testing.
So would it be OK, in your opinion, to set a limit of 6 for now? We'd fix the problem you found, but not until a later build.
-
Jim, I'm working on fixing it this morning. Today's build will be good (hopefully!).
Thanks for testing!
-
Darn! But thanks for testing.
So would it be OK, in your opinion, to set a limit of 6 for now? We'd fix the problem you found, but not until a later build.
I think it depends what the problem is, I only tested a v simple case which tripped this problem but it doesn't mean it can't be tripped in some other way (using fewer biquads)
-
Testing appreciated.
Thanks!
-
Testing appreciated:
https://yabb.jriver.com/interact/index.php/topic,132343.0.html
Thanks!
We're releasing it tomorrow.
-
the problem (with biquads 7 & 8 ) is fixed in the latest build
-
Don't ask if I paid bribes!
-
the problem (with biquads 7 & 8 ) is fixed in the latest build
Whew! Thanks for reporting.
-
So I was paddling around this morning, and it's not a huge deal, but I notice that the highpass and lowpass filter Q in DSP Studio seems to be rounding to two decimals. So for example, if I enter .7071 which is the correct Q for a 2nd order Butterworth, it rounds it off to .71 which isn't quite right. Any chance of more precision there?
Also it might be worth considering setting the default to something other than "1" as that's not an expected filter slope at any order so newly created filters will have unexpected behavior for naive users. To get back the old default behavior (where all filters are butterworth by default) it probably would make sense to set the default to whatever the appropriate Q is for a butterworth filter at that order (e.g. .7071 for 2nd order butterworth, 4th order butterworth has 1.307, etc.).
I put this here to continue the ongoing conversation, but let me know if I should post this in the build threads instead. Thanks again for all the cool improvements this cycle!
-
I just moved this out from the beta board so you can see how much mwillems and mattkahn contributed to the new DSP capabilities. Thanks again!
And thanks to Matt (JRiver) for all the blood sweat and tears he put into making their dreams come true!
-
Coming next build:
Changed: Parameters in the Parametric Equalizer dialog show up to five digits of precision instead of two.
-
So I was paddling around this morning, and it's not a huge deal, but I notice that the highpass and lowpass filter Q in DSP Studio seems to be rounding to two decimals. So for example, if I enter .7071 which is the correct Q for a 2nd order Butterworth, it rounds it off to .71 which isn't quite right. Any chance of more precision there?
Also it might be worth considering setting the default to something other than "1" as that's not an expected filter slope at any order so newly created filters will have unexpected behavior for naive users. To get back the old default behavior (where all filters are butterworth by default) it probably would make sense to set the default to whatever the appropriate Q is for a butterworth filter at that order (e.g. .7071 for 2nd order butterworth, 4th order butterworth has 1.307, etc.).
I put this here to continue the ongoing conversation, but let me know if I should post this in the build threads instead. Thanks again for all the cool improvements this cycle!
Aside, I was under the impression that Q is actually S in MC? https://wiki.jriver.com/index.php/Parametric_Equalizer#Q_or_S
-
Aside, I was under the impression that Q is actually S in MC? https://wiki.jriver.com/index.php/Parametric_Equalizer#Q_or_S
So that's actually something that should have been fixed as part of this effort per Matt upthread. Feel free to test!
Coming next build:
Changed: Parameters in the Parametric Equalizer dialog show up to five digits of precision instead of two.
Thanks Matt!
-
So that's actually something that should have been fixed as part of this effort per Matt upthread. Feel free to test!
Oh wow, I missed that!
-
Also it might be worth considering setting the default to something other than "1" as that's not an expected filter slope at any order so newly created filters will have unexpected behavior for naive users. To get back the old default behavior (where all filters are butterworth by default) it probably would make sense to set the default to whatever the appropriate Q is for a butterworth filter at that order (e.g. .7071 for 2nd order butterworth, 4th order butterworth has 1.307, etc.).
Could you expound on this a bit? A new Low-pass is set to 12 dB/octave and 1 for Q. Are you saying it should be 12 dB/octave and .7071?
You can change the slope, but that doesn't change the Q.
Thanks.
-
Now that I don't have to convert Q->S I'm more likely to play around with custom parametric EQs. Could it be possible to add more than two and to rename them in the sidebar? I know this is somewhat possible with preset files, but it's way nicer just selecting/de-selecting them for AB.
-
Could you expound on this a bit? A new Low-pass is set to 12 dB/octave and 1 for Q. Are you saying it should be 12 dB/octave and .7071?
You can change the slope, but that doesn't change the Q.
Thanks.
So a first order butterworth (6db/octave) has a Q of .5, a 2nd order butterworth (12db/octave) has a Q of .7071. But higher order filters will have multiple poles and not all filters that have the same product Q have the same shape. I think the two poles of the 4th order butterworth are a Q of .541 and Q of 1.31, which make the product Q .7071. But if you change the poles you can wind up with the same product Q and a different slope instead.
To see more info, mattkhan linked a code example above from his beqdesigner program that shows how he modelled/calculated the Q factor for various pass filters: https://github.com/3ll3d00d/beqdesigner/blob/f2991ac3b78669ec237826ef18ca4f2afa885648/src/main/python/model/iir.py#L1208
This complexity was part of why I think mattkhan suggested offering presets for different filter shapes and orders. As it stands getting things right for higher order filters requires cascading several and setting the Q's just so.
-
So what should we change the default to?
-
Aside, I was under the impression that Q is actually S in MC? https://wiki.jriver.com/index.php/Parametric_Equalizer#Q_or_S
Note that that only ever applied to shelf filters
-
So what should we change the default to?
I'd be interested to hear mattkhan's thoughts on this, but if we have to pick only one default (rather than defaults that shift by order), I think .7071 is the sanest default (i.e. least likely to result in surprising behavior).
-
Next build:
Changed: Low and high pass filters have a default Q of 0.7071.
-
I agree the default should be a 2nd order Butterworth (so q=1/sqrt2)
I think a custom q pass filter is a pretty niche thing though, people generally just want the usual named filters of various orders.
-
We can set DSP for individual DLNA servers in MC. Why not also JRiver's 'own' (proprietary) server(s)?
I'd really like to add headphone-related DSP to the stream from my MC server to JRemote on my iPhone.
Thanks!
See also:
https://yabb.jriver.com/interact/index.php/topic,123093.msg852498.html#msg852498