Print

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

[wer]

First I think we need to recognize that any talk of Signal-to-Noise ratio is beside the point.  There is noise in the environment and in the source, but we are dealing with digital data and the manipulations done by JRiver are 64bit.  Further, we are talking about a situation that is inherently not bit-perfect.  As soon as volume leveling is turned on, JRiver is manipulating levels (or volume, if you want to use a vaguer term) ALL THE TIME.  Using Volume Leveling and Dynamic Range Compression is not about making SNR the best it can be, it's about making perceived volume sound appropriate to the ears.  Just as room correction and EQ are about altering the sound, and they also do it by manipulating the levels.  Since JRiver does the manipulation as cleanly as possible, let's embrace it.

BryanC raised the question of only boosting the quiet portions and not peaks, and mwillems was correct about the way recordings are mastered to a peak value.  

The trick is that while there may be only one mathematical peak in the track that reaches 0dBFS, to the ear the loudest 10-20% are going to sound like peaks.  An explosion is an explosion; they're loud.  The fact that this one is .001% quieter than the loudest one doesn't make it sound less of a peak.  But due to the way I think Night mode is behaving, that explosion will get boosted anyway.

I've created these charts.  (input level is horizontal, output vertical)  The first one is the way I think Night Mode is currently working.


As mwillems observed, it's going to boost everything except the mathematical peak.  This is not what I would consider friendly behavior, as it actually makes a lot of explosions louder.  I've verified this conjecture with JRiver's analyzer, so I'm fairly confident this is what it's doing.

The 2nd and third charts are friendlier ways to do it.  Peaks are cut, and quiet parts are boosted.  These are the ways consumer audio equipment with 'Night Mode' functions work, like Audionut's Yamaha.

The third chart uses two thresholds, so that peaks are cut, quiet parts are boosted, and an attempt is made to preserve the dynamics of the middle portion.

Blgentry's question about thresholds was right on the nose.  I think the answer looks like the first chart, regardless of the actual numbers.  But we'd all be better off if it looked like the 2nd or 3rd charts.

Such an approach would better preserve average volume, while still compressing dynamic range.  Making "everything" (99.9%) louder, as in the first chart, is counter-intuitive to what "night mode" should be.  

So again, we need someone from JRiver to weigh in on what it's actually doing, and address if that is the best way to go.  Sorry for the long post!  

[mwillems]

Based on my measurements, I think you're correct that your first graph describes the current behavior of JRiver's Night Mode (or at least is a reasonable approximation).  The current mode attempts to compress while also maximizing volume.

What I'm not sure about is:

But we'd all be better off if it looked like the 2nd or 3rd charts.

I think it really comes down to your expectations about the behavior of the Night Mode.  I think reasonable minds can differ about what the desirable behavior is as a general prospect (some users want to maximize the digital output volume at all times), but I'm reasonably confident that we've more or less correctly described the current behavior.  

The current behavior makes sense in the context of the DSP block it's in ("Adaptive Volume") as all the options in adaptive volume add boost to the signal (with or without compression). However, some of the options (notably peak level normalize) work together with volume leveling in an intelligent way to achieve the goals of the two settings to the extent possible (i.e. peak level normalize + volume levelling will boost the level of a playlist as loud as it can go while still maintaining a level volume).

Based on my testing (and your experience), though, it doesn't appear that night mode necessarily works together with volume leveling in the way a user might expect (i.e. it pushes the volume up and away from the calibrated level).  So while the "correct" behavior of Night Mode without volume leveling is "up for grabs," I think I agree with you that in a perfect world Night Mode would do what your second graph does when volume leveling is also enabled.  But I think we're firmly into "feature request" territory rather than "bug" territory.  

I would enthusiastically +1 such a request FWIW.

[wer]

I also think I reasonable case could be made for a graph I didn't do, one that is almost the opposite of "Current":  Quiet passages are maintained, but peaks are trimmed.  This would be appropriate for a situation in which you've already set the volume level to an appropriate listening level, where you're able to hear the quiet dialog in the movie; in this case, you don't want those parts to get any louder or quieter, you just want the explosions curtailed.  Then the average volume level would go down... That one might be called "Quiet Mode".  



