oops left some demos over

1 files changed, 80 insertions, 26 deletions

diff --git a/blog/post/2020-11-20.html b/blog/post/2020-11-20.html
index 8abf74e..245b88d 100644
--- a/blog/post/2020-11-20.html
+++ b/blog/post/2020-11-20.html
@@ -117,7 +117,7 @@ for(let x of al)
 <article>
 <p>This the follow up article of my first post on the SD-80. View it <a href="https://chrisoft.org/blog/post/2019-04-25.html">here</a>.</p>
 <p>It’s been <del>one year and a half</del> <del style="text-decoration-style: double">two years</del> three years since I got my SD-80. A lot of stuff happened (including the great pandemic of COVID-19 and my escape from Wuhan). I’ve also discovered a lot more about the SD-80. Instead of updating the original post (which is already excessively long), I decided to start a new post instead.</p>
-<p>The actual publish date of this post is 2022-06-30 <del>because I have crippling procratination</del>.</p>
+<p>The actual publish date of this post is 2022-06-30 <del>because I have crippling procrastination</del>.</p>
 <p>My special thanks go to:</p>
 <ul>
 <li>Kalas, who contacted me for my original SD-80 post, without whom half of this article wouldn’t even exist.</li>
@@ -320,7 +320,7 @@ for(let x of al)
 </div>
 <h3 id="tocanch2" class="tvis">(Accidentally) Circuit bent SD-80</h3>
 <p>I started messing around and decided to try to run the SD-80 without the ±15V rail. Everything except the front panel phones output and output 1 on the back panel worked just fine. This is not very surprising – all chips on the main board only takes &lt;= 5V, and it makes sense to derivate all those voltages from the 5V rail. After a quick look at the service notes, I found that the ±15V rail is only used by the OpAmps in the final output stage of output 1, which is on the volume board.</p>
-<p>And then something extremely stupid happened. Any proper electrical engineer will cringe hard. At this point I was getting cocky, and started randoming probing around with my multimeter on the volume board. I “accidentally” shorted the first two pins of the connecter going from the main board into the volume board (pin 1 and pin 2 on CN7 of volume board). The output from the headphone jack immediately turns into complete garbage (severe distortions on low frequencies). The OpAmps chip on the volume board started getting ridiculously hot… crap! I still managed to fry something for an otherwise “perfect” modding project!</p>
+<p>And then something extremely stupid happened. Any proper electrical engineer will cringe hard. At this point I was getting cocky, and started randomly probing around with my multimeter on the volume board. I “accidentally” shorted the first two pins of the connector going from the main board into the volume board (pin 1 and pin 2 on CN7 of volume board). The output from the headphone jack immediately turns into complete garbage (severe distortions on low frequencies). The OpAmps chip on the volume board started getting ridiculously hot… crap! I still managed to fry something for an otherwise “perfect” modding project!</p>
 <p>Of course this is undesirable. So I had to find a fix to this.</p>
 <p>Fortunately, nothing on the main board seemed to be hurt. I can just bypass the volume control and get the correct output on output 1 using some jumper wires. So the fault is contained in the volume board. I’ve basically sent -15V straight into the base of two transistors, but measuring those transistors didn’t reveal anything wrong with them. So I had to assume I have fried the amp chip (NJM4565). I got a few replacements (NJM4580, compatible spec-wise) from taobao, and replaced the “faulty” NJM4565 (still without using flux). But the audio output is still messed up and the opamp chip still gets very hot after the replacement. I decided to give up for now, and look into the thing later. Meanwhile I just tucked some of the wires from CN6 into CN7 so that I can still get analog output from output 1 on the back panel.</p>
 <div style="text-align:center;max-width:90%;">
@@ -328,14 +328,14 @@ for(let x of al)
 </div>
 <h2 id="tocanch3" class="tvis">Recording Setup Update Part 1</h2>
 <p>Since I have always wanted to record my SD-80 through a digital link (even before frying the analog output), I have been keeping an eye on cheap digital recording solutions. Modern professional audio interfaces never come with digital input on budget models. Among the older interfaces, UA-25(EX) from Roland (EDIROL / Cakewalk) seems to be a reasonable choice. There are also a bunch of different models from various brands of the same era that have digital inputs. However these models are virtually impossible to get in China. Then some cheapo consumer grade stuff caught my attention – several relatively nameless brands have “sound cards” for home theater uses that have digital I/O. Those are priced at roughly 200~300 Chinese yuan. Among those I found a more widely recognized brand called Terratec. They have PCI-e and USB sound cards that comes with digital I/O and are available for purchase in China. Price are on the higher end (300+ CNY), however still way cheaper than the cheapest professional audio interface that doesn’t have digital I/O (those start from ~800 CNY). Plus these models seem to have a reasonable Linux user base, so I got their Aureon 7.1 USB.</p>
