26 Sep
2010
26 Sep
'10
1:16 a.m.
On Sat, Sep 25, 2010 at 03:44:33PM -0700, Patrick Shirkey wrote:
On Sat, September 25, 2010 10:48 am, fons(a)kokkinizita.net wrote:
This business about the vocoder came up when I asked about Jamin back when I was mastering
the Better Than Lahar album, and Fons replied explaining the problems with the FFT
"EQ" in Jamin. It seems I've stirred it up again by mentioning that in this
thread.
AIR, the recommended solutions were to use another mastering tool, such as the one that
Julien worked on that has a GUI running in an interpreted lanugage (Python? Perl? I
don't recall the name of it), or try PostFish (unmaintained, doesn't support
JACK), or just build a mastering network out of LADSPA components such as SC4 compressor
and a network of 3 or more parametric EQ's set to cross over each other. Or just stick
with Jamin, and say, "screw it, good enough for free", which is the approach I
ended up taking. My ears simply aren't good enough to hear the artifacts, and I had
plenty of CPU power to deal with Jamin's inefficiency, so I just went with it. Plus,
we hoped to make enough money to pay to get it remastered somewhere professionally in the
future anyway, although, that never happened.
-ken
On Sat, Sep 25, 2010 at 10:07:46AM -0700, Patrick
Shirkey wrote:
I have to admit I didn't follow this part of the development process
closely enough but I will have a look to confirm.
To clarify further, are you referring to the
entire ui or specifically
to
the parametric eq ui which Jan designed? I think Jan would be the first
to
admit that he is not a dsp expert but was instead attempting to provide
a
user friendly interface for the specific plugin.
The confusion continues :-)
AFAIK Jamin does not have a parametric EQ. It uses an FFT-based
method with a graphical interface that makes it look either like
a combination of 'freehand' frequency response and parametric,
or as a 30-band 'graphic EQ'. But it's the same algorithm in all
cases, and it's not a plugin.
If works by taking the FFT of the input,
multiplying in the
frequency domain by some precomputed values, and transforming
back using an IFFT. This modifies the frequency response of
course, but it is *not* a linear filter and produces side
effects (modulation). Jamin minimises this by 1) windowing,
which amounts to crossfading between processed blocks of
samples, and 2) processing much more overlapping blocks than
the minimum required to do crossfading (which would be 2).
Hence jamin is already designed to minimise the negative effects on the
signal flow that are caused by the toolchain.
The proper way to implement a filter of this type
(with a FR
defined at all multiples of Fsamp / 1024) would be by using
linear convolution rather than cyclic. But as said, this is
not the right kind of filter anyway.
So what you are saying is that the whole design is sub optimal? Can you
clarify this in terms of every genre of professionally oriented music or
is it more of an audiophile type of concern? Like preferring Bugatti to
Toyota?
I think the whole jamin team would agree with you that we started out with
the idea we were not the best people to make the software but that instead
we were attempting to resolve a missing component of the LAD toolset. In
that case we did the best with the knowledge and skills that we had.
Jamin was defined from the start as one way of handling the mastering
process. Not necessarily the best or suited to every type of recording. It
integrates the tools for that method into a single interface.
Gold/Platinum radio friendly rock/metal albums have been produced using
that method by the main "professional" contributors.
For those interested in using jamin as a part of their toolset it should
be kept that it has these artifacts Fons describes above. Considering that
you are compressing the audio as much as possible in order to get a radio
sound anyway these trade offs may not be much of a cause for concern.