Maybe a tunable parameter (which would be easily exposed) could let people tailor the DRC to their mode of preference...

The only reason why "bug" or "broken" might come into play, is if what it's actually doing (the first graph) is not what it's intended to do.  What it does is contrary to expectation and to what other "night mode" implementations in the industry do.  Even JimH suggested night mode as a solution to a problem it couldn't fix because of what it actually does.

So there might be some reason to believe it's not working as intended by the developers.  There have been a few requests for them to comment on what it's actually intended to do, but so far no response.

But I agree, it's either a bug or a feature request depending on what that answer is.

[gvanbrunt]

I agree the "friendlier mode" may work better. Not sure how it would sound though. I think the Dual Threshold would cause background noises to become too loud and clutter the speech etc. Could be wrong about that, but I think that is what is done on some R5 disks to make the audio crappy enough that you would want to purchase from another more expensive region. At least as far as I can tell. Could just be boosting the surround material, but has the same effect.

<edit>

Now that I think about it. A great way to experiment with is be taking a track with explosions etc, running it through pro tools and trying various limiter and compressor combinations to see which ones are more pleasing than others. You can play around with a lot of combinations and even surround combinations. Any suggestions for good portion of a movie with some extreme peaks?

[wer]

...as an external amp can't do that. ...

Actually that's not entirely true.  The DRC schemes that are built into a lot of processors/preamps/receivers (like the Yamaha Audionut mentioned) work on the dynamic range metadata encoded into the Dolby Digital and DTS bitstreams.  So actually, when bitstreaming, a sophisticated processor does have excellent knowledge about the totality of the track.  It's for this reason that some of those schemes (I think Yamaha is one) ONLY work when applied to DD/DTS audio, and not to PCM.  It's because the DRC algorithm lacks metadata about the PCM stream, so it wouldn't be able to make informed decisions.

So when it comes to applying DRC to DD and DTS bitstreams specifically, JRiver is playing catchup a bit I think.  But you're quite right in that as they could apply it to ALL audio, since they pre-generate their own metadata (R128) that would be a huge advance.

Nonetheless, I think including DRC is a great feature to have in JRiver (if done right) because it unshackles you from having to bitstream your movies and allows you to use the rest of the JRiver audio engine, and that's fantastic.

[gvanbrunt]

Did not know that. Good to know.

I cut that bit out thought before reading your reply when I edited my post. For anyone else that missed it, what I said essentially was that:

JRiver could use R128 information to dynamically adjust the night mode and amps can't do that. But as wer just posted, that is not actually correct.

[wer]

Yeah, we're posting at the same time...

Regarding background noise, I fail to see how the "dual threshold" is at any competitive disadvantage.  JRiver already seems to be boosting quiet sounds now, including the background noise.

Based on your concerns, it sounds like what you really want is intelligent equalization based on frequency and level, so that for example human voices could be boosted while explosions could be cut.  Some processors have functions that do that (I have a couple.  They generally call them "voice enhancers" or something like that.)  They are only moderately effective and cause some audio distortion.

Based on my experience, I think any of the alternatives would "sound" just as good as what it's currently doing and would suit the purpose better.

Overall, it seems like our thinking on this is reasonably similar.

[gvanbrunt]

Regarding background noise, I fail to see how the "dual threshold" is at any competitive disadvantage.  JRiver already seems to be boosting quiet sounds now, including the background noise.

Based on your concerns, it sounds like what you really want is intelligent equalization based on frequency and level, so that for example human voices could be boosted while explosions could be cut.  Some processors have functions that do that (I have a couple.  They generally call them "voice enhancers" or something like that.)  They are only moderately effective and cause some audio distortion.

Reading back my posting wasn't correct. I said background noise, but meant background sounds. Freudian slip I guess. Speaking outside of the S/N issue boosted background sounds can be really annoying on some R5 disks. I was just suggesting that that graph may end up sounding like that. Only way to see though is to try.

