Director 3 idea
4 messages in this thread
I have a great idea for Director version 3. I'd like to see a sound
and picture, Director specific, file compressor that can be controlled
from within the film script. A four character code within the script
could decompress the picture (or sound) files to a RAM disk, hard drive,
whatever. This might slow things up for set up but you could squeeze more
art on a disk and that art would be secured from people that want to see
the nuts and bolts of your magic. Any possibility? Please?!
Well, CDTV supports a new compression mechanism, which is supported by The
Director as far as images are concerned. The Squeezebox library can be
accessed via the CDTV module for images, and images can be loaded and
retained in their compressed form in RAM. They can be decompressed on the
fly. Currently the squeezebox sound compression is not supported form The
Director, but I suppose it could be.
There are a couple of problems though. The squeezebox library may not be
readily distributable outside of CDTV, and I'm not sure to what extent
Commodore is planning on continuing support for it. Compression can be a
sticky subject, as the higher compression schemes are lossy and slow to
decompress, the lower compression schemes may not compress enough to make
enough difference over ANIM or ILBM or fibonnaci (for audio, which is
already supported by The Director) to be worth the trouble.
Still, it's relatively a no-brainer to provide squeezebox support in a
Director module, I just don't know if anyone can get it who isn't a CDTV
developer.
Keith
Compression is kind of a bonus. What I would really like is a utility
that can encrypt IFF picture or sound files with a key word or sequence of
numbers. Then I would like the Director to be able to decrypt those files
to one of the frame buffers. The key word or numbers could be placed in
the compiled Director script. This would add security to a distributable
disk where a person couldn't simply view the raw picture frames or use
sound files in other projects. If this could be done while adding
compression, well, so much the better. I realize it could add time to
running the scripts but if it is done properly a lot can be done at
startup and placed into RAM. I'm not a programmer so I don't know how
much of a pain in the neck it would be to implement such a thing but it
seems possible. (Maybe something for a version 3 or Toolkit?) Thanks.
I don't expect that some kind of encryption is difficult to add at the
compression/decompression step, in fact, there are crunching utilities that
do such things. However, I also figure we will not be doing our own
trailblazing in the compression algorithm area, since there are multiple
standards in this area now, and I expect that some of these existing
standards would be difficult to beat as far as compression efficiency. Due
to this, I expect that what we will do is to provide hooks to an external
compression/decompression library (like squeezebox) and let other
individuals have at the specialized cases like you describe.
I encourage the utilization of libraries in this manner for a lot of
features (or modules as well) because it allows for the plug-and play of
alternative parts that might add features like you describe.
For instance, a compression library like squeezebox could be utilized by a
front-end "stub" library that calls squeezebox for the compression stages,
but adds its own encryption stage. In this way, it would not be necessary
to derive a specialized compression mechanism, and then be upstaged when a
new standard comes out (and is perhaps implemented into a compatible
library). If squeezebox (or similar) is improved, the stub library would
presumably be compatible and therefore you'd get the features of the new
squeezebox immediately, without waiting for someone to add them to the
proprietary "encrypted" version.
Keith