Print

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

[wer]

It would really be helpful if there could be a couple of improvements to the EQ functionality in MC.

1. Increase the number of bands on the graphic EQ. Having only 4 bands below 1kHz is very limiting. (I know, I know, just use the PEQ. See point 2.)  Also, the combination of band centers and Q's needs to be revised, as the current combination is inappropriate. For example, there is too much overlap in the HF bands (12/14/16k). A 5dB boost at 14k yields a 4dB boost on a 12kHz sine wave. Likewise, a 5dB boost @ 16 yields a 3.5dB boost on the 12kHz sine wave. The 12/14/16k bands are too close together for their Q values and are essentially redundant.

2. The Parametric EQ badly needs some UI usability enhancements.  When making frequency adjustments it would be fantastically useful if it provided a visualization for the curve for each band, as well as for the overall resultant curve. Perhaps even, dare I say it, the ability to change freq, boost/cut, and Q by manipulating graphical elements?  There are external tools to model PEQ curves, but having to do the work twice to key it into MC is a drag.

3. The Q instead of S GUI error for shelf filters should be fixed. Not only is it confusing to require S when requesting Q, but the validation (max 5) severely limits the slope you can use. In this regard, the configuration of the shelf filter is poorly implemented, and needs correction.

UPDATE:
4. Allow an additional instance of the graphic equalizer, and another additional instance of the PEQ. Why? To facilitate per-track EQ adjustments (auto-eq). These additional instances should be loadable by a per-track feature. See further explanation in my later post below.


I know there are VST plugins available that do these sorts of things.  But frankly I am much more trusting in the quality of JRiver's audio manipulations than that of assorted other tools. It would be better if MC were better.

There haven't really been major audio related improvements to MC in quite a while, so it would be nice to do something like this.

[EnglishTiger]

Another DSP one that would be Nice - The ability to set the Equaliser and Effects on a Track by Track basis instead of the current "One Size Fits All" approach. Oh and can we have please more "Presets" for both of them as both lists are far to restrictive.

[wer]

That could be done with the old Auto-EQ plugin, which is broken now.

And it can be done with DSP presets, except the implementation is flawed making it overly cumbersome. But that has been discussed before.

Let's not get off track.  Functional per-track EQ would be wonderful, but it is a totally different thing from improving the equalizer itself.

[mattkhan]

V old thread on same subject - https://yabb.jriver.com/interact/index.php?topic=99096.0 - mostly still valid.

Agree completely with the view that usability of the peq window is really poor. It is a powerful tool but is just so painful to use, I tend not to bother.