-<p>This thing feels extremely cheap on first sight, weights close to nothing, and is made entirely out of plastic. It comes with an extremely thin S/PDIF fiber optical cable which looks so fragile that a single touch may break it. It does work out of the box. ALSA recognizes it as “Aureon 7.1 USB” without further clue about the chip it uses, however the Windows driver is more telling. Its control panel associates the chip with a Taiwanese company called Cmedia, and the kernel driver is named <code>cm106.sys</code>. Upon further investigation this thing is likely to be based on their CM106 chip (which is an ancient solution from 2003), or its pin-compatible successor CM6206. I don’t have interest in disassemblying it right now (update: confirmed by a teardown later. It’s indeed based around the CM6206), but either way it’s a cheap consumer grade solution.</p>
+<p>This thing feels extremely cheap on first sight, weights close to nothing, and is made entirely out of plastic. It comes with an extremely thin S/PDIF fiber optical cable which looks so fragile that a single touch may break it. It does work out of the box. ALSA recognizes it as “Aureon 7.1 USB” without further clue about the chip it uses, however the Windows driver is more telling. Its control panel associates the chip with a Taiwanese company called Cmedia, and the kernel driver is named <code>cm106.sys</code>. Upon further investigation this thing is likely to be based on their CM106 chip (which is an ancient solution from 2003), or its pin-compatible successor CM6206. I don’t have interest in disassembling it right now (update: confirmed by a teardown later. It’s indeed based around the CM6206), but either way it’s a cheap consumer grade solution.</p>
 <p>SD-80’s digital output is fixed at 44100 Hz sample rate. So the sound card must also record at 44100 Hz to make a correct recording (unless it has internal resampling). This is easily doable under Windows (just select the appropriate sampling rate in the device properties dialog). It’s also reasonably easy with Jack, where you can just start the server on that specific device with the correct sampling rate. But this is not that easy to achieve for pulseaudio. By default, recent versions of pulseaudio auto detects cards with the <code>module-udev-detect</code> module, which doesn’t allow setting a different sample rate for a single sound card. Setting <code>alternate-sample-rate</code> doesn’t work either because this card supports digital signals at 48000Hz which in my case is the value for <code>default-sample-rate</code>, and therefore would not fallback to <code>alternate-sample-rate</code>. I had to write a small function to fix this:</p>
 <pre><code>spdif_samplerate()
 {
     pacmd unload-module `pacmd list-modules | grep -B 2 Aureon_7 | awk '/index:/ {print $2}'`
     pacmd load-module module-alsa-card device_id=`awk '/Aureon 7\.1 USB$/{print $1}' /proc/asound/cards` name="usb-0ccd_Aureon_7.1_USB-00" card_name="alsa_card.usb-0ccd_Aureon_7.1_USB-00" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes avoid_resampling=no rate=44100
 }</code></pre>
-<p><del>Using a cheap consumer grade card does come with consequences. The recording seems to have a small DC bias – it’s not real DC though, the offset changes from time to time. When the input signal goes slient, the offset might differ from the offset when the signal was slient last time.</del> <a id="n2" href="#note2" class="note">[2]</a> For this reason, I always add a high-pass filter when using the material recorded by this sound card. With the HPF applied, this sound card does produce clearer digital recording than my Scarlett Solo with very cheap cables.</p>
+<p><del>Using a cheap consumer grade card does come with consequences. The recording seems to have a small DC bias – it’s not real DC though, the offset changes from time to time. When the input signal goes silent, the offset might differ from the offset when the signal was silent last time.</del> <a id="n2" href="#note2" class="note">[2]</a> For this reason, I always add a high-pass filter when using the material recorded by this sound card. With the HPF applied, this sound card does produce clearer digital recording than my Scarlett Solo with very cheap cables.</p>
 <p>There’s no ASIO driver for this card either (Aureon 7.1 PCIe does have ASIO driver, but I can’t install that card on my laptop), which means I have to either use Steinberg’s generic ASIO driver, or ASIO4ALL, both of which are… kind of trash, but still usable. The card doesn’t have a bad latency issue though: it’s obviously way worse than the Scarlett, but still tolerable.</p>
 <p>So that’s my <del>current</del> recording setup. I’m currently OK with it. However I’m not going to stick with it forever. I’ll upgrade to a UA-25(EX), or better yet, an SD-90 because that way I can use its ASIO output directly, plus I’ll be able to chain my SD-80 to it and use both at the same time.</p>
 <h2 id="tocanch4" class="tvis">Recording Setup Update Part 2</h2>
@@ -353,7 +353,7 @@ for(let x of al)
 <p>I saw a UA-101 in a listing for $80. I bought it. Then there was a whole saga which ended in me getting two of them for the price of one. And then I saw a SD-90 for $120… you know what happened.</p>
 <p>This is getting too long to write in detail here. I’ll give detailed information on my current recording setup in a new post, if I care to write it at all.</p>
 <h2 id="tocanch6" class="tvis">Rompler Preservation</h2>
