chm114u@vaxc.cc.monash.edu.au (08/09/90)
In article <434@fawlty.towers.oz>, johnmac@fawlty.towers.oz (John MacLean) writes: > In article <1990Aug1.231338.7751@laguna.ccsf.caltech.edu> toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes: >>About the palette reversals (essentially, GET RID OF THEM!): >>I feel very strongly that a standard format should NOT reverse or convolute >>the palette data in ANY way whatsoever, in spite of the 'all the existing >>formats do it' reasoning. >> >>Todd Whitesel >>toddpw @ tybalt.caltech.edu > > Todd, > you'll be happy to know that palettes are not reversed in all the > existing formats as I was led to believe. > I only recievied my first external source of 3200 pics a few days ago, and > they were totally incompatible with the pics I had created. > > It is also NOT true that the palettes themselves are reversed. > > This all comes from the fact that most source going around uses palette $F > for scanline 0, $E for palette 1 etc, etc. > Most source also puts the last color in each palette into memory first. > > The palette data in all formats is: > > +$00 Palette for scanline 0: color0 color1 color2 ..... color F > +$20 Palette for scanline 1: .......... > ............ > +$1E0 Palette for scanline 199: color0 ..... color F > > Just as I and everyone else would have initially hoped. > > As for the standard form in APF. This seems to imply that we might as well > use the 'PALETTE' chunk. > Any APF file with a MAIN and a PALETTE with the number of scanlines == > the number of palettes is a multi palette picture. > > I'll stick with Brooks format for uncompressed - but change the filetype. > Again - pass this on for anyone interested. > > John MacLean. > -- > This net: johnmac@fawlty.towers.oz.au Phone: +61 2 427 2999 > That net: uunet!fawlty.towers.oz.au!johnmac Fax: +61 2 427 7072 > Snail: Tower Technology, Unit D 31-33 Sirius Rd, Home: +61 2 960 1453 > Lane Cove, NSW 2066, Australia.
chm114u@vaxc.cc.monash.edu.au (08/09/90)
Sorry, I don't know what happened in the last post!
* Can anyone help me with information on how to convert a sound file
digitized on a GS to a sound resource for use by Supercard on the Mac.
I can transfer binary files to and from the GS and Mac but don't know how to
change it into a Mac resource. Information on the reverse process is also
gratefully invited.
Thanks in advance ... Mike.toddpw@tybalt.caltech.edu (Todd P. Whitesel) (08/10/90)
chm114u@vaxc.cc.monash.edu.au writes: >* Can anyone help me with information on how to convert a sound file >digitized on a GS to a sound resource for use by Supercard on the Mac. >I can transfer binary files to and from the GS and Mac but don't know how to >change it into a Mac resource. Information on the reverse process is also >gratefully invited. SoundEdit by Farallon... it's the program that comes with a MacRecorder and it is very handy to have around. However, be warned that early macs can only play back at four sample rates: 22 khz, 11 khz, 7 khz, and 5 khz -- if your GS sounds were digitized at some rate in between then you might have fun trying to get the pitch to sound right. SoundEdit has a computational pitch changer in it but the results usually sound horrible. BTW, What digitizer did you use? My sonic blaster has this annoying hum in the digitize section -- I can't digitize any usable instruments with it. Maybe I should upgrade to an Audio Animator and not worry about it... Todd Whitesel toddpw @ tybalt.caltech.edu