DSP Robotics Support

Tronic wrote:The ISP meter, measure the level above allowed by your D/A converter, and with an approximation to reconstruct the waveform at the points that exceeded 0dBFS, and measuring them, so to give a pseudo-value for recalibrate your level of output.

I see. It isn't something I need to think of when designing a VSTi. It's important only at the end of the chain, the host's master. Thank you

tulamide wrote:I see. It isn't something I need to think of when designing a VSTi. It's important only at the end of the chain, the host's master. Thank you

it can be important if your plugin is a limiter for example.

tulamide wrote:Since the experienced users are all gathered, may I ask a question?

I know what intersample peaks are. Are they in any way harming? Since there are no intersample-samples in the digital domain, wouldn't they just be non-existant when the sound is outputted to the analog domain? Or will there still be some kind of curve between two samples, maybe due to the analog hardware?

There´s one thing to always keep in mind: you never really listen to "digital audio". Digital audio is actually a bunch of numbers stored in the HD - (or any other kind of data storage).Those numbers are discreet values that hold information about a continuous signal, which has been sample at regular intervals. But when you push "play" in you favourite software (be it a DAS or a wave/medua player) those numbers are fed to a syste that converts the discreet values into a continuous signal.So you´re never listening to those discreet values you´re always listening a continuous signal. In other words, you never really liste digital audio, you´re always listening to analog audio, even if the signal has been produced by using discreet values as source.

Having said that, there will always be curves between to samples. The problem appears when the analog curve that is produced as a result of reconstruction of 2 samples that are too near 0dbfs happen to hit the imits of the analog system used to reproduce such signal.If the system cannot tolerate signals higher than the ones equivalent to 0dbfs, then you´ll have distortion.

Hope this helps. Now please forgive me if I´m not that clear...... the tears in my eyes and the wine in my blood, both a side effect of the last match of the world up, might have affected my brain in some undefined ways...

Tzarls wrote:Hope this helps. Now please forgive me if I´m not that clear...... the tears in my eyes and the wine in my blood, both a side effect of the last match of the world up, might have affected my brain in some undefined ways...

What a game it was. And what a relief for me that the goal came close to the end of the extra time. Of course I couldn't sleep at all, with all those party people yelling and making noise the whole night.

You are totally right, and I should have thought about it. But that also brings a new question. How do you know which method the hardware d/a uses? Because, if it uses method a, while a host's ISP meter uses method b, it could still come to peaks, couldn't it?

To help get a better understanding of inter-sample peaks ... you may want to visit the NuGen audio site, and check out the media files for their ISM metering.

Sometimes a simple visual can 'connect the dots'

Below is an intersample peak detector which is accurate to a few percent. It uses 4x oversampling with a 95-tap polyphase FIR filter. That may seem rather heavy, however fewer taps are only possible if you sacrifice bandwith or accuracy. The effect of intersample peaks is quite pronounced if you feed it with broadband noise.

Hi martin,
from what I could see you used a symmetric FIR implementation or am I wrong?
I would like to deepen this oversampling technique, if you have time and desire,
would you explain how to use it both for UP / DOWN sampling, and what you used to derive the coefficients?
As always, thanks for your time and passion.

Wow, thanks Martin!

where did you calculate the equiripple coefs from? Also, by "tap" do you mean pole?

I have tested this with a version I made with the oversampling toolkit and cyto's peak meter. . .

It seems that the OSToolkit + Cyto's Peak Detector find higher values than the example you provided. . ? Im not sure if I did it wrong, probably, but I will upload the fsm when I get home.

martinvicanek wrote:Below is an intersample peak detector which is accurate to a few percent. It uses 4x oversampling with a 95-tap polyphase FIR filter. That may seem rather heavy, however fewer taps are only possible if you sacrifice bandwith or accuracy. The effect of intersample peaks is quite pronounced if you feed it with broadband noise.

Thank you very much. That is a very sophisticated example! So, regarding my question, the interpolation method isn't standardized, but rather one uses generalized algorithms (filtering/oversampling). It approximates to keep reasonable cpu-load/accuracy ratio, accepting to let some peaks unrecognized. I'm not much into sound engineering, but it reminds me on a spline in the graphical world, where start and end are known, and the control points are set to certain discrete values (all with a resolution as low as possible).
I think I better not ask any further questions, but better read about the topic in various documents on the web!

Tronic wrote:you used a symmetric FIR implementation or am I wrong?
I would like to deepen this oversampling technique, if you have time and desire,
would you explain how to use it both for UP / DOWN sampling, and what you used to derive the coefficients?

Yes, it is a symmetric FIR so it is linear phase. I think that most D/A converters are also linear phase, but I really don't know if that is generally true.

There is good information on the SM forum and wiki, just google oversampling. I should note that the filter in the above schematic is designed for the specific task of intersample peak estimation. It is less suited for other sound processing tasks (mainly because of its poor stopband rejection). In that case the toolkit IIR filter will perform much better.

The coefficients are from the excellent LabVIEW online utility.

Drnkhobo wrote:by "tap" do you mean pole?

I have tested this with a version I made with the oversampling toolkit and cyto's peak meter. . .
It seems that the OSToolkit + Cyto's Peak Detector find higher values than the example you provided. . ? Im not sure if I did it wrong, probably

No, I mean tap (I thought that's a common term for FIR filters). Typically you would have (nontrivial) poles in IIR filters, not FIR.

Your test with the SM OS Toolkit is interesting, I get the same result for noise input. However, it really depends on the input signal. For example, for an impulse train, the toolkit actually yields lower peak values, even lower than those of the original input! It does make sense if you look at the time response of the toolkit filter: a single pulse gets heavily distorted with lots of ringing.

tulamide wrote:So, regarding my question, the interpolation method isn't standardized, but rather one uses generalized algorithms (filtering/oversampling). It approximates to keep reasonable cpu-load/accuracy ratio, accepting to let some peaks unrecognized. I'm not much into sound engineering, but it reminds me on a spline in the graphical world, where start and end are known, and the control points are set to certain discrete values (all with a resolution as low as possible).

That's true. If all D/A converters were linear phase, then the "ideal" method would be a sinc-interpolation. My little schematic addresses this scenario, with some (hopefully) reasonable trade-off between CPU load and approximation. For other than linear phase, it is really impossible to know the peaks after D/A conversion.