-<p>Kalas was extremely keen on preserving the sounds of SD-90/80 during our communications. I have the intention to keep these legendary Roland sounds around long into the future as well. We discussed the following possibilities. Note that due to the locked-down nature of SD-90/80, we referred to them mostly as “Romplers”, but these methods listed below apply to those expandable models as well, especially considering they are nothing but Romplers that you can add more ROMs to, and the architecture of Roland’s PCM synth.</p>
+<p>Kalas was extremely keen on preserving the sounds of SD-90/80 during our communications. I have the intention to keep these legendary Roland sounds around long into the future as well. We discussed the following possibilities. Note that due to the locked-down nature of SD-90/80, we referred to them mostly as “Romplers”, but these methods listed below apply to those expandable models as well, especially considering they are nothing but romplers that you can add more ROMs to, and the architecture of Roland’s PCM synth.</p>
 <p>In this section I’ll start using the word “SD-90” and “SD-80” interchangeably, and by saying “SD-90”, I’m actually referring to the synthesizer module built into it. If Roland was being honest when they were saying “the newly developed multitimbral MIDI sound module, as built into the well-received SD-90” when they were introducing the SD-80 <a id="n3" href="#note3" class="note">[3]</a>, it should be safe to assume they are virtually the same thing. I know this is kind of sloppy. If you want to read more on this, checkout the <a href="#tocanch33">“More on SD-80 vs SD-90 vs SD-20”</a> section.</p>
 <h3 id="tocanch7" class="tvis">Emulation</h3>
 <p>This method was brought up by Kalas. Indeed there are a couple of sound modules / synthesizers that has been emulated with reasonable success. <a href="https://github.com/munt/munt">Munt</a> has an amazing emulation of Roland’s LA synthesis found in the MT-32 or D-50. <a id="n4" href="#note4" class="note">[4]</a> Yamaha’s FM synthesis chips have been reverse engineered from inside out: there are <a href="https://github.com/gtaylormb/opl3_fpga">implementations on FPGA</a>, multiple nearly perfect software implementations, and other bizarre stuff. MAME has emulation for multiple MU-series models, plus work has been put into making an emulated SC-55 in MAME.</p>
@@ -365,14 +365,14 @@ for(let x of al)
 <li>They are relatively sample.</li>
 <li>Similar to Yamaha’s FM chips, programmers can also directly interface with them. Therefore their programming manuals have detailed description on how sound generation works in the chips. SD-90/80’s synthesizer chip XV meets neither of these two criteria.</li>
 </ul></li>
-<li>Most emulated sound modules in MAME have been a failure in terms of real-world usability. The emulated MU-series either freezes, produces no sound at all, or makes loud unexpected noise when playing the demo track. The SC-55 emulation barely works – they only got the CPU working and running its dumped control ROM. Please don’t get me wrong: the fact that some emulated MU model could make any sound is almost a miracle for me, and definitely a huge achievement despite the far-from-ideal results it currently has, as Yamaha’s sample based synth chips (<code>GEW/SWP</code> stuff) are no easy nut to crack. This approach is highly unlikely to work for the SD-90/80 because unlike gaming consoles, gettings the CPU to run its system code doesn’t mean much for synthesizer emulation. It’s the emulation of the actual synth/DSP chip that matters. And the XV chip found in SD-90/80 is a <strong>monstrosity</strong> compared to the early SWP chip in the MU-series. For this reason, I find a pure emulation based solution difficult to implement for SD-90/80.</li>
-<li>Munt is successful because instead of an instruction-to-instruction emulation, it’s more like a software reimplementation of the LA synth. It doesn’t try to run the control ROM on an emulated Intel 8098 CPU, but instead only use it for determining some charistics of the software implementation of the LA synth. This approach makes the most sense when trying to recreate SD-90/80 in software form, but still definitely require tons of reverse engineering (either blackbox or whitebox).</li>
+<li>Most emulated sound modules in MAME have been a failure in terms of real-world usability. The emulated MU-series either freezes, produces no sound at all, or makes loud unexpected noise when playing the demo track. The SC-55 emulation barely works – they only got the CPU working and running its dumped control ROM. Please don’t get me wrong: the fact that some emulated MU model could make any sound is almost a miracle for me, and definitely a huge achievement despite the far-from-ideal results it currently has, as Yamaha’s sample based synth chips (<code>GEW/SWP</code> stuff) are no easy nut to crack. This approach is highly unlikely to work for the SD-90/80 because unlike gaming consoles, getting the CPU to run its system code doesn’t mean much for synthesizer emulation. It’s the emulation of the actual synth/DSP chip that matters. And the XV chip found in SD-90/80 is a <strong>monstrosity</strong> compared to the early SWP chip in the MU-series. For this reason, I find a pure emulation based solution difficult to implement for SD-90/80.</li>
+<li>Munt is successful because instead of an instruction-to-instruction emulation, it’s more like a software reimplementation of the LA synth. It doesn’t try to run the control ROM on an emulated Intel 8098 CPU, but instead only use it for determining some characteristics of the software implementation of the LA synth. This approach makes the most sense when trying to recreate SD-90/80 in software form, but still definitely require tons of reverse engineering (either blackbox or whitebox).</li>
 </ul>
 <p>For these reasons, I don’t think an OPL3-level emulation of SD-90/80 is possible <a id="n5" href="#note5" class="note">[5]</a>. However, I will discuss an approach that resembles Munt’s in the <a href="#tocanch8">Dumping and Deciphering</a> section.</p>
 <h3 id="tocanch8" class="tvis">Sampling the Rompler</h3>
 <p>Many people have attempted to sample the SD-90. We already have the (in)famous THFont from forever ago that contains some samples from the SD-90, plus <a href="https://musical-artifacts.com/artifacts/1367">these</a> efforts to create a complete set of sampled instruments from the SD-90. However, these folks aren’t doing it in the most efficient way IMHO. Since the SD-90/80 is extremely editable, one can craft presets ideal for raw sample extraction (no filters, no LFO, just a plain tone with a constant amplitude envelope). Since many preset instruments in the SD-90/80 consist of multiple layers using different samples, instead of sampling the patches, one can sample every individual waveform and layer the samples in a way similar to the original presets to make close imitations of SD-90/80 instruments. If done properly under ideal conditions, the resulting sample library should be around the same size of SD-90/80’s sample ROM, but decompressed (my guess is ~64 MiB <a id="n6" href="#note6" class="note">[6]</a>).</p>
