home *** CD-ROM | disk | FTP | other *** search
/ The Datafile PD-CD 3 / PDCD_3.iso / utilities / utilss / stretch / !Stretch / !Help next >
Text File  |  1995-07-28  |  5KB  |  140 lines
  1.           Release note for "TimeStrech V.01 alpha" or something.
  2.  
  3. Introduction
  4. ============
  5.  
  6. Those of you who're into jungle-music will definitely have heard
  7. the effect this little hack produces. It's called timestretch and
  8. attemps to change a sample's replay-length without changing it's
  9. pitch. The way this is achieved is so slobby that it creates
  10. awful distortion which, in fact, isn't totally unwanted.
  11.  
  12. This little hack was written for my private use as I'm trying
  13. to make some jungle-soundtrackers and this is why the "user-interface"
  14. sucks big rocks.
  15.  
  16. Usage
  17. =====
  18.  
  19. To use this routine in it's present stage copy the samples you
  20. want to process into "!Stretch.Input.", edit the
  21. chsize%, smooth% and stretch values in the source, run it and
  22. the processed samples will be put into "!Stretch.streched.".
  23. Read on to find out what these values mean.
  24.  
  25. In the current stage the routine only copes with raw 8bit linear
  26. unsigned samples. This was easiest so I didn't bother (there's
  27. enough tools out to convert samples). Blowing the routine up
  28. to 16 bit is dead easy, but as I've got no 16bit sample-replay
  29. hardware I don't care aswell.
  30.  
  31.  
  32. The Algorithm
  33. =============
  34.  
  35. This routine works the following way:
  36.  
  37. The sample is divided into chunks (and chsize% is the size of
  38. these chunks). Here's an example with chsize%=4 (which is
  39. purely for demonstrative purposes, this value'd be nonsense):
  40.  
  41.   |--------------------- sample --------------------|
  42.   __________________________________________________
  43.   |     |     |     |     |     |     |     |     |
  44.   | 1-4 | 5-8 | 9-12|13-16|17-20|21-24|25-28|29-32| ...
  45.   |     |     |     |     |     |     |     |     |
  46.   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  47.  
  48. Now a sliding window technique is used to copy the
  49. chunks apart. After the end of chunk 1 the window
  50. gets slided conforming to the stretch-value, so
  51. given a value of 2 the routine would place the 2nd half
  52. of chunk 1 and the first half of chunk 2 after chunk 1,
  53. followed by chunk 2, then the 2nd half of chunk 2 again
  54. and so on and so forth.
  55.  
  56. Something like this, anyway:
  57.   __________________________________________________
  58.   |     |     |     |     |     |     |     |     |
  59.   | 1-4 | 3-6 | 5-8 | 7-10| 9-12|11-14|13-16|15-18|   ...
  60.   |     |     |     |     |     |     |     |     |
  61.   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  62.  
  63. Thus effectively doubling the sample-length by somewhat
  64. retaining the original replay-rate.
  65.  
  66. Now this would lead to clicks at each cut giving a very
  67. noisy output (try it using smooth% = 0) so now these
  68. new chunks are shoved into another by smooth% samples and
  69. are linearly blended (which means high smoothing values
  70. shorten the sample a bit. Take this into account when you
  71. need precise stretching).
  72.  
  73. Now you might notice that you can freak out the routine
  74. by setting smooth% > chsize%. But this still gives
  75. results that sound like a time-stretch so what the hell...
  76.  
  77.  
  78. Well, basically this is all. Easy innit ?
  79.  
  80. Known bugs
  81. ==========
  82.  
  83. The routine crops smooth% bytes at the beginning of
  84. the sample and creates some crap padding at the
  85. end of it... lets say: the processed samples need
  86. a little polishing afterwards...
  87.  
  88.  
  89. Legal crap
  90. ==========
  91.  
  92. This is public domain. I don't want to have anything to
  93. do with this. Sell it, smoke it, use it, change it. I don't
  94. give a shit.
  95.  
  96.  
  97. Author's speech
  98. ===============
  99.  
  100. The first day I saw AudioWorks at my local Acorn
  101. store I thought this was going to be a fine package some day,
  102. but it it's current state it's just as crappy as DSEdit or
  103. Armadeus. And as long as AudioWorks does not feature
  104. FFT-analysis and filtering, better spectrals, noise-filters
  105. and still crashes around on 12 bit samples (how come you
  106. include something in a professional product and don't even
  107. notice it does't work or what ?) I'm not gonna buy it.
  108. My advice: take a peek at COOL for windoze, it's 5$ shareware
  109. and kicks butt (if you give it a night for 100KB samples :) ).
  110.  
  111. Well, erm, this is the reason why I started to code this one.
  112. I'm not gonna write a sample-editor myself, but maybe some
  113. folks who do realise that's it's bloody time to advance to
  114. some trickier sample-processing than just fading up and down.
  115. These are invited to use this code (ask me, I might convert
  116. it to assembler and fix some dodgy parts).
  117. And maybe there're other enthusiasts so we'd start a little
  118. collection of sample-processing-routines and do something
  119. senseful with it someday.
  120.  
  121. How to contact the author
  122. =========================
  123.  
  124. Internet's best, so send E-mail to "unao@rz.uni-karlsruhe.de".
  125.  
  126. Then we've got snailmail: Benjamin Bommer
  127.                           Nuitsstr. 2c
  128.                           76185 Karlsruhe
  129.                           Germany
  130.  
  131. (and let me state that I'm only studying here. I'm from Berlin
  132. and don't want to be taken for a south-west-german moron with
  133. a speech-handicap, moustache, golden chain and shoulder-long hair)
  134.  
  135. And after all you can ring : +49/721/55 21 34
  136. (and keep in mind this is GMT +1)
  137.  
  138.  
  139. So this is it fellas. Laters !
  140.