wavedrum: update section on loops
authorrekado <rekado@elephly.net>
Wed, 14 Aug 2013 13:38:58 +0000 (21:38 +0800)
committerrekado <rekado@elephly.net>
Wed, 14 Aug 2013 13:38:58 +0000 (21:38 +0800)
posts/2013-08-11-hacking-the-wavedrum.markdown

index aafd1a6ae931222b24bb0e91b7549e6a343db480..4b53d77e41386d9866a71d40602a2582632680b8 100644 (file)
@@ -232,17 +232,22 @@ yet, but you can listen to the clearly recognisable loop patterns with
 
     find LOOP -name "*.BIN" -print |\
       xargs -I XXX \
-      play -t raw -r 48k -b 32 -e unsigned-integer -c 2 XXX speed 0.3
-
-Obviously, this isn't quite correct.  I'm interpreting every 32 bits
-as a sample in unsigned integer format, but assuming a sample rate of
-48kHz and two channel output results in extremely fast playback which
-I then artificially slow down again.  This really is the same effect
-as playing back the data at a lower sample rate.  Even at the correct
-speed, the sound is distorted and far from the realistic instrument
-sound when playing back the loops through the Wavedrum.  Clearly, more
-work is required to figure out the correct format.  Once this is
-understood we could use custom loops with the Wavedrum.
+      play -t raw -r 44.1k -b 16 -e signed-integer -c 1 XXX
+
+Obviously, this isn't quite correct.  I'm interpreting every 16 bits
+as a sample in signed integer format, but the sound is distorted and
+far from the realistic instrument sound when playing back the loops
+through the Wavedrum.
+
+All loops start with this 44 byte long header:
+
+    04 dc 10 d3 __ __ __ 95  01 d4 00 d0 30 f8 22 b5
+    46 95 56 95 57 95 57 95  d6 2e 56 95 56 e2 57 95
+    54 95 46 95 32 f4 22 f4  __ __ __ 95
+
+Clearly, more work is required to figure out the complete format of
+these loop files.  Once this is understood we could use custom loops
+with the Wavedrum.
 
 The raw audio data in `WD2_DATA.BOR` suffers from the same problems.
 Although the data can be interpreted as raw audio, the sound is