-<p>If you’re only going to use the vanilla SD patches without any sort of modification (including filter response, envelope, and effect parameters), those existing samples will work just fine and they are probably the most accurate out there if recorded properly. Of course, the “efficient” approach of sampling sacrifices some level of that accuracy (due to a different engine being used for playing back the samples). But in exchange you get the hightest level of freedom to recombine the raw samples into custom patches including tweaking all possible parameters and effects available in the synth engine of your choice (which is a huge plus for me personally, as I love to create whacky patches).</p>
-<p>One problem for extracting the samples is that, a single waveform in the SD-80 may contain different samples assigned for different key ranges. This is often called a “multisample” by some sources. The way the samples are mapped to the keys must be figured out before actually sampling them. I have written a small(ish) python script to do exactly that. It records the SD-80 playing two different keys at the same pitch one after another, and compare them by calculating the correlation. If the correlation is lower than a threshold, the two keys use different samples. This approach works reasonably well for most samples, but for a few analog synth samples, it works poorly. For those samples, I had to resort to relying on the human ear (DTW, dynamic time wraping, is also used sometimes, but it usually has poor results for these samples as well). Also the XV engine have some weird quirks near the keys C7-D8 (96-110). The actual waveform produced within that range varies very slightly from time to time. This is possibly due to the effect of <a href="https://en.wikipedia.org/wiki/Aliasing">aliasing</a> becoming prominent for these high-pitched notes. I have already figured out key-sample mapping for all multisamples (they are not guaranteed to be correct, due to reasons mentioned above).</p>
+<p>If you’re only going to use the vanilla SD patches without any sort of modification (including filter response, envelope, and effect parameters), those existing samples will work just fine and they are probably the most accurate out there if recorded properly. Of course, the “efficient” approach of sampling sacrifices some level of that accuracy (due to a different engine being used for playing back the samples). But in exchange you get the highest level of freedom to recombine the raw samples into custom patches including tweaking all possible parameters and effects available in the synth engine of your choice (which is a huge plus for me personally, as I love to create whacky patches).</p>
+<p>One problem for extracting the samples is that, a single waveform in the SD-80 may contain different samples assigned for different key ranges. This is often called a “multisample” by some sources. The way the samples are mapped to the keys must be figured out before actually sampling them. I have written a small(ish) python script to do exactly that. It records the SD-80 playing two different keys at the same pitch one after another, and compare them by calculating the correlation. If the correlation is lower than a threshold, the two keys use different samples. This approach works reasonably well for most samples, but for a few analog synth samples, it works poorly. For those samples, I had to resort to relying on the human ear (DTW, dynamic time warping, is also used sometimes, but it usually has poor results for these samples as well). Also the XV engine have some weird quirks near the keys C7-D8 (96-110). The actual waveform produced within that range varies very slightly from time to time. This is possibly due to the effect of <a href="https://en.wikipedia.org/wiki/Aliasing">aliasing</a> becoming prominent for these high-pitched notes. I have already figured out key-sample mapping for all multisamples (they are not guaranteed to be correct, due to reasons mentioned above).</p>
 <p>Another problem is looping. Roland uses sample looping extensively in their PCM synths. It’s basically their secret sauce to squeeze thousands of instruments into a unit with only tens of megabytes of samples. Sample loop points can also be computed using cross-correlation. But is nowhere near perfect. Of course it can be done manually, but that would be a tedious task.</p>
 <p>No actual recording of the raw samples have been done by me yet.</p>
 <p>I have also dumped the instrument configuration for all preset instruments and rhythm sets as part of my SD-80 dumping project (for SD-80’s native mode only. I’m not sure whether this is doable for its GS/XGLite instruments without a lot of reverse engineering, but nobody cares about those anyway). For now, it can be used to recreate parameter-accurate SD-80 patches in Roland’s SRX/Zenology plugins. However it’s not yet in a very human-readable form (either raw binary registers dump or decimal values with field names).</p>
@@ -380,7 +380,7 @@ for(let x of al)
 <h3 id="tocanch9" class="tvis">Dumping and Deciphering</h3>
 <p>The wave ROM in the SD-80 is a standard part despite the custom Roland engravement on it <a id="n7" href="#note7" class="note">[7]</a>. This is expected because Roland has been using standard mask ROM parts from various manufacturers for the wave ROM. This means the content of SD-80’s wave ROM can be easily dumped.</p>
 <p>This might be shocking for some of the readers, but Roland does compress their samples. This is evident from the specification of XV-5080 “Wave memory: 64MB (16-bit linear format)” while the XV-5080 only has 32 MiB wave ROM. The compression, previously unknown to me, has been identified to be a variant of the differential pulse-code modulation (DPCM) called FCE-DPCM by <a href="http://www.dtech.lv/techarticles_roland_exp.html">some amazing person</a>. The same person seemed also figured out the structure of the wave ROM used by sample-based synthesizers from Roland of that general era. Unfortunately, I wasn’t able to find the article on the technical details of the compression method at the time of writing. Anyway, hats off to Edward of dtech.lv!</p>
