Room Correction Software question

[everettT]

My new LCR speakers should be arriving this week, do I need to run audessey again even though they will be at the same position as the ones I have now?

Absolutely. New drivers, new baffle, new height, different response below 200hz, etc..

 

[BFL]

Absolutely. New drivers, new baffle, new height, different response below 200hz, etc..

Makes sense.. Wife will hate me

Thanks

 

[ReverendSlim]

One of the things that the aforementioned MultEQ-X does is correct for a known issue in the way delay is handled in D&M AVRs. So even if you are just using the in-AVR or app versions, here's something you should try: If you're in imperial measurements, take the values Audyssey detected for distance and multiply each by 0.889, then plug those numbers in instead.

The issue is that the AVR coarsely uses 1ft=1ms of delay, but your room would need to be -45F for that to be accurate. The 0.889 correction solves that problem. If you're using Metric, use 0.875 instead. This should get you better time alignment across the board and improve cross-channel imaging.

 

[lovinthehd]

One of the things that the aforementioned MultEQ-X does is correct for a known issue in the way delay is handled in D&M AVRs. So even if you are just using the in-AVR or app versions, here's something you should try: If you're in imperial measurements, take the values Audyssey detected for distance and multiply each by 0.889, then plug those numbers in instead.

The issue is that the AVR coarsely uses 1ft=1ms of delay, but your room would need to be -45F for that to be accurate. The 0.889 correction solves that problem. If you're using Metric, use 0.875 instead. This should get you better time alignment across the board and improve cross-channel imaging.

You have something definitive that this isn't just a math error in translation of measured delay into physical distance? Last I saw the engineers at Denon said it was just a conversion thing, didn't affect other issues. Not all Denons have that error, either. I recently changed over from a 4520 to 4700, and while the displayed physical distance translation was off by that factor, it didn't affect delays/levels otherwise (comparing the two results).

 

[ReverendSlim]

You have something definitive that this isn't just a math error in translation of measured delay into physical distance? Last I saw the engineers at Denon said it was just a conversion thing, didn't affect other issues. Not all Denons have that error, either. I recently changed over from a 4520 to 4700, and while the displayed physical distance translation was off by that factor, it didn't affect delays/levels otherwise (comparing the two results).

A math error of 1ms vs 1.132 becomes iterative to the closer speakers (typically surrounds). Denon's response was essentially that it was "close enough" for the consumer, so they weren't correcting it. And hey, maybe so... except that people who use MultEQ-X hear an improvement in imaging between speakers, and people who have made that correction themselves without MultEQ-X have heard the same improvement.

I can't speak to whether it's still present on the 4700, but the OP's 4400 DEFINITELY has the issue, hence my recommendation. I would have to compare a 4700 with MultEQ-X to see what values it assigns. With other models, you can change MultEQ-X to display in milliseconds instead of feet and the ms value in the software will be the constructive "feet" assigned in the AVR, differing from actual physical distance. Because... 1ft = 1ms in the AVR.

 

[lovinthehd]

A math error of 1ms vs 1.132 becomes iterative to the closer speakers (typically surrounds). Denon's response was essentially that it was "close enough" for the consumer, so they weren't correcting it. And hey, maybe so... except that people who use MultEQ-X hear an improvement in imaging between speakers, and people who have made that correction themselves without MultEQ-X have heard the same improvement.

I can't speak to whether it's still present on the 4700, but the OP's 4400 DEFINITELY has the issue, hence my recommendation. I would have to compare a 4700 with MultEQ-X to see what values it assigns. With other models, you can change MultEQ-X to display in milliseconds instead of feet and the ms value in the software will be the constructive "feet" assigned in the AVR, differing from actual physical distance. Because... 1ft = 1ms in the AVR.

If the actual delay measured is fine, and it's just the translation into a display to read, how does that change things? I may have seen that comment attributed to Denon, but also saw a response that it didn't affect the actual delays implemented. From what I can tell it just annoys people who want displayed a more accurate translation of the speed of sound into a physical distance. The difference in translation on the displayed physical distance from the 4520 to 4700 was obvious and off by that factor (just changed avr out with no change in speaker/room otherwise). I've seen some claims of users, but....

 

[BFL]

I guess I can try it and see if I can tell a difference. Thanks for the info either way!

 

[ReverendSlim]

If the actual delay measured is fine, and it's just the translation into a display to read, how does that change things? I may have seen that comment attributed to Denon, but also saw a response that it didn't affect the actual delays implemented. From what I can tell it just annoys people who want displayed a more accurate translation of the speed of sound into a physical distance. The difference in translation on the displayed physical distance from the 4520 to 4700 was obvious and off by that factor (just changed avr out with no change in speaker/room otherwise). I've seen some claims of users, but....

Because the delay measured isn't what is getting applied UNLESS you are using MultEQ-X on affected units. Hence the problem. There's a long thread about it over at AVS where the findings were confirmed with REW. It isn't just a matter of displayed distance not equaling physical distance. It's literally that Audyssey's software is passing off the actual distance as determined by ms of travel at 1.132 but that D&M's internal software uses 1 instead of 1.132 when applying delay.

Now again, there was some talk that it was sorted out in the most recent models, but I don't know that anyone confirmed it for sure. If you have the 4700 and MultEQ-X, you can check it as mentioned previously.

 

[lovinthehd]

