--------------------------------------------------------------------------- **************************** modCRUSHER V2.0 **************************** --------------------------------------------------------------------------- By Olly Koenders 9 Isaac-Edey Place Hampton Park 06-09-96 Victoria, Australia 3976 PH: ISD? (03) 9702 8551 (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.