From owner-freebsd-multimedia Tue Jun 10 19:55:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA23813 for multimedia-outgoing; Tue, 10 Jun 1997 19:55:20 -0700 (PDT) Received: from cais.cais.com (root@cais.com [199.0.216.4]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA23794 for ; Tue, 10 Jun 1997 19:55:14 -0700 (PDT) Received: from earth.mat.net (root@earth.mat.net [205.252.122.1]) by cais.cais.com (8.8.5/) with SMTP id WAA24188; Tue, 10 Jun 1997 22:55:02 -0400 (EDT) Received: from Journey2.mat.net (journey2.mat.net [205.252.122.116]) by earth.mat.net (8.6.12/8.6.12) with SMTP id WAA25553; Tue, 10 Jun 1997 22:55:00 -0400 Date: Tue, 10 Jun 1997 22:54:30 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@Journey2.mat.net To: Wm Brian McCane cc: multimedia@FreeBSD.ORG Subject: Re: Old standards In-Reply-To: <199706110112.UAA28573@bmccane.uit.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Jun 1997, Wm Brian McCane wrote: > > On Mon, 9 Jun 1997, Wm Brian McCane wrote: > > > The algorithm used by this chip was a lossy algorithm. It had a single bit of > data per sample. The sample would start at say 127, then each 0 bit decreases > the value by 1, and each 1 bit increased it by 1. If there are 3 bits in a > row which are identical, the algorithm uses a catchup value from that point > on, say a value of 3, until the current value crosses over the actual target > value. This procedure continues for the entire play back, and `approximates' > the input data. There are two problems with this algorithm, one is that it is > lossy, however at 32K/second the target value doesn't tend to change more than > a couple of bits either way. The second problem is a `hiss' equal to 1/2 the > sample rate because it is NOT possible to play silence. Instead it plays back > 127,128,127,128,127,128,127,128,127,128,127,128. Actually, now that I think > about it, there was a 3rd possible problem. When approximating you could > overshoot the size of a byte, and get a POP when the value went from 0 to 255 > quickly. This sounds like adaptive delta mod, which is not limited to an 8 bit range. At 32K, it would sounds pretty good, I'd think. > > brian > > > > > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+-----------------------------------------------