Print

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

[mattkhan]

I would like to revisit this thread - http://yabb.jriver.com/interact/index.php?topic=88193.0 - which, along with the linked thread, says the recommended way to handle the LFE channel is to set the SW to +10dB in Room Correction. This will reduce the level of the other channels by 10dB and thus the correct channel balance is ensured.

However the 2nd aspect of that thread is about bass management which sums the other channels into the "physical" SW channel.

As I understand it a typical consumer prepro does

- low pass each main input channel, attentuate the low pass by 15dB
- attenuate LFE input channel by 5dB
- sum all those inputs to the SW output channel
- apply 15dB gain to the SW output channel

Is this what the jriver room correction/bass management implementation does?

If the above is corrent then doesn't that approach, of just reducing the other channels by 10dB, still leave the SW channel open to (digital) clipping in the event of high (near full strength) signal levels in the other channels + the LFE channel?

NB: I realise I can measure this to verify but I probably won't have time for a few days hence the post

[mwillems]

If the above is corrent then doesn't that approach, of just reducing the other channels by 10dB, still leave the SW channel open to (digital) clipping in the event of high (near full strength) signal levels in the other channels + the LFE channel?

NB: I realise I can measure this to verify but I probably won't have time for a few days hence the post

The way your question is worded I can't tell if you're concerned about clipping during the DSP chain or on the output or both?

With regard to the DSP chain: JRiver's internal audiopath is 64 bit floating point, so my understanding is that clipping generally isn't an issue until audio is preparing to leave JRiver's audio engine and has to go back to integer (see this thread for detail: http://yabb.jriver.com/interact/index.php?topic=69614.0).  So clip protection only engages when the output would clip, it's unconcerned about what happens during the audio path.  

