11 May
2010
11 May
'10
9:43 p.m.
Hi,
This is not specifically about LAU stuff, at the first level
anyway, but it could be one of these days maybe.
Mostly for fun and to keep my old brain exercised I'm playing with
coding a DSP multiband equalizer. The thing basically works, actually
works pretty well with more or less steady state data, but it doesn't
look at all good with big transients mostly due to ringing in my lower
range band pass filters.
Does anyone know of any reasonably simple papers talking about
sorting out this sort of design problem?
I suspect someone like Steve Harris has forgotten more than I'll
ever know about subject like this but I'm not sure he's here anymore.
Maybe there's someone else who's available to talk to me off list?
Thanks,
Mark
11 May
11 May
10:11 p.m.
On Tue, May 11, 2010 at 02:43:43PM -0700, Mark Knecht wrote:
This is not specifically about LAU stuff, at the
first level
anyway, but it could be one of these days maybe.
Mostly for fun and to keep my old brain exercised I'm playing with
coding a DSP multiband equalizer. The thing basically works, actually
works pretty well with more or less steady state data, but it doesn't
look at all good with big transients mostly due to ringing in my lower
range band pass filters.
Does anyone know of any reasonably simple papers talking about
sorting out this sort of design problem?
I suspect someone like Steve Harris has forgotten more than I'll
ever know about subject like this but I'm not sure he's here anymore.
Maybe there's someone else who's available to talk to me off list?
What type of filter are you using and with which parameters ?
Ringing is a natural effect with some filters, it depends mainly
on how 'steep' a filter is. How it looks is not that important,
what matters is how it sounds.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
10:36 p.m.
On Tue, May 11, 2010 at 3:12 PM, Fons Adriaensen <fons(a)kokkinizita.net> wrote:
On Tue, May 11, 2010 at 02:43:43PM -0700, Mark Knecht
wrote:
So far just Butterworth - 2 & 3 pole. 2 pole is a big improvement over 3.
If I was using this to adjust actual audio data then I'd completely
agree with you - trust my ears.
Actually though, as a test of an idea I had and just because I've got
the data here, I'm using stock market data, decomposing the data into
bands of energy if you will, and then summing the bands back together
to see how close I come to the original data. It works fairly well
most of the time, but stock data can have big directional moves at
times which appears as a big transient event. When those events
complete then the slower filter bands ring and cause large
displacements in the output.
One thought it pre-processing the data going into each filter to
ensure that it doesn't contain too much high frequency data. I suspect
this is probably done in physical designs anyway. Another is to do
some error correction along the way and adjust the ways things are
summed to reduce error in the final output.
Once my design gets better I'll use something like an R-Squared
computation to tell me more about the accuracy of the signal over time
but for now the results are so far off visually that it's clear I need
to do something very different.
I suspect since I just hacked a bunch of code together in an area that
I've not touched since my junior year at university some number of
decades ago that there are some really basic things I could do to
improve my results. I was thinking about tearing into the code for
something like Jamin to look at what's done there. Maybe there are
better examples for me to use though?
Cheers,
Mark
This is not specifically about LAU stuff, at
the first level
anyway, but it could be one of these days maybe.
Mostly for fun and to keep my old brain exercised I'm playing with
coding a DSP multiband equalizer. The thing basically works, actually
works pretty well with more or less steady state data, but it doesn't
look at all good with big transients mostly due to ringing in my lower
range band pass filters.
Does anyone know of any reasonably simple papers talking about
sorting out this sort of design problem?
I suspect someone like Steve Harris has forgotten more than I'll
ever know about subject like this but I'm not sure he's here anymore.
Maybe there's someone else who's available to talk to me off list?
What type of filter are you using and with which parameters ?
Ringing is a natural effect with some filters, it depends mainly
on how 'steep' a filter is. How it looks is not that important,
what matters is how it sounds.
Ciao,
--
FA
11:18 p.m.
On Tue, May 11, 2010 at 03:36:08PM -0700, Mark Knecht wrote:
Actually though, as a test of an idea I had and just
because I've got
the data here, I'm using stock market data, decomposing the data into
bands of energy if you will, and then summing the bands back together
to see how close I come to the original data. It works fairly well
most of the time, but stock data can have big directional moves at
times which appears as a big transient event. When those events
complete then the slower filter bands ring and cause large
displacements in the output.
So you want a set of filters with the following properties:
1. each filter has a frequency response with a shape that allows
an intuitive interpretation as a 'bandpass', i.e. a range of
frequencies, and
2. the sum of the filter outputs equals the original input.
This is a *hard* problem. Basically none of the classical filter
types have these properties. There are filter sets that can do
this but they are quite esoteric.
'Ringing' is not really a problem here, each of the individual
filters may ring, as long as this is cancelled by the others
when you add the outputs.
An FFT will provide a set of filters having property (2), but
each filter has a sin(x)/x shape, which is not really a bandpass.
You can 'improve' the shape by windowing, but that destroys (2).
And anyway using an FFT like this is a 'block' operation - how
a sample is treated depends on its position within the block.
Windowing requires overlapping blocks, and they won't add up
to the original input.
I was thinking about tearing into the code for
something like Jamin to look at what's done there. Maybe there are
better examples for me to use though?
Jamin's FFT based filter is not really a filter, it's a vocoder
being used as a filter and it has side effects.
Now if the purpose of the filtering is to extract 'features' of
the data, you really don't need property (2). And given the
nature of stock market data, I suspect that classic audio filters
are not the right way to extract such features. I'd have a look
at wavelet filters for example.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
11:46 p.m.
Fons Adriaensen wrote:
2. the sum of the filter outputs equals the original
input.
This is a *hard* problem. Basically none of the classical filter
types have these properties. There are filter sets that can do
this but they are quite esoteric.
Linkwitz-Riley filters:
http://en.wikipedia.org/wiki/Linkwitz-Riley_filter
I'm pretty sure they can just be converted to the digital domain
using the bilinear transform.
I'd have a look at wavelet filters for example.
Do look at the discrete time version of the continuous wavelet
transform, but from my experience, the discrete dyadic wavelet
transform is a complete waste of time for anything other that
sub-band coding applications.
Also, is this a bit more appropriate for the LAD list?
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
12 May
12 May
1 a.m.
On Tue, May 11, 2010 at 4:46 PM, Erik de Castro Lopo
<mle+la(a)mega-nerd.com> wrote:
Fons Adriaensen wrote:
Thanks Erik. I do think this is more appropriate for LAD. I'm not
subscribed there but will get subscribed.
This topic is, for me, mainly about learning something about the topic
of DSP and then applying it to something a bit different. It has
application, I think, to stock market trading, but at the same time
I've run across a few papers here and there talking about 'listening'
to the stock market - converting what's going on into audio to then
viewing the market from another perspective. Our ears are far more
sensitive to changes than our eyes so why not use them? If I develop
something interesting then giving back to the Linux audio community
that has given me so much over the years would be cool. Keeping in
mind that I'm not a programmer I think that is unlikely, but who knows
and why not try?
Addressing your comment about the non-DC bias, I agree so I detrend
all the data first with longer term trend info to remove that
component of the data and give it something approaching zero offset
over time. While not necessarily appropriate for audio, one difference
with stock data is there is no absolute high or low - no real voltage
range - and time is fungible (there aren't necessarily specific time
periods like we have with audio) so I'm looking for things like 30-bar
oscillations, and not necessarily 333 Hz signals. (I hope that's
clear...) Still, I'm free to do anything I want with the data to make
it easier to process which might be completely inappropriate for real
audio data.
Again, thanks for the ideas. Moving this conversation to LAD in the
next day or two but will certainly correspond with this list if
there's interest or anyone off list if they want to.
Cheers,
Mark
2. the sum of the filter outputs equals the
original input.
This is a *hard* problem. Basically none of the classical filter
types have these properties. There are filter sets that can do
this but they are quite esoteric.
Linkwitz-Riley filters:
http://en.wikipedia.org/wiki/Linkwitz-Riley_filter
I'm pretty sure they can just be converted to the digital domain
using the bilinear transform.
I'd have a look at wavelet filters for
example.
Do look at the discrete time version of the continuous wavelet
transform, but from my experience, the discrete dyadic wavelet
transform is a complete waste of time for anything other that
sub-band coding applications.
Also, is this a bit more appropriate for the LAD list?
Erik
-- 
9:09 a.m.
On Wed, May 12, 2010 at 2:00 AM, Mark Knecht <markknecht(a)gmail.com> wrote:
This topic is, for me, mainly about learning something
about the topic
of DSP and then applying it to something a bit different. It has
application, I think, to stock market trading, but at the same time
I've run across a few papers here and there talking about 'listening'
to the stock market - converting what's going on into audio to then
viewing the market from another perspective.
I have a vague recollection that Thomas Cavicchi's DSP book opens with
a treatment of stock market data. Can't remember to what purpose,
though...
Chris
3:05 p.m.
On Wed, May 12, 2010 at 2:09 AM, Chris Cannam
<cannam(a)all-day-breakfast.com> wrote:
On Wed, May 12, 2010 at 2:00 AM, Mark Knecht
<markknecht(a)gmail.com> wrote:
One simple usage is replacing old-style indicators such as moving
averages with DSP low pass filters. Whereas a moving average requires
summing say the last 50, 80, 100 bars of data and then dividing by the
number of bars summed, you can do a two pole low-pass filter by
setting up a couple of coefficients and then looking at only the last
3 bars.
Thanks for the title reference. Too expensive to buy but maybe I can
find a copy at the library.
- Mark
This topic is, for me, mainly about learning
something about the topic
of DSP and then applying it to something a bit different. It has
application, I think, to stock market trading, but at the same time
I've run across a few papers here and there talking about 'listening'
to the stock market - converting what's going on into audio to then
viewing the market from another perspective.
I have a vague recollection that Thomas Cavicchi's DSP book opens with
a treatment of stock market data. Can't remember to what purpose,
though...
Chris
13 May
13 May
7:47 a.m.
On Wed, May 12, 2010 at 10:09 AM, Chris Cannam
<cannam(a)all-day-breakfast.com> wrote:
I have a vague recollection that Thomas Cavicchi's
DSP book opens with
a treatment of stock market data.
Checked the book -- I'm not sure why I remembered that it "opened"
with that -- it doesn't at all, maybe it was just the first bit I
read.
Stock market data are used in two places: as an illustration of time
aliasing resulting from decimation in the frequency domain (take an
8192-point DFT of 27 years of Dow closings, take only every 8th point,
inverse DFT: observe to general amazement that the result is nothing
like the original), and in a separate exercise in stochastic
modelling.
Chris
12 May
12 May
8:52 a.m.
On Wed, May 12, 2010 at 09:46:03AM +1000, Erik de Castro Lopo wrote:
Fons Adriaensen wrote:
L-R filters do *not* sum to the original signal. The amplitude
response of the sum is flat, but the phase response is not linear.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
2. the sum of the filter outputs equals the
original input.
This is a *hard* problem. Basically none of the classical filter
types have these properties. There are filter sets that can do
this but they are quite esoteric.
Linkwitz-Riley filters:
http://en.wikipedia.org/wiki/Linkwitz-Riley_filter
I'm pretty sure they can just be converted to the digital domain
using the bilinear transform. 
12:41 a.m.
On Wed, May 12, 2010 at 01:19:45AM +0200, Fons Adriaensen wrote:
On Tue, May 11, 2010 at 03:36:08PM -0700, Mark Knecht
wrote:
Wha??? Um, yuck.
I just mastered a CD using Jamin. Was that a mistake? I mastered a CD through a vocoder?
Is there a better GPL tool I should have used?
Actually though, as a test of an idea I had and
just because I've got
the data here, I'm using stock market data, decomposing the data into
bands of energy if you will, and then summing the bands back together
to see how close I come to the original data. It works fairly well
most of the time, but stock data can have big directional moves at
times which appears as a big transient event. When those events
complete then the slower filter bands ring and cause large
displacements in the output.
So you want a set of filters with the following properties:
1. each filter has a frequency response with a shape that allows
an intuitive interpretation as a 'bandpass', i.e. a range of
frequencies, and
2. the sum of the filter outputs equals the original input.
This is a *hard* problem. Basically none of the classical filter
types have these properties. There are filter sets that can do
this but they are quite esoteric.
'Ringing' is not really a problem here, each of the individual
filters may ring, as long as this is cancelled by the others
when you add the outputs.
An FFT will provide a set of filters having property (2), but
each filter has a sin(x)/x shape, which is not really a bandpass.
You can 'improve' the shape by windowing, but that destroys (2).
And anyway using an FFT like this is a 'block' operation - how
a sample is treated depends on its position within the block.
Windowing requires overlapping blocks, and they won't add up
to the original input.
I was thinking about tearing into the code for
something like Jamin to look at what's done there. Maybe there are
better examples for me to use though?
Jamin's FFT based filter is not really a filter, it's a vocoder
being used as a filter and it has side effects.
Now if the purpose of the filtering is to extract 'features' of
the data, you really don't need property (2). And given the
nature of stock market data, I suspect that classic audio filters
are not the right way to extract such features. I'd have a look
at wavelet filters for example.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
9:11 a.m.
On Tue, May 11, 2010 at 05:39:04PM -0700, Ken Restivo wrote:
Depends on if you like the result...
Jamin's
FFT based filter is not really a filter, it's a vocoder
being used as a filter and it has side effects.
Wha??? Um, yuck.
I just mastered a CD using Jamin. Was that a mistake? I mastered a CD through a vocoder?
Yes.
Early versions had quite severe side effects. Later the
overlap factor of the block processing was increased, this
more or less hides the artefacts, but they are still there.
Another thing to take into account that at LF the real
filter does not correspond at all to the one shown in
the GUI.
Is there a better GPL tool I should have used?
If you want one that has this type of 'graphical' filter
I suspect the answer is no. But you don't need graphical
filters for mastering, a multiband parametric will give
better results.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
6:32 p.m.
On Wed, May 12, 2010 at 11:12:22AM +0200, Fons Adriaensen wrote:
But what about the compression and limiting?
-ken
On Tue, May 11, 2010 at 05:39:04PM -0700, Ken Restivo
wrote:
Depends on if you like the result...
Bleak.
Jamin's FFT based filter is not really a filter, it's a vocoder
being used as a filter and it has side effects.
Wha??? Um, yuck.
I just mastered a CD using Jamin. Was that a mistake? I mastered a CD through a vocoder?
Yes.
Early versions had quite severe side effects. Later the
overlap factor of the block processing was increased, this
more or less hides the artefacts, but they are still there.
Another thing to take into account that at LF the real
filter does not correspond at all to the one shown in
the GUI.
So, are the artifacts caused by the compressors or the EQ? I didn't use the EQ on
JAMIN at all, just the multiband compressors and the final limiter.
Is there a
better GPL tool I should have used?
If you want one that has this type of 'graphical' filter
I suspect the answer is no. But you don't need graphical
filters for mastering, a multiband parametric will give
better results.
7:44 p.m.
On Wed, May 12, 2010 at 11:30:11AM -0700, Ken Restivo wrote:
So, are the artifacts caused by the compressors or the
EQ?
The ones I referred to are caused by the FFT-based EQ.
I didn't use the EQ on JAMIN at all, just the
multiband
compressors and the final limiter.
I don't know if Jamin uses the FFT processing to implement
the bandsplitting for the multiband compressor.
If it does then the artefacts of this type of processing
will show up in the output.
If it doesn't, then Jamin needs some type of bandsplitting
fillters that add up to exactly the input if compressors
are inactive. I doubt very much if these are implemented
in Jamin.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
8:04 p.m.
On Wed, May 12, 2010 at 09:44:58PM +0200, Fons Adriaensen wrote:
On Wed, May 12, 2010 at 11:30:11AM -0700, Ken Restivo
wrote:
Ugh, that sucks. Well, is there a multiband compressor, other than Jamin, which works with
JACK? Or, should I start trying to get postfish to run with ALSA on my M-Audio card in
24-bit big-endian mode?
-ken
So, are the artifacts caused by the compressors
or the EQ?
The ones I referred to are caused by the FFT-based EQ.
I didn't use the EQ on JAMIN at all, just the
multiband
compressors and the final limiter.
I don't know if Jamin uses the FFT processing to implement
the bandsplitting for the multiband compressor.
If it does then the artefacts of this type of processing
will show up in the output.
If it doesn't, then Jamin needs some type of bandsplitting
fillters that add up to exactly the input if compressors
are inactive. I doubt very much if these are implemented
in Jamin.
9:36 p.m.
On 12/05/10 21:02, Ken Restivo wrote:
Ugh, that sucks. Well, is there a multiband compressor, other than Jamin, which works
with JACK? Or, should I start trying to get postfish to run with ALSA on my M-Audio card
in 24-bit big-endian mode?
-ken
I don't know how good this is, because I haven't got round to testing it
yet but ...
http://sourceforge.net/projects/teliasopia/
regards, G.
17 May
17 May
9:55 a.m.
On 05/12/2010 10:02 PM, Ken Restivo wrote:
Well, is there a multiband compressor, other than
Jamin, which works with JACK?
check out the multiband lv2 plugin in calf. iirc, it was still
"experimental" last time i looked, but it worked quite well. haven't
used it for very demanding stuff yet, though. so ymmv, but it's
definitely worth trying.
12 May
12 May
8:16 p.m.
On Wed, May 12, 2010 at 09:44:58PM +0200, Fons Adriaensen wrote:
On Wed, May 12, 2010 at 11:30:11AM -0700, Ken Restivo
wrote:
Some time ago, Julien Claassen forwarded to me the
results of his exchange with Fons regarding reasonable defaults for
a three-band mastering network for Nama.
As Fons writes here, the sum of the bandsplitting filters
is unlikely to add up to the original signal, however
we did adopt what we believe to be a reasonable compromise,
with just a couple dB error.
I'm appending the default settings for the LADSPA effects
we are using. Each of the low/mid/high branches gets a compressor
and a spatialiser.
+-- low --+
mix ----> eq ---+-- mid --+-- boost ---> output
+-- high -+
You could create a similar network in Ardour or any other
sufficiently flexible software.
It might be worth experimenting with some A/B comparisons.
(Might be nice to have a program that can randomly cross
fade a couple signals with a beep indication. The listener does a
blind comparison, inputting his opinion at the keyboard.
Afterwards the program correlates the inputs with the
signals.)
eq: Parametric1 1 0 0 40 0.125 0 0 200 0.125 0 0 600 0.125 0 0 3300 0.125 0
low_pass: lowpass_iir 106 2
mid_pass: bandpass_iir 520 800 2
high_pass: highpass_iir 1030 2
compressor: sc4 0 3 16 0 1 3.25 0
spatialiser: matrixSpatialiser 0
limiter: tap_limiter 0 0
Regards,
Joel
--
Joel Roth
So, are the artifacts caused by the compressors
or the EQ?
The ones I referred to are caused by the FFT-based EQ.
I didn't use the EQ on JAMIN at all, just the
multiband
compressors and the final limiter.
I don't know if Jamin uses the FFT processing to implement
the bandsplitting for the multiband compressor.
If it does then the artefacts of this type of processing
will show up in the output.
If it doesn't, then Jamin needs some type of bandsplitting
fillters that add up to exactly the input if compressors
are inactive. I doubt very much if these are implemented
in Jamin.
Ciao,
13 May
13 May
8 a.m.
On Wed, May 12, 2010 at 10:14:41AM -1000, Joel Roth wrote:
On Wed, May 12, 2010 at 09:44:58PM +0200, Fons
Adriaensen wrote:
This is interesting. Never thought of building a DIY mastering system out of LADSPA
plugins, but I guess it couldn't hurt.
I'm not sure how to match up the settings you have here with the ASCII diagram above.
i.e. where does the spatializer and limiter fit in? And why is the parametric in front of
the three high/mid/low pass filters, and what purpose does it serve? Also, I'm
assuming that the SC4 has the same settings for each band, at least for starters.
Also, I'm not sure how to route this in stereo. I thought SC4 was mono anyway. I'd
guess that the compressors for each band should be stereo compressors, ganged togehter in
some way (RMS?), like perhaps the Calf Compressor is.
I feel limited here by ASCII art, and also by how to do the routing in for example Ardour,
which might be really complex, or maybe in something like Ingen.
The GLAME settings make sense to me: all 2-pole filters, with the lowpass rolling off at
106, the bandpass at 520 and 800, and the highpass at 1030.
How would these LADSPA filters compare to, for example, postfish? I'm really starting
to wish I'd used postfish instead of JAMIN now.
-ken
On Wed, May 12, 2010 at 11:30:11AM -0700, Ken
Restivo wrote:
Some time ago, Julien Claassen forwarded to me the
results of his exchange with Fons regarding reasonable defaults for
a three-band mastering network for Nama.
As Fons writes here, the sum of the bandsplitting filters
is unlikely to add up to the original signal, however
we did adopt what we believe to be a reasonable compromise,
with just a couple dB error.
I'm appending the default settings for the LADSPA effects
we are using. Each of the low/mid/high branches gets a compressor
and a spatialiser.
+-- low --+
mix ----> eq ---+-- mid --+-- boost ---> output
+-- high -+
You could create a similar network in Ardour or any other
sufficiently flexible software.
It might be worth experimenting with some A/B comparisons.
(Might be nice to have a program that can randomly cross
fade a couple signals with a beep indication. The listener does a
blind comparison, inputting his opinion at the keyboard.
Afterwards the program correlates the inputs with the
signals.)
eq: Parametric1 1 0 0 40 0.125 0 0 200 0.125 0 0 600 0.125 0 0 3300 0.125 0
low_pass: lowpass_iir 106 2
mid_pass: bandpass_iir 520 800 2
high_pass: highpass_iir 1030 2
compressor: sc4 0 3 16 0 1 3.25 0
spatialiser: matrixSpatialiser 0
limiter: tap_limiter 0 0
So, are the artifacts caused by the compressors
or the EQ?
The ones I referred to are caused by the FFT-based EQ.
I didn't use the EQ on JAMIN at all, just the
multiband
compressors and the final limiter.
I don't know if Jamin uses the FFT processing to implement
the bandsplitting for the multiband compressor.
If it does then the artefacts of this type of processing
will show up in the output.
If it doesn't, then Jamin needs some type of bandsplitting
fillters that add up to exactly the input if compressors
are inactive. I doubt very much if these are implemented
in Jamin.
Ciao,
17 May
17 May
9:14 a.m.
On Thu, May 13, 2010 at 12:58:15AM -0700, Ken Restivo wrote:
On Wed, May 12, 2010 at 10:14:41AM -1000, Joel Roth
wrote:
> Some time ago, Julien Claassen forwarded to me the
> results of his exchange with Fons regarding reasonable defaults for
> a three-band mastering network for Nama.
>
> As Fons writes here, the sum of the bandsplitting filters
> is unlikely to add up to the original signal, however
> we did adopt what we believe to be a reasonable compromise,
> with just a couple dB error.
>
> I'm appending the default settings for the LADSPA effects
> we are using. Each of the low/mid/high branches gets a compressor
> and a spatialiser.
>
> +-- low --+
> mix ----> eq ---+-- mid --+-- boost ---> output
> +-- high -+
>
> You could create a similar network in Ardour or any other
> sufficiently flexible software.
>
> eq: Parametric1 1 0 0 40 0.125 0 0 200 0.125 0 0 600 0.125 0 0 3300 0.125 0
>
> low_pass: lowpass_iir 106 2
>
> mid_pass: bandpass_iir 520 800 2
>
> high_pass: highpass_iir 1030 2
>
> compressor: sc4 0 3 16 0 1 3.25 0
>
> spatialiser: matrixSpatialiser 0
>
> limiter: tap_limiter 0 0
>
This is interesting. Never thought of building a DIY
mastering system out of LADSPA plugins, but I guess it
couldn't hurt.
Hi Ken,
The network here is based on the one used in Jamin.
I'm not sure how to match up the settings you have
here
with the ASCII diagram above. i.e. where does the
spatializer and limiter fit in?
+-- low --+
mix ----> eq ---+-- mid --+-- boost ---> output
+-- high -+
The low/mid/high branches each get a spatializer
and compressor.
The limiter goes on the boost track. Could be a
brick-wall limiter, however the scaling limiter
is OOTB defaut.
And why is the parametric
in front of the three high/mid/low pass filters, and what
purpose does it serve?
Same as any equalizer: for boosting/cutting various
frequency ranges, which may not correspond to the
low/mid/high bands.
Also, I'm assuming that the SC4 has
the same settings for each band, at least for starters.
Yes, zero compression is the default (see Julien's notes
below).
Also, I'm not sure how to route this in stereo. I
thought
SC4 was mono anyway. I'd guess that the compressors for
each band should be stereo compressors, ganged togehter in
some way (RMS?), like perhaps the Calf Compressor is.
In this case, Ecasound is hosting the LADSPA effects.
I believe Ecasound gangs the effect if necessary
to obtain the correct number of channels.
I feel limited here by ASCII art, and also by how to
do
the routing in for example Ardour, which might be really
complex, or maybe in something like Ingen.
Well, you could try installing Nama. Then you get
your mastering network by issuing 'master_on' at
the prompt.
The GLAME settings make sense to me: all 2-pole
filters,
with the lowpass rolling off at 106, the bandpass at 520
and 800, and the highpass at 1030.
Under Nama, if you want to use GLAME plugins instead of the
default filters, you can just substitute the plugin name or
LADSPA Unique ID into the appropriate configuration file
lines quoted above.
(Incidentally, I'm just getting ready to release a 1.0x
version. I've just today uploaded version 1.056 to CPAN,
but it has yet to show up. 1.055 is broken.)
How would these LADSPA filters compare to, for
example,
postfish?
In my untutored opinion, all conventional mastering tools
will use a somewhat similar network and similar effects.
If you understand how to use the individual effects, I think
there will not be any unfathomable mystery in the aggregate.
The mystery and artistry will be in your own creative
choices.
What I think Jamin does better than the others is that
it allows you to use different mastering parameters (scenes)
for different parts of the song.
Ron Parker is a respected engineer who not only approves of
Jamin but also wrote the mastering with Jamin tutorial.
http://jamin.sourceforge.net/en/tutorial.html
You say you hear some artifacts. Did you ever approach
the author?
I'm really starting to wish I'd used postfish
instead of JAMIN now.
Is Postfish current? It's not on the Linux Sound and MIDI
Applications page, and the last journal entry for postfish
I see is 2004:
http://xiphmont.livejournal.com/595.html
# Julien Claassen's Notes on Mastering effect defaults
#
# Eq: All sections are initially off. You can turn them
# on as needed, one at a time.
#
# Bandpass: Default settings are courtesy of Fons
# Adriaensen, who says they will be within 1.5dB of
# flat settings.
#
# Compressor is turned off, with reasonable default values
# set.
#
# Spatialiser and limiter: both initially off so you can start out
# clean and slowly work your way from there.
best,
Joel
-ken
--
Joel Roth
9:31 a.m.
On Sun, May 16, 2010 at 11:12:06PM -1000, Joel Roth wrote:
Yeah, it's old. But it's very cool, and Monty certainly knows his DSP.
On Thu, May 13, 2010 at 12:58:15AM -0700, Ken Restivo
wrote:
They do indeed seem similar in layout. As for the quality of the filters in them, that
varies. But if we're all using the same LADSPA effects, the results should be
comparable.
On Wed, May 12, 2010 at 10:14:41AM -1000, Joel
Roth wrote:
> Some time ago, Julien Claassen forwarded to me the
> results of his exchange with Fons regarding reasonable defaults for
> a three-band mastering network for Nama.
>
> As Fons writes here, the sum of the bandsplitting filters
> is unlikely to add up to the original signal, however
> we did adopt what we believe to be a reasonable compromise,
> with just a couple dB error.
>
> I'm appending the default settings for the LADSPA effects
> we are using. Each of the low/mid/high branches gets a compressor
> and a spatialiser.
>
> +-- low --+
> mix ----> eq ---+-- mid --+-- boost ---> output
> +-- high -+
>
> You could create a similar network in Ardour or any other
> sufficiently flexible software.
>
> eq: Parametric1 1 0 0 40 0.125 0 0 200 0.125 0 0 600 0.125 0 0 3300 0.125 0
>
> low_pass: lowpass_iir 106 2
>
> mid_pass: bandpass_iir 520 800 2
>
> high_pass: highpass_iir 1030 2
>
> compressor: sc4 0 3 16 0 1 3.25 0
>
> spatialiser: matrixSpatialiser 0
>
> limiter: tap_limiter 0 0
>
This is interesting. Never thought of building a
DIY
mastering system out of LADSPA plugins, but I guess it
couldn't hurt.
Hi Ken,
The network here is based on the one used in Jamin.
I'm not sure how to match up the settings you
have here
with the ASCII diagram above. i.e. where does the
spatializer and limiter fit in?
+-- low --+
mix ----> eq ---+-- mid --+-- boost ---> output
+-- high -+
The low/mid/high branches each get a spatializer
and compressor.
The limiter goes on the boost track. Could be a
brick-wall limiter, however the scaling limiter
is OOTB defaut.
And why is the parametric
in front of the three high/mid/low pass filters, and what
purpose does it serve?
Same as any equalizer: for boosting/cutting various
frequency ranges, which may not correspond to the
low/mid/high bands.
Also, I'm assuming that the SC4 has
the same settings for each band, at least for starters.
Yes, zero compression is the default (see Julien's notes
below).
Also, I'm not sure how to route this in
stereo. I thought
SC4 was mono anyway. I'd guess that the compressors for
each band should be stereo compressors, ganged togehter in
some way (RMS?), like perhaps the Calf Compressor is.
In this case, Ecasound is hosting the LADSPA effects.
I believe Ecasound gangs the effect if necessary
to obtain the correct number of channels.
I feel limited here by ASCII art, and also by how
to do
the routing in for example Ardour, which might be really
complex, or maybe in something like Ingen.
Well, you could try installing Nama. Then you get
your mastering network by issuing 'master_on' at
the prompt.
The GLAME settings make sense to me: all 2-pole
filters,
with the lowpass rolling off at 106, the bandpass at 520
and 800, and the highpass at 1030.
Under Nama, if you want to use GLAME plugins instead of the
default filters, you can just substitute the plugin name or
LADSPA Unique ID into the appropriate configuration file
lines quoted above.
(Incidentally, I'm just getting ready to release a 1.0x
version. I've just today uploaded version 1.056 to CPAN,
but it has yet to show up. 1.055 is broken.)
How would these LADSPA filters compare to, for
example,
postfish?
In my untutored opinion, all conventional mastering tools
will use a somewhat similar network and similar effects.
If you understand how to use the individual effects, I
think
there will not be any unfathomable mystery in the aggregate.
The mystery and artistry will be in your own creative
choices.
What I think Jamin does better than the others is that
it allows you to use different mastering parameters (scenes)
for different parts of the song.
Ron Parker is a respected engineer who not only approves of
Jamin but also wrote the mastering with Jamin tutorial.
http://jamin.sourceforge.net/en/tutorial.html
You say you hear some artifacts. Did you ever approach
the author?
Well, Fons kind of sniffed at Jamin-- "you are mastering through a vocoder"--
and I've seen and heard the quality of his code so I tell he knows a LOT more than
most folks about DSP. Meanwhile, the code of JAMIN looks like some cut-and-paste filters
off of a web forum, and indeed their EQ is an FFT. The GUI is pretty and well-organized,
but I'm not sure if what's going on underneath the hood is any good.
My ears are not good enough to hear DSP artifacts-- and to know that's what they are.
I did have some problems in the 6K and 12K range, which I fixed in the mix (my mixer going
straight to the mastering stage in one chain). And I guess I'm just worried that I may
have used a tool that introduced artifacts I can't hear or see, but others will.
It's not a big deal. It's not like millions of CD's are going to get printed
up.
I'm really
starting to wish I'd used postfish
instead of JAMIN now.
Is Postfish current? It's not on the Linux Sound and MIDI
Applications page, and the last journal entry for postfish
I see is 2004:
http://xiphmont.livejournal.com/595.html
# Julien Claassen's Notes on Mastering effect defaults
#
# Eq: All sections are initially off. You can turn them
# on as needed, one at a time.
#
# Bandpass: Default settings are courtesy of Fons
# Adriaensen, who says they will be within 1.5dB of
# flat settings.
#
# Compressor is turned off, with reasonable default values
# set.
#
# Spatialiser and limiter: both initially off so you can start out
# clean and slowly work your way from there.
Thanks!
-ken
9:52 a.m.
On 05/17/2010 07:29 PM, Ken Restivo wrote:
The toolchain uses ladspa fx. The gui is just a nice and compact way of
working with them. The overall sound quality is as good as 2 very
experienced dsp devs, 1 mastering engineer and 2 user interface
designers could come up with over approximately 500 hours worth of their
time. It's not perfect but it does a pretty good job and some people
have mastered some great music with it as a result.
In my untutored opinion, all conventional
mastering tools
will use a somewhat similar network and similar effects.
They do indeed seem similar in layout. As for the quality of the filters in
them, that varies. But if we're all using the same LADSPA effects, the results should
be comparable.
If you understand how to use the individual
effects, I think
there will not be any unfathomable mystery in the aggregate.
The mystery and artistry will be in your own creative
choices.
What I think Jamin does better than the others is that
it allows you to use different mastering parameters (scenes)
for different parts of the song.
Ron Parker is a respected engineer who not only approves of
Jamin but also wrote the mastering with Jamin tutorial.
http://jamin.sourceforge.net/en/tutorial.html
You say you hear some artifacts. Did you ever approach
the author?
Well, Fons kind of sniffed at Jamin-- "you are mastering through a
vocoder"-- and I've seen and heard the quality of his code so I tell he knows a
LOT more than most folks about DSP. Meanwhile, the code of JAMIN looks like some
cut-and-paste filters off of a web forum, and indeed their EQ is an FFT. The GUI is pretty
and well-organized, but I'm not sure if what's going on underneath the hood is any
good.
My ears are not good enough to hear DSP artifacts--
and to know that's what they are. I did have some problems in the 6K and 12K range,
which I fixed in the mix (my mixer going straight to the mastering stage in one chain).
And I guess I'm just worried that I may have used a tool that introduced artifacts I
can't hear or see, but others will. It's not a big deal. It's not like
millions of CD's are going to get printed up.
As Fons said, if you are happy with the sound that is what counts. If
you are looking for a specific thing such as the perfect radio dynamics
or a more powerful way of processing the sound then you may need to try
out some other tools. As far as I know Jamin is the only app for
Linux/Jack native that attempts to provide a professional mastering
toolchain. I haven't used postfix though but would expect it to be of
similar quality or better depending on how much time Monty has been able
to spend on it.
In terms of introducing artifacts. There have been some reports of very
specific items which as far as I know have been fixed in svn or else no
one has had any time or motivation to work on them. You owuld have to
check the mailig list to find out if they are anything you need to be
concerned about. I'm pretty sure that anything that is a major
showstopper will be immediately squashed and committed.
Now on the other hand if Fons has an idea for a more advanced mastering
tool and wants to share it I'm certainly interested in the possibilities
that represents. Jamin was built becasue we didn't have anything for
that step in the audio production process but it has been over 5 years
since any seriously active development has gone into it so we may be in
need of a refresh and broadening the options for getting the perfect
sound is always a good thing (tm).
Cheers.
--
Patrick Shirkey
Boost Hardware Ltd.
18 May
18 May
8:55 p.m.
On Mon, May 17, 2010 at 02:29:01AM -0700, Ken Restivo wrote:
Well, Fons kind of sniffed at Jamin-- "you are
mastering through a vocoder"
Well, that is not really what I wrote:
Responding to:
> I was thinking about tearing into the code for
> something like Jamin to look at what's done there. Maybe there are
> better examples for me to use though?
I wrote:
Jamin's FFT based filter is not really a filter,
it's a vocoder
being used as a filter and it has side effects.
Which is just true. It's also true that changing the window
function and increasing the FFT overlap has reduced the
artefacts to below -80..-90 dB w.r.t. the signal. But that's
not a solution but a cover-up, coming at the expense of a lot
of wasted CPU load - Jamin takes 35% on my 2GHz P4. For what
it is doing 5% would be reasonable. And it doesn't help to
bypass the EQ: it is *always* in circuit, even if the response
is forced to flat when you enable the 'bypass' checkbox. Nor
does it help to improve the atrocious type of responses that
the 'HD' filter will generate if you are just a bit unlucky.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
9:03 p.m.
On Tue, 18 May 2010 22:56:44 +0200
Fons Adriaensen <fons(a)kokkinizita.net> wrote:
On Mon, May 17, 2010 at 02:29:01AM -0700, Ken Restivo
wrote:
This is rather disturbing. I had noticed that jamin was quite
processor heavy, but was unaware that this was unnecessary. Has this
been discussed with the devs? Mostly I like the way it sounds and works,
and the interface it presents (not that I have much to compare it
with). I would rather see it improved than dropped.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Well, Fons kind of sniffed at Jamin-- "you
are mastering through a vocoder"
Well, that is not really what I wrote:
Responding to:
> I was thinking about tearing into the code
for
> something like Jamin to look at what's done there. Maybe there are
> better examples for me to use though?
I wrote:
Jamin's FFT based filter is not really a
filter, it's a vocoder
being used as a filter and it has side effects.
Which is just true. It's also true that changing the window
function and increasing the FFT overlap has reduced the
artefacts to below -80..-90 dB w.r.t. the signal. But that's
not a solution but a cover-up, coming at the expense of a lot
of wasted CPU load - Jamin takes 35% on my 2GHz P4. For what
it is doing 5% would be reasonable. And it doesn't help to
bypass the EQ: it is *always* in circuit, even if the response
is forced to flat when you enable the 'bypass' checkbox. Nor
does it help to improve the atrocious type of responses that
the 'HD' filter will generate if you are just a bit unlucky.
Ciao,
13 May
13 May
8:44 a.m.
On Wed, May 12, 2010 at 09:44:58PM +0200, Fons Adriaensen wrote:
On Wed, May 12, 2010 at 11:30:11AM -0700, Ken Restivo
wrote:
I dunno. What would the artifact sound like or look like? If I had a sample of what this
kind of damage sounds like, or a picture of what it looks like, I'd be able to better
determine if JAMIN was doing it or not.
One of the things I (and others) noticed, is a "nasty harshness" in the hihat. I
don't know if this might have been caused by JAMIN artifacts, but it did go away by
bypassing JAMIN. Being naive, and assuming that JAMIN was actually good mastering
software, I thought the problem was with the hihat itself, and was just being made more
noticeable when mastering. So, I "solved" the problem by hauling quite a few dB
of 12Khz and 6Khz, .5 octave each, out of the overhead mics. I will be really annoyed if I
ended up doing this just because of an artifact caused by JAMIN, or if there is other
sludge in my mixes that was caused by it.
-ken
So, are the artifacts caused by the compressors
or the EQ?
The ones I referred to are caused by the FFT-based EQ.
I didn't use the EQ on JAMIN at all, just the
multiband
compressors and the final limiter.
I don't know if Jamin uses the FFT processing to implement
the bandsplitting for the multiband compressor.
If it does then the artefacts of this type of processing
will show up in the output.
If it doesn't, then Jamin needs some type of bandsplitting
fillters that add up to exactly the input if compressors
are inactive. I doubt very much if these are implemented
in Jamin.
9:01 a.m.
On Wed, May 12, 2010 at 09:44:58PM +0200, Fons Adriaensen wrote:
On Wed, May 12, 2010 at 11:30:11AM -0700, Ken Restivo
wrote:
After poking around in JAMIN's source code (gawd I love Free Software, and also being
able to code well enough to read the source and get a decent sense of what it is doing),
it seems that JAMIN uses an IIR filter to do the crossovers. It seems to be a Butterworth
biquad filter. So, since I didn't use the FFT graphical EQ, it's possible that no
Ceylons infiltrated my music.
Thanks, and sorry about hijacking the thread.
-ken
So, are the artifacts caused by the compressors
or the EQ?
The ones I referred to are caused by the FFT-based EQ.
I didn't use the EQ on JAMIN at all, just the
multiband
compressors and the final limiter.
I don't know if Jamin uses the FFT processing to implement
the bandsplitting for the multiband compressor.
If it does then the artefacts of this type of processing
will show up in the output.
If it doesn't, then Jamin needs some type of bandsplitting
fillters that add up to exactly the input if compressors
are inactive. I doubt very much if these are implemented
in Jamin.
12 May
12 May
1:16 a.m.
Hi Fons
On Tue, May 11, 2010 at 4:19 PM, Fons Adriaensen <fons(a)kokkinizita.net> wrote:
On Tue, May 11, 2010 at 03:36:08PM -0700, Mark Knecht
wrote:
Yes, a specific (small) range of frequencies and some ability to see
if the energy meets some minimum level of interest.
Actually though, as a test of an idea I had and
just because I've got
the data here, I'm using stock market data, decomposing the data into
bands of energy if you will, and then summing the bands back together
to see how close I come to the original data. It works fairly well
most of the time, but stock data can have big directional moves at
times which appears as a big transient event. When those events
complete then the slower filter bands ring and cause large
displacements in the output.
So you want a set of filters with the following properties:
1. each filter has a frequency response with a shape that allows
an intuitive interpretation as a 'bandpass', i.e. a range of
frequencies, and
2. the sum of the filter outputs equals the original
input.
This is not really a requirement, but if they did then I'd have a more
visual demonstration that the process was working.
This is a *hard* problem. Basically none of the
classical filter
types have these properties. There are filter sets that can do
this but they are quite esoteric.
'Ringing' is not really a problem here, each of the individual
filters may ring, as long as this is cancelled by the others
when you add the outputs.
Not sure I totally agree with this as it assumes that in the end I
listen to the reconstituted sum of all the filters. On the other hand,
if I listen to only a few then without the other 'negative'
contributions I end up hearing the ringing in the few I'm listening
to.
An FFT will provide a set of filters having property (2), but
each filter has a sin(x)/x shape, which is not really a bandpass.
You can 'improve' the shape by windowing, but that destroys (2).
And anyway using an FFT like this is a 'block' operation - how
a sample is treated depends on its position within the block.
Windowing requires overlapping blocks, and they won't add up
to the original input.
I think also that an FFT assumes some sort of longer-term steady state
repetitive nature which isn't in the stock data. I could take a
representative sample - the last 1000 bars, and then treat that as if
it was a repeating cycle and extract frequencies. I'm not sure what
that will do for me and the sample points are likely to introduce lots
of new artifacts. Still, worth thinking about.
<SNIP>
Now if the purpose of the filtering is to extract 'features' of
the data, you really don't need property (2). And given the
nature of stock market data, I suspect that classic audio filters
are not the right way to extract such features. I'd have a look
at wavelet filters for example.
Ciao,
Will do. Thanks.
Cheers,
Mark
4:55 a.m.
Mark Knecht wrote:
I think also that an FFT assumes some sort of
longer-term steady state
Its actually worse than that. The FFT assumes that the input is steady
state periodic with a period length equal to the FFT length.
repetitive nature which isn't in the stock data.
The good news is that your stock data isn't much worse of a fit to
the assumptions of the FFT than real audio data :-).
I could take a
representative sample - the last 1000 bars, and then treat that as if
it was a repeating cycle and extract frequencies.
Then you loose time locality. In music, its not uncommon for the
chord to change once every bar. By doing the FFT over 100 bars
you are effectively 'averaging' the chord over those 100 bars.
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
11 May
11 May
11:35 p.m.
Mark Knecht wrote:
Actually though, as a test of an idea I had and just
because I've got
the data here, I'm using stock market data,
I thnk thats part of your problem.
Stock market data is not zero mean. It has a DC offset plus it usually
has a long term upward trend. The long term upward trend will look like
a large amount of low frequency energy.
If this filter really is for audio data, I really suggest you put audio
data through it.
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
5123
days inactive
5130
days old
linux-audio-user@lists.linuxaudio.org
28 comments
10 participants
participants (10)
-
Chris Cannam -
Erik de Castro Lopo -
Folderol -
Fons Adriaensen -
Garry Ogle -
Joel Roth -
Jörn Nettingsmeier -
Ken Restivo -
Mark Knecht -
Patrick Shirkey