I'm familiar with voice enhancers\removers etc. Don't generally work worth a darn. They can work wonders in isolated tracks, but when combined with the rest of the material to adjust "after mixing" seldom is useful.

I think we are also talking about 2 separate issues here:

1. the current implementation still makes peaks sound to loud. I don't use it, so I don't know if that is necessarily the case.
2. the current implementation is counter intuitive as it makes it "louder" when engaged and might throw some users off. Again I don't use this on my own receiver so I can't comment how it works in other systems.

Can anyone comment on those 2?

[glynor]

I think we are also talking about 2 separate issues here:

1. the current implementation still makes peaks sound to loud. I don't use it, so I don't know if that is necessarily the case.
2. the current implementation is counter intuitive as it makes it "louder" when engaged and might throw some users off. Again I don't use this on my own receiver so I can't comment how it works in other systems.

Can anyone comment on those 2?

I use it on my system for sure. I have not done tests with a sound meter, and don't care to do any, but MC's Night mode works quite well for me.  My comments on that are:

1. I'd agree that the modification it does is a bit more "mild" than the Night mode of both my Denon and my Yamaha amp.  I like it that it isn't quite so extreme, however.
2. This is counter-intuitive if you don't understand what is happening (basically normalizing the audio, which increases the apparent volume but decreases dynamic range).  In this case, I would say it is roughly analogous to the level change on my Denon and Yamaha receivers.

One thing that might impact my usage, however, is that I use Internal Volume control for MC.  I have two Zones set up which are otherwise identical, one "regular" and one "Night".  Since I use Internal volume, these two zones have independent volume controls (which remember where they were last set on a per-zone basis).  Because of this, I basically never have to adjust volume when switching between them simply because I'm switching between them.

If you aren't using Zones to activate and de-activate the feature, or are using System Volume (like an animal), then it might be much more frustrating to use. I don't know why you'd do that, though.  Certainly it makes the most sense to use Night mode as a defined Zone. And, then if #2 still bothers you, it would be easy to mitigate by adding a level adjusting DSP to the Night Zone.

[mojave]

Your Quiet Mode graph looks similar to what a compressor and limiter does for live sound.



This is the same as what Night Mode does to the signal. After compression, Night Mode then expands the signal to maximum digital level. Does this increase volume level? It increases the potential volume level which is helpful for those using laptops, etc. The actual volume level is up to the user and the volume control.



Now anybody can playback and adjust volume level to their liking and find that dynamics have been greatly reduced with Night Mode. How much have they been reduced? It's pretty easy to compare by using the Convert Format tool. The top track is without Night Mode and the bottom is with Night Mode. It works exactly as it is supposed to. There is no need for any other mode.

[blgentry]

I've just done some experiments and watched the Audio Path display while doing it.  To me, what I'm seeing doesn't make sense.   There are entries for each part of the DSP chain.  Volume Leveling, Night Mode, and Internal Volume.

The amount of Night Mode adjustment changes in real time, based on what's playing at any given moment.  That makes sense.  But, if you adjust the Internal Volume control, the amount of Night Mode changes!  So, watching a 30 second passage of a movie, with Internal Volume set to 0 dB (100%), you'll see one set of Night Mode adjustments.  Watch the same passage, with Internal Volume set to -12.5 dB (75%), and you'll see a totally different set of Night Mode adjustments.

Shouldn't Night Mode's adjustments be based on just the file's levels?  ...and then Internal Volume gets applied afterwards?

Can someone else validate my experiment?

Brian.

[mojave]

Can someone else validate my experiment?

You are right, the amount of compression is highest at maximum internal volume level. The lower the volume, the less compression takes place. It works on the input level similar to the chart I previously posted. This is because the quietest sounds are least important and leaving them below the audible level is preferred to allow one to still clearly hear dialogue. There is still compression, but the compression is of more at the top range of the audible spectrum. Brilliant!

