Digital Room Correction Project

[Carl_Huff]

On latency ...

Adding in a BruteFIR convolver to your audio chain will add a 40 to 50ms delay to the audio dependent upon the processor used. A video frame roughly equates to 30ms. That means when watching a DVD or any other video source the audio will lag the video by roughly 1.5 frames. Most people begin to perceive the delay when the difference is 2 frames or greater. The best way to fix this problem would be to delay your video by an equal amount bring the audio back in sync with the video. There are video processors on the market allow you to do this.

[lazycatken]

Originally Posted by boconnor

The question then becomes is it better to use 24 bits or 16 bits in the final digital to analogue conversion? Remember that the original input data stream that goes into the convolver is likely to come from a CD source. That means that the original data stream is in 16-bit format. Even if it is up-converted to 24 bits, no additional information is created in that up sampling process. Provided the convolution algorithms are correctly designed, convolving a 16-bit input with a 32-bit floating point file should not result in any loss of information. Certainly not information that would be audible.

Just do an experiment.
Normalize a music clip. Let's call the result N.
Filter N. Normalize the result, then convert to 16 bits format. Let's cal the result NF.
Play NF. Then play N.
You'll find N sounds louder.

I think that the question can only ultimately be answered through psychoacoustic testing. A properly designed and executed test will indicate if there are audible improvements in going from 16 bits to 24 bits in the final DAC process.

In my system, 24bits indeed sounds better. More detail and emotional...

I hired an anechoic chamber

That's great! How much per hour did they charge?

I also think that room correction is easier if the reflected waves are both lower in intensity and there is a longer time gap between the direct wave and the reflected one - on the basis that the algorithms will have less work to do in distinguishing the corrections needed for the direct wave compared with correcting the reflected waves. At higher frequencies the DRC program uses an increasingly short time window so that would imply to me that the corrections are attempting to deal more with the direct wave from the loudspeaker rather than the room reflections.

As you have noticed, DRC uses an increasingly short time window at high frequency range. http://drc-fir.sourceforge.net/doc/drc004.gif
That means, reflections that with time gap longer than the window can not be filtered out...

I am very persuaded by the argument of Seigfreid Linkwitz concerning the best speaker geometry and placement of speakers in a room to generate a sound field that convinces the ear/brain combination that you are in the recording space rather than the listening room.

By making the impulse respone of the whole system(equipment + room) close to ideal impulse response, DRC tried to make the sound reproduced in listening position close to original music source. In my opinion, that means, the music produced in mastering studio, you know, nearly all direct sound.

BTW, did you have to do balancing for filtered music?
In my system, right channel must be distorted 3dB. That's another reason for 24 bits...

[boconnor]

Originally Posted by Carl_Huff

On latency ... Adding in a BruteFIR convolver to your audio chain will add a 40 to 50ms delay to the audio dependent upon the processor used. A video frame roughly equates to 30ms. That means when watching a DVD or any other video source the audio will lag the video by roughly 1.5 frames. Most people begin to perceive the delay when the difference is 2 frames or greater. The best way to fix this problem would be to delay your video by an equal amount bring the audio back in sync with the video. There are video processors on the market allow you to do this.

That's interesting about the latency calculation. So what you are saying is that a latency of greater than 60 ms will result in a perceptible ‘out of sync’ mismatch.

Do you know what the latency would be for the Behringer DCX2496 unit that I am using? I would have thought that it would be of comparable latency to your calculation for BruteFIR, given that BruteFIR is known for its speed and I would be surprised if the DSP unit inside the Berenger was very fast. If it is of comparable latency (or greater) then that would imply I should already be seeing a perceptible delay. But there has been no problem so far.

[boconnor]

Originally Posted by lazycatken

Just do an experiment. Normalize a music clip. Let's call the result N. Filter N. Normalize the result, then convert to 16 bits format. Let's cal the result NF. Play NF. Then play N. You'll find N sounds louder. In my system, 24bits indeed sounds better. More detail and emotional...

