Text 11849, 77 rader
Skriven 2008-09-30 20:33:20 av Maurice Kinal (1:261/38)
     Kommentar till en text av James Bradley
Ärende: the band[width] played on
=================================
Hey James!

> So your nine-bit representation would suppose you are including a
> redundancy check?

You mean nine-byte representation since each ASCII character is a byte,
actually 7 bits per character which ends up taking up a byte as far as storage
is concerned.  However it doesn't really matter since the only point of the
ASCII representation was to replicate continuous and discrete functions using
the available ASCII character set.  Can you do better?

No builtin redunancy checking but I am sure that your modem took care of that
when my reply containing the ASCII replication of continuous and discrete
functions was being trasferred to your box, probably zipped up like all
DOS-think fido transfers.  If not then it seems to have survived from what I
see in your reply that I am currently replying to.

> Which brings me to the analog slope. Your representation would be a
> pretty boring tune. <G+D>

The digital one would be at the very least equally boring to the analog one
upon playback, tonally speaking.  Both are nine bytes and would "compress"
equally as well as the other.

That is my story and I am sticking to it.

> I think that was pretty close to being true at 44.1k 16bit.
> (Isn't that the CD spec?)

I am not sure but when converting to mp3 that seems to be the acceptable specs
or at least the most widely employed.  DVD soundtacks seem to all be 48kHz AC3
which I believe is a Dolby standard.  Shows up as 16-bit 2 channel on all my
boxes and apparently 6 channel to the 'correct' decoder but I think it is still
16-bit.  Perhaps the blu-ray jobbers might have 24-bit soundtracks but don't
quote me on that.

> You missed the "Chicken and the egg" inference.

Maybe.  You'll never know for sure will you?

> Now, I use a compression alogarithm on my ASCII to economize bandwidth.
> I don't understand your aversion that.

What compression method are you employing?  I noticed binkd could use either
gzip or bzip2 but there was never all that much pure ASCII being trasferred
between here and anywhere else to be all that useful as it pertained to
(de)compressing ASCII on the fly.  Also too few of the Fido messaging suppliers
could exploit it if indeed it was ever really an issue or threatened to become
an issue, which is EXTREMELY doubtful.

I have no aversion to ASCII compression.  However DOS-think Fido sysops can't
handle pure compression and compensate with a combination archiver and
compression (eg pkzip, arj, etc) and thus pure compression techniques seem to
be beyond their grasp as it could pertain to on the fly ASCII compression. 
Besides the current echomail header "standards" aren't ASCII anyhow so it
really isn't a worthwhile pursuit given that filtering out non-ASCII characters
would reduce bandwidth even without compression. Pure text messages don't
compress all that well to be worth it in most cases and most definetly
stripping non-ASCII characters from Fido messages is more successful at
reducing bandwidth as well as further processing time just to display a text
message to a terminal.

> Because I use a POTS for giving you a hard time

That works for me.  Don't stop on my account.

 MK> No doubt.  I am analog.  :-)

> Analogous, to be *sure!* }B-]

To what?

Life is good,
Maurice

--- BBBS/LiI v4.01 Flag
 * Origin: Prism bbs (1:261/38)