I guess they're used to eye candy over there in closed software land. Hell, I liked Jamin too until Fons hipped me to the fact that it's a vocoder.

On Fri, September 24, 2010 9:54 am, Folderol wrote: Just out of interest, when did this become a fact? IIRC Fons suggested the sc4 compressor algorithm was similar to a vocoder. Apart from the multiband parametric, limiter and overall ui development that are also part of the jamin experience, I have never heard anything coming out of jamin that sounds remotely like a vocoder. I have also not heard of any other jack application that attempts to provide a complete mastering tool chain. So, I'm not sure why jamin is now to be considered passe. Of course if someone else actually wrote something that was comparable in functionality then I would be more than interested to hear the results. But until that time jamin still stands as the only tool in it's class that I know of.

Although Fons has raised an issue with the compressor algorithm there seems to be no one who is able to make it better who also has the interest in doing so.

On Sat, Sep 25, 2010 at 09:47:33AM -0700, Patrick Shirkey wrote: Again, I have not made any comments on the compressor used in Jamin.

IIRC Fons suggested the sc4 compressor algorithm was similar to a vocoder. Apart from the multiband parametric, limiter and overall ui development that are also part of the jamin experience, I have never heard anything coming out of jamin that sounds remotely like a vocoder. I have also not heard of any other jack application that attempts to provide a complete mastering tool chain. So, I'm not sure why jamin is now to be considered passe. Of course if someone else actually wrote something that was comparable in functionality then I would be more than interested to hear the results. But until that time jamin still stands as the only tool in it's class that I know of.

IIRC Fons suggested the sc4 compressor algorithm was similar to a vocoder.

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.

On Sat, September 25, 2010 10:48 am, fons(a)kokkinizita.net 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. Hence jamin is already designed to minimise the negative effects on the signal flow that are caused by the toolchain. 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.

On Sat, Sep 25, 2010 at 03:44:33PM -0700, Patrick Shirkey wrote: To some extent, yes. But it's a kludge, and a solution to a problem that shouldn't exist in the first place. As said, there are two issues with the EQ. The first is that the implementation is subobtimal and introduces artefacts that have to be (and are to some extent) hidden by changes added after the initial release. The second is that this type of filtering allows and invites to do things that do indeed 'destroy' the sound from a purist POV, while adding nothing useful from any other POV. How much this matter depends on what other cruelties the signal has been subjected to before :-) It's interesting to review the whole issue of mastering. Why does it exist at all ? There is a mix of reasons for this. 1. To take technical limits of the distribution format into account. 2. To compete in the global 'loudness wars'. 3. To give the suits the last word. 4. To assemble a set of recorings into a coherent whole. (1) was certainly an issue in the analog days. Today this matters only for broadcasting, but radio stations are taking care of this anyway - at least those that are constrained by commercial factors to be 'louder than the competion'. (2) still exists, but it if matters you can have better results by taking care of this while mixing. Or just turning up the volume while listening. (3) still exists, but given that production and mixing techniques have become much more sophisticated, the possibilities for changing things in any major ways afterwards have in practice decreased. (4) still valid. Given all this, one can start thinking of what would be required from a mastering application. * Equalisation. Certainly. One advantage of having a separate mastering step is that it provides a second set of speakers, a second set of ears, and a second 'informed opinion'. But whatever is done in the way of EQ will have to be gentle and require rather smooth frequency response curves. It's a matter of adding a bit of 'clarity' or 'body', or 'punch'. None of this is done by agressive EQ. It's a few dB on rather broad frequency ranges. * Multi-band compression. Maybe. But if that improves the result, it's much easier to apply compression while mixing, on selected tracks. The 'multi-band' thing is there only to try and separate things again, and usually it fails. IMHO dynamics are part of the mixing step, no excuses. * Peak limiting to allow higher average level. No discussion here. Any signal, even purist classical recordings, can benefit from this without being degraded in any significant way -- if done correctly. But you can't do this using a general-purpose compression plugin. This really requires ad-hoc algorithms to do it well.

What's an ad-hoc algorithm? Why are general purpose audio compressors/limiters insufficient?

On Sunday 26 September 2010 02:22:21 fons(a)kokkinizita.net wrote: There is one exception to this rule: When you have a stereo feed from the console and a stereo feed from room mics, you can't get back to "mixing" to fix the issues that you can easily fix with multi-band compression.

On Mon, September 27, 2010 12:31 pm, Arnold Krille wrote: Just for the sake of clarity, now the problem is that jamin doesn't have a real parametric eq? Or is the main issue that it uses more resources than necessary and can be optimised?