-<p>I <strong>will surely</strong> make a dump of the wave ROMs of my SD-80. However, I want to do it in an indestructive manner – I don’t want to get a ROM dump and an unusable SD-80 (or end up with no valid ROM dump and an unusable SD-80). Since I have proved my SMT soldering job is terrible and shall never be in the vicinity of a SMT board holding a soldering iron or hot air gun, I might try some clipping the chip instead. I’m considering to try <a href="https://www.360-clip.com/uni-48.htm">this</a> clip from 360-clip. It claims to be applicable to any 48-pin TSOP chips. If that’s true, with the help of this clip and a Raspberry Pi <a id="n8" href="#note8" class="note">[8]</a>, I can suck that juicy content out of the wave ROM chips of the SD-80.</p>
+<p>I <strong>will surely</strong> make a dump of the wave ROMs of my SD-80. However, I want to do it in an nondestructive manner – I don’t want to get a ROM dump and an unusable SD-80 (or end up with no valid ROM dump and an unusable SD-80). Since I have proved my SMT soldering job is terrible and shall never be in the vicinity of a SMT board holding a soldering iron or hot air gun, I might try some clipping the chip instead. I’m considering to try <a href="https://www.360-clip.com/uni-48.htm">this</a> clip from 360-clip. It claims to be applicable to any 48-pin TSOP chips. If that’s true, with the help of this clip and a Raspberry Pi <a id="n8" href="#note8" class="note">[8]</a>, I can suck that juicy content out of the wave ROM chips of the SD-80.</p>
 <p>Once we have the ROM dump, we can start trying to figure out its structure. If we somehow managed to do that, we would be able to feed the decompressed samples together with the already dumped patch parameters to some existing or new, custom sample-based software synthesizer, and achieve decent results mimicking the SD-90/80. Patches that make use of MFX would certainly be a pain to deal with. However one can always simulate MFX with external DAW effects. To hear the difference MFX makes for various preset patches that use it, see the <a href="#tocanch37">“What role does MFX play?”</a> section.</p>
 <p>I believe this approach is very similar to that one used by Munt (although I only read a small part of Munt’s code base, and I didn’t read anything about their reverse engineering approach). The SH3 CPU plays a relatively minor part in the tone generation of SD-80. Instead, we should focus on replicating the sounds of the XV engine. Also, an logic-level reverse engineering of the XV chip doesn’t seem reasonable because it’s such a huge and complex chip (or rather, a huge gate array). Just save the hassle, treat it like a blackbox and try to reproduce its output using a software implementation should be able to produce acceptable result on its own.</p>
 <h4 id="tocanch10" class="tvis">Extra rambling about the ROM chip</h4>
@@ -389,13 +389,67 @@ for(let x of al)
 <h3 id="tocanch11" class="tvis">SD-20 MIDI File Converter</h3>
 <p>This extremely intriguing piece of software is brought up by Kalas during our communications. At the time of writing, this application can be still found <a href="https://www.roland.com/jp/support/by_product/sd-20/">here</a>. The installer can only proceed if an SD-20 is detected. This can be easily circumvented by using a InstallSheld extractor. The converter does try to access a registry key <code>HKLM\Software\Wow6432Node\Edirol\SD-20 MIDI File Converter\BaseDataFile</code>, which should be set to a string pointing to the url of its param.dat file. However, even with this key set, the converter still refuse to do anything, saying it failed to initialize. By the way even with an SD-20 connected to the computer via USB, the converter still refuses to start on Windows 10.</p>
 <p>However, this kind of nonsense is not going to stop me. I quickly found cracks floating around on the Internet. This converter is extremely simplistic: you pick the midi file to convert, it spits the wav file into the same folder. Here are some quick samples.</p>
-<p>AMEDLEY.MID by Earl Gray Fowler from Voyetra Technologies, arranged for SD-80 (Native Mode)</p>
+<div>
+<table style="position:relative;left:50%;transform:translate(-50%,0);text-align:center">
+<tbody><tr>
+<td>
+SD-80
+</td>
+<td>
+SD-20 Converter
+</td>
+</tr>
+<tr>
+<td>
+<audio controls="" src="//filestorage.chrisoft.org/blog/data/SD-80/AMEDLEY.SD80.N.ogg">
+</audio>
+</td>
+<td>
+<audio controls="" src="//filestorage.chrisoft.org/blog/data/SD-80/AMEDLEY.SD80.SD20C.N.ogg">
+</audio>
+</td>
+</tr>
+<tr>
+</tr><tr>
+<td colspan="2">
+AMEDLEY.MID by Earl Gray Fowler from Voyetra Technologies, arranged for SD-80 (Native Mode)
+</td>
+</tr>
+</tbody></table>
+</div>
 <p>Used instruments: St.Strings, St.Timpani, St.Harp, St.Fr Horns, Flute vib, St.Tubular, St.Harp, St.Xylophone, St.Music Box, St.Room, Bassoon vib, SpaceVoice 3, Atmosphere 3, Ice Rain 3, PanFlute vib, Bird Tweet, Seashore, Sweep Pad 3, Rockabilly, St.Kalimba, Piccolo vib, Steel Drums, Tuba vib, Romantic Tp, St.Banjo, Trombone vib, JazzClarinet, Gunshot, Clavi Bass 3, St.Brass, Dist.Gt 2, St.Orc Hit, Jazz Organ 2, PhaseFrtless, Solo Vox 3, Reed Romance, Ice Rain 2, St.Power, Oct.JP Saw, SH-2 Lead, Jazz Slap, OverdriveGt2, Applause.</p>
 <p>Reed Romance and SH-2 Lead are from the special 2 set, therefore cannot be used by the SD-20 MIDI File Converter. They are substituted by Violin 2 vib and Warm SynHorn automatically. A single SD-80 system exclusive DT1 message is used to change the patch volume of SH-2 Lead.</p>
