Re: [LAU] looking for command-line/scriptable mastering software

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: <grekimj@...>
To: Fons Adriaensen <fons@...>
Cc: <linux-audio-user@...>
Date: Friday, November 23, 2012 - 1:01 pm

--=_f34c6d47244e25f8fd4be5a17a09f3ee
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; Also
consider to what happens when the stereo signals are summed
to mono. If your panner is set slightly off-center, L and R will
have nearly the same gain (since they need to be identical for
a center source) and a delay between them of a fraction of a
millisecond or so. Summing L and R will result in quite strong=20
comb filter effects.
Thanks for starting some thoughts on the time alignment aspects.
Yes, I did make that provision for a mono source, so that the same
signal level is added to L and R whether panned or not, but just time
shifted in one channel if panned. And full left or full right is a
separate 'function' and only has signal in one side.=20
I will add the traditional pan. =20
Is mono compatibility really worth worrying about these days?
Because I do not just record signals directly from the A/D
converters,
but also signals that have already had some processing and probably
will have some more later. All serious audio processing in Linux (and
in almost all environments where audio is processed digitally) is
done
in floating point format, for good reasons. Why should I convert each
time I read or write a file ? That would only add errors.
Okay, makes sense. =20
You could probably eliminate a lot of code by using something like
libsndfile. And you would at least be able to read floating point
files.=20
I can see also adding options for things like LADSPA or LV2. But,
I'd also like the code to run if these things are not present in the
system.=20
If all filtering, effects, etc. is done in FP format, it's plain
silly to convert to integer just to add some values. And adding
also happens even when you don't see it explicitly. Any linear
filter is defined by its impulse response. Depending on the type
of filter that could be hundreds or even thousands of samples long.
So every output sample is a weighted sum of hundreds or thousands
of input samples even if not computed explicitly that way. Are you
really claiming that doing that in FP is OK while adding a few
signals on a mix bus isn't ?
There are a couple of outstanding (commercial) fixed point filters
out there, by the way. To answer your question, no I basically agree
with you. But realize the initial challenge of this project was to
make an absolutely pure signal path. And that path is still there if
you choose to not use effects. When you do use effects it's 64 bit
float because I am wary of 32 bit float. =20

Quote from the Quick Start Guide:
There are 3 text files that control Mixer4 and they must be kept
in the same directory, at least for now, as the Mixer4 executable.
Okay, I thought that's where the confusion was. 'For now' is
referring to walking the user through the set up process, not the
state of the code. I did not want to get into different directories
for the newbie user. I wanted to make initial setup as straight
forward as possible. =20
Grekim
On Fri 23/11/12 4:34 AM , Fons Adriaensen fons@linuxaudio.org sent:
On Thu, Nov 22, 2012 at 10:26:10PM -0500, Grekim wrote:
> /Maybe neat on headphones, but definitely the wrong thing for
> reproduction on speakers. Also bad for mono compatibility.
> And since it's closed source it's not possible to change
> this to normal panning, which would be a trivial exercise
> otherwise./
>=20
> I'd like to learn more about why it's so wrong.
There's no one-line answer to that. To understand why it's wrong
you have to work out how the signals from the two speakers combine
at the ears and compare the result to what happens for a real
sound source.
For low frequencies the analysis is very simple, you can do it
in two minutes just using pencil and paper. Just do it and you'll
see. For mid an high frequencies it gets considerably more complex
and a lot of psycho-acoustics is involved. The results go against
simple intuition, which is why many people have some difficulty
accepting them.
Also consider to what happens when the stereo signals are summed
to mono. If your panner is set slightly off-center, L and R will
have nearly the same gain (since they need to be identical for
a center source) and a delay between them of a fraction of a
millisecond or so. Summing L and R will result in quite strong=20
comb filter effects.
> /I've got ~3TB of floating point files here, and I'm not going
> to convert them just to be able to use a particular - any - SW./
>=20
> Why did you record in floating point format if your A/D converters
are not?
Because I do not just record signals directly from the A/D
converters,
but also signals that have already had some processing and probably
will have some more later. All serious audio processing in Linux (and
in almost all environments where audio is processed digitally) is
done
in floating point format, for good reasons. Why should I convert each
time I read or write a file ? That would only add errors.
A/D and D/A converters are probably the only components in the chain
that 'naturally' use an integer format. But even that isn't really
true any more. Most high quality converters are not just the bare
converter and an analog filter. They have some digital processing
going on between the SW interface and the actual converters, e.g.
most of the anti-alias filtering will be done digitally in an
oversampling converter. And that processing could very well be done
in FP format these days. Some high end sound cards (e.g. RME) have
native floating point interfaces.
There is nothing magic about the 2^16 or 2^24 analog levels that
correspond exactly to integer sample values. Change your gain by
0.1 dB and they will be an entirely different set, as good or as
bad as any.
> /
> The summing being exact is quite irrelevant if the rest isn't,
> and doesn't need to be anyway./
>=20
> Sorry it's not relevant to you. Aside for the latest version which
> does use ALSA, I have about 4 C header files. So there's no
libsend
> file or anything like that.=20
You could probably eliminate a lot of code by using something like
libsndfile. And you would at least be able to read floating point
files.=20
If all filtering, effects, etc. is done in FP format, it's plain
silly to convert to integer just to add some values. And adding
also happens even when you don't see it explicitly. Any linear
filter is defined by its impulse response. Depending on the type
of filter that could be hundreds or even thousands of samples long.
So every output sample is a weighted sum of hundreds or thousands
of input samples even if not computed explicitly that way. Are you
really claiming that doing that in FP is OK while adding a few
signals on a mix bus isn't ?
Regarding the latter, it may also help to analyse the situation a
bit more rigorously before jumping to easy conclusions. It involves
a bit of maths, but nothing esoterical.=20
> /OK, then the info on your site is out of date.../
>=20
> Don't think so.=20
Quote from the Quick Start Guide:
There are 3 text files that control Mixer4 and they must be kept
in the same directory, at least for now, as the Mixer4 executable.
Ciao,
--=20
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
=20
--=_f34c6d47244e25f8fd4be5a17a09f3ee
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"

BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; Also consider to what happens when=
the stereo signals are summed
to mono. If your panner is set slightly off-center, L and R will
have nearly the same gain (since they need to be identical for
a center source) and a delay between them of a fraction of a
millisecond or so. Summing L and R will result in quite strong
comb filter effects.

Thanks for starting some thoughts on the time alignment aspects.
Yes, I did make that provision for a mono source, so that the same signal l=
evel is added to L and R whether panned or not, but just time shifted in on=
e channel if panned.  And full left or full right is a separate 'funct=
ion' and only has signal in one side.
I will add the traditional pan. 
Is mono compatibility really worth worrying about these days?

Because I do not just record signals di=
rectly from the A/D converters,
but also signals that have already had some processing and probably<=
br style=3D"font-style: italic;">
will have some more later. All serious audio processing in Linux (and
in almost all environments where audio is processed digitally) is done
in floating point format, for good reasons. Why should I convert each
time I read or write a file ? That would only add errors.

Okay, makes sense.  

You could probably eliminate a lot of c=
ode by using something like
libsndfile. And you would at least be able to read floating point
files.

I can see also adding options for things like LADSPA or LV2.  But, I'd=
also like the code to run if these things are not present in the system. <=
br>

If all filtering, effects, etc. is done=
in FP format, it's plain
silly to convert to integer just to add some values. And adding
also happens even when you don't see it explicitly. Any linear
filter is defined by its impulse response. Depending on the type
of filter that could be hundreds or even thousands of samples long.<=
br style=3D"font-style: italic;">
So every output sample is a weighted sum of hundreds or thousands
of input samples even if not computed explicitly that way. Are you
really claiming that doing that in FP is OK while adding a few
signals on a mix bus isn't ?

There are a couple of outstanding (commercial) fixed point filters out ther=
e, by the way.   To answer your question, no I basically agree wi=
th you.  But realize the initial challenge of this project was to make=
an absolutely pure signal path.  And that path is still there if you =
choose to not use effects.  When you do use effects it's 64 bit float =
because I am wary of 32 bit float.  =

Quote from the Quick Start Guide:

There are 3 text files that control Mixer4 and they must be kept
in the same directory, at least for now, as the Mixer4 executable.<=
br>