On Tue, September 28, 2010 5:14 am, Arnold Krille wrote: Ok, Thanks for the clarification. I am pretty sure you know already that there are two eq modes in jamin? 30 band multi and 3 band parametric with shelves. However there is not 4 band. It wouldn't be that hard to add though if you are serious about it as the three band code is a good place to start.

I'm pretty sure that this is the reasoning behind going with the filter option. The resources are available even on a eeepc as Ken has reported so it is not really a big deal as jamin is intended for use post pro.

If you want to have it running during production then you should probably just get a very powerful machine or invest the time to correct the issues as near as possible to source.

On Tue, September 28, 2010 7:33 am, Arnold Krille wrote: Good point. Maybe Ken could clarify if he used his eeepc for the mastering stage on his album? Well, it was never designed as a foh tool. It is and always has been a stereo channel post prod tool. When it was developed I was running a 1 ghz celeron. It ran on there without issues. I don't see why it would have problems on any recent (past 8 years) notebook/netbook or PC. This is by design. When the 2 very experienced DSP engineers Steve Harris and Jack O'Quin and the very experienced mastering engineer Ron Parker spec'd the backend they decided that this was the most appropriate method given the available resources at the time. The idea was to provide as much smoothing of the bands as possible to create a very "clean" sound as per traditional mastering technique. Now if you want to use a tool that is designed explicitly with that goal in mind then you should definitely be considering jamin as an option. Which has not been corroborated and in fact has been out right dismissed by my contact here. I think it would be worth your time to build a little mock up with pd or jack rack and listen to the difference in the audio quality. I have very good reason to trust my sources that Fons is not correct when he says the current implementation is defective. The point about using a stand alone parametric eq plugin as you suggested is that it would definitely add artifacts to the end result which is why the decision was made to use the linear filter. That is a good point. I know you have the skills to make that happen. Do you have the time to craft a patch?

This would only output a stereo signal and the compressor expects three stereo signals. So you would have to either seperate the stereo signal after the eq with a filter or run a copy of the signal to each band of the compressor which might increase load but will certainly increase the chance of artifacts on the final post compressor output.

On Tuesday 28 September 2010 14:51:09 Patrick Shirkey wrote: If I understood Fons and yourself correctly, the "parametric eq" is just another way of modifying the response of the big filter. My idea is _not_ to *add* a three-band parametric, but to *replace* the convolution-based eq with one of the very fine ladspa plugins of parametric eq.

This should lower cpu-usage quite a lot. And if your audio signal needs a 31- band or a free-hand-drawn equalizer, you are better off with fixing the mix or using freqtweak, I think. Have fun, Arnold _______________________________________________ Linux-audio-user mailing list Linux-audio-user(a)lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-user

On Tue, Sep 28, 2010 at 04:48:09PM +0200, Dragan Noveski wrote: It should be easy enough to integrate this. The LV2 version includes the code to calculate the frequency response (correctly, using the actual filter parameters). It's python ATM but easy to rewrite in C. There's an improved version of this (as a Jack client), also adding 2nd order ('Neve style') shelf filters. Not to be released any time soon but available if you accept the NDA.

Ciao,

On Tue, Sep 28, 2010 at 04:48:09PM +0200, Dragan Noveski wrote: It should be easy enough to integrate this. The LV2 version includes the code to calculate the frequency response (correctly, using the actual filter parameters). It's python ATM but easy to rewrite in C. There's an improved version of this (as a Jack client), also adding 2nd order ('Neve style') shelf filters. Not to be released any time soon but available if you accept the NDA. Ciao,

Are you speaking from an existing plugin ? Sorry, I could not follow now ;) - which LV2 version or python code do you mean ?

Ok, Thanks for the clarification. I am pretty sure you know already that there are two eq modes in jamin? 30 band multi and 3 band parametric with shelves. However there is not 4 band. It wouldn't be that hard to add though if you are serious about it as the three band code is a good place to start.

Now I am not sure that the 3 band parametric should be considered a *real* parametric or not.

However I have been told that the implementation of the linear filter in jamin is fundamentally correct as the FFT/IFFT approach is the preferred implementation to obtain a more idealized functionality of those forms of EQ without screwing up the phase.

Fons has cause for suspicion about the current optimisation. It may turn out that it is possible that we could shave off some cpu cycles. Perhaps we can get to the bottom of that problem, but as we are using these large windows to increase the smoothing across the bands(?) it may be that there is no further optimisations that can be achieved.

On Tue, September 28, 2010 8:22 am, fons(a)kokkinizita.net wrote: Well if this is the case the implementation needs optimisation. That doesn't change the fundamental nature of the design choice.

Don't you mean an optimised implementation of the filter?

How can it be fundamentally wrong if all linear convolution operations can be expressed in the the transformed domain, and vice versa.

If there is a problem it is not due to the fundamental nature of the linear filter.

But I will query your analysis first because it may be that we are talking at cross purposes. IMO what you have identified is the potential for optimising the code.

This is definitely something that should be addressed if it indeed turns out you are correct in your analysis. Although I have strong reservations given that 3 different DSP engineers with qualitatively more experience than you can justify this design choice.

On Sat, Sep 25, 2010 at 10:07:46AM -0700, Patrick Shirkey wrote: 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). 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.

On Sun, Sep 26, 2010 at 12:45:30AM -0700, Patrick Shirkey wrote: The problem is not the use of an FFT nor the implementation of that FFT. It's about *how* the FFT is used. Let's look at a basic vocoder algorithm. We have two inputs signals wich we want to combine spectrally, using N-point FFT operations. 1. T1 = N samples from the first input. 2. F1 = FFT (T1) 3. T2 = N samples from the second input. 4. F2 = FFT (T2) 5. Multiply F1 and F2 point by point -> F3 6. T3 = inverse FFT (F3). 7. output T3. Repeat for the next block. Since we don't want clicks at block boundaries the blocks of N samples processed in this way are made to overlap, and the output is crossfaded between them. This is usually done by windowing before steps (2) and (4) and after step (6), and then just adding the output blocks that overlap. For example a square-root-raised-cosine window applied at all three places will have the net result of a raised-cosine window on the output, and this provides perfect crossfading between blocks that overlap by N/2 samples. Jamin's algorithm is just the same, except that F2 is not the result of an FFT but constructed from the data provided by the GUI. As long as the user does not change the frequency response, F2 is constant. A common mistake is to think that in that case this algorithm is just a filter, but it isn't. The reason is that step (5), multiplication in the frequency domain, is equivalent to convolution in the time domain. And the convolution of two signals of N samples (T1 and T2) has lenght 2*N-1. This means that this result is wrapped around in step (6) since the inverse FFT produces only N samples. The windowing on the inputs will reduce the errors resulting from this, and anyway for a vocoder or other spectral processor it doesn't matter so much since this is an effect anyway. Jamin reduces the errors by using a much larger overlap (IRCC the step is N/8 or N/16 instead of the usual N/2). To get the correct result, T1 and T2 must be limited to N/2 samples followed by as many zeros. Then each block of N/2 input samples produces N output samples without wrapping around, and they can just be added with an overlap of N/2. This is how linear convolution engines such as BruteFir or Jconvolver work. There is no windowing involved at all. For Jamin that would also mean that the required frequency response, F2, must the the N-point FFT of an impulse response that is not longer than N/2 samples. The data from the GUI must be preprocessed to ensure that this condition is satisfied. Now let's look at the CPU load involved. Assuming a step size of N/8, Jamin performs 16 N-point FFTs per channel per N samples. Using the exact linear convolution algo it would perform two FFTs of twice the size. This is roughly the same as 4 N-point FFTs, or 1/4 of the work. Ciao,

Can you give me a little more idea why you feel using FFT in this method is more likely to return atrifacts than the equivalent convolution? Is it simply because there is more data being crunched to get to the end result?

On Sun, Sep 26, 2010 at 05:50:24AM -0700, Patrick Shirkey wrote: Again, the choice is not between 'FFT' and 'convolution'. Jamin performs convolution, and uses an FFT to do it. The problem is that what Jamin does is *cyclic* convolution which produces artefacts and is not the same as filtering. Filtering requires *linear* convolution, which would actually be simpler, if you take into account the steps that Jamin takes to reduce the ill effects of the cyclic convolution. As explained above, the difference is in step (6) which for cyclic convolution is allowed to wrap around (meaning that part of the output ends up where it shouldn't be), while in linear convolution this is avoided by limiting the size of the inputs. Unless you want the detailed maths I don't think I could explain it any more clearly.

The reason is that step (5), multiplication in the frequency domain, is equivalent to convolution in the time domain. And the convolution of two signals of N samples (T1 and T2) has lenght 2*N-1. This means that this result is wrapped around in step (6) since the inverse FFT produces only N samples.