With regard to "soft" clipping (i.e. clipping on the output that would trip JRiver's clip protection), my understanding is that JRSS and the Room Correction/Bass Management panels automatically leave appropriate amounts of headroom when summing channels (the amount of headroom being dependent on the number of channels being downmixed).  If you're doing your sub mixing in PEQ or convolution, you're obviously on your own and need to leave some headroom (unless you use internal volume).

I haven't done methodical testing, but I've used JRSS to handle downmixing to a sub in the past, and never saw clip protection engage (even trying to trip it).  

[mattkhan]

My concern is that I'm implementing bass mgmt myself and I now think I have been relying on jriver clip protection to avoid clipping when the low passed mains are summed into the sw output channel

Curiosity got the better of me so I ran a few tests as follows

Test 1
- send full strength sine wave from REW signal generator to jriver via ASIO line in at 25Hz
- set jriver to 5.1 output + JRSS mixing + use room correction
- add PEQ stage to copy input channel to all other channels
- add convolution stage using my filters
- review output in analyser and audacity (set to record the SW output)
- remove clip protection
- repeat output checks

==> result = clip central when clip protection removed

Test 2
- as per test 1 but add output scaling factor (-5dB aka 0.562 to low pass main channels, -15dB aka 0.1778 to LFE)

==> result = scaling factor either not supported or I'm doing it wrong

Test 3
- as per test 1 but remove convolution and add jriver room correction (24dB and 48dB/octave slopes to ensure main channels not involved in output stage)

==> result = clipping not as severe but still clip central, peak level of 100% reported only when I reduce the sine wave level by 5.2dB in REW


This suggests that jriver is using the "standard" approach to bass mgmt of leaving 5dB headroom for main channel summation (seems reasonable though reportedly has been breached by certain scenes).

Does this test method seem ok?
Does jriver support scaling in the convolver cfg?
Why does the peak per channel level disagree with the "peak level" indicator in the analyser? I can see 0dB in the subwoofer feed for example (and -150dB in the other channels) but >140% in the peak level indicator.

[mattkhan]

actually if jriver doesn't support the scaling factor then correctly supporting bass mgmt through convolution seems difficult doesn't it? you'd have to use PEQ to copy the input channels with some attenuation and then route them to the low or high pass as appropriate wouldn't you?

[mwillems]

My concern is that I'm implementing bass mgmt myself and I now think I have been relying on jriver clip protection to avoid clipping when the low passed mains are summed into the sw output channel

Ah, that makes sense.

This suggests that jriver is using the "standard" approach to bass mgmt of leaving 5dB headroom for main channel summation (seems reasonable though reportedly has been breached by certain scenes).

Does this test method seem ok?

I'm not sure as I'm a little foggy on what's happening in your third testing method?  Matt confirmed at one point that their headroom was a compromise between not over-attenuating, but still preventing most clipping.  The point was made that there's no "no clip" guarantee with the downmixing, which is why clip protection is there (to catch the rare scene that blows through).

Does jriver support scaling in the convolver cfg?

I've never tried scaling in the .cfg file, so I can't confirm whether it works or not.  The fact that a scaling factor of "0" means unity gain (i.e. what I would call a scaling factor of 1) and negative numbers flip phase always threw me (I could never figure out how to express attenuation when 0 is already 1), so I've always just used PEQ to attenuate the channels as needed.
 

Why does the peak per channel level disagree with the "peak level" indicator in the analyser? I can see 0dB in the subwoofer feed for example (and -150dB in the other channels) but >140% in the peak level indicator.

I think one is showing you the actual output, the other is showing you the signal's level in the audio chain.  Put another way, no output signal can go higher than 0dB; even with clip protection disabled it just gets flattened. So the Sub can't go above 0dB. The peak level is showing where the peak is in the audio chain (i.e. it's telling you that clipping is occurring which might not be obvious if clip protection were engaging).  I'm not sure about that, but that's how I've always read the two (because I've never seen clips on the channels, only in the peak level).

actually if jriver doesn't support the scaling factor then correctly supporting bass mgmt through convolution seems difficult doesn't it? you'd have to use PEQ to copy the input channels with some attenuation and then route them to the low or high pass as appropriate wouldn't you?

I don't think it's an issue, because (per the thread I linked above) no clipping occurs during the DSP chain (because it's in floating point).   There isn't an opportunity to clip until the output.  So you can just use PEQ to attenuate the channels after routing with convolution.  If the convolver added too much boost as long as it's netted out before the end of the chain, it's as though it never happened.  Here's Matt explaining:

Since all audio data is 64bit floating point, there's no hard limit at -1.0 and 1.0.

So if one effect does +100dB and the next effect does -100dB, no clipping occurs.

It's only a clip when that hard-limit between -1.0 and 1.0 is enforced before output (because it's required by the soundcard), and this is only at the very end.

[mattkhan]

I've never tried scaling in the .cfg file, so I can't confirm whether it works or not.  The fact that a scaling factor of "0" means unity gain (i.e. what I would call a scaling factor of 1) and negative numbers flip phase always threw me (I could never figure out how to express attenuation when 0 is already 1), so I've always just used PEQ to attenuate the channels as needed.

the only suggestion I've found so far is that it uses decibel voltage ratio, e.g. -10dB is 0.316 but it's written as <output channel>.<scale> so 0.316 is not 0.316 but is in fact output channel 0 with scale factor .316 (though this seems to do nothing in my quick test).

I will dabble some more at the weekend. There are definitely times when a simpler setup would be a good thing

[mattkhan]

Some pics to demonstrate my test, the signal chain is

REW signal generator -> ASIO Channel 7
JRiver ASIO Line In 2 channels with offset 6
Output Format 5.1 + JRSS mixing on
PEQ set to copy the L channel (i.e. the REW signal) to the other 5 channels)
RC set to move bass to the subwoofer at 80Hz

[mattkhan]

here's the output with a -20dBFS (peak) sine wave, no problems as expected

[mattkhan]

the output with a -5.3dBFS (peak) sine wave is in analyser_83.png, this is the max before jriver reports an overflow & you can see that my audio device sees a -0.1dBFS signal here.

I've also attached the output at 0dBFS in analyser_3.png which shows that we've blasted through into clipping.

I don't think it's an issue, because (per the thread I linked above) no clipping occurs during the DSP chain (because it's in floating point).   There isn't an opportunity to clip until the output.  So you can just use PEQ to attenuate the channels after routing with convolution.  If the convolver added too much boost as long as it's netted out before the end of the chain, it's as though it never happened.  

as far as I can see this demonstrates that jriver bass management does clip on output when presented with a full strength signal on all channels, i.e. it cannot be allowing sufficient headroom here. Is my test wrong/invalid or does it just indicate a bug?

[mwillems]

the output with a -5.3dBFS (peak) sine wave is in analyser_83.png, this is the max before jriver reports an overflow & you can see that my audio device sees a -0.1dBFS signal here.

I've also attached the output at 0dBFS in analyser_3.png which shows that we've blasted through into clipping.
as far as I can see this demonstrates that jriver bass management does clip on output when presented with a full strength signal on all channels, i.e. it cannot be allowing sufficient headroom here. Is my test wrong/invalid or does it just indicate a bug?

No I think your test is correct, but I don't think it's a bug either; I think it's a conscious design choice.

As I noted above Matt has indicated that their mixing headroom setup isn't designed to never clip under any circumstances because that would require a massive reduction in volume (imagine, for instance, downmixing 7.1 to 2.0; to guarantee no clips you'd need something like 18dB of attenuation).  It's a compromise between virtually never clipping and acceptable real world attenuation.  And clip protection is there to catch the occasional "blow-through."  Actual clipping is hard to make happen unless you turn off the safety net. 

Maybe the devs can provide some insight?

[mattkhan]

No I think your test is correct, but I don't think it's a bug either; I think it's a conscious design choice.

As I noted above Matt has indicated that their mixing headroom setup isn't designed to never clip under any circumstances because that would require a massive reduction in volume (imagine, for instance, downmixing 7.1 to 2.0; to guarantee no clips you'd need something like 18dB of attenuation).  It's a compromise between virtually never clipping and acceptable real world attenuation.  And clip protection is there to catch the occasional "blow-through."  Actual clipping is hard to make happen unless you turn off the safety net. 

Maybe the devs can provide some insight?

I can understand that in a downmixing scenario but it seems less obviously correct where no mixing, apart from bass management, is involved.

[mwillems]

I can understand that in a downmixing scenario but it seems less obviously correct where no mixing, apart from bass management, is involved.

I think I agree, especially since your tests show that the literal worst case scenario (mixing full-scale sine waves of the same periodicity) only requires another -.3dB to handle successfully.

[mattkhan]

if a passing dev picks up on this then it would be good if they can confirm whether or not jriver supports output scaling in the convolver cfg file

[mattkhan]

I found this post

There are still a few unsupported features of Convolver configuration files.  I haven't seen them used, but just let me know if they're important to you:

Input line delays (different than output delays mentioned above)
Multiple output channels in a path (we support multiple input channels to one output channel, but not the other way around)
Output channel weights (this seems ambiguous / unnecessary since multiple paths can target an output channel, and you can set an input weight)

this implies input weights are supported, I don't really understand the distinction between input and output here though.

[mojave]

I've also attached the output at 0dBFS in analyser_3.png which shows that we've blasted through into clipping.
as far as I can see this demonstrates that jriver bass management does clip on output when presented with a full strength signal on all channels, i.e. it cannot be allowing sufficient headroom here. Is my test wrong/invalid or does it just indicate a bug?

I see you've been participating in the discussion at data-bass.com.  JRiver does use different bass managements levels for 5.1 vs 7.1 and allows more headroom for 7.1. I've never seen clipping in my testing with real content. I can check again with Godzilla, How To Train Your Dragon, and Edge of Tomorrow but I will need to rent or borrow a couple of them.

Even if JRiver does clip with a worse case scenario test, it doesn't "fail" the test really since the user can still do a - dB adjustment for all channels in PEQ. In other words, the user still has complete control. The user really can't fix a receiver that is clipping the output in bass management.

JRiver does clip when downmixing to lower channel counts. This is an issue if you don't use internal volume or aren't careful with the volume. I wish there was an option for "safe" downmixing.

You might want to check out the discussion for downmixing to mono. This method is used for the Spectrum Labs analysis at data-bass and was fully vetted by maxmercy.

[mattkhan]

I have used that method for analysing a track in speclab, v useful

how does audiolense handle this? does it attenuate the low pass of each main channel in the same way as jriver?

[mattkhan]

as far as I can see, input weights don't work either.

Is there a current list of supported features for the jriver convolver? the list in that thread can't be right as it references a partitioned impl to reduce latency (doesn't on my system) and input weights (no apparent effect).