I suppose we need to be clear as to what is the question and therefore what is the experiment seeking to answer. As I understand it what you are saying is that a 24 bit signal “sounds better” after having a filter applied to it compared with a 16 bit signal with a filter applied. And by sounds better I suppose that would mean that there is less distortion or greater clarity or any other description that would fit the idea that the is no distortion of the signal. Or less distortion compared to that in the 16-bit signal.

So what we need is an experiment which allows us to determine if a 24 bit input signal convolved has less artefacts in it compared with a 16-bit signal similarly convolved. My experiment to answer that question would be as follows:

Take a known analogue signal. Do two analogue to digital conversions, producing a 16-bit datastream and a 24 bit datastream.

Call the 16-bit conversion A. Call the 24 bit conversion B. Convolve both A and B with the same filter. If necessary normalise both A and B so there is no clipping of the datastreams. Check that both A and B will have the same average signal amplitude after conversion back to analogue.

Convert both A and B back to analogue, A with a 16-bit conversion, B with a 24 bit conversion.

Use a ABX software program to do a double blind experiment to see if there is a perceptible difference between A or B. If there is a perceptible difference then it is likely that the 24 bit datastream has retained more information (less distortion) than the 16-bit datastream. If there is no perceptible difference compared to chance, then it doesn't matter whether you use a 16-bit datastream or 24 bit datastream for conversion. My guess is that there would be no perceptible difference but that's an empirical question.

That's great! How much per hour did they charge?

About 125 Australian dollars per hour. I hired the chamber for 2 hours.

As you have noticed, DRC uses an increasingly short time window at high frequency range. http://drc-fir.sourceforge.net/doc/drc004.gif That means, reflections that with time gap longer than the window can not be filtered out... By making the impulse respone of the whole system(equipment + room) close to ideal impulse response, DRC tried to make the sound reproduced in listening position close to original music source. In my opinion, that means, the music produced in mastering studio, you know, nearly all direct sound. ...

I have listened to music in a very acoustically dead environment. In fact I have listened to music in an anechoic chamber, and I must say that whilst there was fantastic clarity it was a very empty experience and not very emotionally engaging. Sort of like being inside a huge pair of headphones, but with the sound in front of you rather than inside your head.

The point that writers like Linkwitz are making is that you actually need a normal reverberant space, the sort of space that you would find in a living room, to generate the reflections needed for the listener to perceive phantom images in the soundstage. And being able to perceive a credible soundstage in front of you is essential to the emotional engagement with the reproduced performance.

The great advantage of the DRC program is that its control of bass response in the room is fantastic. When I looked at the output from the program it was creating many hundreds of filter taps for frequencies below 100 Hz. As the frequency increases the filtering is reduced. So in that sense the reflections from the higher frequencies are being left alone, as you say. And I think that is a good thing. Because it means that there is a nice reverberant space that is giving the right psychoacoustic clues to the listener.

BTW, did you have to do balancing for filtered music? In my system, right channel must be distorted 3dB. That's another reason for 24 bits...

Can't say that I've noticed a need to adjust left or right channels after filtering. I have a very symmetrical speaker setup. Both speakers are placed in the room at the same distance from the side walls in a triangle configuration. And the distance from each speaker to the listener is the same within 1 cm.

[Carl_Huff]

Do you know what the latency would be for the Behringer DCX2496 unit that I am using? I would have thought that it would be of comparable latency to your calculation for BruteFIR, given that BruteFIR is known for its speed and I would be surprised if the DSP unit inside the Berenger was very fast. If it is of comparable latency (or greater) then that would imply I should already be seeing a perceptible delay. But there has been no problem so far.

As I remember it, the Behringer DCX2496 runs a SHARC DSP to do its processing. The SHARC is a good performer. I would be very surprised if it represents more than 30ms delay total.

On 16 vs 24 bit ...
Always use 24 bit. In an ideal world, If you load allpass filters into a convolver what you put in would be identical to what comes out. If the output matches the input, the system is said to be 100% 'bit accurate'. However in the real world that never happens. What you will find is that DSP processing will trash a minimum of 2 bits and more if there is a sample rate conversion. As crazy as it seems, you must run at 24 bits to be 16 bit accurate.

