Amiga ISO Collection/AmigaMiscModsCD3.iso/_PROGRAMME/TOOLS/modCRUSHER.lha/modCRUSHER.doc

Text File | 1980-01-01 | 8.5 KB | 223 lines

---------------------------------------------------------------------------
****************************  modCRUSHER V2.0  ****************************
---------------------------------------------------------------------------

                    By Olly Koenders
                    9 Isaac-Edey Place
                    Hampton Park
        06-09-96        Victoria, Australia 3976

                    PH: ISD? [phone] (anytime)



This program and its associated files are free to distribute anwhere to
anybody on any medium providing all files are distributed as a package and
it's made perfectly clear that the two styles of Modcrusher which form the
basis of this package are SHAREWARE.  If you like 'em and use 'em, don't
forget the programmer (name and address above).  Contributions of any
amount are welcome including feedback.  The more feedback and ideas for
improvements will see the same returned.  The Amiga user base in Europe is
HUGE in comparison to Australia and most AmigaNuts here have sold their souls
for the Idiot Breed Mentality and turned their brains to mush.

Remember, the Amiga's NOT finished and may never be BUT:

Buy for it, write for it, be part of it - but in all cases - SUPPORT IT!

===========================================================================

I've coded two styles of Modcrusher so the user can derive the best use of
its facilities.  A Workbench/GUI interface and a CLI/Shell style.  The GUI
style will be described first as the usages are virtually identical to the
CLI style.


**** Workbench/GUI Style:

This program may be run from its icon or from the CLI.

To Crush a Module:
------------------

1.    Select the appropriate mode (explained shortly),

2.    Type the appropriate path/filenames in the "Load:" and "Save:"
    gadgets (or if you have the arp.library in your "libs:" directory,
    click the "REQ" gadget to bring up first the load requester and
    finally the save one will appear).  Note that you WILL require at
    least a filename in both stringgadgets or Modcrusher will eventually
    display an error!

3.    If everything looks OK to you, press "GO!".

The module will be loaded (if found) and compressed to your requirements.
Eventually to be saved as your specified filename.

Just follow the same procedure to unpack the file.  Its status will be
recognised automatically and if packed, will be unpacked again and written
to the specified destination.  The current "Mode" setting will be ignored
and the mode of pack will be gleaned from the packed file and reiterated in
the window.


**** CLI/Shell Style:

This program is not capable of running from an icon.


From the CLI window type: MODCRUSHER [Mode] [ModNameToLoad] [ModNameToSave]

where "Mode" is a number from "0" to "4".  Do not include the "[]" stuff!

I coded this especially for script files and fans of the excellent
DirectoryOpus.

If you're unpacking a module using this style then the "Mode" setting is
ignored but MUST be present in the parameter list for internal parsing of
the input string.  See if I'm wrong.


**** Modes Explained:

To those that've been using version 1.5, some things have changed but only
for the better.  I'm sorry that I didn't get it right the first time.

Modes for both versions and their equivalents:

V1.5    V2.0
------------
0    0 - No Change

1    1 - No Change

    2 - Added and Renamed

2    3 - Renamed

3    4 - Renamed

4    * - Dispensed with


V1.5 packed on Mode "1" if unpacked with V2.0 will more than likely be
completely knackered (sorry!) - Use V1.5 to unpack.

V1.5 packed on Modes "2" or "3" will unpack fine although "Mode x Pass" will
display a higher number - Don't panic, all is well.

To unpack a V1.5 file packed with Mode "4", use CLI style V2.0 to unpack as
the GUI V2.0 doesn't understand the mode and will subsequently fail to give
satisfactory results (if any!).

The modes are:

    0 - No loss (1 Pass)
    1 - Quieter Samples
    2 - Quiet/Normal Music
    3 - Louder Samples
    4 - In Case 1-3 Fail!

It's not as simple to explain as that but here goes:-