[mwillems]

as far as I can see, input weights don't work either.

Is there a current list of supported features for the jriver convolver? the list in that thread can't be right as it references a partitioned impl to reduce latency (doesn't on my system) and input weights (no apparent effect).

As far as I know, that thread is the list, but it's odd; Matt confirms a partitioned implementation in that thread, but I see textbook non-partitioned latency when I measure (and you did too as I recall). 

As for scaling, is there any reason not to use PEQ in the meanwhile?  Or are you just trying to run the issue down?

[mattkhan]

As far as I know, that thread is the list, but it's odd; Matt confirms a partitioned implementation in that thread, but I see textbook non-partitioned latency when I measure (and you did too as I recall). 

As for scaling, is there any reason not to use PEQ in the meanwhile?  Or are you just trying to run the issue down?

yes I measured it as showing textbook non partitioned latency too.

weighting in the convolver cfg looks like the simplest, most convenient implementation as it means I can just change a few values in the cfg file and it just works. Changing filters means ploughing through a load of filters and adjusting gains (trivial but tedious) while using PEQ means switching to, I think, a 12 channel output format. I tried this but it meant I could not open asio line in so I couldn't test the outcome, bit of a blocker to say the least! Doesn't this also mean I lose any mixing capability and have to do everything by hand? not sure if that is a big issue or not though.

