#axonlib: A cross-platform VST effect framework

ccernn, not so long ago, started the work on a cross-platform vst framework for linux and windows.

axonlib home
Its in an early version currently, but has proven quite stable already.


some screenshots:




I've joined in to help (as much as i can) with some cross platform tests, ideas and possibly with development once we set a version control repository.

Lubomir

#dBFS calculator

Here is a simple dBFS calculator:

You can download it in Flash SWF format or as a C source / Win32 binary (binary compiled with the DJGPP online-compiler).


The summing of decibel values is a bit of a confusing subject, i believe because decibels are units with no dimension (ratio like %) and also that they are logarithmic.

You can read this whole article for more information:
http://www.homeandprojectstudio.com/features/feature001.html

...Using dB FS (full-scale) in digital audio means that a change of +6 dB FS is the same as +10 dB spl (sound pressure level); in other words, twice as loud. How can this be? We know that each bit in a digital audio system increases the sampling resolution by approximately 6 dB. In essence, each bit represents an exponential increase in the sampling resolution, doubling the value with each bit. That’s why in a digital audio system, +6 dB FS, and not +10 dB spl, represents a doubling in sound levels. Not coincidentally, this corroborates the earlier statement that an increase of 6 dB is really a doubling of sound pressure, although not the perceived doubling of sound pressure. This is true for both analog and digital measurements.
The important bit here is to learn to distinguish different types of measurement (decibels). What you are seeing on the meters in your audio program is dbFS originally designed for ADCs (analog-to-digital converters) and assimilated by modern audio tools. dbFS is the reverse of dbSPL.

The above article explains an easy way to sum dbSPL values and also provides a table to convert dbSPL to dbFS (16bit only):

If you have 80dbSPL + 80dbSPL the result would be approx 83dbSPL (80+3), because the difference between the two is 0 units - from the "rule of thumb".

--------

a dbSPL calculator works with the following equation:

result = 10*(log(10^(input1/10)+10^(input2/10))/log(10)
where "input1" and "input2" are the dbSPL (!!) values you want to sum. 80db+80db=83db

--------

to sum two sinewaves in your audio program (with dbFS measures):

result = 20*(log(10^(input1/20)+10^(input2/20))/log(10)
But why 20*? Here is a explanation quote from wikipedia:

20 log rule, and similarly the formula for ratios of powers is the 10 log rule, and similarly for other factors. The factor of 20 is explained as: 10 is because it is in decibels (10ths of bels), and 2 is because it is a ratio of powers (squares of amplitudes): the product is 20.
So result for the sum of -9dbFS and -9dbFS, would be -2.97940008672037 for equal input/output impedance.

Lubomir

#BBE Sonic Maximizer 482i circuit explained

update dec. 2011
we had a small debate with mr. domino49 at the cockos forums:
here

we were mainly discussing what is the correct way to write an open source, DSP version of the unit using the JesuSonic platform, since his initial proposal was using only RC filters (first order passive cross-over).

i think the version in the first post (#1) is still a bit incorrect (phase of HF), but you can see a couple of realizations from me in the thread:
- post #20 - this is a version using a second order crossover using digital biquads and has a program controllable gain for the HF.
- post #66 - this is a version that uses a digital state variable implementation, but does not have the program controllable HF.

bellow is my old review / article:

"Is the bbe sonic maximizer just a 2-band eq?"
A similar question has been asked on some forums, so i've decided to find out by searching for a schematic of a BBE SM unit and found this link via google:
http://www.radio-flier.com/PDF%20Files/BBE%20482i.pdf

Without checking the website from which the pdf file originated i wrote a quick review of the schematic.
And it seems i've doubled some things already written in there...apparently this pdf schematic extends the bbe schematic with the contents of the NJM2153 chip - the original schematic has only one big chip from a japanese manufacturer, which in a way hides all the processing in the unit.

So more useful info on BBE SM here:
http://www.radio-flier.com/bbe_data.htm
Thanks to Tom Farrand for reconstructing the 482i sheet with the NJM2153!

Here is my review:

Quote from the bbe website on the 482i:

"The 482i Sonic Maximizer restores an audio signals natural brilliance and clarity by the use of two primary functions. First it adjusts a signal’s phase relationships between it’s low, mid and high frequencies while progressively adding longer delay times to lower frequencies, this creates a kind of “mirror curve created by the speaker neutralizing its phase distortion. Secondly the Sonic Maximizer augments higher and lower frequencies; loudspeakers tend to be less efficient in their extreme treble and bass ranges. The end result is a dynamic program-driven restoration without the ear fatigue that is normally experienced with the use of equalizers or exciters."

+ A look at this sheet of a 482i channel.

http://www.radio-flier.com/PDF%20Files/BBE%20482i.pdf

At first sight, it looks like a 3 band second-order splitter (multiband). this is achieved with what they call "pseudo state variable filter". Phase shifting (band split) is present for each band !even! if "process" is set to 0 - i.e. fx is part of the signal chain (not bypassed). The band-splitting is not controlled by the process knob.

The delay for the bands which BBE state is present, can be accomplished with a capacitor discharge, however I can't seem to find this in the sheet. Another way to do the delay, would be with separate buffer for this band, which stores the signal and plays it back with a delay. This type of design goal isn't something new and if you do it right, it can improve the sound trough certain speakers (a tweak for better acoustics). But how would you compensate for IIR phase shifts with a constant delay value? Phase correction with All-pass? This won't make the filter linear-phase.

There is a low-band amplification with a potentiometer which is not a low-shelf filter - this is just a band boost. Same goes for the 'process' knob, it boosts the top-band. for the top-band signal path we see voltage-controled-amp (VCA), which has its control voltage trough a peak-detector. The peak-detector works with the non-filtered signal and increases/decreases the control voltage of the VCA. The summed voltage from the peak detector trough the VCA, should add more to the high frequency content and act like an exciter. Btw i've never seen a VCA the way its drawn in this sheet, so i can't say for certain if it does what I've described above.

Another thing to take note here are the input/output buffers.
- By looking at the input buffer, I believe this is just for impedance accomodation between the input (jack) and the next stages filter/pd, this is required in most cases. I have some doubts that the input buffer acts like an allpass filter and that the necessary impedance accomodation is made with just R30.
- The output buffer looks more complicated: there is a what its called a frequency dependent inverting operational amplifier. What it does is - it doesn't amplifies frequencies above certain range (10khz for example), also it sums the three bands. This can be used to compensate for the harmonic boost of the high end. After that i see a one pole high-pass filter (RC), which i think they use only to band-limit lower frequencies (for example below 10hz) - the capacitor C20 takes care of that.

There is no potentiometer on the output stage, because i see there is no "output gain" control for separate channels on the 482i.

Summary:
There are a couple of mysteries (things i'm not certain of) in here, but the design does not look that complex. Also the price for a 482i is around 200$ (zsound) and it is a two channel unit - not very expensive, but still I believe you can custom build and improve the unit with a !lot! less than that.

I've heard a lot of positive and negative comments on the BBE SM units. The negative were about its sharpness on the top end (mainly in the plugin version). This may be, because of the use of cheap IIR filters and bad control for the VCA input voltage values...
From a recent discussion at music-dsp mailing list, we've agreed that by band-splitting and boosting a band (apply gain) instead of using a peak / shelf filter in the same range, you are essentially dealing with an inferior equalizer! this is due to the phase shifting at band crossovers. BBE states that they deal with this problem with one "progressive" delay shift?

But to conclude, if something is designed well and has quality elements, low noise floor, low harmonic distortion - it may sound great and even improve the sound. This type of circuit does not have much "magic" to add, but as I've said it can improve the sound if designed well. Also I don't believe that the software version will sounds better than the hardware, if modeled accurately...

Hope that helps for better understanding of this particular unit. :)

---UPDATE---

I believe I made some mistakes:

I've managed to run the old "cakewalk sonic maximizer" plugin demo (dx) with a wrapper & vst pa (from c.budde). The new bbe version from nomad factory has no demo?

So if this is accurately modeled - indeed, there is a all-pass filter with F0 at 700hz (crossover freq)

So the "progressively adding longer delay times to lower frequencies, this creates a kind of “mirror curve created by the speaker neutralizing its phase distortion." statement is accurate in this case. All-passes can be used for this application, but this just a non-adjustable all-pass design, which cannot deal with phase distortion issues in !any! speaker.

I must admit though, that changing the top-band and low-band voltage also affects the group-delay of the sum. signal chain is: [in] -> [acmd] -> [band-split] -> [sum] -> [hp] -> [out]

Things are much more complicated than that :)

Here is an article on the subject of all-pass crossovers and phase distortion issues:
http://www.linkwitzlab.com/phs-dist.htm

Lubomir

#"Dynamic Range" - Pleasurize Music?

Just recently I've found out about this web page:
http://www.pleasurizemusic.com



This time behind the initiative are serious companies such as:
Tischmeyer Technology
Alogorithmics
SPL
Brainworx
Tomo AudioLabs

The initiative of the "Pleasurize Music Foundation" is proposing an open source VU/RMS meter, which can be used to calculate a "Dynamic Range" value of a audio track - offline or real-time with hosted plugin. The main idea is to standard-ise the use of a specific tool in any studio across the world, a tool that determines what the "Dynamic Range" of the tracks examined is and if these track are unnecessary loud. I strongly support this proposal!

Here is more info I've gathered from personal experience:

"Dynamic Range"
From the website explained as:
...This is the average cumulative difference between peak and loudness (RMS) over a specific period of time (duration of a song or album) and is a whole number value given in decibels. Just the top 20% of the loudness are taken into consideration to ensure that songs with a long intro and an over compressed refrain doesn´t appear with a too high DR value.
For the quick tests I did with the "Offline Meter" they are providing, the returned DR values seem completely adequate. Tracks which I think sound super-loud had DR values of 6 for example. Tracks with normal volumes were around 11-14 DR.
Basically the manual of the tools says that an acoustical musical performance for example should be around DR=12, DR=14. For electronic club music I guess it can go a little bit lower around DR=10. But still! This means that the limiters will begin to kick in and DR=12 still will be absolutely reasonable value.

The "Offline Meter"

The offline meter can be used outside of your DAW application (since it is a standalone exe). Loads and analyzes the tracks very fast! The DR value returned from the meter should be considered the "official" DR value for this track. Not the DR values returned from the "Realtime Meter"

The Plug-in "Real-time Meter"

So far the plugin version of the DR meter is only available in the VST format. They are saying that AU/RTAS versions are on the way too.
The plug-in version loads almost instantaneously on my old PC. It has peak meter, RMS meter, mono switch, link switch, and DR value meter along side a very nice moving colored block which turns from green to red if the DR values begin to lower too much.
The only remark I must make here is that apparently the RMS has "Display gain" value of 3dB applied to it. So if you compare the RMS values with other meters (such as Voxengo Span for example) you will have to add 3db more to DR meter values to make them equal. So far I think they are using a 300ms window for RMS calculation which is ok.

Both the plug-in and the offline versions are developed by Tischmeyer and Alogorithmics. Algorithmics alongside Isotope are probably one of the most respected DSP code algorithm suppliers. Tischmeyer Technology is an offspring of Tischmeyer Publishing GMBH with their excellent mastering studio located in Germany and publishing of mastering books and tutorials.

So far so good. I've already started using the new meter. If you are interested give it a try, register on their website and spread the word on forums and blogs if you support the initiative.

Regards
Lubomir

#Designing an analog VU meter in DSP

Here are some notes on how to design a VU meter DSP fx.
I won't be getting much into the signal detection, but mostly into the visual of the plugin. If you wish to know more about it, please feel free to send me an email and I will be happy to respond to your questions.

Here is what we are going to use as an example. This is a very simple JesuSonic fx:



Setting some dimensions
We begin by setting the width and height for the visualization.
Its important to set the dimensions first, because they will determine the radius of the needle and the span of our scale.

We are going to make a rather large VU meter - 425x260px, with needle radius of 200px. You should be able to create an arch withing these dimensions using the needle radius.

Designing the VU meter scale
After the dimensions are set we can start creating our scale.
You can very easily design the scale, try to approximate other scales, or use ready equations.

In this example we are going to design our own scale by roughly approximating to an actual scale. There are a lot of photos of analog VU meter over the net. Different manufacturers have patented different scales. We will create our own (in a way).
Similar to this one for example:



We can use it as our base. In general its very difficult to make the approximation 100% accurate if you don't know the original function. Still there are ways to (try) to do so. For example LaGrange polynomials can help you with that. It may require a lot of points to be interpolated and the resulting function and the algorithm may became much more inefficient than a simple exp(). Also by using interpolation there might be some minor unavoidable and unwanted deviations between points.

First thing to do is to set some scale markings in dB:
-20, -10, -7, -5, -3, -2, -1, 0, +1, +2, +3

Here is how to convert amp signal in dB and then get the value of X (dB -> pixels on the X axis):



//code executed at bigger intervals - 1024 samples for example

//amp2dB
//take only abs(input) of input
//6/log(2) is our dB scale
in_db = log(abs(input))*6/log(2);

//then

//xl - is the value of X
//in_db - is the value in decibels
//use numbers 2.1 and 285 to tweak the equation
xl = floor(exp(log(1.055)*2.1*in_db)*285);


xl is the result we are looking for here, after converting amp into dB.
A very useful thing to do is to use some sort of a plotting program which can make calculations and draw some lines at the same time. I've used Adobe Flash which is quite fast to work with.


fig.1

The vertical lines on the left and right represent our width. Point O is the center the circle. Point A lies on the circle therefore OA = r. Point S0 represents a point from our scale using the above equations. To draw the actual lines from the scale, two additional large arches may be used (colored in blue). If we connect O with S0 an intersection will occur between the new cirlces and OS0. These are points D01, D02. So lines such as D01D02 will be visible on our scale. When we know all the coordinates of the points we can make an arrayand draw these 'markings' on plugin initialization.

Drawing the needle in realtime
After we have the result on the X axis we can start drawing the needle.
Of course if you wish to use a bitmap as the needle you should use a different method here (i.e. calculate angle of rotation).


fig.2

The math method used here to calculate point A's X,Y coordinates is by using proportional triangles and Pitagor theorem - as simple as it gets. Where: S0A / AO = P1A / AP2 etc. And since we know some of the lengths and coordinates of points we can get point A very easily.


//get y from x and radius - r
//Pitagor and proportional triangles used here
l=sqrt(sqr(r)+sqr(212-xlt));
h=((l-r)*r/l);
m=sqrt(sqr(l-r)-sqr(h));
ylt=35+h;
xlt < 212 ? xlt=xlt+m : xlt=xlt-m; // check if x is < of middle point 212


The results - xlt & ylt are the A's x,y coordinates and after we have them, we can draw a line between O and A in realtime.

Needle response
Updating the needle per sample is not advisable so I suggest that you use some sort of a countdown before make the above calculations. After some trial and error you will get an acceptable 'response' speed. You should know that the magnetic-electric system (inductor+constant magnet) of an analog vu-meter has response of 300ms. This is quite slow but of course you can tweak it.

Another characteristic of the needle response is the inertial fallback. This is due to the inductor exponential discharge. After executing the x,y calculation code you can add the fallback by simply subtracting pixels from X (original exp() scale) while multiplying the result by some factor for adding inertia (emulating the discharge).

Limiting x and y of A may also be a good thing since the given log scale in dB can go as low as -350db. Or you can just limit the input gain value to -25,+3.5 db

RMS window
Adding a RMS detector isn't very difficult to make in DSP either. Here is an example:


//***per sample
//cs - current sample counter
//300 - window in ms
//sum - peak values stored here
if (cs == (0.001*300*44100)) {
cs = 0;
sum = 0;
} else {
cs += 1;
//square the abs value of the input
sum += sqr(abs(input));
}
//***execute at bigger intervals - at sample block for example
//calculate value while converting into dB
//*100/100 is to output the values in the X.XX format
rms = floor(6/log(2)*log(sqrt(sum/cs))*100)/100;


So 'rms' would be our RMS value for a 300ms window.

Thats all...well mostly. If you have any question post a comment here or send me an email.

I leave that task of making the VU meter look good to you.

Lubomir

#Inter-sample peaks and audio compression

Inter-sample peaks have been more of a problem recently with the constant struggle for louder sound. This post includes some tests of the consistency of ISP clear audio signals after performing compression .


The above article at Gearslutz explains inter-sample peaks quite well. Just to simplify it a little bit here is a time-domain plot of a sample. This could be part of any type of sound - bass guitar, synthesizer, but this is more of a 'designed' plot, since the chance of a similar sequence appearing is minimal (there are drastic changes in sample values).

view image

The areas marked with 'ISP' are the actual problems. ISPs are a digital-to-analog (DAC) conversation issue. Your digital medium such as CD-A may contain tracks that does not clip at all on normal meters, but in theory there is a chance that at certain sample configurations such as the shown above, the reconstructed (via interpolation) analog audio signal, exceeds 0 db. Such peaks will be introduced as distortion in listening conditions.

"Would this type of distortion be really that audible?"
It really depends on the playback system (DAC), the listener, the audio material. But it may be quite audible.

"Well how to prevent it?"
There are algorithms in some DSP limiters, that deal with the problem quite well. From my understanding of interpolation in mathematics, the only way to deal with such problems is to change values of the neighbor points (samples) forward and probably backwards in the time domain. Another important thing that must be done is to over-sample the signal so that more points are introduced in the plot.
Here is the list of the know limiters that prevent ISP:

Sonnox Limiter, Voxengo Elephant, TC Limiter, Izotope Ozone, PSP Xenon and others.
Note, that you must engage the oversampling mode of the limiter to enable the desired functionality.

As you may know most of these limiters are commercial products. The only free tools you would find are the meters, such as: John Schwartz's Bitter, SSL's X-ISM and others.
Still, if you are willing to buy a DSP limiter for your needs, I could not recommend a better limiter than Elephant. Its the cheapest, the most flexible and arguably the best sounding one.

Do the listed above tools really work for ISP?
Well here is the tricky part. There are certain conditions in which the ISP prevention may not work for any of the above products. However most of these conditions are quite extreme.

Recently I've conducted some tests with two very popular audio compression formats - MP3 and FLAC. The idea behind the test was a simple question: Does audio compression over a ISP free signal, introduces back the ISPs? Well the answer to that question ended up slightly complicated.

My first test was with a "designed" WAV file with series of samples that would positively introduce ISPs:

view image

I've used Elephant 2 to add 24db of gain to the signal, while oversampling to x2 and limiting at -0.1 db. Then created a MP3 file directly from Reaper with LAME encoder at 320kbps, normal quality. While decoding the resulted MP3 file into Cooledit I've noticed that there is no sample clipping or eventual inter-sample peaks. Then I repeated the same test with lower bitrate MP3 - still no problems were found, after the decoding. But then I've realized that this test is flawed for the following reasons:
- the frequency response of the input signal wasn't really 'sufficient' for testing (it was just a waveform peaking around 2khz)
- the average RMS level after limiting was still quite low.

So I'vee decided to do a little bit more testing on the subject. This time with pink noise and some extreme settings.

Without explaining more I will directly post the test results. There are two tests included (for FLAC, MP3) at different RMS levels.


input: 20 sec pink noise (WN trought 6pole 'pink' filter, simple pseudo-random
numbers generation, extended with XOR)
limiter: voxengo elephant2, default settings, 4x os, roof -0.2db, test dependant
input gain.
decoding: outputs decodeded with reaper 2.55
meter: SSL X-ISM

### test 1 -12db rms:

output wav (-12db_rms_24bit.wav): 24bit, 44100hz, no dither
* result: no ISP & no clipping

output mp3 (-12db_rms_320kbps.mp3): lame 3.98, CBR 320kbps, normal q
* result: no ISP & no clipping on decode

output mp3 (-12db_rms_96kbps.mp3): lame 3.98, CBR 96kbps, normal q
* result: no ISP & no clipping on decode

output flac (-12db_rms_q8.flac): flac 1.2.1, 24bit, q8
* result: no ISP & no clipping on decode

output flac (-12db_rms_q0.flac): flac 1.2.1, 24bit, q0
* result: no ISP & no clipping on decode

### test 2 -6db rms:

output wav (-6db_rms_24bit.wav): 24bit, 44100hz, no dither
* result: no ISP & no clipping

output mp3 (-6db_rms_320kbps.mp3): lame 3.98, CBR 320kbps, normal q
* result: ISP present & clipping on decode

output mp3 (-6db_rms_96kbps.mp3): lame 3.98, CBR 96kbps, normal q
* result: ISP present & clipping on decode

output flac (-6db_rms_q8.flac): flac 1.2.1, 24bit, q8
* result: ISP present & no clipping on decode

output flac (-6db_rms_q0.flac): flac 1.2.1, 24bit, q0
* result: no ISP & no clipping on decode

### Tests summary:
Lower RMS levels for both MP3 and FLAC decode with no clipping and ISP.
Decoding of mp3 streams with higher RMS level introduce clipping,
but when normalized, ISPs are not present. Higher RMS level flac q8 does
not clip, but strangly ISP are present. Lower compression q0 for FLAC preforms
very well for higher RMS values.

The tested compressors deal much better with lower RMS values.

Test files can be downloaded from here:
mirror1
mirror2

Regarding the MP3 tests:
Decoded MP3 audio signal would only clip if the RMS of the input is very high.

There are ways to deal with this problem:


lame -b 320 --clipdetect [file]
...
WARNING: clipping occurs at the current gain. Set your decoder to decrease
the gain by at least 0.1dB or encode again using --scale [arg]
(For a suggestion on the optimal value of [arg] encode
with --scale 1 first)

You can use the --scale command in LAME or tools like mp3gain to fix this.
But still this is sample clipping. There is a chance that no ISP will be present after normalizing the MP3 singal!

Still I should point out that there are way to many parameters involved, when conduction these tests and the test results may vary a lot.

I've also did a another much more extreme test with -1db RMS values (not included). Various limiters did not perform well in prevent ISP in these extreme conditions.
Excessive levels does not do well for ISP prevention and for audio compression.

"How to deal with compression of audio?"
- always use ISP prevention over the track.
- lower the limiter roof to -0.3, -0.5db, or even -1db
- decode the resulted mp3 file with an audio editor and check for clipping
- use statistics in your encoder (such as --clipdetect in LAME)
- of course use the best encoder possible

But still, as the above test proved moderate RMS levels, may not need any normalizations and lowering of the limiter roof at all.

Lubomir