[lazycatken]

Originally Posted by boconnor

So what we need is an experiment which allows us to determine if a 24 bit input signal convolved has less artefacts in it compared with a 16-bit signal similarly convolved.

What I mean is, more dynamic range is necessary for filtered sound.
Just use Audacity, check the waveform of N & NF.

I have listened to music in a very acoustically dead environment. In fact I have listened to music in an anechoic chamber, and I must say that whilst there was fantastic clarity it was a very empty experience and not very emotionally engaging. Sort of like being inside a huge pair of headphones, but with the sound in front of you rather than inside your head.

That's interesting... I can image it.

The point that writers like Linkwitz are making is that you actually need a normal reverberant space, the sort of space that you would find in a living room, to generate the reflections needed for the listener to perceive phantom images in the soundstage. And being able to perceive a credible soundstage in front of you is essential to the emotional engagement with the reproduced performance.

Someone said the phantom image is due to sound from sides of ears.
I tried heavily damping at sides of listening position, indeed resulted in less lively sound.

The great advantage of the DRC program is that its control of bass response in the room is fantastic. When I looked at the output from the program it was creating many hundreds of filter taps for frequencies below 100 Hz. As the frequency increases the filtering is reduced. So in that sense the reflections from the higher frequencies are being left alone, as you say. And I think that is a good thing. Because it means that there is a nice reverberant space that is giving the right psychoacoustic clues to the listener.

Well...Anyway, I tried to raise MPWindowExponent to 1.5 and MPLowerWindow to 740, that is much stronger than Extreme(1/740).
Filtered music is much clear, I have to say, huge improvement.
Even more lively, perphaps, it's due to less noisy.
And make me more enjoy music...great...

I have a very symmetrical speaker setup. Both speakers are placed in the room at the same distance from the side walls in a triangle configuration.

I tested 4 systems.
Before filtering, can't hear any unbalance, though, all with asymmetrical setup.
After filtering, 2~6dB adjustment is necessary, depends on correction level.

[boconnor]

Originally Posted by Carl_Huff

On 16 vs 24 bit ... Always use 24 bit. In an ideal world, If you load allpass filters into a convolver what you put in would be identical to what comes out. If the output matches the input, the system is said to be 100% 'bit accurate'. However in the real world that never happens. What you will find is that DSP processing will trash a minimum of 2 bits and more if there is a sample rate conversion. As crazy as it seems, you must run at 24 bits to be 16 bit accurate.

Interesting stuff about 2 bits being trashed. I think the final arbiter is whether or not we can perceive a difference. That is why I suggest a proper psychoacoustic test to decide. If it showed that 24 bits was needed then so be it – I’m not wedded to 16 bits. In fact, my gear is going to convert the analogue signals to 24 bits anyway (that’s just the way there are designed).

But I remain sceptical about the absolute need for the 24 bits. Particularly given the maximum 60 db dynamic range in a normal listening room at home, I can’t see a difference of 24 bits vs 16 bits being perceived in those environments.

[boconnor]

Originally Posted by lazycatken

Anyway, I tried to raise MPWindowExponent to 1.5 and MPLowerWindow to 740, that is much stronger than Extreme(1/740). Filtered music is much clear, I have to say, huge improvement. Even more lively, perphaps, it's due to less noisy. And make me more enjoy music

I haven’t varied any of the parameters – just used the defaults. Looks like you’ve found a big difference in the sound using the MPWindowExponent and MPLowerWindow parameters. How did you decide on those values? Have you varied any other parameters?

I tested 4 systems. Before filtering, can't hear any unbalance, though, all with asymmetrical setup. After filtering, 2~6dB adjustment is necessary, depends on correction level.

That’s unexpected. Intuitively I’d expect the filters to deliver very nearly equal matched signals. Any idea why the filters would be generating a channel imbalance?