It would be nice to get a clear statement of the functionality provided by jriver here though. This is, I think, the 3rd time I've bumped into something around the convolver that is left unresolved because no one will say what functionality it actually implements. It's quite frustrating really, it (knowing whether a feature is supported or not) doesn't seem like too much to ask!

[mwillems]

weighting in the convolver cfg looks like the simplest, most convenient implementation as it means I can just change a few values in the cfg file and it just works. Changing filters means ploughing through a load of filters and adjusting gains (trivial but tedious) while using PEQ means switching to, I think, a 12 channel output format. I tried this but it meant I could not open asio line in so I couldn't test the outcome, bit of a blocker to say the least! Doesn't this also mean I lose any mixing capability and have to do everything by hand? not sure if that is a big issue or not though.

I'm not sure I'm following you here (we might be talking past each other).  If you're using JRiver's convolver, you need to have enough output channels in output format for the convolver to do the routing.  So you've got all the channels you need already.  I'm not talking about doing all of your bass management in PEQ, I'm just talking about using PEQ to emulate input scaling on the convolver.

You just would add some PEQ volume level adjustment before the convolution module to simulate input scaling.  I'm talking about something as trivial as adding two filters in the PEQ before the convolver: an "adjust the volume" filter for the sub channel with whatever attenuation you're looking for (-5.3dB, etc.), and a similar filter for the other channels.  

It shouldn't affect mixing targets or output format at all.

It would be nice to get a clear statement of the functionality provided by jriver here though. This is, I think, the 3rd time I've bumped into something around the convolver that is left unresolved because no one will say what functionality it actually implements. It's quite frustrating really, it (knowing whether a feature is supported or not) doesn't seem like too much to ask!

I agree.  It sounds like the channel scaling isn't working at all, so you might do well to report a bug against the current build with a link to the thread that said it was supported.  That should get you an answer on that point.  Otherwise, I think it might make sense to start a thread with an appropriately descriptive title ("What features are supported by JRiver's Convolver?" or something) and lay out the issues you've identified cleanly in the first post.  

I think threads like this one may not get much dev attention because the titles make them sound like advice threads rather than bug threads, and there's a lot of discussion on various topics.

[mattkhan]

I'm not sure I'm following you here (we might be talking past each other).  If you're using JRiver's convolver, you need to have enough output channels in output format for the convolver to do the routing.  So you've got all the channels you need already.  I'm not talking about doing all of your bass management in PEQ, I'm just talking about using PEQ to emulate input scaling on the convolver.

I was thinking in terms of only applying the scaling the low passes only. However I now see that you're saying (or I think you're saying) apply a PEQ stage before convolution to attentuate the input channels and then apply a PEQ stage after to raise the output channels back up to the intended level. I will give this a try.