-<p>YOSEMITE.MID by Passport Designs, arranged for SD-80 (Native Mode)</p>
+<div>
+<table style="position:relative;left:50%;transform:translate(-50%,0);text-align:center">
+<tbody><tr>
+<td>
+SD-80
+</td>
+<td>
+SD-20 Converter
+</td>
+</tr>
+<tr>
+<td>
+<audio controls="" src="//filestorage.chrisoft.org/blog/data/SD-80/YOSEMITE.SD80.N.ogg">
+</audio>
+</td>
+<td>
+<audio controls="" src="//filestorage.chrisoft.org/blog/data/SD-80/YOSEMITE.SD80.SD20C.N.ogg">
+</audio>
+</td>
+</tr>
+<tr>
+</tr><tr>
+<td colspan="2">
+YOSEMITE.MID by Passport Designs, arranged for SD-80 (Native Mode)
+</td>
+</tr>
+</tbody></table>
+</div>
 <p>Used instruments: Enh.Nylon o, Ocarina vib, St.Slow Str2, PhaseFrtless, Celtic Ens, St.Standard, Soft60’Organ, Pre Bass, St.BritePno.</p>
 <p>St.BritePno is a custom patch. It’s selected using system exclusive messages generated by SD-80’s bulk dump feature. Enh.Nylon o, Celtic Ens, Pre Bass are not available in the SD-20 Converter.</p>
-<p>The output from the converter is significantly louder than SD-80’s digital output. I normalized all recordings before uploading them. The converter actually sounded exceptionally good, and exceeded my expectation by quite a large margin.</p>
+<p>The output from the converter is significantly louder than SD-80’s digital output. I normalized all recordings before uploading them. Despite the lack of a lot of features and patches, the converter actually sounded exceptionally good, and exceeded my expectation by quite a large margin.</p>
 <p>The converter is not a software implementation of SD-20’s internals. There’s misinformation out there claiming so, but that’s simply not the case. Roland explicitly disclosed this in the readme file of the converter.</p>
 <h4 id="tocanch12" class="tvis">FrankenTTS-1</h4>
 <p>Something smells fishy instantly when I got this converter. That file name “param.dat” looks really familiar. If you have used any of Roland’s HQ software synthesizer products from the early 2000s <a id="n10" href="#note10" class="note">[10]</a>, you might feel the same. They all use this file to store their samples and patch data.</p>
@@ -417,7 +471,7 @@ for(let x of al)
 <h3 id="tocanch15" class="tvis">Roland Cloud</h3>
 <p>Roland has been pushing their subscription service “Roland Cloud” since 2018. When it first came out there was no plugin of my interest. The deal breaker for me back then was there was no permanent licensing option. If you know me, I’m strongly opposed to the subscription model used for software products.</p>
 <p>Starting from May 2020 though, Roland started offering “lifetime keys”, which now puts this service within my radar. I took the ultimate tier trial and installed every piece of plugin replicating SRX boards and the XV-5080, as well as the then-new “Zenology” synth. I’ve got mixed results.</p>
-<p>The software aspect is okay. It’s much better than SoundCanvas VA I’ve used years ago, which has glitchy TVA and TVF and was never fixed. The user interface scales perfectly on high DPI screens. Editing experience of the SRX/XV plugins is basically the same as the editors for later Roland PCM synths (such as the SonicCell and the Integra-7) – that is, much better than the original XV or SD-80 editor. These plugins still have terrible performance as most previous Roland software synths do (each instance needs plenty of processing power – if you use a computer that predates the relase of these plugins, the performance will probably suffer).</p>
+<p>The software aspect is okay. It’s much better than SoundCanvas VA I’ve used years ago, which has glitchy TVA and TVF and was never fixed. The user interface scales perfectly on high DPI screens. Editing experience of the SRX/XV plugins is basically the same as the editors for later Roland PCM synths (such as the SonicCell and the Integra-7) – that is, much better than the original XV or SD-80 editor. These plugins still have terrible performance as most previous Roland software synths do (each instance needs plenty of processing power – if you use a computer that predates the release of these plugins, the performance will probably suffer).</p>
 <p>The sound is … fine? Didn’t give me the same astonishment when I heard a real XV-5080 on YouTube though (I thought “no way this thing only has 32 MiB of sample content!”). For most patches, they sound “close enough” to an actual XV-5080, despite a handful of caveats. The synth engine do behave nearly identical to actual XV-based synths, at least according to my tests. The XV-5080 plugin is especially underwhelming, considering the original XV-5080 is expandable and can also load external samples. If only the XV-5080 plugin could load samples and patches from other SRX plugins installed, it would have been a lot better (although this is solved by Zenology, it has its own issues). The MFX uses a different set of effect types from the original XV-5080 and SD-80: they are modeled after synths after the Fantom-S era). However I’d say the effects bearing the same name as XV effects do sound largely the same.</p>
 <p>The executables contain a resource folder named “WROM”, and it contains the wave ROMs used by the plugins. They are all exactly 32 MiB. The wave ROM files contains a similar 32-byte header to dumps of actual wave ROM of earlier Roland PCM synths (see the JD-800 wave ROM dump from Edward of dtech.lv).</p>
 <p>I do have some major complaints though. Each executable contains a copy of the wave ROMs. If you choose to install all plugin formats, that will install 4 copy of exactly the same wave ROM on your computer. Also it’s impossible to combine the sounds of different SRX boards. Most samples originated from Spectrasonics are missing from the SRX plugins but are reincluded in the EXZ expansions which can be used in Zenology, indicating a copyright dispute between the two companies that was resolved later <a id="n11" href="#note11" class="note">[11]</a>. These problems can be partially solved if you use the newer Zenology plugin instead. But Zenology is riddled with its own issues. It uses a nearly entirely new set of MFX (identical to the MFX from their 2019 Fantom-6/7/8 workstations and other “ZEN-CORE” based products), and completely lacks reverb effects. Effects that have the same name in Zenology and XV-based synths doesn’t necessarily behave the same. And Zenology still can’t load samples from different sample groups to left and right channels of a single voice. I know it’s a thing in the original XV, but since it’s a software reimplementation, they don’t have to stick to the same restrictions do they? Also, why are all these plugins monotimbral? If your answer is “just use multiple instances”, I would remind you that these are Roland software synths, and they don’t perform well if you add multiple to your virtual rack…</p>