The second entry of the track is with the volume at -20 dB. There is greater dynamic range (R128) but less overall crest factor (DR) than with the volume at max.

[wer]

It works exactly as it is supposed to.

If you're authoritative (one of the people who wrote it) for what the algorithm does,  then that's disappointing to hear, as it tells me not to expect any improvements.

There is no need for any other mode.

I disagree.  I think we've laid out some alternate use cases already.

Glynor hit it on the head with zones.  I don't use them for that.  I have one zone for playback in my living room, and other zones for audio in different rooms.  As Glynor is using them, zones make it easy to use Night Mode in a particular way, because you can automatically have the volume set lower in the night mode zone to counteract the overall boost night mode adds.

But it's not a good solution for me.  First, I'm using a remote, so switching zones that way is not another step I'm eager to add.  Using an auto zone switch is not what I want, because I might not want to use night mode only according to predefined rules.

Secondly, changing zones requires that playback be stopped and restarted.  For me, turning on DRC is more of a spur of the moment thing.  I'd like to just be able to turn it on or off simply, on the fly.  I can do this with my preamp, and I'd like to be able to do it with JRiver.  Indeed, activating or deactivating Night Mode happens live, but if you also have to switch zones or adjust volume it becomes cumbersome.

[glynor]

First, I'm using a remote, so switching zones that way is not another step I'm eager to add.

I don't think this is a good reason not to use Zones for this purpose. You can turn on Zone display in Theater View, if you didn't know that.  I use that to switch them the most on my HTPC when needed. You can also easily program a remote button to switch MC to a different zone.  It is easily automated.

I suspect (but I'm totally guessing here) the real reason, deep down, you don't like the idea of using Zones for this is because you "think of" Zones as for separate physical spaces.  They work for that, but really they are just presets of settings that work independently. They do not need to be tied to physical spaces, and if you restrict usage to that, you're limiting your own possibilities.

Secondly, changing zones requires that playback be stopped and restarted.  For me, turning on DRC is more of a spur of the moment thing.  I'd like to just be able to turn it on or off simply, on the fly.  I can do this with my preamp, and I'd like to be able to do it with JRiver.  Indeed, activating or deactivating Night Mode happens live, but if you also have to switch zones or adjust volume it becomes cumbersome.

Despite what I said above, I agree with you here, and think this is a completely valid concern. I don't like it either, and it almost kept me from switching from using my receiver's version of the function.

It is worth mentioning that my receiver had the same issue that I needed to fiddle with volume levels after activating it.  Maybe MC's is ever so slightly worse, but if you use Zones, then that is a moot point.

However, the fact you can't switch mid-playback easily is a huge bummer. I'd really like some way to link two zones (like these) together so that they become mutually exclusive, where playback automatically switches to and from them without having to fiddle with stopping and restarting playback. Behind the scenes, it could even stop and re-start playback (it may need to depending on the playback device, which could change between these zones), but as long as it did it in an automated fashion, and auto-resumed where you left off (which MC can already do when it wants to) then a little "blip" when enabling it wouldn't be a big deal (my receiver might very well do this anyway, I don't remember). Obviously, doing so seamlessly would be even better.  But, I'd be okay with something like that if it makes the feature less limited (or just plain possible).

It is tolerable the way it is, but clumsy for sure. But, I think that's an issue with Zones, not necessarily with the Night mode DSP in particular.

[glynor]

If you're authoritative (one of the people who wrote it) for what the algorithm does,  then that's disappointing to hear, as it tells me not to expect any improvements.

No one who works for JRiver has yet commented on this thread. Mojave is certainly an authoritative poster here (especially on these sorts of topics), but he doesn't work for JRiver (nor do I).

They're monitoring it for sure, though. They often like to see some sort of consensus form before making any changes. Remember...

[gvanbrunt]

Here is my 2c on how Night Mode seems to be implemented in most systems from what others have said here.