Because the delay measured isn't what is getting applied UNLESS you are using MultEQ-X on affected units. Hence the problem. There's a long thread about it over at AVS where the findings were confirmed with REW. It isn't just a matter of displayed distance not equaling physical distance. It's literally that Audyssey's software is passing off the actual distance as determined by ms of travel at 1.132 but that D&M's internal software uses 1 instead of 1.132 when applying delay.

Now again, there was some talk that it was sorted out in the most recent models, but I don't know that anyone confirmed it for sure. If you have the 4700 and MultEQ-X, you can check it as mentioned previously.

Nope, don't use MultEQ-X and no particular plan to.

I think someone pointed out that thread at avs before and I started to wade thru it but didn't get thru all of it, maybe I'll give it another shot but if only affecting that specific application, I'm in no hurry. I certainly couldn't tell any audible difference and if the delay is applied by the processor vs an outside additional app/calculation, that perhaps makes sense. For me it just appears to use the same amount of delay, in changing from an older unit that didn't have the issue to a newer one that does reflect the different conversion to physical distance.

There anything official from Denon recognizing the situation? If so, any plan of addressing it with a firmware update? Or is it baked into the hardware somehow?

 

[ReverendSlim]

Nope, don't use MultEQ-X and no particular plan to.

I think someone pointed out that thread at avs before and I started to wade thru it but didn't get thru all of it, maybe I'll give it another shot but if only affecting that specific application, I'm in no hurry. I certainly couldn't tell any audible difference and if the delay is applied by the processor vs an outside additional app/calculation, that perhaps makes sense. For me it just appears to use the same amount of delay, in changing from an older unit that didn't have the issue to a newer one that does reflect the different conversion to physical distance.

There anything official from Denon recognizing the situation? If so, any plan of addressing it with a firmware update? Or is it baked into the hardware somehow?

It's definitely something they COULD address with a firmware update... but consider how many older units we're talking about. You're looking at new firmware for every model going back how many years? That's likely why they've said that it's "close enough". Do you think the speed of sound at -45F is close enough? I don't.

In the meantime, it's an easy enough bit of math to plug in and compare using any Dolby Atmos demo clip to hear if cross-channel imaging improves, and that's why I mentioned it.

 

[lovinthehd]

It's definitely something they COULD address with a firmware update... but consider how many older units we're talking about. You're looking at new firmware for every model going back how many years? That's likely why they've said that it's "close enough". Do you think the speed of sound at -45F is close enough? I don't.

In the meantime, it's an easy enough bit of math to plug in and compare using any Dolby Atmos demo clip to hear if cross-channel imaging improves, and that's why I mentioned it.

I was somewhat surprised that the 4400 was affected, but since that's beyond my 4520 at least fits there. I thought I'd seen just more recent models, tho. More why I'd like to see an official Denon/Masimo position statement....

 

[ReverendSlim]

I was somewhat surprised that the 4400 was affected, but since that's beyond my 4520 at least fits there. I thought I'd seen just more recent models, tho. More why I'd like to see an official Denon/Masimo position statement....

I doubt you'll ever see anything official beyond what Audyssey have explained in the MultEQ-X videos.

 

[BFL]

Just to clarify, I use audessey thru the $20 app version, so these delays that need tweaking you are referring to still apply? And is it for all speakers, or just the surrounds?

 

[ReverendSlim]

Just to clarify, I use audessey thru the $20 app version, so these delays that need tweaking you are referring to still apply? And is it for all speakers, or just the surrounds?

Yes, it still applies. And yes, you apply the x0.889 correction to all channels, subs included.

 

[BFL]

Yes, it still applies. And yes, you apply the x0.889 correction to all channels, subs included.

Thanks

 

[BFL]

Thanks....so, .889 x the distance numbers that i have listed

 

[lovinthehd]

Yes, it still applies. And yes, you apply the x0.889 correction to all channels, subs included.

That's not the same as MultEQ-X you mentioned earlier, tho. I still didn't perceive any difference between using the editor app and the avr (except for the readout of the "feet"). Are you advising that people use the correction factor to adjust to physical distance more accurately as information or are you changing the settings in the avr and/or app by that factor?

 

[ReverendSlim]

That's not the same as MultEQ-X you mentioned earlier, tho. I still didn't perceive any difference between using the editor app and the avr (except for the readout of the "feet"). Are you advising that people use the correction factor to adjust to physical distance more accurately as information or are you changing the settings in the avr and/or app by that factor?

There is no difference between using the editor app and the AVR, as both get you the wrong result due to D&M's software error. I am advising people who AREN'T using MultEQ-X (which does the correction automatically) to do the correction manually. You are changing the distances on the AVR post-Audyssey to their value in feet x 0.889.

 

[lovinthehd]

There is no difference between using the editor app and the AVR, as both get you the wrong result due to D&M's software error. I am advising people who AREN'T using MultEQ-X (which does the correction automatically) to do the correction manually. You are changing the distances on the AVR post-Audyssey to their value in feet x 0.889.

If the delay is correct then why change it? I'm saying the delays were set the same by my 4520 (without the math conversion error) as the delays set by my 4700 (but with the math error readout in "feet").

 

[ReverendSlim]

If the delay is correct then why change it? I'm saying the delays were set the same by my 4520 (without the math conversion error) as the delays set by my 4700 (but with the math error readout in "feet").

Because the delays aren't correct. Perhaps we should clarify... Are you saying that the distances in your 4700 match up to the distances you had in your 4520 x 0.889? That's the question. If your 4700 is already making the correction, then it doesn't matter if you use the editor app or the in-AVR version.