[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [kidsgames] Word database
Along the lines of the picture format thread I was hoping someone would do
some research to see if there is a noncopyrighted resource for images
perhaps a image archive on the web. It will be alot easier to use what
already exists rather than making alot of new images for the word database.
I think png at this point sounds like a good choice but if there is a
resource it doesn't really matter what format the image files are since we
can convert them.
Thanks
Brian Thompson
> -----Original Message-----
> From: owner-kidsgames@smluc.org [mailto:owner-kidsgames@smluc.org]On
> Behalf Of Erik
> Sent: Saturday, February 19, 2000 8:37 PM
> To: kidsgames@smluc.org
> Subject: Re: [kidsgames] Word database
>
>
>
> On 19-Feb-2000 Steve Baker wrote:
> > Kidsgames Project Coordinator - Jeff Waddell wrote:
> >
> >> -->I think there are a few things I'm really going to need
> help with are: a
> >> -->recording mechanism, maybe one that can be used from inside
> of forms for
> >> -->enter the data, what is a good format, mp3 wav...
> >>
> >> I personally like .au (Sun audio format, but I'm not sure the status of
> >> that format)
> >>
> >> I can't recommend (even though I'd like to) .mp3 or .wav
> because they have
> >> patent issues.
> >
> > MP3 is very costly (in time and code complexity) to decode -
> it's compression
> > is also optimised for music, not voice. I don't recommend it.
> >
>
> mp3 is expensive to decode and extremely expensive to encode, but the
> optimization if for general sound, not just music. It's highly
> effective for
> voice, and if you use low bitrates and mono, it's incredibly
> small and fairly
> cheap to decode. decoding into persistant buffers would probably
> be a good move
> to low powered computers (IE, store them in mp3 on the hdd, but cache them
> uncompressed in ram or tmp files). For a small low quality mp3,
> the time to
> decode would probably be a fraction of a second on even a 486.
>
> the MP3 format itself is an iso standard and is free for use, the
> patent issues
> are with a specific algorithm that Fraunhofer-IIS patented for
> encoding, but
> the format is open, and there are free implementations available.
> I've read
> about some upset with patents and iso standards, so I'm not 100% sure :/
>
> > WAV is nasty to decode and being a Mircosoft product is liable to change
> > with every new release of Windoze. I don't like it - but it is a pretty
> > universal standard - and you should probably support it.
> >
>
> modern wav only has one small header difference from RIFF format
> and hasn't
> changed in the real format for a long long time. I'm not quite
> sure what the
> difference between AIFF and RIFF are, but they're very old
> formats. MP3's are
> actually compressed RIFF/wav audio files
>
> > AU is OK too.
> >
>
> au has some quality deficiencies, but is probably good enough for
> plain voice.
>
> >> --> Another thing is the
> >> -->image files format? pcx png gif????
> >>
> >> I recommend AGAINST gif due to the Unisys patent fiasco. PNG should be
> >> great, and if somebody submits a gif, it can't be too hard to
> pull it into
> >> the gimp and resave it as .png before it is made globally
> avabilable can
> >> it?
> >
> > Choosing GIF could be very bad news. If a GIF is generated from a
> > non-licensed
> > program (eg GIMP) then if you have that file on your web page -
> you could
> > be liable for a $25,000 license fee to UniSys...don't go there!
> >
> > PNG is an excellent choice. There is a convenient portable library for
> > reading and writing them, they are suitable for the WWW and are nicely
> > compressed with a LOSSLESS compression scheme. You might also consider
> > 'MNG' - which allows simple animations to be stored in the file just as
> > GIF does - and which is based on PNG. Both PNG and MNG come from the
> > OpenSource community and are FREE in every sense.
> >
> > JPEG is another obvious standard - but beware because JPEG is a LOSSY
> > compression scheme - the image you get out is not as good quality as
> > the one you put in. This isn't too noticable for photos - but
> for simple
> > 'cartoonish' images (such as this project is most likely to use), JPEG
> > produces nasty 'ringing' artifacts around sharp colour transitions.
> > JPEG also doesn't allow an 'alpha' channel - so no transparency - also
> > no GIF-style animation.
> >
> > PCX is obsolete....let's not go there.
> >
> > Another format I like is '.rgb' - or 'SGI' format. It's VERY easy to
> > read and write - allows for monochrome images and images with
> transparency.
> > No animation features though.
> >
> > TIFF may be worthy of investigation - it has a lot of obscure varients
> > though and some 'extensions' make it hard to read well.
> >
> > There are a variety of X-windows formats - but they are not well used
> > or supported under Windoze...so let's not go there.
> >
> > BMP is the commonest Windoze format - but just like WAV, it changes with
> > every new version of Windoze and is not too well documented.
> >
>
> GIF is evil, pcx and tiff are prehistoric and so de-standardized
> they're almost
> worthless, there are a few differnet rgb/sgi formats (I've seen some with
> headers and some without... I beleive imagemagick produces rgb
> and rgba without
> which means very easy parsing, but absolutely no compression).
> JPG and PNG are
> the two best ones, and libraries exist to handle them easily (the
> libraries
> even exist on windows, crystal space uses 'em).
>
> > As for the format of the database itself, I'd STRONGLY recommend
> > that we go with XML - which is a spin-off of HTML and which is going
> > to become a big-time standard for web-based databases. Hopefully,
> > most database engines will ultimately support it.
> >
>
> Tools to convert between dbms formats are pretty trivial to
> write, and mysql
> can 'export' files into a script of sql commands. SQL is a well
> defined and
> common dbms language, and it's here right now. I don't know of any mature
> dbms's for XML, it'd be nice if they went that way, but it's not
> a certainty.
> If you want to implement one then switch to the other, it'd be
> trivial to write
> conversion utilities. The actual dbms chosen is actually fairly
> moot, the more
> important thing is the schema used.
>
> > While you are thinking about standards for things like images and
> > sounds, why not also consider a format for 3D models. Allowing people
> > to attach a 3D model to a word is going to be very important for the
> > future. 2D is dead!
> >
> > There is one clear format for 3D in a situation like this - and it's
> > VRML. This allows for animations and even simple 'behaviours' to
> > be attached to a model.
> >
>
> that would be cool
>
> > Conclusions:
> > ~~~~~~~~~~~~
> >
> > I would recommend:
> >
> > * WAV or AU for sounds.
> If a lot of sounds are present, a more compressed format, like
> mp3, would be
> better.
> > * PNG or MNG for pictures and 2D animations.
> png/mng and jpg/mpeg both are good choices
> > * VRML for 3D models and animations.
> > * XML for the overall database structure.
> moot and pointless, it's an implementation detail, how the tables
> are built is
> far more important than if they use xml or sql or dbase or whatever
>
> >
> > --
> > Steve Baker http://web2.airmail.net/sjbaker1
> > sjbaker1@airmail.net (home) http://www.woodsoup.org/~sbaker
> > sjbaker@hti.com (work)
> >
> >
> > -
> > kidsgames@smluc.org -- To get off this list send "unsubscribe" in the
> > body of a message to majordomo@smluc.org
>
> -Erik <erik@smluc.org> [http://math.smsu.edu/~br0ke]
>
> The opinions expressed by me are not necessarily opinions. In all
> probability, they are random rambling, and to be ignored. Failure
> to ignore
> may result in severe boredom or confusion. Shake well before opening. Keep
> Refrigerated.
>
> -
> kidsgames@smluc.org -- To get off this list send "unsubscribe" in the
> body of a message to majordomo@smluc.org
>
-
kidsgames@smluc.org -- To get off this list send "unsubscribe kidsgames"
in the body of a message to majordomo@smluc.org