@@ -1231,9 +1285,9 @@ Reverb, Chorus, MFX (16 slots, 67 types), EQ, compressor (drum part), Surround,
 </tr>
 </tbody></table>
 </div>
-<p>The following section summerizes generation-over-generation improvements of the synth engine noticed by me reading the manuals. It is <strong>not</strong> based on analysis of the actual chip, but instead based on analysis of the most capable synth model using that chip. Some of the features might be added with newer version of system software (such as the multisampling feature on XV-based synths mentioned below) rather than improvements on the actual synth chip. It’s in no way, shape or form complete. A lot of synthesizer keyboard models are not listed.</p>
+<p>The following section summarizes generation-over-generation improvements of the synth engine noticed by me reading the manuals. It is <strong>not</strong> based on analysis of the actual chip, but instead based on analysis of the most capable synth model using that chip. Some of the features might be added with newer version of system software (such as the multisampling feature on XV-based synths mentioned below) rather than improvements on the actual synth chip. It’s in no way, shape or form complete. A lot of synthesizer keyboard models are not listed.</p>
 <h3 id="tocanch17" class="tvis">LA</h3>
-<p>Not strictly a PCM synth. Only uses PCM for the attack phase of the sound. Already showing Roland’s base designs for later PCM synths: 4 “partials” (this term is from 80s Roland samplers, and was referrred to as either voices or tones in later products) for each patch. Each partial has its “timbre”, which consists of a WG (“wave generator”), 5-stage envelope generators for filters and amplifiers (which in later PCM synths were reduced to 4-stage), and a single LFO for mod wheel. Filters are always low-pass. Poor panning resolution (15 steps instead of GM’s 128). Rhythm patches reference to individual “timbres” on each key. Usually paired with external reverb and chorus processing chips. Up to 32 polyphony.</p>
+<p>Not strictly a PCM synth. Only uses PCM for the attack phase of the sound. Already showing Roland’s base designs for later PCM synths: 4 “partials” (this term is from 80s Roland samplers, and was referred to as either voices or tones in later products) for each patch. Each partial has its “timbre”, which consists of a WG (“wave generator”), 5-stage envelope generators for filters and amplifiers (which in later PCM synths were reduced to 4-stage), and a single LFO for mod wheel. Filters are always low-pass. Poor panning resolution (15 steps instead of GM’s 128). Rhythm patches reference to individual “timbres” on each key. Usually paired with external reverb and chorus processing chips. Up to 32 polyphony.</p>
 <p>Used in MT-32, CM-64, CM-32L, D-110 (as MB87136A “LA32”, QFP), and D-50 (as MB87136, PGA).</p>
 <p>Due to the popularity of MT-32, which is supported by a whole bunch of DOS games, emulation of this engine is pretty well-developed already (see the aforementioned Munt project).</p>
 <h3 id="tocanch18" class="tvis">(Unnamed synth engine in U-110)</h3>
@@ -1316,12 +1370,12 @@ Reverb, Chorus, MFX (16 slots, 67 types), EQ, compressor (drum part), Surround,
 </ul>
 <p>This list is far from complete. There has been extensive efforts to map the multisamples in the SD-80 to XV-5080 and SRX multisamples. <a href="//filestorage.chrisoft.org/blog/data/SD-80/SD-80_Waveform_Comparison.pdf">Here</a> is one made by Palto. These mappings are extremely useful if you wish to recreate SD-80 patches with Roland’s VSTi plugins.</p>
 <p>So the content of the SD-80 is actually a mixture of XV-5080, SRX wave expansion boards, SR-JV80 boards, earlier SoundCanvas patches and maybe a few new sounds. Reusing stuff isn’t surprising for Roland, nor should it be considered “bad”. They’ve been known to do this <a href="https://www.soundonsound.com/reviews/roland-sc88">since the early SC days</a>, where they used JV- and SR-JV80 expansion board sounds in the old SC series. Evidently, the waveforms come with XV-5080 itself include everything from the JV-2080/1080, which are in turn partially from the JV-880, and eventually from the JD-800… I’ve also noted that SuperQuartet has a substantial overlapping set of instruments with SRX-03. All I want to say in this section is that if you want to get some particular sounds from the Studio Canvas, instead of waiting for a second-hand offering, maybe look somewhere else.</p>