[lazycatken]

Originally Posted by boconnor

But I remain sceptical about the absolute need for the 24 bits. Particularly given the maximum 60 db dynamic range in a normal listening room at home, I can’t see a difference of 24 bits vs 16 bits being perceived in those environments.

Just as you said. Judge it by your ears. You'll find the truth.
And then think about "What's wrong with the measurement theory/method/tool/value?"

Originally Posted by boconnor

I haven’t varied any of the parameters – just used the defaults. Looks like you’ve found a big difference in the sound using the MPWindowExponent and MPLowerWindow parameters. How did you decide on those values? Have you varied any other parameters?

Did you tried to filter the sample impulse response provided by Denis Sbrigion?
To achieve the simulation drawing shown on DRC document, huge correction must be applied.
I tried to apply as strong as possible correction to the filter of my system, until pre-echo is perceivable. A quick way to do this is to find how sensitive is your system vs pre-echo. Then make simulations, find the most possible strong correction. And verify it.

That’s unexpected. Intuitively I’d expect the filters to deliver very nearly equal matched signals. Any idea why the filters would be generating a channel imbalance?

Check DRC document, you can find normalization factor...
Balance, means, equal loudness of left & right channel. It's judged by ears. You know human ears are not frequency linear...
One of the correction of DRC is magnitude frequency response. That is, DRC does the inverse of your system response. Check this. 沈浸在音樂之ä¸*...: EQ的目標是？20~20KHz平直？
The first graph is my system response(record of impulse response measurement, log sweep), the second is corrected log sweep.
The correction applied to both channels may not be equal.

BTW, the graph shows why more dynamic range is necessary for filtered signal.

[Wingfeather]

Hi all.

Originally posted by boconnor
As I understand it there are three components to the magnitude of the latency delay (independent of what is happening in the Behringer): the latency within the sound card, the speed of the PC in doing the convolution calculations, and the programming efficiency of the convolution algorithms.

You're almost correct. The sound card will certainly introduce some latency, which I'll term hardware latency. In professional sound cards you can usually specify one of several available. I think 32 samples is the lowest mine goes to. Note that hardware latency is caused by the block-processing nature of the PC and is not intrinsic to DSP - an embedded DSP system might only have a single sample of hardware latency.
However, it is only a common misconception that processing latency has anything to do with the processing speed of the machine. If you have a fast processor, then your system will work; if you have one that's too slow, you'll get glitches and it won't. Instead, processing latency is decided by the specific types of filters being used.*

The DCX2496 emulates traditional analogue filters (such as Linkwitz-Riley and similar). In digital systems, this is achieved with infinite impulse response (IIR) filters, which are computationally cheap and which themselves, like their analogue counterparts introduce no latency. So, the following observation:

Originally posted by boconnor
I have not noticed any sync issues when watching images on the screen and listening to the dialogue from the front stereo speakers.

is absolutely what should be expected from such a system. Actually, I tell a quick lie - each IIR filter in a system will introduce a single sample of latency. I would be very surprised if the DCX2496 isn't based on cascaded second-order filters (by far the simplest way to do it), so an eighth-order `effective' filter should introduce 4 samples of latency - essentially nothing.