What they are doing is "correct" from a technical point of view. Sound systems have been designed over the years so that the levels at various stages are relatively consistent and stable. And sources are mastered so the peaks are at 0dbfs. When modifying signals in general it is usually considered best practice to keep the max peak at 0dbfs if you alter the original signal in some way. The reason can be illustrated with a simple example: If you crank your amp (without any noise reduction which many have built in) and run a signal into it then turn the source down as low as it can and still be audible you would have a lot of noise. For that reason every "link in the chain" is supposed to "return the signal to 0dbfs". Otherwise if a bunch of processing changed things in a chain you could have an extremely low signal that would result in excessive noise at the amp.

So that is what is supposed to happen. However after thinking about it, not only is it non intuitive for night mode, it also is the wrong approach. What a listener wants, is to hear the same material but only with reduced peaks. And you are actually not loosing anything by not boosting the signal after compression. I think night mode should be done as a special case. However, if the rest of the industry does it the other way, maybe we shouldn't buck the trend?

[wer]

I agree with almost everything gvanbrunt just said... Except the industry isn't really consistent, otherwise we wouldn't need volume leveling would we?  The "industry" makes lots of mistakes (see volume wars), so I don't think JRiver should be shy about doing better.

Thanks for the idea Glynor.  Yes, I'm aware of the zone switch roller.  It's a lot of arrowing around but it's there.  I could bind a remote button, but I'm starting to run out of buttons that aren't already assigned to something...

But really my two objections are tied together, and currently it is just too cumbersome to do spur of the moment.

When you say "tolerable the way it is" that of course is a matter of personal tolerance.  It's tolerable for you, but not for me.

To get around the zone obstacle, I had suggested in the "Too Easy" thread a simple enhancement of adding an MCC command to enable/disable Night Mode, since that can be done live, just not easily.  No response from JRiver on that.

But then you're back to square one, because Night Mode raises the volume so much you have to immediately turn the volume down.  

Mojave sort of made it sound like my "Quiet Mode" chart of a DRC implementation was what Night Mode was doing.  But the important part of what he said was "After compression, Night Mode then expands the signal to maximum digital level."

That's the sticking point (if that's what it's doing) because in that case it's NOT just DRC:  it's DRC with peak level normalization applied afterwards.

Because of that, applying it live demands an immediate volume adjustment.  And having an automatic volume adjustment (via a zone) means you can't apply it live.

There ought to be a better way...     And there is; good processors implement DRC in a more friendly way, so I don't think JRiver would be "bucking the trend" in that regard.

[wer]

If you look at both of these threads, I do seem to think that a consensus is emerging (except for Mojave) that the current behavior is in need of improvement, in one way or another...

[blgentry]

You are right, the amount of compression is highest at maximum internal volume level. The lower the volume, the less compression takes place.

Thanks for validating.  I was very surprised by the result.

It works on the input level similar to the chart I previously posted. This is because the quietest sounds are least important and leaving them below the audible level is preferred to allow one to still clearly hear dialogue. There is still compression, but the compression is of more at the top range of the audible spectrum. Brilliant!

I have to disagree with thinking this is a good idea.  Volume level shouldn't determine dynamic range.  It ties one thing to another that doesn't make sense.  It means that any time you turn the volume down, you're making the problem worse because the dialog (or other low level sounds) reduce faster than the high level sounds.  When I turn the volume down a bit, it's usually because the peaks are still too loud, even with Night Mode enabled.  This is probably exacerbated by the fact that I watch a lot of movies wearing headphones.  So volume and dynamics are more prominent (easier to notice).

I'm of two minds on this:

1.  A supplemental mode called something like "quiet mode" (as previously suggested) that brings down peaks, does NOT normalize, and does not consider Internal Volume as part of the compression ratio or threshold or anything else.
2.  An adjustable DRC with controls that make sense.  Maybe normalization on and off.  Perhaps low, medium, and high compression ratios.  With high being even higher than we have today in Night Mode.  ...and perhaps a control for Volume tracking on and off.

I was originally thinking of "standard" DRC controls like threshold, ratio, etc.  But those are confusing unless you have a lot of experience with those types of controls.  Despite my having more experience in the pro audio world than your average audiophile, I'm not all that comfortable with "standard" DRC controls myself.

