[LAU] Subject: Albums under a label recorded and/or mixed with Linux

sonofzev at iinet.net.au sonofzev at iinet.net.au
Wed Sep 29 07:19:04 UTC 2010

On Wed Sep 29 16:11 , "Patrick Shirkey"  sent:

>On Tue, September 28, 2010 5:47 pm, Jan Depner wrote:
>> On Tue, 2010-09-28 at 18:22 -0700, Patrick Shirkey wrote:
>>> On Tue, September 28, 2010 7:33 am, Arnold Krille wrote:
>>> > On Tuesday 28 September 2010 16:21:48 Patrick Shirkey wrote:
>>> >> 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.
>>> >
>>> > I don't actually remember Ken saying that he runs jamin on his eeepc.
>>> > True, he
>>> > is running an awful lot of software on there, but I doubt that he is
>>> > adding
>>> > 10ms artificial delay from jamin to his live-setup...
>>> >
>>> Good point. Maybe Ken could clarify if he used his eeepc for the
>>> mastering
>>> stage on his album?
>>> >> 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.
>>> >
>>> > Yes, a 1.8GHz turion64 running jack (3x1028 at 48kHz) and an ardour
>>> session
>>> > with
>>> > two stereo tracks, 4 plugins (SC4-compressor and an eq for each
>>> stereo) is
>>> > to
>>> > weak to also run jamin.
>>> >
>>> > Please get a grip! I am not using jamin on an under-spec machine. And
>>> I am
>>> > not
>>> > mis-using it during mixing/recording of a >48-channels session either.
>>> I
>>> > even
>>> > stopped dreaming about using jamin for live-foh usage (because of the
>>> > delay
>>> > introduced by the filter).
>>> 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.
>>> > All I am saying is that jamin takes up a good amount of resources for
>>> its
>>> > processing. [*]
>>> 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.
>>> > And I combined Fons' argument that the filter used is not a good
>>> > implementation
>>> Which has not been corroborated and in fact has been out right dismissed
>>> by my contact here.
>>> > and probably not needed anyway with my idea of a simpler but equally
>>> > useful tool.
>>> 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.
>>> > [*] It would be uber-cool if one could switch off that analyzer-view
>>> to
>>> > save processing cycles.
>>> That is a good point. I know you have the skills to make that happen. Do
>>> you have the time to craft a patch?
>>     Since the analyzer view is only redrawn by default 10 times per
>> second there really isn't much overhead to save.  Take a look at
>> draw_EQ_spectrum_curve in hdeq.c.  You'll see that all it's really doing
>> is drawing a predefined pixmap, converting 1023 levels to dB, and then
>> drawing 1023 line segments.  This is hardly a drag on any system.  Be
>> that as it may, you can adjust the frequency of the update in
>> Edit->Preferences to be any value from 10 times per second to 0 times
>> per second.  In other words, the ability to switch off the analyzer view
>> is already there.
>Good point, thanks for the reminder.
>Yet another reason why nothing has been done on jamin for a while now ;-)

I've used Jamin a number of times for self-mastering releases, including a vinyl
release in 2009. While I would prefer to go to a professional mastering agency my
return from music currently doesn't justify it (it doesn't even pay my ardour
subscription :) ).. . The labels I've submitted too were more happy with the
mastering quality (probably happier than I was .. although the problem is my
skill level not the software quality). 

Jamin does a very good job, I can't see any reason to change it. 

As for resources, I have got in the habit of not rendering my final mix-down to
stereo and then mastering, but simply inserting Jamin into the main output of
Ardour.. this allows for any adjustments to be made at the mix level (e.g. a
channel being too loud)... without going through the process of rendering again.. 

On a AMD Phenom II X3 720 OC'd to ~3.5 GHZ.. I have not exceeded resource limits
on 24 channel (48KHz 32 bit broadcast wav)... with numerous plugins, including
some of the more complex ones then going through JACK while retaining a 128
period and 3 buffer setting on jackd - remembering that everything inside Jack is
in on one processor core... (with the other cores simply providing smooth X11
rendering e.t.c..) .. 

It's not a eeepc but it is just an average spec PC.. (with some high quality parts).

More information about the Linux-audio-user mailing list