Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!wuarchive!udel!princeton!pilot.njin.net!rutgers!cbmvax!cbmehq!cbmswi!cbmcel!stoller
From: stoller@cbmcel.UUCP (Martin S. Stoller)
Newsgroups: comp.sys.amiga
Subject: Re: a new music standard
Message-ID: <188@cbmcel.UUCP>
Date: 16 Nov 90 11:26:24 GMT
References: <35126@nigel.ee.udel.edu> <558@cbmger.UUCP> <183@cbmcel.UUCP> <1360@mpirbn.mpifr-bonn.mpg.de> <185@cbmcel.UUCP> <1373@mpirbn.mpifr-bonn.mpg.de>
Reply-To: stoller@cbmcel.UUCP (Martin S. Stoller)
Organization: COMMODORE ELECTRONICS LIMITED
Lines: 39

In article <1373@mpirbn.mpifr-bonn.mpg.de> p554mve@mpirbn.UUCP (Michael van Elst) writes:
>In article <185@cbmcel.UUCP> stoller@cbmcel.UUCP (Martin S. Stoller) writes:
>>>                                "A potential Snark may lurk in every tree."
>>So you know your SF-Fantasy...   ^^^^->
>It's from the Mike Batt album "The hunting of the snark" based on Lewis Carrols
>Epos. Would you call this SF ?
And Mike Batt must have read Edgar Rice Burroghs :^)

[stuff deleted] Read my Rablings elsewhere, if they still exist :^)
>I don't think that a complicated IFF is much slower to load. Of course
A complicated IFF plays H*LL with normal disks.  As I wanted to say before,
HARD DISKS are perfect for complicated IFF, but not Floppies... A simple IFF,
with only one FORM, (planned proparly) will load faster than any CAT.
>it needs a little more time than loading a plain memory dump but if you
>introduce any coding schemes (like data compression), you won't see anything
Copmression is also needed for simple IFF.  Even decompressors written in C
can be real fast on 68000/8Mhz!
>from the overhead of IFF.
>I've never seen a reason for ANIM files not to include complete ILBMs but
> the stripped BODY. Maybe you'll
>end with redundant information but it makes the format more orthogonal.
Quite simply 'cause the ANIM saves space on DISK and IN RAM!  All my frames (
except the original) are diffs from the previous.  I have Anims which are 
40 frames long.  How big ? Not much bigger than 2 ILBM's of the same resolution,
 noise and depth.
>Any volunteers to write (and publish) a SMUS/8SVX reader and player ?
>I've seen a nice SMUS player but it comes binary only, so you can't
>use it with your own programs.
Ok, repair SMUS & 8SVX.  You might end up with something usable :^)

>Michael van Elst
>                                "A potential Snark may lurk in every tree."
You know what a SNARK is?  No?  Lucky you...


-- 

   Regards,
   UUCP: [{(uunet|pyramid|rutgers)!cbmvax}!cbmehq!cbmcel!stoller