Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!eru!hagbard!sunic!mcsun!unido!mpirbn!p554mve
From: p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst)
Newsgroups: comp.sys.amiga
Subject: Re: a new music standard
Message-ID: <1384@mpirbn.mpifr-bonn.mpg.de>
Date: 24 Nov 90 16:42:47 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> <188@cbmcel.UUCP>
Reply-To: p554mve@mpirbn.UUCP (Michael van Elst)
Organization: Max-Planck-Institut fuer Radioastronomie, Bonn
Lines: 47

In article <188@cbmcel.UUCP> stoller@cbmcel.UUCP (Martin S. Stoller) writes:
>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.
Why ? Especially with floppies you won't see much differences between
reading large chunks and smaller ones (ok, sth like 8 or 16 blocks).
And then you can simply use buffered reads (or even double buffered).
With harddisks that's a difference, the fantastic transfer rates 
most people mention (>300k/sec) can be reached only by reading contigous
blocks in one single read operation, so you get slower when dealing with
smaller buffers.

>>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!
Yes, that is but I don't see the point here. If you have to process the
data at all (versus "loading a plain memory dump") you won't see any
speed loss from parsing the IFF structure too.

>>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.
No, I didn't think of saving frames with full information, but I wouldn't
invent a new FORM while say a LIST ILBM with maybe some new property
chunks would have done the same.

>>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 :^)
What should I repair ? SMUS and 8SVX is quite usuable.

>You know what a SNARK is?  No?  Lucky you...
Well, it's handsome for striking a light.

Regards,
-- 
Michael van Elst
UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
                                "A potential Snark may lurk in every tree."