-<p>Since the content of SD-80 is mostly just cherrypicked XV/SRX content, it really doesn’t need any additional praise from me. However I think it’s worth pointing out that Roland’s samples of that era, just like sounds from most other vendors, are heavily looped. They have loop periods that are quite short (usually less than a second). They are also usually heavily preprocessed. As the amount of memory used for reproducing the instruments saw a huge boom in the 2000s, they no longer sound downright “fake” or “plasticky” compared to romplers from a decade ago. However when compared against huge modern sample libraries, most instruments from these 2000s Roland romplers sound more “idealistic” rather than “realistic”, just like your average Japanese anime girls with unrealisticly huge eyes. Not saying that such sound is bad, though.</p>
-<p>The GS sounds and XGLite sounds of the SD-80 are completely trash. The GS sound set is pretty much just the SC-55 map in later SoundCanvas models using SD-80 samples. The XGLite sound set however, is notably larger than the average bottom-of-the-line Yamaha Portatones from the early 2000s (the XGLite intrument listing in SD-80/90’s manual is incomplete. Check my first SD-80 post for a complete list). There are probably only 5 or so usable sounds offered in these modes in total (most of which are in the XGLite sound set, which is kind of ironic for a Roland sound module). It’s not worth it to switch modes just for those sounds, especially since these modes don’t support low-level editing like the native mode.</p>
+<p>Since the content of SD-80 is mostly just cherrypicked XV/SRX content, it really doesn’t need any additional praise from me. However I think it’s worth pointing out that Roland’s samples of that era, just like sounds from most other vendors, are heavily looped. They have loop periods that are quite short (usually less than a second). They are also usually heavily preprocessed. As the amount of memory used for reproducing the instruments saw a huge boom in the 2000s, they no longer sound downright “fake” or “plasticky” compared to romplers from a decade ago. However when compared against huge modern sample libraries, most instruments from these 2000s Roland romplers sound more “idealistic” rather than “realistic”, just like your average Japanese anime girls with unrealistically huge eyes. Not saying that such sound is bad, though.</p>
+<p>The GS sounds and XGLite sounds of the SD-80 are completely trash. The GS sound set is pretty much just the SC-55 map in later SoundCanvas models using SD-80 samples. The XGLite sound set however, is notably larger than the average bottom-of-the-line Yamaha Portatones from the early 2000s (the XGLite instrument listing in SD-80/90’s manual is incomplete. Check my first SD-80 post for a complete list). There are probably only 5 or so usable sounds offered in these modes in total (most of which are in the XGLite sound set, which is kind of ironic for a Roland sound module). It’s not worth it to switch modes just for those sounds, especially since these modes don’t support low-level editing like the native mode.</p>
 <p>The SD-80 features 1050 instruments and 30 drum sets, which is a significant decrease from the last generation SC-8850 (1640 instruments and 63 drum sets). The loss of SC-8850’s ethnic and analog instruments is a shame. But the quality of instruments does receive a general uplift.</p>
 <h3 id="tocanch34" class="tvis">More on SD-80 vs SD-90 vs SD-20</h3>
 <h4 id="tocanch35" class="tvis">What does a SD-90 have that SD-80 doesn’t?</h4>
-<p>Easy. The audio interface (together with post-proccessing effects) and the large screen.</p>
+<p>Easy. The audio interface (together with post-processing effects) and the large screen.</p>
 <p>It is a shame that Roland didn’t implement full XV-level editability of patches on such a large screen though.</p>
 <p>SD-80 is also not capable of switching the output sample rate on its digital audio outputs.</p>
 <h4 id="tocanch36" class="tvis">What does a SD-80 have that SD-90 doesn’t?</h4>
@@ -1469,13 +1523,13 @@ Stereo Auto Wah
 </ul>
 <h2 id="tocanch43" class="tvis">References</h2>
 <ul>
-<li>Roland Wave Expansion Cards Edward D-tech https://www.dtech.lv/techarticles_roland_exp.html</li>
-<li>Don Solaris’ ultimate Roland JV/JD/XV FAQ http://www.donsolaris.com/?p=404</li>
-<li>COSM Sweetwater https://www.sweetwater.com/insync/cosm/</li>
-<li>SOS Review of XV-5080 https://www.soundonsound.com/reviews/roland-xv5080</li>
-<li>SOS Review of SD-90 https://www.soundonsound.com/reviews/edirol-sd90</li>
-<li>SOS Review of SD-80 https://www.soundonsound.com/reviews/edirol-sd80</li>
-<li>SOS Review of SC-88 https://www.soundonsound.com/reviews/roland-sc88</li>
+<li><a href="https://www.dtech.lv/techarticles_roland_exp.html">Roland Wave Expansion Cards by Edward D-tech</a></li>
+<li><a href="http://www.donsolaris.com/?p=404">Don Solaris’ ultimate Roland JV/JD/XV FAQ</a></li>
+<li><a href="https://www.sweetwater.com/insync/cosm/">What is COSM?</a></li>
+<li><a href="https://www.soundonsound.com/reviews/roland-xv5080">SOS Review of XV-5080</a></li>
+<li><a href="https://www.soundonsound.com/reviews/edirol-sd90">SOS Review of SD-90</a></li>
+<li><a href="https://www.soundonsound.com/reviews/edirol-sd80">SOS Review of SD-80</a></li>
+<li><a href="https://www.soundonsound.com/reviews/roland-sc88">SOS Review of SC-88</a></li>
 </ul>
 </article>
 </div><br><hr>