I'm not trying to turn this into a big project or a bunch of work.  But the more I read and the more I experiment, the more I think that something should be changed or added.

Brian.

[gvanbrunt]

I think the ultimate solution for gear heads would be the same controls as a compressor really. You have various frequency ranges, q (slope), "knee" control and gain. With it you can duplicate just about any chart presented here. A toy you could tune to exactly what you are after. Beats some definition of someone's idea of one perfect or correct "preset".

For novices you could have some presets. Possibly the very curves presented here.

If this were done though, how do you go about engaging night mode from the couch with the remote? What I mean what is the best way to handle turning off and on given the new options? Or does the current way still make sense?

[wer]

It would be very simple to establish an MCC command to enable/disable adaptive volume.  Then it could be bound to a remote button.

[Audionut11]

Having a million adjustment knobs (or modes) defeats the purpose.

[BillT]

If you look at both of these threads, I do seem to think that a consensus is emerging (except for Mojave) that the current behavior is in need of improvement, in one way or another...

2 people agree a couple more seem to think it might be worth fiddling with. Very few people have contributed to the thread. That doesn't look like a consensus to me, certainly isn't a significant portion of the user base.

I don't use DRC, it's inimical to high quality reproduction and recordings are largely already over compressed. If I did have need of it I really don't see what's wrong with the current approach and just turning the volume down!

[gvanbrunt]

It would be very simple to establish an MCC command to enable/disable adaptive volume.  Then it could be bound to a remote button.

I agree, but if there were more control over what options are available someone may wish to use different curves at different times. The compressor could be used for much more than just night mode. For example you could use it to compensate where background noises are too high or something.

I believe the currently solution is to assign different DSP settings to different zones and switch zones to change the settings. Would that work here or are there some potential issues?

[wer]

Very few people have contributed to the thread. That doesn't look like a consensus to me, certainly isn't a significant portion of the user base.

Then nothing would ever get done.  Most users don't participate in the forums, much less in each individual thread.  Consensus amongst those participating is what I meant obviously.  That you don't use it is fine; it's for convenience about movie soundtracks in my opinion (I'd never use it with music), not an audiophile feature.  But then neither is equalization or a thousand other features JRiver has.  Lots of features are for niche uses.

gvanbrunt, I agree with you, but I'm mindful of the need to avoid making this so big of an ask it won't get done, or making it so complicated they're afraid to release it.  A fully customized set of controls would be very nice to have of course, but just something simple that works in a more appropriate way from the current method would also be extremely welcome.

[kensn]

Most users don't participate in the forums, much less in each individual thread.

As of this post there are 477 hits on this thread in less than 24 hours. I have been reading it. I normally don't post unless I can really contribute useful, pertinent information. I have seen response from the JRiver team like no other software developer out there. I am not sure where this would fall on the priority list....

Ken

[mojave]

One can create their own night mode:

1.  In DSP Studio add Adjust the Volume, Limiter, and Adjust the Volume to Parametric Equalizer
2.  Set the Limiter to Adaptive and whatever parameters you desire (default are fine)
3.  Set the first Adjust the Volume to 10 dB and set the second Adjust the volume to -10 dB
4.  Make sure Parametric Equalizer is checked
5.  While Parametric Equalizer is selected, click Options in the upper right of DSP Studio and check "Process independently of internal volume"

Adjust the input and output volume levels as desired. A higher first dB level means the compressor kicks in sooner.
Once finished, turn the Parametric Equalizer on/off for night mode.

[JimH]

As of this post there are 477 hits on this thread in less than 24 hours. I have been reading it. I normally don't post unless I can really contribute useful, pertinent information. I have seen response from the JRiver team like no other software developer out there. I am not sure where this would fall on the priority list....

Ken

I don't see any urgent need for change.

[mattkhan]

To get around the zone obstacle, I had suggested in the "Too Easy" thread a simple enhancement of adding an MCC command to enable/disable Night Mode, since that can be done live, just not easily.  No response from JRiver on that.