I agree.  It sounds like the channel scaling isn't working at all, so you might do well to report a bug against the current build with a link to the thread that said it was supported.  That should get you an answer on that point.  Otherwise, I think it might make sense to start a thread with an appropriately descriptive title ("What features are supported by JRiver's Convolver?" or something) and lay out the issues you've identified cleanly in the first post.  

I think threads like this one may not get much dev attention because the titles make them sound like advice threads rather than bug threads, and there's a lot of discussion on various topics.

fair point, I will do that

[Buckster]

I tried (and have gone back to bitstream lossy) - outputting 6-8 channel PCM - 48/16 - but was also having clipping problems

admittadly I'm applying a 10dB boost to the LFE channel (as my av amp doesn't apply it to PCM in) - but as far as I know this doesn't make a difference as it just makes all other channels - 10dB

but with a lot of content I was still getting anywhere from -2 to -5 or so dB volume reduction as reported by the audio stream info reported by JRiver - for the internal JRiver engine to avoid clipping

often happened after anything dynamic going on with the sound - and if a very dynamic scene in a film - you could actually hear the volume adjust down

[6233638]

as far as I know this doesn't make a difference as it just makes all other channels - 10dB

Have you actually tried it the other way around? Reducing all channels except LFE by 10dB

[Buckster]

yes - thanks for suggestion - but tried in the past and doesn't seem to make any difference

I think it was one of the devs on here that said that -10 on all channels except LFE is same as +10 on LFE and other channels untouched

[mattkhan]

yes - thanks for suggestion - but tried in the past and doesn't seem to make any difference

I think it was one of the devs on here that said that -10 on all channels except LFE is same as +10 on LFE and other channels untouched

That is correct, room correction reduces the other channels rather than boosting one of them. Were you using jriver to do bass mgmt? If so there is some info in http://yabb.jriver.com/interact/index.php?topic=95807.0 that might help.

[Hilton]

The best way I've found to manage this is have two zones setup. My amp has the same problem.

I also push 7.1 LPCM to my amp as it doesn't support DTS-HD MA and it doesn't do bass management very well.
To avoid pushing +10 on the LFE in the MC DSP I have an 8ch zone configured with the sub calibrated to the mains with a DTS-HD MA test disc with all MC DSP levels flat.
Effectively I've added the +10 in the Sub Amp as it's got way more headroom than my AVR amp anyway.

I also have a 2.1 Zone where I've backed the MC DSP LFE down 10db.

This avoids all the clipping issues and is the cleanest way to switch between 2ch and multi-channel and also get the best out of your AMP without driving your pre-amp so hard.

PS. I've also saved another seating position in the AVR memory with -10db on the sub for when Im using other inputs other than MC into the amp. (it has 3 seating position memories all calibrated for the same seating position, I also have a late night mode memory with -20db on the sub)

AVR Memory 1. MC LPCM input has +10 LFE by having the sub turned up when I calibrated it.  I auto zone switch switch between 7.1 and 2.1. The 2.1 has -10db on LFE in the DSP.
AVR Memory 2. Other input (PS3 etc) -10db in the Amp for the LFE to bring it back down.
AVR Memory 3. Late night mode -20db LFE on the Amp

[6233638]

That is correct, room correction reduces the other channels rather than boosting one of them.

Yes, I know that people have said that it should, I just wondered if anyone had actually tested it recently.

[mwillems]

yes - thanks for suggestion - but tried in the past and doesn't seem to make any difference

I think it was one of the devs on here that said that -10 on all channels except LFE is same as +10 on LFE and other channels untouched

That's only true if you do it in the room correction module, not if you do it in PEQ.  If you apply the boost in PEQ or in Equalizer it will be clip city.  How exactly are you applying the 10dB boost in JRiver?

Yes, I know that people have said that it should, I just wondered if anyone had actually tested it recently.

There are some relevant tests in this thread's sister threads:

http://yabb.jriver.com/interact/index.php?topic=95717.0
http://yabb.jriver.com/interact/index.php?topic=95807

Room correction seems to be ensuring zero net gain (or close to it); PEQ, obviously, does not.

[mattkhan]

Yes, I know that people have said that it should, I just wondered if anyone had actually tested it recently.

Yes, me