home *** CD-ROM | disk | FTP | other *** search
-
- WAV.svobject
-
- © 1994 by Andreas R. Kleinert.
-
- FREEWARE. All rights reserved.
-
- Version : 2.2
- Release Date : 21.07.1994
-
-
- Description
- ~~~~~~~~~~~
- WAV.svobject is an external Library-Module for the superplay.library V1+.
-
- It supports reading and writing of PC RIFF-WAVE (WAV) Sample-Files,
- playing is supported as far as the Amiga is able to (8 Bit only).
-
-
- Author
- ~~~~~~
- Andreas R. Kleinert
- Grube Hohe Grethe 23
- D-57074 Siegen
- Germany
-
-
- History :
- ~~~~~~~~~
- V2.2 (21.07.1994) :
-
- - added possibility to save all Samples from all multiple-SampleList
- and to accept NULL parameters for the Source-SPObject with
- SPO_Write(), so that custom applications may save their self-
- created SampleLists by simply setting them via SPO_SetSampleList().
- The old way behaviour is still supported (as also handling of
- V1 SPObjects).
- - in former versions the sourcebuffer had been left "trashed", because
- conversion into the WAV format (via XOR) had not been reversed.
- Now the old buffer is reconstructed after saving.
-
-
- V2.1 (17.07.1994) :
-
- - integrated new "SampleList"-Functions for exporting more than one
- sample
-
-
- V1.4 (19.06.1994) :
-
- - version still reflected 1.2 instead 1.3. Now we're at 1.4 :-)
- - changed way of reading the WAV-Header, so that files with
- extended Headers (don't know if there are such files) might be
- read as well in the future, while files with shortened header
- (possibly corrupted) will no longer be accepted (they would be
- interpreted wrong, anyway).
- - made some WORDs to UWORDs
- - fixed possible bug-source (memory)
-
-
- V1.3 (29.04.1994) :
-
- - fixed (hopefully) "header not located" problems within memory
- delocation
- - also fixed AllocMem()/FreeVec() conflict with SampleData-Buffer
-
-
- V1.2 (31.03.1994) :
-
- You should consider V1.1 to be a _BAD_ BETA-Version now, because :
-
- - as soon as I got some original (not converted) WAV-Files, I found
- out, that V1.1 was more or less UN-USEABLE, because it was so
- BUGGY ;<
- - IntelToMotorola (and reverse) conversion was not correct for
- LONGwords, which concerned :
-
- - ChunkSize (File Header : FileSize)
- - SubSize (Fmt Chunk : Chunk Size)
- - SamplesPerSec (Fmt Chunk : Frequency)
- - BytesPerSec (Fmt Chunk : Frequency, stereo)
- - DataSize (Data Chunk : Chunk Size)
-
- If you were "lucky", this might have meant, that the samples would
- have been played too short and with the wrong frequency ;)
- If you were "unlucky", they would not have been played at all !
-
- Due to these bugs, only self-written WAV-Files were replayed
- correctly, because they were WRITTEN AS WRONG as they have been read.
- - The Fmt-Header ID was written as "FMT " instead of "fmt ", so that
- perhaps not all other programs might accept files written with the
- old V1.1-WAV.spobject.
- Nevertheless you may recover your self-created WAV-Files by passing
- them through the Freeware-Tool SoundZAP V2.3 (Fish-Disk 646), which
- accepts them obviously (only the frequency might be wrong).
-
- - Now the positive things :
-
- - with this version not only the File Header, but also the single Chunks
- are now checked for their correct IDs : - "WAVE","RIFF" (Header)
- - "fmt " (Fmt-Chunk)
- - "data" (Data-Chunk)
- - since this version also a length of the Fmt-Chunk greater than
- 16 Bytes will be handled correctly : this definitely will not happen
- at the time, but may happen with future expansions of the RIFF-WAVE-
- Format
- - the Longword-Conversion now works ;)
- - now testing with "real" WAV-Files has been done :
- there's a high probability now, that all WAV-Files - assuming that
- they actually fit into your Chip Memory ;) - will be played in the
- right way
- - now there's more information given about the loaded Sample :
- This information will even be available, even if there's not enough
- memory to store the actual sample-data (e.g. more than 2 MByte
- sample data against 1 MByte free Chip Memory)
- - and more
-
-
- V1.1 (30.03.1994) :
-
- - we use RawDoFmt()-based sprintf()-routine, instead of SAS/C's.
- This saves about 1800 Bytes.
- - "utility.library" is not used, because this crashes the Player-Task
- and no reason for this could be found.
- - first version
-
-
- Literature
- ~~~~~~~~~~
- [1] "c't", Magazin für Computertechnik, Issue 1/1993, DMV-Verlag
-
-
- Copyrights
- ~~~~~~~~~~
- Some of the mentioned names or products above may be copyrighted by
- companies or trademarks of companies.
-
-
-