there is a MCWS command to turn a DSP block on/off

off
http://localhost:52199/MCWS/v1/DSP/Set?DSP=Adaptive%20Volume&On=0&Zone=Player&ZoneType=Name

on
http://localhost:52199/MCWS/v1/DSP/Set?DSP=Adaptive%20Volume&On=1&Zone=Player&ZoneType=Name

so you can do this today (assuming that block is configured to use adaptive volume already)

[gvanbrunt]

gvanbrunt, I agree with you, but I'm mindful of the need to avoid making this so big of an ask it won't get done, or making it so complicated they're afraid to release it.  A fully customized set of controls would be very nice to have of course, but just something simple that works in a more appropriate way from the current method would also be extremely welcome.

Agree with you completely. My comments were to show the extreme version of what could be done. I was hoping it could find other uses besides night mode and then perhaps it would get done on that basis.

I would be happy with manual adjustment that you decrease the output from night mode by a few db if wanted. That is the simplest to add and fixes having to mess with the volume after enabling a feature that is "supposed make it quieter". I guess you could do that with other dsp controls as it is to compensate? I never looked, but I think there is boost/cut in there somewhere. Not at home right now.

[Listener]

It seems to me that the current night mode is a reasonable way to address a common need.  A scenario:

1. Neighbor beats on the wall and yells "Turn down that cr**."

2. You turn down the volume in response.  However, the quiet parts are too quiet.

3. You'd like a way to make the quiet parts louder.

4. You engage quiet mode and not you can hear the quiet parts..

---
Combine the current quiet mode with using the volume control to lower the peaks and you get a graph like wer's friendlier mode.

[wer]

there is a MCWS command to turn a DSP block on/off

I wasn't aware of that, and it's very interesting to know, thanks.  Is there a way I can do that with a remote control, other than using a 3rd party utility to generate the http request and calling that using a run command that I assign to a remote button?

[Audionut11]

Combine the current quiet mode with using the volume control to lower the peaks and you get a graph like wer's friendlier mode.

Using the volume control adjusts the level of the entire signal equally, it does not apply adjustment of the peaks relative to other parts of the signal.

[Listener]

Using the volume control adjusts the level of the entire signal equally, it does not apply adjustment of the peaks relative to other parts of the signal.

And that is the point of using the volume control with quiet mode.  Quiet mode does the compression and the volume control adjusts the level of everything.

[mattkhan]

other than using a 3rd party utility to generate the http request and calling that using a run command that I assign to a remote button?

that's the only way I am aware of to do that

[gvanbrunt]

I wasn't aware of that, and it's very interesting to know, thanks.  Is there a way I can do that with a remote control, other than using a 3rd party utility to generate the http request and calling that using a run command that I assign to a remote button?

I'm going to whip up a script for Eventghost that will activate both the night mode and an optional volume adjustment. I'll post that later if anyone is interested. I use Eventghost to do quite a bit with my setup including automatically dimming lights when a movie is played etc. I also find it is simple to use to do custom things from the remote such as enter Theater View Mode etc. You can do most of this stuff via MC's internal system, but you can do a lot more using eventghost including call web services.

[wer]

And that is the point of using the volume control with quiet mode.  Quiet mode does the compression and the volume control adjusts the level of everything.

Having a multi-step, manual solution, perhaps one that involves 3rd party utilities, is a solution, I admit.  But it is not as good as a 1-step automated solution.  A manual garage door is a solution, but you don't want one.

I think the point was that since the current design of night mode necessitates a volume change, which is a non-trivial step to automate in a non-disruptive way, it would be better if the design implemented DRC in a way that did not necessitate extra work on the part of the user.

We could use the volume control after each album, too.  But it's better that we have volume leveling.  Anyway, I don't mean to sound difficult...

[Audionut11]

And that is the point of using the volume control with quiet mode.  Quiet mode does the compression and the volume control adjusts the level of everything.

Which doesn't provide a graph like the wer's friendlier mode, which is (part of) the problem.