Mode "0" will ignore the placement of the sound data and will just pack the
thing as best it can.  This will incur no loss whatsoever on the sound
quality and in fact can be used to pack ANY file - sound, data, executable,
game, you name it.  Just remember that all modes are "heavy" packers and
on slow Amigas the time to compress will take considerably longer.  The
"Final Pass" will take the longest.

Modes "1" to "4" are a whole 'nother story and they REQUIRE the module to be
of the 31 Instrument type - If they're not, expect a nasty crash (booo!).
Besides, I've seen bugger all of the lesser types but if called for and
providing I can find one of these, I'll include the necessary code.

Packing sound isn't as simple as running a standard "ByteRun" algorithm
through it and hoping for the best.  Something entirely different is
required.  It took me a few days of computational and testing but it
manages well.

Mode "1" will embark on a vicious campaign to compress the sound data.
Albeit some sound quality will be lost from certain loud samples in the
module, it should still be playable if a little muffled (approx. 10%
depending on the sample) and the pack rate increases substantially.

Mode "2" attempts to rectify the losses obtained through sample compression
and in songs sampled at 12000 to 20000 s/ps, Mode "2" can be used with
indiscernible loss most of the time.  The sometimes muddy/muffled samples
tend to become much clearer (brighter) and as a side benefit the pack rate
also increases.

If the song still sounds muddy or muffled then try Mode "3" and although it
will sound brighter, some of the low-speed, high pitch samples might begin
to "buzz" or sound grainy.

Mode "4" goes still further and although not recommended, may be of use
in some instances.  Most of the samples will begin to sound grainy
depending on the samples in the module.

Version 1.5 preferred the sound data to be sampled at low/mid volumes and
in VERY rare cases this may still apply.  A big fix has ensued since then...


**** The Big(?) Fix:

The "Error Correction" routine has now been completely replaced and
integrated with the "Post-Sine-Decompression Mode-Pass" and will flawlessly
remove all errors in the sample data (clicks, pops, spikes etc.).

It was discovered that the abovementioned routine was actually overdriving
some of the data on recreation and CAUSING the spikes, therefore the
rewriting and integration hasn't only caught the problem before it occurred,
it's now 100 bytes shorter AND 100% faster!

Also discovered was the first few bytes of the first sample coming to grief
which used to cause a "click".  This was only noticeable with VERY few
modules and has subsequently been repaired.

Added an extra mode between the original "1" and "2", called it "2" and
renamed all those above it.  Dispensed with the original Mode "4" as it
went way too far and removed too much of the sample integrity to be of any
particular use.

These few fixes have improved the performance of Modcrusher to such a
degree as to make its output quality of a class I originally intended and
subsequently better than I'd hoped for.

It'll now handle practically any module with greater ease including those
with loud and overdriven samples.  Although sound data sampled at or above
12000 samps/sec is still desired for best results, it's no longer entirely
necessary.

Some modules are of the type where "synthesised" samples were used, and due
to their short, looped duration and rapid pulsing, seem to cause no problems
whatsoever and therefore the loss in quality in most cases is nil even when
packed on modes as high as "4".


**** Disclaimer:

I really, really hate this bit but you'd be surprised about the STOOPID
things I've done in the past 7 years of programming...

In no way shall I be held responsible for any damages to software/equipment
and such like incurred through the use of either style of Modcrusher.
Although if it somehow manages to write off an entire HD on an IBM then I'll
be damned and really chuffed to boot!

Never write over your original stuff without being absolutely sure of the
consequences.  In all cases Modcrusher won't overwrite the source with the
destination so the decision is entirely yours.  'Nuff said.

===========================================================================

I really hope you enjoy using Modcrusher for its simplicity and
flexibility.  I'd like to assemble it into a library but I know little of
how to do this.  If anyone around the globe has any assembler know-how on
this then drop me a line.  If I receive even a small amount of helpful
suggestions and programming hints I'll endeavour to include them in the
next version.  Spread the word and this program, just don't forget the
programmer.  - Enjoy.