Text 11855, 104 rader
Skriven 2008-10-03 09:17:16 av James Bradley (1:342/77.0)
     Kommentar till en text av Maurice Kinal
Ärende: the band[width] played o
================================
Subject: the band[width] played on (1/2)

09-30-08 20:33: Maurice Kinal to James Bradley, "the band[width] played on"

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

 MK> You mean nine-byte representation since each ASCII
 MK> character is a byte, actually 7 bits per character which
 MK> ends up taking up a byte as far as storage is concerned.

No... Your representation was taken at face value. "~~~~~~~~~" in an analog
representation would give us some sinusoidal tone with a DC offset, and some
NASTY sawtooth interruptions where the tildes don't match up to their
neighbour. The ASCII words to represent that waveform, would be an eight bit
word "sample" in the most bizarre definition of the term. (See my other post
regarding analog vrs. digital recording.)

 MK> However it doesn't really matter since the only point of
 MK> the ASCII representation was to replicate continuous and
 MK> discrete functions using the available ASCII character set.
 MK>  Can you do better?

I don't need to reinvent the wheel to drive a car. The codepages in place are
numerous enough to not need *my* input. <L>

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

As long as that wheel turns, it takes less energy to roll with it, than stop
it, re-invent it, test for bumps, stop that, re-invent that...

 > pretty boring tune. <G+D>

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

In an ASCII->binary world, one would think so. A digital sample of anything but
a predictable signal gets impossible to compress with todays techniques, unless
you throw some info out.

 MK> That is my story and I am sticking to it.

...And the world goes 'round.

 MK> apparently 6 channel to the 'correct' decoder but I think
 MK> it is still 16-bit.  Perhaps the blu-ray jobbers might have
 MK> 24-bit soundtracks but don't quote me on that.

Nor am I about to research the topic. (Doing the math...) Yup... Six channels
should give us a stereo pair for the fronts, the same for the surrounds, a
center, and a sub. The stereo surrounds are a 'home-theatre' dictate. Theatre
release prints, used a mono-surround channel for years. "4.1" in todays
parlance.

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

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

Nor would it change my course to find out. <L>

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

 MK> What compression method are you employing?  I noticed binkd

'Ta hell if I care! If it's one that DOS-Maximus and Linux can both provide,
it's the right one. <G> Even on a large mail fetch, I rarely see a 1M file, so
I'd be splitting hairs to compare one against the other. Then, we have the
modem compression schemes that couldn't better even the worst of todays tools.
(No, I don't care how old pkzip is, or what engine he used, or how it stacks up
to bz2... ... ...) Now that mail is moved through TCP, and the volume of Fido
traffic is mostly a trickle...

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

I thought ASCII, as used to parlay our language, (IE: This or any other
non-iconic message.) is highly successful in compression ratios?


 MK> No doubt.  I am analog.  :-)
 > Analogous, to be *sure!* }B-]

--- Maximus 3.01
 * Origin: -=-= Calgary Organization CDN (403) 242-3221 (1:342/77)