On Wed, 11 May 2011 13:25:47 +0200
Alexandre Ratchov <[email protected]> wrote:

> On Wed, May 11, 2011 at 09:45:05AM +0300, Sviatoslav Chagaev wrote:
> > On Wed, 11 May 2011 03:35:56 +0000
> > Jacob Meuser <[email protected]> wrote:
> > 
> > > clipping is better than normalizing?  really?
> > 
> > Clipping might describe something like value&0xffffff, so no, not
> > clipping, saturating addition.
> > Try it and see for yourself.
> 
> truncating higher bits or clipping alter the stream non-linearly and
> imo both are evil.

But I think the lowering of dynamic range also degrades the quality.
You had 100 different values and then you suddenly have, say 20,
some information has been lost...

> 
> > 
> > > 
> > > what about the case where aucat is used for offline mixing?
> > > 
> > 
> > What about it?
> > 
> 
> I'd like "aucat -n -o result.wav -i file1.wav -i file2.wav" to not
> saturate.
> 

As far as I've read undeadly.org, you're a musician. I do understand
that you require very precise control of audio and various processing
operations. But I think most users probably aren't that sophisticated
and are more interested in the sound system "just working", so that
mp3s play, videos can be watched and aucat doesn't surprise them by
having it's own will and changing the volume when it feels like it.

> > > like the mixerctl change, you are taking away things that exist
> > > for good reason, because it makes *your* situation better in *your*
> > > opinion, when you can (mostly) have what you want with the current
> > > code (if you just try a little).
> > > 
> > 
> > I'm not taking anything away, I'm setting things right.
> > Like I already said, the -v option stays fully functional.
> > Everything can be boiled down to opinion. Please don't answer
> > in the style "you're wrong because I said so".
> 
> It's more complicated that "i'm right so you're wrong".
> 
> Mixing (as other processing in aucat) is best effort. It's a
> compromise between quality loss by distortion and by dynamic range
> reduction.
>
> > I've already given enough insight and evidence as to per why the
> > way it's done currently is wrong.
> >
> 
> Come on, both approches are physcally wrong, it's a matter of taste,
> and the way you claim it's wrong tends to be irritating. Espectially
> since this is 3+ years old code, and you guess this was discussed
> plenty of times.

Yes, you are right. We can model what happens with sound in real
world only to some degree.

> 
> > Explain why it's not important to adhere to the least surprise
> > principle.
> 
> least surprise priciple for me is: streams do not suffer non-linear
> distortion when played through aucat.
> 

I see. For me, a regular Joe User, the least surprising thing would be
for aucat to do mixing in a similar manner to what I have previously
experienced, i.e. similar to how it happens in real world and in other
OS.

> > Explain why is it better to force the users to choose between
> > two evils when they could be offered one good.
> 
> Because diffent users may have different needs.

That is true, but I believe it is possible to do things in such a way,
so that ordinary users who are not interested in super-advanced
functionality can be freed from the burdens.

> 
> > Explain why aucat should not model real world sound physics.
> > 
> 
> because DACs have limited dynamic range; if you use "-v 100",
> your closer to sound physics than with clipping.
> 

We are talking about a system which directly interfaces to human
sensory inputs. I think we can't rely only on logic in this case,
subjective feelings have even higher priority. Consider MP3 for example
-- it doesn't even try to be as precise as possible, rather, it makes
it so that it would seem to humans that it sounds ok, but in reality
the sound gets distorted.

> [...]
> 
> And note that two approaches are not exclusive. If you don't like the
> way dynamic range is shared, roll a nice diff to disable this
> feature. If people like it, and it hurts nobody, they will take it.
> 

I agree, I think a hybrid approach could be used.

> -- Alexandre

Reply via email to