Okay, I thought that's where the confusion was.  'For now' is referrin=
g to walking the user through the set up process, not the state of the code=
.  I did not want to get into different directories for the newbie use=
r.  I wanted to make initial setup as straight forward as possible.&nb=
sp;

Grekim

On Fri 23/11/12 4:34 AM , Fons Adriaens=
en fons@linuxaudio.org sent:
On Thu, Nov 22=
, 2012 at 10:26:10PM -0500, Grekim wrote:

> /Maybe neat on headphones, =
but definitely the wrong thing for

> reproduction on speakers. A=
lso bad for mono compatibility.

> And since it's closed sourc=
e it's not possible to change

> this to normal panning, whi=
ch would be a trivial exercise

> otherwise./

>

> I'd like to learn more abou=
t why it's so wrong.

There's no one-line answer to that. To understand why it's wrong

you have to work out how the signals from the two speakers combine

at the ears and compare the result to what happens for a real

sound source.

For low frequencies the analysis is very simple, you can do it

in two minutes just using pencil and paper. Just do it and you'll

see. For mid an high frequencies it gets considerably more complex

and a lot of psycho-acoustics is involved. The results go against

simple intuition, which is why many people have some difficulty

accepting them.

Also consider to what happens when the stereo signals are summed

to mono. If your panner is set slightly off-center, L and R will

have nearly the same gain (since they need to be identical for

a center source) and a delay between them of a fraction of a

millisecond or so. Summing L and R will result in quite strong

comb filter effects.

> /I've got ~3TB of floating =
point files here, and I'm not going

> to convert them just to be =
able to use a particular - any - SW./

>

> Why did you record in float=
ing point format if your A/D converters are not?

Because I do not just record signals directly from the A/D converters,

but also signals that have already had some processing and probably

will have some more later. All serious audio processing in Linux (and

in almost all environments where audio is processed digitally) is done

in floating point format, for good reasons. Why should I convert each

time I read or write a file ? That would only add errors.

A/D and D/A converters are probably the only components in the chain

that 'naturally' use an integer format. But even that isn't really

true any more. Most high quality converters are not just the bare

converter and an analog filter. They have some digital processing

going on between the SW interface and the actual converters, e.g.

most of the anti-alias filtering will be done digitally in an

oversampling converter. And that processing could very well be done

in FP format these days. Some high end sound cards (e.g. RME) have

native floating point interfaces.

There is nothing magic about the 2^16 or 2^24 analog levels that

correspond exactly to integer sample values. Change your gain by

0.1 dB and they will be an entirely different set, as good or as

bad as any.

> /

> The summing being exact is =
quite irrelevant if the rest isn't,

> and doesn't need to be anyw=
ay./

>

> Sorry it's not relevant to =
you. Aside for the latest version which

> does use ALSA, I have about=
4 C header files. So there's no libsend

> file or anything like that.=

You could probably eliminate a lot of code by using something like

libsndfile. And you would at least be able to read floating point

files.

If all filtering, effects, etc. is done in FP format, it's plain

silly to convert to integer just to add some values. And adding

also happens even when you don't see it explicitly. Any linear

filter is defined by its impulse response. Depending on the type

of filter that could be hundreds or even thousands of samples long.

So every output sample is a weighted sum of hundreds or thousands

of input samples even if not computed explicitly that way. Are you

really claiming that doing that in FP is OK while adding a few

signals on a mix bus isn't ?

Regarding the latter, it may also help to analyse the situation a

bit more rigorously before jumping to easy conclusions. It involves

a bit of maths, but nothing esoterical.

> /OK, then the info on your =
site is out of date.../

>

> Don't think so.

Quote from the Quick Start Guide:

There are 3 text files that control Mixer4 and they must be kept

in the same directory, at least for now, as the Mixer4 executable.

Ciao,

--

FA

A world of exhaustive, reliable metadata would be an utopia.

It's also a pipe-dream, founded on self-delusion, nerd hubris

and hysterically inflated market opportunities. (Cory Doctorow)

--=_f34c6d47244e25f8fd4be5a17a09f3ee--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [LAU] looking for command-line/scriptable mastering soft..., , (Fri Nov 23, 1:01 pm)