More > JRiver Media Center 27 for Windows
Feature Request: Equalizer Improvements
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:
--- Quote from: mattkhan on December 18, 2020, 01:44:58 am ---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).
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version