Re: [fluid-dev] Purpose of dither?

[Z F]

--- Miguel Lobo <address@hidden> wrote:

> >
> > No, you do not... :) Ever heard of texture synthesis? All you need
> > is statistical properties, not the signal itself to generate which
> > looks like a cat. So, it can be done without the original :) Since
> the
> > main features of the signal are preserved after truncation
> (otherwise
> > it would have been useless), it should be enough to synthesize
> noise'.
> 
> 
> 1) If the premise is that we can use an algorithm that can
> reconstruct the
> original signal, even in the presence of high-energy harmonics in the
> same
> frequency range as our signal, with less noise than through the use
> of
> dithering, no offence but I want to see the code.
> 
> 2) Even if such an algorithm exists and is usable, the raw s16 audio,
> which
> is the format that the FluidSynth function we're talking about is
> supposed
> to output, will still have the huge harmonics, and will sound really
> poor
> unless the software (or hardware!) using it knows it has to use our
> hypothetical harmonics removal algorithm.  Put it another way, by
> adding a
> compulsory step before playback, we would be defining a different
> audio
> format that is no longer raw s16.
> 
> 3) If one is really desperate for transmitting higher quality audio
> using 16
> bits, there is a much easier solution than inventing a new audio
> format, and
> that is using the float output format, which is already supported by
> FluidSynth.
> 
> 4) By the definition of information itself, once information is lost
> (e.g.
> by truncation) there is no getting it back algorithmically.  An
> algorithm
> can't output more information (in the sense of information entropy)
> than it
> receives as input.  It can try to reconstruct what the original
> information
> may have looked like, but there can't be any guarantee that it will
> get the
> reconstruction right, because it doesn't actually *have* that
> information.
> For example, say that there was an algorithm that, given the
> flat-color cat
> picture in the Wikipedia page, could reconstruct an approximation to
> the
> original high-color picture.  Hurrah, we say, we can save bandwidth
> by
> transmitting the smaller flat cat picture and having the receiver
> reconstruct the original.  But wait, what if we actually wanted to
> send a
> picture with flat colors?  What if we wanted to transmit a picture
> with an
> intermediate degree of color flatness?  The information that would
> have
> allowed us to distinguish between these cases is the information that
> was
> lost in the truncation, so it is not available to the reconstruction
> algorithm.
> 
> In any case, if we actually saw some code, we would be able to have a
> more
> concrete discussion.
> 
> Regards,
> Miguel
> 

I have to disapoint you by saying that to me the purpose of this
discussion was two-fold.

1. Understand what is happening with the setup Mihail has. I think
I understood. It was very intersting. It is interesting to fix the
radio by simply listening to it. It brought some old memories...

2. Academic discussion on the purpose of dithering, when it is needed
and when it is not. What it does.

I have learned a lot in this discussion, maybe other people too. I am 
glad to read the questions which you pose. When I as sitting on a
digital data processing course and asked similar questions, I got
nonsense in responce. Like about the flat-cat. The guy was claiming
that he can remove noise. I asked how he knows what noise is... maybe
that junk should be there, or at least part of it...
(question 4). To me this separation is impossible unless something is
known
about the signal you are getting which is not in the signal itself.

I completely agree on the information loss when truncation is happeing,
I just do not see how adding noise fixes that. I said that it
does not fix anything, simply changes one distortion for another which
is more pleasant to us, humans. This created a wave of discagreement
with comments that there is a fundamental theoretical need for that
noise. I do not understand that with my brain, but should be able to
hear with my ears.. My point was that if 16bit is not satisfactory than
the only known to me solution which is practically available is 24
bits. Noise does not help. Academic solution -- go float...

The reason why adding noise can not fix is this. If you transmit the 
same truncated value several times than by adding noise with proper
distribution, on average, you will transmit the correct number. But
if you repeat the transmission, why not simply increase the number of
bits. (Some design restrictions may come to play here to make this
multi-transmit interesting). But for audio applications when each
sample is transmitted only once, I simply do not see how the quality
(or more information) is beeing transmitted. So, I can only see the
trade-off of distortions which is perfectly valid, but has no
theoretical grounds, in my opinion.

The solution to the 16bit prolem (questions 1 and 2) is to use some
sort of basis-set, other whan the comb in the time-domain to provide
higher quality with
the same data rate. This is known as mpeg and all other compression
methods. But this needs to be supported in hardware, which should have
proper DAC. I am not aware of such special hardware, other than
a regular cpu running fluidsynth with a 24bit audio card. :)


Oh at least we are not discussing if the cat is dead of alive after we
shot into the room with it.

Best wishes,

ZF


       
____________________________________________________________________________________Yahoo!
 oneSearch: Finally, mobile search 
that gives answers, not web links. 
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC