From: jj@alice.att.com (James D. Johnston)
Newsgroups: comp.compression
Subject: Re: Too much lossy encoding?
Keywords: PASC, audio, ASPEC, MPEG-Audio, PAC, PXFM, MUSICAM, AC-2
Date: 14 Apr 92 14:44:02 GMT
Reply-To: jj@alice.UUCP (James D. Johnston)
Organization: Signal Processing Research Department, AT&T-Bell Labs

In article <1992Apr13.212222.7605@tc.fluke.COM> kurt@tc.fluke.COM (Kurt Guntheroth) writes:
>I want to clarify some things I've said in light of the discussion that has
>ensued.  
OK.
>The following things concerns me about lossy encoding 
>1.  People are "lowering the bar" for what is acceptable signal loss.  
Not true.  They are lowering the bit rate (and substantially) for
signals that sound the same as the original.  You could, if you
wanted, rather, raise the quality at the SAME bit rate as
the original, although I admit that I'd be hard pressed to come up
with a use for more than about 384kb/s for a typical stereo pair,
even with the most paranoid encoding considerations.

>2.  A given digital encoding scheme generally defines a single level of
>    quality such that if you can decode the signal at all, you get that
>    level of quality and no more.
This is an example of a completely incorrect statement, said in
an authoritive and reasonable appearing fashion.  No matter how 
true it looks, it's absolutely true.  It's true, for instance,
for PCM, but not for compressed algorithms.  In fact, the
quality of compressed signals varies with the signal, in both
the objective (SNR) and meaningful (subjective) fashion,
if you have low enough average bit rate.    It's also true
that given a smarter encoder, you can do better in the same
bit rate.  It's NOT true that you are stuck with "a single level
of quality" until after you've chosen a particular encoder and encoded
the signal.  Nobody can keep the producer or user from doing
something wrong.

>3.  Multi-format formats are only useful if the receiver can understand them
>    all, at least to some extent.  If each sub-format requires its own
>    receiver hardware, we've hardly improved anything have we?
Ever hear of a DSP?

>Another example would be a storage format with 20 bits of precision, and a
>decoder that could decode 14 bits, or 17, or 20, depending on the needs of
>the users.  These digital techniques have the same desirable user-oriented
>attribute that the user chooses the fidelity of playback.
But why?   I think you'll find that the only use for such a system
is to maintain some level of performance in locations with bad
signal.  You won't see this on a cable, a fiber, or whatever, rather
only on broadcast, and I frankly think broadcast will soon be limited to
mobile and remote (physically remote, that is) uses.

>On the other hand, many other proposed systems do not posess this attribute.
>They fix playback fidelity to conform to the instantaneous market and
>technology conditions of a particular day, not to theoretical absolute
>limits or traditional limits like available channel bandwidth.
Pardon me?  If you look at the MPEG-Audio standard, which I 
believe to be a rather flawed standard, it puts the lie to your
statement here, as it can be run at a large variety of bit
rates and samplign rates, allowing any sort of quality from
AM-like to CD-like. Yes, this is only selectable during encoding,
but why blame the algorithm for the producer's mistake?

>Here's some questions.  These are the reality checks for claims of
>imperceptible signal loss.  This is the test for whether the signal loss is
>REALLY imperceptible, or just a hack to fit today's storage technology.

>1.  Anybody designing storage formats where the receiver determines the
>    fidelity in a non-trivial way?
Pardon ME?  The RECEIVER?  Why use less than what you can achieve at
best, unless it's something very expensive?  (and it generally
won't cost any more)   There are two flaws here.  First, you will
generally have access (even in a broadcast system) to some level
of signal quality <assuming unequal error protection, as you
econd, if you allow either the channel or the reciever to determine
the quality, you're doing something called "embedded" coding,
which can be shown to be ALWAYS worse than composite coding,
for any given bit rate.  For sophisticated coders, like the
perceptual coders, it's MUCH worse, in general.  What you propose
is to make the decoder both artificially crippled AND the
whole process inefficient.

>2.  
>    All these formats were replaced by significantly better ones, both in
>    terms of ease of use and signal quality.  All these formats improved
>    during their lifetime, especially the quality of playback equipment.
And what's your problem with the new format?

>3.  How many people will give up CDs for mini disks and digital cassettes
>	and MPEG players if the signal quality is less good?  
A very good question, and one that I've argued extensively myself, to
no avail, in the MPEG-Audio committee.  I'll spare you the politics,
but suffice it to say <censored> overweighed any sort of technical or
economic needs.

(4 is rhetorical)
>5.  Have we really exhausted what we can do with lossless compression?  
In some sense, no, and in some sense, yes, but it is easily shown that
for given sorts of lossless compression, there is a lower bound
on the compression rate (this varies with the sort of compression,
but); this lower bound is much higher than ISDN, MPEG-I,
or satellite rates.

Kurt, I'd suggest that you learn a bit more about both lossless and
lossy compression techniques before you jump in with authoritarian
statements.
-- 
Vote for    *Copyright alice!jj 1992, all rights reserved, except transmission
President 1992 *by USENET and like free facilities granted. Said permission is
___________________*granted only for complete copies that include this notice.
Just Say !!!NO!!!       *Use on pay-for-read services specifically disallowed.


-- 
Vote for    *Copyright alice!jj 1992, all rights reserved, except transmission
President 1992 *by USENET and like free facilities granted. Said permission is
___________________*granted only for complete copies that include this notice.
Just Say !!!NO!!!       *Use on pay-for-read services specifically disallowed.