Conference napalm::commusic_v1

    
    
    The phone people have been doing this stuff for a long time.  The chips
    they've developed are generically referred to as "codecs";
    COder/DECoder.  This topic may have already been addressed in the AUDIO
    conference.  I don't think codecs are a good thing for samplers,
    though.  They do sacrifice some fidelity.  What might be more useful is
    a data compression scheme imbedded in the sampler's OS.  But as memory
    prices continue to drop, manufacturer's are much more likely to just
    throw more chips in the box...
    
    

    from today's new Voice announcements :
       
    "Standards -- Digital's voice products are designed in accordance
    with standards. DECvoice supports the CCITT standards for voice
    digitization, and CIT will support emerging ECMA standards. "
    
    As CCITT was instrumental in image compression/decomp, I intuit that
    this also may be part of the voice digitization stuff.
    
    The nice thing about standards is there's so many to choose from.
    
    karl  

We had a go-round on compression a little while back in, I believe, the AMIGA
conference. One assumption most folks make is that compression automatically
means data loss, which isn't necessarily so (although it usually is). Image and
voice compression algorithms usually do capitalize on the fact that not all the
data is required for recognition of the "key" aspects of the image and sound,
respectively; these are typically the methods which get immortalized in silicon,
because of their commercial value.

Some algorithms for lossless data compression are around (no, I can't recall
names at the moment), and I think audio (as opposed to voice) data compression
should use these, if any. "Loss of fidelity" is just not equivalent to "loss of
recognizability," which is the only concern in compression of voice data.

Then again, as someone has already said, memory is getting cheaper, and it
seems silly to throw CPU time (albeit coprocessor CPU) at the problem when you
can throw memory at it- unless one talks about long-term storage media. When
storing samples on disk for the long haul, a little longer access time might be
considered acceptable in exchange for a significant reduction in disk space
requirements.

Has anyone heard of a lossless data compression algorithm being committed to
a chip?

Bob

    Compression is not just of interest for storage, but also for
    transmission.  You just can't buy long distance hi-fi analog
    circuits from the telephone companies any more.  All they sell
    is digital circuits.
    
    Stereo at CD quality, with no compression, is about 1.5 megabits
    per second.  That gets expensive real fast.
    
    But with compression you can get two 15kHz circuits into 256 kilobits
    per second.  But I am sure the distortion numbers are higher.

    
    
    	IT is interesting to note that our ( and the rest of the indutry )
    Data DAT drives have compression in hardware. The DDS standard that
    defines Data DAT has picked a standard. The standard includes "C"
    code for compression/decompression and HP sells a chip ( $50 ) to
    do it in hardware.
    	You can bet this is a loss less system. Data files want %100 back.
    
    		Steve Peters
    		Tape/Optical Eng.
    

    There are several standards for compression of audio either established
    or under development.  CCITT has standardized four (I think) 4 KHz audio
    encodings.  This includes two 64 Kbit/sec standards as well as one each
    at 32 Kb/s and 24 Kb/s.  It has also standardized a 7.5 KHz audio
    encoding at 64 Kb/s.  In addition, there is work under way to define an
    MPEG/audio standard for very good quality audio to go along with
    MPEG/video motion picture encoding.  This is a multi-bitrate standard
    targeted around 128 Kb/s or 256 Kb/s I think (this is from memory).
    
    The loss-less versus lossy discussion really only make sense in a pure
    digital domain.  Any crossover between the analog and digital domains
    is inherently lossy.  The only thing you get to control is how much
    loss.
    
    The 64 Kb/s encodings use an 8 KHz sample rate with 8 bit samples. 
    Even this basic encoding has a form of `compression', since the encoding
    is logarithmic instead of linear.  This either increases the dynamic
    range or improves the quanitization accuracy near at lower signal
    levels, depending on how you look at it.  There are two different
    versions of this because you need one for the U.S. and one for the rest
    of the world, as in everything else.
    
    The 32 Kb/s encoding starts with the basic 64 Kb/s encoding above, but
    stores a 4 bit difference between samples, rather than the 8 bit value
    of the sample.  For anyone who remembers the PRO-350 TMS option, it
    used a similar scheme called CVSD which stores a single bit difference
    at a 32 KHz rate  (that's right - a single bit DAC before they were all
    the rage).
    
    DECvoice implements the two 64 Kb/s standards as well as the 32 Kb/s
    standard.  DECaudio supports both 64 Kb/s standards by default, but can
    also do CD standard sampling with optional hardware.
    
    I don't remember how the 24 Kb/s encoding works off-hand, but it is a
    lot more complex than the 32 Kb/s.  The MPEG/audio standard is more
    complex again with a multi-level encoding strategy.  If I remember
    correctly, it breaks the signal into frequency bands which are encoded
    individually and then these bits streams are fed up to a higher level
    encoder that decides how to allocate the available digital bandwidth
    among the different frequency bands (dynamically) for the best results. 
    I seem to remember that it might even be a three level encoding scheme,
    but I can't remember what the third level would be.  Davis Pan
    represents Digital on the MPEG/audio standards committee.
    
    Anyone interested in more details on the CCITT encodings can find them
    in Recommendations G.721, G.722, and G.723 or others in that same
    Fasicle (that's what they call their volumes - honest).
    
    Tom