29 Sep
2010
29 Sep
'10
11:59 p.m.
On Wed, 2010-09-29 at 15:19 +0800, sonofzev(a)iinet.net.au wrote:
On Wed Sep 29 16:11 , "Patrick Shirkey" sent:
I do the same. I have occasionally come up against something that I
can't handle that way but those are few and far between. When it does
happen I just export the master, make a new ardour project with just the
master track, and then run JAMin.
On Tue, September 28, 2010 5:47 pm, Jan Depner wrote:
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 Tue, 2010-09-28 at 18:22 -0700, Patrick Shirkey wrote:
Good point, thanks for the reminder.
Yet another reason why nothing has been done on jamin for a while now ;-)
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@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.
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).