Lack of easy import/export for interop with filter design programs is a real pain (https://yabb.jriver.com/interact/index.php?topic=124236.0 relates to this)

Variable Q high/low pass filters also have a similar problem with unconventional Q values btw

.

[Foggyroad]

Great to see that the DSP PEQ issue has been raised again...as it has for more than 5 years now and it never seems to gain any traction.

To add a visual representation would be wonderful and as has been mentioned before - it is really a sanity check on what has been input. As the PEQ stands now with just text input it is so easy to make a mistake. The only way to check that the required transfer function (I have 4-way actives) has been implemented correctly is to do a loopback measurement using REW or similar.

Fixing the Q=S issue would also be welcome.

[drmimosa]

Great suggestions. I think all of these would amount to substantial improvements to the EQ abilities and contribute to ease use. Especially the GUI for PEQ, I often want to see the goal for the PEQ values, not just the result in the white noise visualizer (which is very approximate and the only way you can currently get this information in JRiver)

Also note that improvements in this area might drive sales. The use of EQ adjustment to correct design deficiencies in speaker design is becoming more and more popular. Browse audiosciencereview forums, for example, and you see a lot of interest here.

[wer]

I was thinking about this last night, and I decided I was a bit too hasty in considering equalizer improvements totally separate from the per-track DSP issue.  (Some of this has been discussed in past threads, but I think it's worth mentioning again.) Accordingly, I've amended my original post with a #4.  Here's why.

For a long time, lots of people wanted per-track DSP.  And when it was implemented, there was excitement, but that was short lived. Because the feature doesn't really work. Not for its needed purpose.

The problem is that there is a conflict: per-ZONE DSP is fundamental to MC.  It is essential. Zones are often related to physical conditions: either specific playback devices, or specific rooms.  Therefore, certain DSP modules (for example, Output Format, Room Correction, and Convolution) absolutely MUST be associated with those physical realities of output. Those modules must not be allowed to vary from track to track. They must persist, as long as playback continues in the zone where those physical realities exist.

However, some DSP modules (like PEQ, GEQ, and Effects) are free to vary on a per-track basis.  They might be needed in association with a physical output (e.g. someone might use PEQ to adjust for their room, if they're not up to use Room Correction) but they might not.

The problem is the per-track DSP feature, as currently implemented, ties all DSP effects together in one bundle.  In order to get per-track EQ, you must accept per-track Convolution (and Room Correction, etc).  But per-track Convolution is forbidden:  If you played the same track in two different rooms (zones), each of which requires its own convolution, the convolution would follow the track (either enabled with a specific filter, or disabled) instead.

For this reason, per-track DSP is fundamentally incompatible with per-zone DSP. Therefore, per-track DSP basically doesn't exist in a usable form currently.

So that's the motivation behind my #4 above.  Additional instances of PEQ and GEQ, that can be loaded on a per-track basis, provide the foundation for a non-conflicting per-track EQ/DSP.  That per-track EQ could supersede the current per-track DSP (which is basically useless).  The additional instances would allow for one instance to remain tied to the zone and active, while the additional instance, loaded only with the track if called for, would allow further modifications to the sound for the track.  It is also important that when the track ends, the track-loaded EQ settings should be unloaded, so that the zone reverts to its default sound for the next track (which may or may not have a per-track EQ setting).

This would represent a complete solution for per-track EQ (especially if the Effects module is also loaded per-track), which is something we just don't have now.

I do think these per-track-EQ related changes are separate from the purely quality-based improvements needed to GEQ and PEQ (numbers 1-3), and could be added incrementally later, but they would require as an underpinning the #4 change to EQ as described above.

At one time, JRiver felt per-track DSP was worth investing some time in to implement. But what ended up being implemented is functionally equivalent to ZoneSwitch. It doesn't really provide per-track sound modification to the current zone, which I think was the intention.  I suggest it's worth investing a bit of time to get it working properly.  This would be a huge improvement for the user community.

So although separate, I think it's quite related to the also-needed EQ enhancements. Thanks to ET for the nudge.

[mattkhan]

I can imagine the UI for that (adding a DSP block as a per track entry) being slightly confusing if it were baked into the current DSP Studio. It would really from API access to setup such configuration as well. You'd also have the problem that per track EQ is, ideally, not in a fixed position in the processing pipeline (BEQ when applied pre and post bass management) and may still be zone related (per track eq appropriate for one location may not be appropriate for another, the BEQ example also has this problem).

Personally I prefer https://yabb.jriver.com/interact/index.php?topic=112836.0 (i.e. completely decouple physical, inc DLNA, locations, or zones, from other config, allow routing rules to send content to such locations, allow those rules to also select a per track dsp configuration to merge into the zone config) but realise that is a bigger change so probability of it being done is essentially zero.

[wer]

I can imagine the UI for that (adding a DSP block as a per track entry) being slightly confusing if it were baked into the current DSP Studio. .....  and may still be zone related (per track eq appropriate for one location may not be appropriate for another, the BEQ example also has this problem).

The UI might have a certain bit of complication about it, but in my view no more than per-track DSP currently, which doesn't work. At least this would work.

Perhaps in DSP Studio the modules could be named "Per track Parametric Equalizer" and "Per Track Equalizer". That would make it very straightforward, and a nota bene in the module itself could indicate those modules are only activated by the per-track tag. Other modules have help text now.

I think I disagree about per-track EQ being zone related.  The idea is that each Zone will have its own EQ and PEQ, separate from the per track EQ and PEQ. This means each zone can be "corrected" independently to the same standard, whatever standard the user thinks is appropriate. Where the "per-track EQ" comes into play is when there's a problem with a particular recording; for example Journey CDs mastered in the 80's. Extremely bright and brittle; they need to be rolled off at the top end.  But the album will need the same roll off on all zones, assuming all zones have already been normalized to some semblance of uniformity. If they haven't been, then that lack of uniformity is the problem.  If you have a zone where the speakers have no bass, you boost the bass in the PEQ for the zone. You oughtn't try in boost it in every per-track just in case they play in that zone. When the per-track EQ is loaded, it is added to the zone's EQ. So the roll-off on Journey would cause the corresponding roll-off in the zone. If the rest of the bands in Journey's EQ are flat, the rest of the bands in the zone EQ will be unaffected.

Of course what you describe is exactly a problem that exists NOW, without this enhancement. Even if you do define a per-track DSP currently, it will override the PEQ for the zone (along with convolution and RC) and it will be impossible for such a track to sound good in two zones with different sonic characteristics (like speakers that need different PEQ or convolution). With the per-track EQ, it will be easy to have the track sound good in both, since both zones will maintain their speaker-specific "corrections" and only the idiosyncrasies of the per-track-eq need be incorporated.

So what I mean is I can't think of any case where what I'm describing would affect worse results than current capabilities, and many cases where it would be better.

[mattkhan]

Say I have a 2.0 system in one room and a much more capable multichannel setup in another room. I will want to apply output channel beq in the latter but the former is not going to be able to cope so don't want to apply it there at all. Alternatively I might need to apply an additional high pass filter in the 2.0 case because I want some of the extra content but also need to cut it off as a safety measure.

Additionally perhaps I don't have beq for some tracks and want to apply a generic house curve in this case so then I need to remove it when the per track eq is in effect.

[dtc]

Conceptually, I think you both are correct. The per track DSP should correct for problems in the original file. The per zone DSP should correct for problems in the room or with playback equipment.  The results of applying the per track DSP should be what you want if you have a perfect room and perfect equipment.  The per zone  DSP then corrects for problems in the room or equipment.  The per track DSPs are applied first in order to get the "perfect" track, followed by the per zone DSPs to correct for the room/equipment.

So, for example, a beq filter should be applied to the track. A low pass filter that cuts off high frequency noise for a DSD to PCM conversion should be applied to the track. For the example of Journey's CDs, the correction would be at the track level.

The zone level DSPs should be based on anomalies in the room, like standing wave problems, or in the equipment, like inadequate bass.  They should be applied after the per track DSPs.

Unfortunately, zones (and zoneswitch) have been used for both physical zones and to apply other DSPs and other characteristics. For the above to work, zones should be limited to physical zones and the other changes would need to be applied at the track level.

As to UI, it seems pretty simple. You select either a zone or group of zones or a file or group of files then you select the DSP to apply and it is applied to the selected items. Some DSPs may be limited to either zones or tracks.

Also, conceptually it is possible that you would want to change the per track DSPs based on the zone. That is sometimes discussed with beq filters for example. For example, why do certain DSPs if you will never hear the difference in the output zone.  I could see a structure where there are multiple sets of per track DSPs, which each set related to a particular zone. Actually, that would probably not be that hard to implement, but I would probably leave it out for now.

The concepts seems pretty straightforward, but the implementation is another thing.

[mattkhan]

Yes that is the setup I would prefer/seems most appropriate for the problem (zones are physical locations, per track DSP can be applied on top, rule based selection of a per track DSP for a zone).

[MGD_King]

An alternative EQ is the free VST plugin from Voxengo. From their website:

"Marvel GEQ is a linear-phase 16-band graphic equalizer AAX, AudioUnit and VST plugin with multi-channel operation support (supporting up to 8 input/output channels, audio host application-dependent) for professional streaming, sound and music production applications.  Marvel GEQ offers extensive internal channel routing capabilities, and supports mid/side channel processing."

I just installed it and added it to MC27 and so far, I'm impressed! I can fine tune the sound and the interface isn't bad. Tinkering with multichannel set up now.

And did I mention it was FREE?

[wer]

An alternative EQ is the free VST plugin from Voxengo.

Yeah, I have some experience with this one.

I will give credit to them for having pretty good centers to their bands, a sufficient number of bands, better LF coverage, and an appropriate Q. Moving one slider doesn't affect 3 or 4 adjacent bands. It has a good interface that makes it easier to test EQ patterns. All of which are improvements on MC's GEQ.

However, as a plugin, it can be no help at all with the per track EQ question.

Furthermore, Marvel is a linear phase EQ. It exhibits pre-ringing and is going to sound different from the MC EQ, which is minimum phase. I'll leave it to the listener to decide which sound they prefer.

I would much prefer MC to have a proper built-in solution.

[Foggyroad]

I would much prefer MC to have a proper built-in solution.

Yes, me too.

I've only posted here a few times as I've been a happy MC user for more than 10 years and never really had a reason to post. But it is time for the DSP PEQ to be updated and made more user-friendly with a graphical interface. I have no problem with inputting the parameters as is the case now, but it is important to be able to see visually what has been input.

My particular use case is for two sets of active speakers - 3-ways and 4-ways. Both are dipoles, so as well as the x-overs they require shelving and peaking filters to linearise the drivers. Room correction is not my primary use for the PEQ.
 
I currently have separate 8-channel DACs and 7/8 channel amps for each speaker pair. These are setup as zones which works well and I'm quite happy with this. The input method also works well enough for me, but I'm beginning to find the lack of a display a real handicap.   

Prior to using JRiver for speaker x-over/eq I have used several MiniDSP products and have always found their graphical interface really useful. JRiver's PEQ looks quite dated in comparison. However using JRiver for x-over/eq has enabled me to do away with extra boxes and cables.

Due to my frustration with JRiver's lack of PEQ graphics I trialled Roon for 90 days earlier this year, primarily to see if its DSP was worth the extra that Roon costs. Roon's graphical PEQ representation is quite simple and displays individual and overall EQ nicely. However, I was less happy with other aspects of the data input procedures in Roon and decided to stick with JRiver.

I wouldn't think that implementing a graphical representation would be too onerous of a task.   

[wer]

Thanks for posting, Foggyroad.

I think your post is important because it illustrates that the sort of improvements we are discussing are helpful and necessary not only for less-advanced users with simple sound-shaping needs, but also for users with extremely complicated setups who are leveraging a lot of MC's capabilities.

MC has tremendous capability and quality in its sound modification capabilities, but they could be much better utilized by a broad swath of users if they were more accessible and usable.

[JimH]

We'll try to give this some attention after our end-of-year break.

[Foggyroad]

We'll try to give this some attention after our end-of-year break.

Many thanks for your quick response JimH - this would be brilliant.

Have a safe Christmas everyone!

[JunoAudio]

Hello,

Would like to see the option of minimum phase and linear phase for the SoX resampler be implemented.

Please add your filter requirements for your dipole X-over, as an example of functionality required.

Cheers - Have a safe Christmas everyone

[Foggyroad]

Hello,

Would like to see the option of minimum phase and linear phase for the SoX resampler be implemented.

Please add your filter requirements for your dipole X-over, as an example of functionality required.

Cheers - Have a safe Christmas everyone

The functionality to input complex multi-channel x-overs, shelving and peaking filters already exists in JRiver. This works fine and is not the issue for me. It is being able to visualize what has been input that would greatly improve the usability of the DSP PEQ. Avoiding the necessity to calculate the S=Q difference for a shelving filter (depends on frequency) would also be useful.

Personally, I don't need to be able to create linear phase x-overs in JRiver. I own Acourate and can build complex minimum phase or linear phase filters using that and use them in JRiver's via the convolver. However, if for example I want to make a small EQ change on the fly, say for an overbright recording, it is much easier to switch in a high shelf filter in JRiver's PEQ than it is to switch in another filter that has been built in Acourate. Acourate is a very powerful piece of software, but it has a complex interface and just making a small change to an existing configuration takes time. Also, complex multi-channel minimum phase filters built in JRiver have a tiny effect on processor load compared to the exact same filters built in Acourate.

[mattkhan]

I measured the effect of Q on high/low pass filters in MC and can say that jriver Q = actual Q / sqrt(2)

i.e.

jriver Q= 0.707 is a conventional Q=0.5
jriver Q = 1 is a conventional Q = 0.707
jriver Q = 1.414 is a conventional Q = 1
jriver Q = 2 is a conventional Q = 1.414

and so on

conventional in this case being the RBJ audio cookbook implementation of a variable Q high or low pass filter (assorted references online, one copy can be found at https://github.com/libaudioverse/libaudioverse/blob/master/audio%20eq%20cookbook.txt)

Code: [Select]

    omega = 2*PI*frequency/sampleRate
    cos    = cos(omega)
    sin   = sin(omega)
    alpha = sin/(2*Q)                                   

LPF:            H(s) = 1 / (s^2 + s/Q + 1)

                b0 =  (1 - cos)/2
                b1 =   1 - cos
                b2 =  (1 - cos)/2
                a0 =   1 + alpha
                a1 =  -2*cos
                a2 =   1 - alpha

HPF:            H(s) = s^2 / (s^2 + s/Q + 1)

                b0 =  (1 + cos)/2
                b1 = -(1 + cos)
                b2 =  (1 + cos)/2
                a0 =   1 + alpha
                a1 =  -2*cos
                a2 =   1 - alpha

I do not know how this is implemented in jriver but it's definitely not going to give the results that anyone expects when using an external filter design tool unless they know to scale Q accordingly.

[wer]

If you want a good chuckle, try measuring the effect of the 12k, 14k, and 16k sliders in the GEQ.

[mattkhan]

If you want a good chuckle, try measuring the effect of the 12k, 14k, and 16k sliders in the GEQ.

it seems fairly normal here, some warping as it gets closer to nyquist but that seems unavoidable & it seems to behaves the same as a peaking filter with the same bandwidth. Does it behave differently for you?

[wer]

No, you're capturing how it performs.

It just demonstrates those three sliders are so close together as to be superfluous.

We have what is effectively an 8-band eq, not 10.  With insufficient resolution at the low end, and insufficient resolution at the high end.

[mattkhan]

right yes, that is pretty pointless

a simple graphical interface that lets you manipulate peaking and shelf filters would be so much more useful

[Matt]

We have what is effectively an 8-band eq, not 10.  With insufficient resolution at the low end, and insufficient resolution at the high end.

Could you propose frequencies for a change?  We'd keep 10 band, but I'm not picky about what the bands are.

A few years ago I made this change:
NEW: Replaced the 10 band graphical equalizer with the high quality parametric equalizer code.  Should solve artifacts that have been reported.

Thanks!

[wer]

Sure Matt.  Re the change you mentioned, there are a lot of issues with the PEQ too, hence this thread. Not sure if you saw the things mentioned earlier.

There are certainly many avenues for improvement in the GEQ. 15 bands would be awesome, but still many improvements possible and still staying with 10 bands.

The ideal way to address the question of "which frequencies" would be to just have a little text entry box above the slider where the user could set their own frequencies. I can't see any drawback to doing that.

If we have to stick with hard-coded frequencies, we need more resolution in the bottom end. So I would propose:
30,60,120,200,360,600,1k,3k,6k,14k

Although I for one would be grateful for any improvement, really a lot more is needed in the PEQ and GEQ sections than just new centers. See my original post and the latter discussion.  But new centers would certainly be welcome for a quick and easy start.

[mattkhan]

you can use rephase as inspiration

easy enough to set a load of default values which correspond to your existing GEQ bands

fwiw ISO standard frequencies would be 31.5, 63.0, 125.0, 250.0, 500.0, 1000.0, 2000.0, 4000.0, 8000.0, 16000.0

[wer]

I would love to see something like that, even if it left off the fancy impulse and range adjustments in the lower right corner.

I don't think MC needs something that complex, but a middle ground between that and what we currently have would be terrific.

[Matt]

I'll adjust the frequencies for a coming build.  Thanks for the help.

[Foggyroad]

I measured the effect of Q on high/low pass filters in MC and can say that jriver Q = actual Q / sqrt(2)

i.e.

jriver Q= 0.707 is a conventional Q=0.5
jriver Q = 1 is a conventional Q = 0.707
jriver Q = 1.414 is a conventional Q = 1
jriver Q = 2 is a conventional Q = 1.414

and so on

conventional in this case being the RBJ audio cookbook implementation of a variable Q high or low pass filter (assorted references online, one copy can be found at https://github.com/libaudioverse/libaudioverse/blob/master/audio%20eq%20cookbook.txt)

Code: [Select]

    omega = 2*PI*frequency/sampleRate
    cos    = cos(omega)
    sin   = sin(omega)
    alpha = sin/(2*Q)                                   

LPF:            H(s) = 1 / (s^2 + s/Q + 1)

                b0 =  (1 - cos)/2
                b1 =   1 - cos
                b2 =  (1 - cos)/2
                a0 =   1 + alpha
                a1 =  -2*cos
                a2 =   1 - alpha

HPF:            H(s) = s^2 / (s^2 + s/Q + 1)

                b0 =  (1 + cos)/2
                b1 = -(1 + cos)
                b2 =  (1 + cos)/2
                a0 =   1 + alpha
                a1 =  -2*cos
                a2 =   1 - alpha

I do not know how this is implemented in jriver but it's definitely not going to give the results that anyone expects when using an external filter design tool unless they know to scale Q accordingly.

Yes, you are spot on, here.

Just to illustrate how the lack of a graphical representation of input to the PEQ can lead to large errors here are a couple of LR4 crossovers @120Hz. Both are constructed of two cascaded BW 12dB/oct. One (purple and red) has Q=1 and the other (green and blue) has Q=0.707 (actually 0.71 as JRiver will only allow 2 digits).

As @mattKhan has pointed out Q=1 is actually 0.707 and Q=0.707 is actually 0.5.

The difference between the two is not small.

[wer]

Thanks Matt for adjusting the GEQ frequencies!

I'm hoping that will be the beginning not the end of some much needed improvements... 

[samtheman57]

I was very happy with the built in Graphic EQ, but just downloaded and tried this parametric plug in instead, HUGE difference, and easy to figure out. You do need to keep your volume low enough while adjusting.You need the 32 bit version of MC 27 for this to work  as a plug in. http://www.rs-met.com/freebies.html

[samtheman57]

Nevermind. It kept crashing the program. 

[Foggyroad]

Thanks Matt for adjusting the GEQ frequencies!

I'm hoping that will be the beginning not the end of some much needed improvements... 

+1

[Chipicui]

Hi. Agree on the need of a graphical representation for the peq.
In the meantime I’d like to add that I’m using a beautiful free, multichannel, 64 bits vst parametric eq.
You can find it here

https://plugins.iem.at/docs/plugindescriptions/#multieq

[wer]

Any thoughts on some of the other ideas, Matt?

[mattkhan]

https://yabb.jriver.com/interact/index.php/topic,129609.0.html may be of interest to people in this topic

[kurosawa]

Are we still able to install the AutoEQ (https://yabb.jriver.com/interact/index.php?topic=89890.0) plugin?

AutoEQ https://github.com/jaakkopasanen/AutoEq contains a huge list EQ presets for almost all headphones!
Or is there a way to import a text file with EQ parameters in JRiver mediacenter?

[JimH]

The equalizer was changed to 20 band.

Feel free to bump a couple of suggestions.

[JunoAudio]

Hi,

The Equalizer should have 31 bands 20 – 20K, and have a constant Q mode.
A fine full scale slider mode, range maybe +/- 3 db so that you are able to resolve and set to 0.1 db increments easily.
Include a mono button to better determine mix balance with the EQ.

Please look carefully at all posts in this topic as you have an opportunity here. 

Make rePhase native in MC, that would be something !

Thanks.

[Matt]

Next build will switch the up / down keys to 0.1 dB for the EQ.  Thanks for the suggestion.