In contrast, convolution is another word for the `other' type of digital filter - the finite impulse response (FIR). These filters generally do exhibit latency, but the amount is dependent on the design of the filter, and may be significant. It is however bounded by the number of taps, so the filter cannot at least introduce a delay longer than itself.

One of the supposed advantages of FIR filters is that they can, with correct design, adjust frequency response in a linear-phase fashion, meaning simply that they delay all frequencies by the same length of time and will maintain waveshape. IIR filters don't do this. Whether this constitutes an audible advantage is still up for debate, but it's a popular criterion for designing many filters. Anyhow, a linear-phase FIR filter will by definition always have a delay which is half the length of the filter. So for example, at a 48kHz sample rate, a filter which is 4800 taps long will exhibit 2400 taps (50ms) of delay.
With room-correction filters, the definition of latency is rather more woolly, but it is often considered to be the location of the first large peak in the filter impulse response. I don't know offhand, but there might well be a large latency introduced in room-correction applications. I imagine this will depend on the exact method and the exact measurements used to produce it. In any case, if you're using a convolution-based filtering system, you should tread carefully with regards to latency - it can be an issue, in a way that it cannot with your DCX.

Originally posted by boconnor
So what we need is an experiment which allows us to determine if a 24 bit input signal convolved has less artefacts in it compared with a 16-bit signal similarly convolved

Thankfully, this experiment can be done in the mind. A quantised signal can be regarded as the sum of the infinite-resolution analogue signal and some error signal introduced due to the quantisation process. Convolution is a linear process, so the convolved output can be regarded as the convolution of the infinite-precision original signal plus the convolution of the error signal. Now, using a 16-bit signal will result in a larger error signal than that of a 24-bit signal, and there will be larger errors at the output. However, since the convolution introduces no error of its own, this increase will be exactly proportional to the increase in input error.
Now to implementation: 32-bit floating point is not perfectly linear, so the real convolver will introduce error on top of that contained in the input signal. The output error will be difficult to predict as it is the result of two nonlinearities in series, but it will be slightly more than proportional. It will also have a slightly more complex harmonic distortion structure.

Really, in the end, I think the difference in artefacts will be very close to proportional (i.e. if you can't hear the quantisation noise in a 16-bit signal then it's unlikely you will hear the quantisation noise in the convolver output). There will be more error, but it will be only slightly.

In any case, the convolved signal will contain more information than the signal coming in, so you should use 24 bits at the end regardless of whether the input was 16-bit or 24-bit, or you're artificially adding yet another error signal on top of the convolver output.

ASIDE: Since floating-point arithmetic cannot be made linear I would not use 32-bit floating point in a system where 24-bit transparency is required - in many instances, mostly when dealing with loud signals, harmonic distortion spikes will show above the 24-bit noise floor. Using 64-bit floating-point will solve this in a practical sense - though I will say that the distortion due to 32-bit arithmetic is unlikely to be audible.

Originally posted by Carl Huff
What you will find is that DSP processing will trash a minimum of 2 bits and more if there is a sample rate conversion. As crazy as it seems, you must run at 24 bits to be 16 bit accurate

That's a vastly over-generalised statement. Poorly-done DSP arithmetic will trash the LSB (by truncation), but I don't know where you got 2 bits from. Especially, fixed-point systems which truncate and which are dealing with quiet signals may introduce many LSBs-worth of harmonic distortion - and this is for a single multiplication. Signal processing chains such as a filter are comprised of many multiplications and the distortions of each are summed together. A long FIR filter can exhibit a surprising amount of distortion because of this.

A `proper' DSP audio system will be TPDF-dithered, adding 2 LSBs of noise. However, `trash' is absolutely the wrong word for what this process does, as such a system will display an infinite dynamic range and can perfectly represent signals which are much less than one LSB in amplitude. It sounds incredulous, but the latter isn't even theoretical - you can readily measure it (search for some old threads here on this subject - I've posted some).
Some noise will be added to the signal - this is what dither does, after all - but it's white noise and not distortion. Even for 16-bit output, it's usually below the noise floor in the room and can be ignored.


Whew, that's a long post! If my explanations are unclear (or even contain little mistakes), it's only because it's very late and I'm tired. The issues are subtle though and should get careful, thorough explanation. I can give more detail on anything that needs it.

Right. Bed time...




* BruteFIR is a special case. It uses a frequency-domain algorithm, as compared to an FIR filter which is time-domain. The result is much the same, it's more of an implementation issue than anything. However, frequency-domain methods must be processed in blocks and actually add yet another layer of latency on top of what I've mentioned, similar in nature to how the sound card adds latency. BruteFIR's algorithm allows this (and only this) extra latency to be reduced by throwing more CPU power at it. Even so, the total system latency can only approach that of an FIR filter - never beat it.