Jan Beta could be the parser for converting 0-15 in ascii would have been longer than actually using a table .. but then why not just use 0-f hex style, would have been shorter and simpler anyway
@@VintageGearFreak: Using digits 0-9 is more "user-friendly" than 0-F. Too many people would have been looking for the 'F' digit on their numeric keypad.
This video reminds me of how blown away I was with Ghostbusters on the 64, must have spent half a day hitting the space bar to play the Ghostbusters sample in time to the music!
Same with Impossible mission :"Another visitor, stay a while, stay for evvvvvvaa" and " Ahhghghghghhgh" Now that I think about it, how did they fit all that into memory ? :)
@@hqqns they used LPC - linear predictive coding, that only works for speech. they practically simulate the vocal tract by genrtazimg a sawtooth and noise signal and use filters to change the harmonics of the sawtooth signal. now you don't need that much information anymore. you update the information for the sawtooth and noise generator every now and then. if you listen very carefully to the "aaaaahhh" in mission impossible, then you hear the updates "very slow" - maybe every 0,2 seconds.
@@stefanweilhartner4415 when you say harmonics where there different sawtooth signals to create overtones? Or did they use the noise to mask the robotic voice quality? Got me really interested in this now.
Compute's Gazette had a program that would play samples from the Datasette. I think it was the August 1988 issue, but I don't have the magazine anymore so I don't know for sure.
Hah! For me and my cousin, it was that and "V-8; return to base immediately!" Great music in that game (The Last V-8). Not so much the actual game, though.(There were a couple other vocal samples, something like "Caution: avoid radioactive sides" if you got to the second level. But we rarely played long enough to even finish the first level.)
9:38 3kHz sound output means approx 6kHz sample rate. That sounds about right. The sounds you played at the beginning reminded me a lot of the 5khz sound files I would, play on my Mac SE back in the day. They didn't sound wonderful (the SE was capable of 22 kHz -- that's how powerful the 68000 was), but you could store a pretty nicely sized chunk of speech (movie quotes, usually) in RAM for playback. 10:36 Yep! 😅 12:58 Wolfram Alpha says it's 3.321928 bits, but I like "Robin Math" ^__^ 15:00 I did something very similar on the PC in the early nineties. I used a serial-port microphone on my Mac SE to record a sound (I can't remember the sample rate, it might have been 11 kHz), and brought the raw file into the pc. I then used a Pascal program I wrote to convert each sample to a line (or two?) of x86 assembly, and chop it up so that it would be a series of files that would assemble down to 64k of instructions (.com file limit). I then used a batch file to assemble each chunk using MS DOS debug, then used a batch file to execute each .com file in order. It was pretty primitive, because I didn't understand enough assembly to create a loop or anything like that, and there was a small pause as each 64k chunk got loaded, but it did work ;)
one very important information about down sampling. before down sampling to 6kHz: you need to do some good and steep low pass filtering from about 2,5kHz on. because down sampling mirrors down high frequency signals. for example, if you have a 3,2khz signal in your audio file, after down sampling to 6khz sample frequency the signals above 3kHz are getting mirrored down. that means that the 3,2khz signal part does not vanish magically after down sampling. it will show up as a new 2.8kHz signal.which sounds wired. that filtering is the difference between good and bad sampling
Nice episode. As a kid I was thrilled to hear the sample of the initial piece of the song "Carl Douglas - Kung fu fighting" through the "voice" of the Commodore64. I hope I still have that floppy disk somewhere.
That was good. There were others as well as Robin and I briefly touched on in an earlier video. Samples from Van Halen’s “Why Can’t This Be Love” and Nu Shooz’ “I Can’t Wait” were a couple of others I remember hearing back in the day.
I think you could further improve sound quality by taking the non-linearity of the volume command into account. As you pointed out in the disassembly, the actual amplitude applied is taken from a look-up table. If your 8bit-to-10steps conversion (line 50) would use the exact trigger points (ten points on the 8bit range, i.e. the reverse operation of the original volume look-up), your sample amplitudes would be more precise and quantisation noise should be reduced.
Thats really helpful always wanted to take full advantage of the amazing audio quality of my commodore I love your videos I wish I could come over and learn from you
Now that is an interesting discovery. I have never heard (or heard of) this before. Fascinating. I had to laugh - I still have my "I Adore My C64" badge from a big World of Commodore show back in the 80s.
I used to have a small C64 program back in the day that "recorded" a sample and played it back, and it indeed only changed the volume register to create the synthesis. I can't remember what it was in - some magazine-like book with a yellow cover.
Damn, this is like some kind of telephaty. A few days ago I was just wondering about how actually the SID works and if it would be possible to reproduce waveforms of decoded MP3s for instance. Well, this answers a lot of questions, and raises some new ones (mainly I now want to dig deeper into the principles of how these older sound chips work compared to the modern ones :D )
i think the ghostbusters and mission impossible sounds where stored in a compressed LPC format which is optimized for speech and then somehow decoded. there are super crazy ways to digital analog convert soumds with the sid. one of them is using a sawtooth generator with different ramp speeds in combination with a reset of the phase at every sample, if i am correct
I remember there being a way to take a C64 datasette and digitizing audio from it onto the C64. I believe there was an old Compute! or perhaps a Compute! Gazette magazine which had a type in program for the C64 that could do this. There was also the famous Impossible Mission's digitized voice which was very clear.
I remember that datasette digitizer program, and have it on my long list of potential episode ideas. I see a couple other people mentioning it in the comments here today, it really made an impact on us!
Another commenter found the program you mentioned, it's in the December 1988 issue of Compute!'s Gazette, called Digi-Sound. I might do an episode on it in the future. :)
There was a program in compute's gazette that allowed you to do this on the c64...there was even a program that allowed you to use the datasette to do the sampling.
Yes, lots of great examples of digis on the C64. The first one I remember was a loop of Billy Idol's "Flesh for Fantasy" around 1986? And of course, all the great examples in games, a couple of which I play in this video.
Not to mention one of Mel & Kim's songs "Showing Out (Get Fresh At The Weekend). There's loads more such amazing digitized loops... (I wish I could get my 80's back)
@@8_Bit I also remember some random Bananarama song and the Miami Vice theme in the early 80s. I thought it was truly amazing. I suspect when I hear it now I would be underwhelmed, as we are used to MP3s today, but back then it was like magic! (Edit to add: It is still amazing considering the memory limit on the C64!)
Off course the C128 can play pcm samples, because it’s sid chip has 2 8bit dac convertors and it’s also possible to combine all 4 soundchannels together and then rapidly change the volume of it to play 1bit samples, So i really don’t know how this bug allows you to play pcm samples in another way on the C128, am mean what makes it different? Is beyond me. But it’s impressive. THX for showing this.
The difference is that you can do it using the built in PLAY command in BASIC7. Some people get a lot of joy out of making BASIC do fun tricks it wasn't intended to do.
Jeremy Levi yeah oke, i can understand that, but now am wondering, how is that pcm via basic7 outputted? Does it get output via the sid chip or something like that??
@@johneygd Yep, it's using the same technique of taking advantage of changing the volume levels on the SID to produce PCM, just through the BASIC PLAY command instead of the usual method of manipulating the SID directly via machine code. Just afaik, no one knew you could do that from BASIC before.
the sid had 3 channels and you did not have direct access to the 8-bit DACs. only the 4 bit volume register could be used as a DAC because of a calculation bug. however, the sawtooth could be used to have a sort of pwm output
Thanks for your video, wonderful to see all what this good old c128 was able to do. Actually as my real C128D PAL seems to have died, I have to use x128 (VICE) and indeed it didn't work first. However, by changing the version of the SID from 8250 to 6581, your trick actually works. Which makes me wonder if they had to use another method in order to "play" samples... Did you try already to contact Bil Herd ? :-)
Thanks! In my experience, a real 8580 SID does play $D418 (volume) digis, but at a much quieter volume than a 6581. I wonder if VICE takes that difference to an extreme and makes them inaudible? I should open up this C128 to make 100% sure it does have an 8580, as I'm surprised how loud the volume is. I haven't tried to contact Bil Herd, but I know he does sometimes watch my show as I've heard from him a couple other times :)
Update: I opened up the C128 used in this video, and indeed it has a 6581 in it. Apparently many flat C128s have the 6581, while the 128D more frequently has the 8580. I took a picture of it which can be seen on the "Community" tab here on my channel.
I was able to get the 128 PLAY command to transpose the theme to Mr. Bean into the SID Chip's three voices. Coding it in 80-column mode works best for me.
Hmm, nice one. Just came back here after your recent C128 video. Wouldn´t it be possible to create a vertically scrolling wave analyzer, with the DRAW command, using the V$ array values as trigger? Every volume change could be drawn as a horizontal line, length matching the volume value, every change is drawn one pixel line below. I´d love to see that, in whatever visual way that´s practical and nice to look at.
The conversion has to be done sometime, so I put it in the loader. Certainly could have written a converter on my Mac, but where's the fun in that, or written another one-time converter program on the C128 to make loading in the future faster. But since I was only demoing each sample once, that would have taken even longer. Anyway, if anyone wants to improve it, the .d64 is downloadable in the description :)
Even doing it in basic. Precalculating a table, that is doing the float divide only 256 times and populating an array once. Is must be faster to access a 256 integer array than doing a float divide in C128 basic? But i agree that this channel often prefers easier to understand and shorter code than optimized one. And i do like it as it is. As somebody else pointed out, it makes sense NOT to use the linear float divide, but invert the non linear transformation of the C128 basic look up table from 0-9 to 0-F. So the integer lookup table won't be populated by 256 divide flops, but from 9 ranges. This should improve playback quality slightly by removing some amplitude quantization distorsions. I have my C128 in the attic. If i put it again in the living room, i think i would try these DIGIs with PLAY and test if one can really hear an improvement implementing this correctly unlinearly reversed lookup table
To speed up reading you can put the Value/25.6 into an array of 0..255 so, the expensive division is only done 256 times, not 150 * 127 = 19050 times (saves about 18794 divisions) and add the 48 already. Then use % on that array to keep it smaller (no real numbers, only 2 bytes per number), with and use + chr$(PC%(ASC(N$))) to add into the array. Didn't think you could just toggle the volume without switching on a voice, though. Also, I envy the C128 for BASIC v7 and 2Mhz 6502 equiv. - would have loved it above C64.
Do note that dividing by 25.6 is only an approximation. You can get better sound quality by mapping each number in 0..255 to the 0..9 that corresponds to the closest available 4-bit value in the lookup table.
My guess it was to save space in the BASIC ROM chips, since they made a ton of improvements to BASIC 7 in the C128 versus BASIC 2 in the C64 and had to fit it all somewhere...
An excellent video as always, I'm playing with VICE right now. I was trying something similar with the volume in C64 with ASM but the 128 PLAY command is a nice shortcut! I do live-coding processing DSP in real time with functions, do you know something about bytebeat? It seems it can be done with this information, maybe you'll be interested...
I thought SID producing noise with volume change was an unintended bug (which was widely used for this very purpose), and it was fixed in later revisions. Is this running on an unmodified 8580?
Hi, I love your videos, can you create a C128 CP/M video as I am looking to use mbasic in 80 column CP/M mode but I have no clue how to get a downloaded file on my PC running on my C128 running in CP/M mode!
Hi, I’m working on getting a video capture solution for 80 column mode and then I’ll make some videos about it. Probably will take another month or two.
It would be interesting to reconstruct the (best fit of the) sound out of the noisy output C128 makes... Sounds like a deconvolution problem to me! Impulse response, what do you think people?
lot of jitter noise and quantisation noise and maybe no suitable low pass filtering before down sampling. the bad filtering could be found out with upsampling to 48000Hz and listening from the PC (with a good equipment)
That was pretty neat :) I'd be kind of curious what sort of resolution audio you could squeeze out if that program was written in assembly, probably would need to do the play command too maybe
I vote that you set it up to read the files from an REU - that should be pretty fast. A nice 256k REU should hold quite a lot of digitized speech. You could have a robotic hand move around in your next video, and your C128 dictate it.
Jeez, this is bugging me, but I remember back in the late 80s/early 90s (would have been at least 1988 or later), in one of the Commodore magazines, probably Compute's Gazette or RUN, there was a type-in program where you could use your datasette to create short digital samples of music that will play back on your C128 or C64. (I can't for the life of me remember whether it was a C128-only program or a C64 program that I ran on my C128. I don't _think_ it used the PLAY command -- just the usual switching on and off of the volume register.) I remember digitizing and saving a 3 or 4 second sample of Weird Al's "Lasagna." on it. I've tried searching the archives for Run and Compute's Gazette very quickly, but my search terms aren't doing it. I'll have to go through the issues one by one to see if I can find it. ETA: Ah, I found it. "Digi-sound" in the December 1988 issue (#66) of Compute's Gazette. The program was written mostly in BASIC (both C64 and C128 versions) , but it did have ten DATA lines of a machine language digital playback routine (POKED into memory), so it did not use the PLAY command like here. But it was cool at the time, letting you record from Datasette, playback, and save and load to disk samples.
@@8_Bit Here's the link: archive.org/details/1988-12-computegazette/page/n93 I wouldn't be surprised if other magazines had other versions of this, but that's the one I used, and I had a C128, so I typed in the C128 version, which was able to record a little bit more of the sample.
Thanks for that find - would be interesting to list the machine code in assembly to see how the digitization from tape is done, since it's not explained in the article.
I have use bit-banging in all my BASIC and C games. In BASIC I simply use the VOL command. It works under Vice but you need to configure the right SID version.
I think the cause of the difference was my C128 has the older 6581 SID in it, while VICE defaults to the newer 8580 when emulating the C128. The 6581 clicks loudly, while on the 8580 it's almost inaudible. Pretty sure VICE does emulate the clicking when set to 6581.
With a core loop like « - lda (data),y : sta sid_volume : iny : bne - », you could play up to 73,000 samples/sec. You would need to add code to slow this down.
9:19 You can calculate the sample rate from the number of samples played, 100*254 = 25,400, and the time, 4.47 seconds. Your video only included 2.05 seconds of play time plus an extraneous "Hooo-ooo!", but VICE gives me 4.47 seconds using the TI variable. This gives 5,682 samples per second (2,841 max Hz sound). You could also get a little more consistent performance by disabling IRQs. 11:51 Why couldn't they use a round number like 44 kHz instead of 44.1 kHz? Or just 40 kHz given that almost nobody can hear the full 20 kHz sound. 12:52 A system of ten symbols contains log2(10) ≈ 3.322 bits of information per symbol. Using densely-packed BCD comes close to this, stuffing 1000 symbols into 10 bits of space ≈ 3.333 bits per decimal digit. The "Robin Math" system still uses four bits per decimal digit. 14:08 I guess the C128 fixed the ASC("") bug. I seem to recall the VIC-20 returning an empty string for a GET# that reads in a CHR$(0), and subsequent code blowing up when attempting to do an ASC() on that string. The C64 may have this problem. 14:30 The optimal divisor would be 25.5000001, to divide the sample space evenly into 10 "buckets". It would also be more efficient to multiply by the reciprocal of the divisor, since multiplication is faster than division on old hardware and new. 14:38 Appending to the string is going to slow down as the string gets longer, since the long content needs to be copied around. It would be faster to build up shorter strings and flush those to the long string. 15:57 Changing «FOR C=0 TO B» to «FOR C=.TOB» won't make the playback any faster since this is parsed before the playback begins. 16:09 On the C64, you could try Jason's POKE 648:PRINT trick from your "Even More Commodore 64 BASIC Optimizations" video, th-cam.com/video/J9QH-tUJB2s/w-d-xo.html . He reported 1800 samples/second. 16:43 It's a bug in the documentation!
Your post got flagged as spam again - for the sin of linking to one of my videos, apparently :) Thanks re: sample calculation. Were you running VICE in PAL or NTSC mode? 5682 Hz seems a little lower than I expect, but I should give it another try. I thought of disabling IRQs after I finished recording, but still haven't looked up how to do it on the C128 from BASIC. Maybe it's just that POKE I did in the other video to allow switching between colour RAM banks? Yeah, "Robin Math" is dumb. And yes, C128 ASC("") returns 0, while on the VIC-20 and C64 it returns an ?ILLEGAL QUANTITY ERROR Thanks as always for all the great feedback!
@@8_Bit: You'd think TH-cam would be okay with links to TH-cam's own site. Your playback of the digis sounded a little slowed down, which is an effect that would be produced by creating them for 6026 samples/sec and then playing them at 5682 samples/sec. I ran this in VICE configured for NTSC.
@@8_Bit: The character-base I/O would be a real Achilles heel to running this. When producing the sample data, instead of outputting RAW samples, you could map them to characters 0-9 and put 255 of them on a line, separated by carriage returns, and use INPUT# in the playback program. I.e., set up the strings in the disk file. This would optimize for a write-once, read-many environment.
The 44.1 kHz originates from Sony's U-matic studio videorecorder which was used to record 3 digital audio samples per video raster line. It had to be compatible with both the PAL and the NTSC standard, hence the strange frequency.
regarding the 44,1kHz, I might have the coolest answer ever. the number 44100 is dividable by 50 and by 60. that makes it suitable to use it perfect for video with 60hz ntsc and 50Hz pal. i calculated again and found a new discovery: the studio sample frequency of 48000Hz is dividable by 24 (film), 50 (pal) and 60 (ntsc)!
Try the sequence (0x0, 0x1, 0x3, 0xc, 0xe, 0xf, 0xe, 0xc, 0x3, 0x1, 0x0), and feed those values to the SID chip via 6502 assembler (rather than going through the BASIC interpreter). This sequence is a (rough) approximation of a sine wave (one cycle’s worth.) Or - in BASIC - use the sequence 1,2,7,8,9,8,7,2,1,0 and repeat 25x in A$, then play a$. Of course, this will be a lower pitch (frequency) than the square wave generated by the repeating 9,0 sequence, but that’s to be expected, since my sequence is 5x as long, so the frequency should be roughly 5x lower. 😎
You will get better intelligibility of your "digi's" if you either sample at half the playback speed (in this case 1.5 Khz) and then upconvert the sample to 3 Khz, or sample at 3 Khz with a lowpass filter on the input set at 1.5 Khz. Either way the ratio you need is sample rate ( or sample lowpass filter frequency) = playback rate / 2. Doubling the playback rate for a sample rate as you did effectively quartered the effective playback frequency and doubled the aliasing. Also a better test would be to set up 2 strings like A$="9999999988888888777777776666666666666666777777778888888899999999" B$="0000000000000000000000000000000000000000000000000000000000000000" then playback a$ followed by b$ over and over, record it, and in your sample editing program look for a single cycle edge where the zeros convert back to 9's and trim anything before that point and then look for where the 9's convert to zeros and trim anything after that point. Now you have a single 16 bit cycle in your editor you can copy paste to complete the waveform and then measure the frequency to find the what the commodore is capable of outputting from a captured wavesample. Use that as your playback frequency for calculating the the sample rate.
Hi! Thanks for the info. I think the effective playback speed in FAST mode is maybe 5900 Hz; I initially calculated it at 6026 Hz but I must have made an error as everything was pitched a bit low. So I down-sampled to what I thought was half the playback speed, 3013 Hz, and on at least a couple of the examples I did run a low-pass filter at 3000 Hz first but didn't show that in the brief Audacity clips I showed. Just clarifying that in case I wasn't clear in the video. Thanks for the info on how to better measure the speed, if I revisit this I'll try it!
Is there on 128d a FREE prg that load very fast samples with turbo routine and "EDIT" them (listen, see time-graph and some options to modify as well as a mini-mini-audacity)??!! Maybe in Geos??!! Must BE FREE and FAST so i think there isn't!
"I just should have looked at the disassembly" I just learned again that all the books in the world are no alternative for this.. The code is the real documentation of how things work.. :-) (this after wondering why some ancient program from a magazine din't work properly, and my own independent version of the same idea failed in the exactly same way). So what was the issue? I was loading a C64 program in 128 mode (starting the load at $1801) and after the load finishes, switch to 64 mode, move the code down to $0801, set the start of variables pointer properly, and try to run the program. That works fine for smallish things, but.. it turned out the byte at $9004 did not have the original content. The address (originally $a004 before moving the program back to $0801) should have triggered some alarm bells.. What was at that address did look familiar ($55) as something likely put there by a ram test... this should have triggered more alarm bells.. But I did determine quickly this happened during c64 boot.. and tracing the boot process did make me end up at the ramtas code, unsurprisingly. So... that code is nice at first glance. It reads a byte from ram, stores it so the original ram content can be resored later.. tests if it can write the address (in 2 ways) and if it can, and the data it gets back matches what it wrote, it will restore the original content. So far so good. Where it goes wrong is when it runs into rom. At that point, it will conclude it isn't reading back what it wrote, and doesn't try to restore the original content. Of course, due to how it reads the original content, it would try to restore a byte from rom anyway, so it would still fail even if it did. But.. that also means a reset (without skipping the ram test) will always corrupt a byte of ram at $a004, and not just overwrite data below $0802. A good thing to know, its entirely logical it happens, but.. it did take a more carefull read of the actual rom code to spot why it was happening. I did fix my code to work around it, and can now load any c64 program (which ends before $d000) in 128 mode, and start it in 64 mode.. which has some uses as those who use my C128 device manager will soon find out :-)
Awesome episode, great explanation! I made a small program that does the conversion based on measured loudness levels for the 10 volume settings and added a menu system allowing to save and load converted Digis. We also linked to your episode, the program is here: csdb.dk/release/?id=192738
Nice, thanks for the link! The reason I called it a hack was because the official documentation (such as the C128 Programmer's Reference Guide page 55, at least, my English North American edition) for the PLAY command says the volume change command requires both a "U" in front of the number, and then some documentation says it should be followed by a number 0 through 15, and other documentation says 0 through 8. So while the PLAY command may be working as designed by the programmers, when it's such a complete mismatch with the official documentation, it seems that there's a bug or a hack work-around somewhere!
The C128 can play much higher-quality samples using machine language. These examples are played 100% in BASIC which I previously thought was impossible. Even if they don't sound all that great, I'm amazed they work at all.
when you use that basic commands you have a lot of jitter coming with it too, some from interrupts, some maybe from an inconsistent bus access (bad lines)
Nah, you guys and your "modern" (!) C64 samples. Try the "Kung Fu Fighting" sample from '86 :) Seemed like hours of load time (especially on cassette!) and all for 20 seconds...
I guess that it isn't the fact that they want you not to know, it is the fact that the sound quality is so bad. Better not speak about it. Softly softly catch a monkey.
Wow, that's some clever use of that non-bug! Amazing that the C128 still has surprises up its sleeve today (in the right hands, that is). :D
Jan Beta could be the parser for converting 0-15 in ascii would have been longer than actually using a table .. but then why not just use 0-f hex style, would have been shorter and simpler anyway
That’s a “hands-based vlogger” joke, isn’t it?
Agreed, and it will never stop blowing my mind what these 8-bit machines can still do. Wow!
@@VintageGearFreak: Using digits 0-9 is more "user-friendly" than 0-F. Too many people would have been looking for the 'F' digit on their numeric keypad.
Cool. It sounds like there was a lot of confusion even within Commodore about how the command worked, but the disassembly clears it up.
This video reminds me of how blown away I was with Ghostbusters on the 64, must have spent half a day hitting the space bar to play the Ghostbusters sample in time to the music!
Same with Impossible mission :"Another visitor, stay a while, stay for evvvvvvaa" and " Ahhghghghghhgh"
Now that I think about it, how did they fit all that into memory ? :)
@@hqqns they used LPC - linear predictive coding, that only works for speech. they practically simulate the vocal tract by genrtazimg a sawtooth and noise signal and use filters to change the harmonics of the sawtooth signal. now you don't need that much information anymore. you update the information for the sawtooth and noise generator every now and then. if you listen very carefully to the "aaaaahhh" in mission impossible, then you hear the updates "very slow" - maybe every 0,2 seconds.
@@stefanweilhartner4415 when you say harmonics where there different sawtooth signals to create overtones?
Or did they use the noise to mask the robotic voice quality?
Got me really interested in this now.
@@littleloner1159 the sawtooth signal itself contains harmonics. every signal but a pure sine wave contains harmonics
@@stefanweilhartner4415"genrtazimg"? now that's a word I've never seen before.
Compute's Gazette had a program that would play samples from the Datasette. I think it was the August 1988 issue, but I don't have the magazine anymore so I don't know for sure.
Where is the MOST famous "digi"? "Another visitor...stay a while... stay FOREVER!"
It's on the demo D64 now if you want to load it: psw.ca/prg/c128sample.d64
(Might not work in an emulator)
Hah! For me and my cousin, it was that and "V-8; return to base immediately!" Great music in that game (The Last V-8). Not so much the actual game, though.(There were a couple other vocal samples, something like "Caution: avoid radioactive sides" if you got to the second level. But we rarely played long enough to even finish the first level.)
"V8 return to base immediately"
I loved the Intro speech from Turrican:
"Hello and welcome to Turrican. Be my guest. Another day, another try. But remember, shoot or die, hahahaha"
@William Baric You are a true masochist! LOL. Glad someone out there actually enjoys it for something other than the music.
9:38 3kHz sound output means approx 6kHz sample rate. That sounds about right. The sounds you played at the beginning reminded me a lot of the 5khz sound files I would, play on my Mac SE back in the day. They didn't sound wonderful (the SE was capable of 22 kHz -- that's how powerful the 68000 was), but you could store a pretty nicely sized chunk of speech (movie quotes, usually) in RAM for playback.
10:36 Yep! 😅
12:58 Wolfram Alpha says it's 3.321928 bits, but I like "Robin Math" ^__^
15:00 I did something very similar on the PC in the early nineties. I used a serial-port microphone on my Mac SE to record a sound (I can't remember the sample rate, it might have been 11 kHz), and brought the raw file into the pc. I then used a Pascal program I wrote to convert each sample to a line (or two?) of x86 assembly, and chop it up so that it would be a series of files that would assemble down to 64k of instructions (.com file limit). I then used a batch file to assemble each chunk using MS DOS debug, then used a batch file to execute each .com file in order.
It was pretty primitive, because I didn't understand enough assembly to create a loop or anything like that, and there was a small pause as each 64k chunk got loaded, but it did work ;)
one very important information about down sampling. before down sampling to 6kHz: you need to do some good and steep low pass filtering from about 2,5kHz on. because down sampling mirrors down high frequency signals. for example, if you have a 3,2khz signal in your audio file, after down sampling to 6khz sample frequency the signals above 3kHz are getting mirrored down. that means that the 3,2khz signal part does not vanish magically after down sampling. it will show up as a new 2.8kHz signal.which sounds wired. that filtering is the difference between good and bad sampling
That's true, but I suppose Audacity already does this in the resampling process (otherwise its resampling algorithm is really bad).
Nice episode. As a kid I was thrilled to hear the sample of the initial piece of the song "Carl Douglas - Kung fu fighting" through the "voice" of the Commodore64. I hope I still have that floppy disk somewhere.
That was good. There were others as well as Robin and I briefly touched on in an earlier video. Samples from Van Halen’s “Why Can’t This Be Love” and Nu Shooz’ “I Can’t Wait” were a couple of others I remember hearing back in the day.
I think you could further improve sound quality by taking the non-linearity of the volume command into account. As you pointed out in the disassembly, the actual amplitude applied is taken from a look-up table. If your 8bit-to-10steps conversion (line 50) would use the exact trigger points (ten points on the 8bit range, i.e. the reverse operation of the original volume look-up), your sample amplitudes would be more precise and quantisation noise should be reduced.
Thats really helpful always wanted to take full advantage of the amazing audio quality of my commodore
I love your videos I wish I could come over and learn from you
Now that is an interesting discovery. I have never heard (or heard of) this before. Fascinating. I had to laugh - I still have my "I Adore My C64" badge from a big World of Commodore show back in the 80s.
I used to have a small C64 program back in the day that "recorded" a sample and played it back, and it indeed only changed the volume register to create the synthesis. I can't remember what it was in - some magazine-like book with a yellow cover.
9:20 guess you could say that sound hertz. :D
Achievment Unlocked: Comedy
+100 humor
-10 friends
Still way funnier than some professional comedians... Ex: Amy Schumer
:P
Damn, this is like some kind of telephaty. A few days ago I was just wondering about how actually the SID works and if it would be possible to reproduce waveforms of decoded MP3s for instance. Well, this answers a lot of questions, and raises some new ones (mainly I now want to dig deeper into the principles of how these older sound chips work compared to the modern ones :D )
Pretty cool idea! Thanks for mentioning me :)
I’d probably never have realized if you didn’t make the comment, thanks again 😊
Wow, nice discovery Robin. Really enjoyed this episode.
The 128 is still my favourite computer. My first is a Atari 800, got a Amstrad, 386sx, couple Pentiums and this Thinkpad but I still love my 128.
Wow, didn't know that the digi playback works in basic too. Thanks for presenting this.
i think the ghostbusters and mission impossible sounds where stored in a compressed LPC format which is optimized for speech and then somehow decoded.
there are super crazy ways to digital analog convert soumds with the sid. one of them is using a sawtooth generator with different ramp speeds in combination with a reset of the phase at every sample, if i am correct
I remember there being a way to take a C64 datasette and digitizing audio from it onto the C64. I believe there was an old Compute! or perhaps a Compute! Gazette magazine which had a type in program for the C64 that could do this.
There was also the famous Impossible Mission's digitized voice which was very clear.
I remember that datasette digitizer program, and have it on my long list of potential episode ideas. I see a couple other people mentioning it in the comments here today, it really made an impact on us!
Another commenter found the program you mentioned, it's in the December 1988 issue of Compute!'s Gazette, called Digi-Sound. I might do an episode on it in the future. :)
That's brilliant! Very simple but elegant basic code as well.
There was a program in compute's gazette that allowed you to do this on the c64...there was even a program that allowed you to use the datasette to do the sampling.
i have a really weak memory about a program listing in a magazine that could record a short "sample"" from the datasette and play it back
I remember that one (or a similar). And I wrote one that did it in real-time.
1 bit sampling.
I wrote an entire GUI based sampler on the C64 using this technique.
@@grahampickard3325 @Graham Pickard But sadly even with oversampling and smoothing it still sort of sounded, well not good :)
Thank you for another great video! going to have to try this on my 128.
You know that there are a C64 demo named "19" that plays Paul Hardcastles song "19" as it streams the data from the 1541...
Yes, lots of great examples of digis on the C64. The first one I remember was a loop of Billy Idol's "Flesh for Fantasy" around 1986? And of course, all the great examples in games, a couple of which I play in this video.
Not to mention one of Mel & Kim's songs "Showing Out (Get Fresh At The Weekend).
There's loads more such amazing digitized loops...
(I wish I could get my 80's back)
@@8_Bit I also remember some random Bananarama song and the Miami Vice theme in the early 80s. I thought it was truly amazing. I suspect when I hear it now I would be underwhelmed, as we are used to MP3s today, but back then it was like magic!
(Edit to add: It is still amazing considering the memory limit on the C64!)
I would try that last loop backwards for fun. Great video. Very interesting.
Off course the C128 can play pcm samples, because it’s sid chip has 2 8bit dac convertors and it’s also possible to combine all 4 soundchannels together and then rapidly change the volume of it to play 1bit samples,
So i really don’t know how this bug allows you to play pcm samples in another way on the C128, am mean what makes it different? Is beyond me.
But it’s impressive.
THX for showing this.
The difference is that you can do it using the built in PLAY command in BASIC7. Some people get a lot of joy out of making BASIC do fun tricks it wasn't intended to do.
Jeremy Levi yeah oke, i can understand that, but now am wondering, how is that pcm via basic7 outputted? Does it get output via the sid chip or something like that??
@@johneygd Yep, it's using the same technique of taking advantage of changing the volume levels on the SID to produce PCM, just through the BASIC PLAY command instead of the usual method of manipulating the SID directly via machine code. Just afaik, no one knew you could do that from BASIC before.
the sid had 3 channels and you did not have direct access to the 8-bit DACs. only the 4 bit volume register could be used as a DAC because of a calculation bug.
however, the sawtooth could be used to have a sort of pwm output
Thanks for your video, wonderful to see all what this good old c128 was able to do. Actually as my real C128D PAL seems to have died, I have to use x128 (VICE) and indeed it didn't work first. However, by changing the version of the SID from 8250 to 6581, your trick actually works. Which makes me wonder if they had to use another method in order to "play" samples... Did you try already to contact Bil Herd ? :-)
Thanks! In my experience, a real 8580 SID does play $D418 (volume) digis, but at a much quieter volume than a 6581. I wonder if VICE takes that difference to an extreme and makes them inaudible? I should open up this C128 to make 100% sure it does have an 8580, as I'm surprised how loud the volume is. I haven't tried to contact Bil Herd, but I know he does sometimes watch my show as I've heard from him a couple other times :)
Update: I opened up the C128 used in this video, and indeed it has a 6581 in it. Apparently many flat C128s have the 6581, while the 128D more frequently has the 8580. I took a picture of it which can be seen on the "Community" tab here on my channel.
Can you use the digi playing feature with some kind of irq freeing cycles for example streaming the file from disk or maybe a harddisk?
Like your videos; thank you for making these!
I was able to get the 128 PLAY command to transpose the theme to Mr. Bean into the SID Chip's three voices. Coding it in 80-column mode works best for me.
Hmm, nice one. Just came back here after your recent C128 video.
Wouldn´t it be possible to create a vertically scrolling wave analyzer, with the DRAW command, using the V$ array values as trigger? Every volume change could be drawn as a horizontal line, length matching the volume value, every change is drawn one pixel line below. I´d love to see that, in whatever visual way that´s practical and nice to look at.
That is some impressive sleuthing.
This is kind of genius, I can imagine this would have been a breakthrough back in the day.
It was... Pre MP3 long before there was MP3! (lol)
Real Great Stuff!! Thanks for that! Greetings, Doktor64!
This is pretty cool. Thanks for sharing this discovery.
You are basically doing digital samples just like Pokemon yellow's pickachu's voice.
Yesterday I Purchased a Commodore 128 + 1571 disk drive for a bargain. Neat machine!
Doing a floating-point divide per-byte is pretty crazy. Can't you store the data already in binary format? (err, I mean pre-scaled?)
The conversion has to be done sometime, so I put it in the loader. Certainly could have written a converter on my Mac, but where's the fun in that, or written another one-time converter program on the C128 to make loading in the future faster. But since I was only demoing each sample once, that would have taken even longer. Anyway, if anyone wants to improve it, the .d64 is downloadable in the description :)
Even doing it in basic.
Precalculating a table, that is doing the float divide only 256 times and populating an array once. Is must be faster to access a 256 integer array than doing a float divide in C128 basic?
But i agree that this channel often prefers easier to understand and shorter code than optimized one. And i do like it as it is.
As somebody else pointed out, it makes sense NOT to use the linear float divide, but invert the non linear transformation of the C128 basic look up table from 0-9 to 0-F. So the integer lookup table won't be populated by 256 divide flops, but from 9 ranges. This should improve playback quality slightly by removing some amplitude quantization distorsions.
I have my C128 in the attic. If i put it again in the living room, i think i would try these DIGIs with PLAY and test if one can really hear an improvement implementing this correctly unlinearly reversed lookup table
To speed up reading you can put the Value/25.6 into an array of 0..255 so, the expensive division is only done 256 times, not 150 * 127 = 19050 times (saves about 18794 divisions) and add the 48 already.
Then use % on that array to keep it smaller (no real numbers, only 2 bytes per number), with and use + chr$(PC%(ASC(N$))) to add into the array.
Didn't think you could just toggle the volume without switching on a voice, though. Also, I envy the C128 for BASIC v7 and 2Mhz 6502 equiv. - would have loved it above C64.
Do note that dividing by 25.6 is only an approximation. You can get better sound quality by mapping each number in 0..255 to the 0..9 that corresponds to the closest available 4-bit value in the lookup table.
So sample values $00 to $08 should become "0", $09 to $20 should become "1", $21 to $3F should become "2" and so on.
I just wonder why they would build this translation table to map 10 volume levels onto 4 bits... Is 10 more user friendly than 16?
My guess it was to save space in the BASIC ROM chips, since they made a ton of improvements to BASIC 7 in the C128 versus BASIC 2 in the C64 and had to fit it all somewhere...
An excellent video as always, I'm playing with VICE right now. I was trying something similar with the volume in C64 with ASM but the 128 PLAY command is a nice shortcut! I do live-coding processing DSP in real time with functions, do you know something about bytebeat? It seems it can be done with this information, maybe you'll be interested...
I thought SID producing noise with volume change was an unintended bug (which was widely used for this very purpose), and it was fixed in later revisions. Is this running on an unmodified 8580?
I opened up this C128 and found it actually has a 6581 in it. There's a picture of it on my channel's Community tab.
yes, they made the calculations in the early SID in unsigned integer instead of signed integer. that introduces that steps with the volume register
Wow. You and your friends are geniuses!
Hi, I love your videos, can you create a C128 CP/M video as I am looking to use mbasic in 80 column CP/M mode but I have no clue how to get a downloaded file on my PC running on my C128 running in CP/M mode!
Hi, I’m working on getting a video capture solution for 80 column mode and then I’ll make some videos about it. Probably will take another month or two.
is there a basic interpreter in CP/M mode?? This C128 3-in-1 (*and* 2 graphics chips!?), keeps blowing my mind.
It would be interesting to reconstruct the (best fit of the) sound out of the noisy output C128 makes... Sounds like a deconvolution problem to me! Impulse response, what do you think people?
lot of jitter noise and quantisation noise and maybe no suitable low pass filtering before down sampling. the bad filtering could be found out with upsampling to 48000Hz and listening from the PC (with a good equipment)
That was pretty neat :) I'd be kind of curious what sort of resolution audio you could squeeze out if that program was written in assembly, probably would need to do the play command too maybe
A fascinating update 👍
I vote that you set it up to read the files from an REU - that should be pretty fast. A nice 256k REU should hold quite a lot of digitized speech. You could have a robotic hand move around in your next video, and your C128 dictate it.
Jeez, this is bugging me, but I remember back in the late 80s/early 90s (would have been at least 1988 or later), in one of the Commodore magazines, probably Compute's Gazette or RUN, there was a type-in program where you could use your datasette to create short digital samples of music that will play back on your C128 or C64. (I can't for the life of me remember whether it was a C128-only program or a C64 program that I ran on my C128. I don't _think_ it used the PLAY command -- just the usual switching on and off of the volume register.) I remember digitizing and saving a 3 or 4 second sample of Weird Al's "Lasagna." on it. I've tried searching the archives for Run and Compute's Gazette very quickly, but my search terms aren't doing it. I'll have to go through the issues one by one to see if I can find it.
ETA: Ah, I found it. "Digi-sound" in the December 1988 issue (#66) of Compute's Gazette. The program was written mostly in BASIC (both C64 and C128 versions) , but it did have ten DATA lines of a machine language digital playback routine (POKED into memory), so it did not use the PLAY command like here. But it was cool at the time, letting you record from Datasette, playback, and save and load to disk samples.
Excellent, thanks for finding that. So many people have mentioned this little program, and I remember it too, so I think I should do an episode on it.
@@8_Bit Here's the link: archive.org/details/1988-12-computegazette/page/n93
I wouldn't be surprised if other magazines had other versions of this, but that's the one I used, and I had a C128, so I typed in the C128 version, which was able to record a little bit more of the sample.
Thanks for that find - would be interesting to list the machine code in assembly to see how the digitization from tape is done, since it's not explained in the article.
That is 1 bit sampling.
Digis are 4 bit.
I have use bit-banging in all my BASIC and C games. In BASIC I simply use the VOL command. It works under Vice but you need to configure the right SID version.
does VICE not simulate the click when you change SID master volume? Seems like a big oversight.
I think the cause of the difference was my C128 has the older 6581 SID in it, while VICE defaults to the newer 8580 when emulating the C128. The 6581 clicks loudly, while on the 8580 it's almost inaudible. Pretty sure VICE does emulate the clicking when set to 6581.
I wonder if the sample rate could be increased by using ML for playback instead of tokenized BASIC.
With a core loop like « - lda (data),y : sta sid_volume : iny : bne - », you could play up to 73,000 samples/sec. You would need to add code to slow this down.
9:19 You can calculate the sample rate from the number of samples played, 100*254 = 25,400, and the time, 4.47 seconds. Your video only included 2.05 seconds of play time plus an extraneous "Hooo-ooo!", but VICE gives me 4.47 seconds using the TI variable. This gives 5,682 samples per second (2,841 max Hz sound). You could also get a little more consistent performance by disabling IRQs.
11:51 Why couldn't they use a round number like 44 kHz instead of 44.1 kHz? Or just 40 kHz given that almost nobody can hear the full 20 kHz sound.
12:52 A system of ten symbols contains log2(10) ≈ 3.322 bits of information per symbol. Using densely-packed BCD comes close to this, stuffing 1000 symbols into 10 bits of space ≈ 3.333 bits per decimal digit. The "Robin Math" system still uses four bits per decimal digit.
14:08 I guess the C128 fixed the ASC("") bug. I seem to recall the VIC-20 returning an empty string for a GET# that reads in a CHR$(0), and subsequent code blowing up when attempting to do an ASC() on that string. The C64 may have this problem.
14:30 The optimal divisor would be 25.5000001, to divide the sample space evenly into 10 "buckets". It would also be more efficient to multiply by the reciprocal of the divisor, since multiplication is faster than division on old hardware and new.
14:38 Appending to the string is going to slow down as the string gets longer, since the long content needs to be copied around. It would be faster to build up shorter strings and flush those to the long string.
15:57 Changing «FOR C=0 TO B» to «FOR C=.TOB» won't make the playback any faster since this is parsed before the playback begins.
16:09 On the C64, you could try Jason's POKE 648:PRINT trick from your "Even More Commodore 64 BASIC Optimizations" video, th-cam.com/video/J9QH-tUJB2s/w-d-xo.html . He reported 1800 samples/second.
16:43 It's a bug in the documentation!
Your post got flagged as spam again - for the sin of linking to one of my videos, apparently :)
Thanks re: sample calculation. Were you running VICE in PAL or NTSC mode? 5682 Hz seems a little lower than I expect, but I should give it another try. I thought of disabling IRQs after I finished recording, but still haven't looked up how to do it on the C128 from BASIC. Maybe it's just that POKE I did in the other video to allow switching between colour RAM banks?
Yeah, "Robin Math" is dumb.
And yes, C128 ASC("") returns 0, while on the VIC-20 and C64 it returns an ?ILLEGAL QUANTITY ERROR
Thanks as always for all the great feedback!
@@8_Bit: You'd think TH-cam would be okay with links to TH-cam's own site. Your playback of the digis sounded a little slowed down, which is an effect that would be produced by creating them for 6026 samples/sec and then playing them at 5682 samples/sec. I ran this in VICE configured for NTSC.
@@8_Bit: The character-base I/O would be a real Achilles heel to running this. When producing the sample data, instead of outputting RAW samples, you could map them to characters 0-9 and put 255 of them on a line, separated by carriage returns, and use INPUT# in the playback program. I.e., set up the strings in the disk file. This would optimize for a write-once, read-many environment.
The 44.1 kHz originates from Sony's U-matic studio videorecorder which was used to record 3 digital audio samples per video raster line. It had to be compatible with both the PAL and the NTSC standard, hence the strange frequency.
regarding the 44,1kHz, I might have the coolest answer ever.
the number 44100 is dividable by 50 and by 60. that makes it suitable to use it perfect for video with 60hz ntsc and 50Hz pal.
i calculated again and found a new discovery: the studio sample frequency of 48000Hz is dividable by 24 (film), 50 (pal) and 60 (ntsc)!
Great video!
Like hearing old wax discs!
Try the sequence (0x0, 0x1, 0x3, 0xc, 0xe, 0xf, 0xe, 0xc, 0x3, 0x1, 0x0), and feed those values to the SID chip via 6502 assembler (rather than going through the BASIC interpreter). This sequence is a (rough) approximation of a sine wave (one cycle’s worth.) Or - in BASIC - use the sequence 1,2,7,8,9,8,7,2,1,0 and repeat 25x in A$, then play a$. Of course, this will be a lower pitch (frequency) than the square wave generated by the repeating 9,0 sequence, but that’s to be expected, since my sequence is 5x as long, so the frequency should be roughly 5x lower. 😎
Great videos. Keep it up!👍
Had a demo disk back in the day. Called master mix it contained digis from song kungfu fighting and something else. Forget now.
That is freakin amazing!!
You will get better intelligibility of your "digi's" if you either sample at half the playback speed (in this case 1.5 Khz) and then upconvert the sample to 3 Khz, or sample at 3 Khz with a lowpass filter on the input set at 1.5 Khz. Either way the ratio you need is sample rate ( or sample lowpass filter frequency) = playback rate / 2. Doubling the playback rate for a sample rate as you did effectively quartered the effective playback frequency and doubled the aliasing.
Also a better test would be to set up 2 strings like
A$="9999999988888888777777776666666666666666777777778888888899999999"
B$="0000000000000000000000000000000000000000000000000000000000000000"
then playback a$ followed by b$ over and over, record it, and in your sample editing program look for a single cycle edge where the zeros convert back to 9's and trim anything before that point and then look for where the 9's convert to zeros and trim anything after that point. Now you have a single 16 bit cycle in your editor you can copy paste to complete the waveform and then measure the frequency to find the what the commodore is capable of outputting from a captured wavesample. Use that as your playback frequency for calculating the the sample rate.
sorry that should have read "Doubling the sample rate of the playback rate as you did..."
Hi! Thanks for the info. I think the effective playback speed in FAST mode is maybe 5900 Hz; I initially calculated it at 6026 Hz but I must have made an error as everything was pitched a bit low. So I down-sampled to what I thought was half the playback speed, 3013 Hz, and on at least a couple of the examples I did run a low-pass filter at 3000 Hz first but didn't show that in the brief Audacity clips I showed. Just clarifying that in case I wasn't clear in the video. Thanks for the info on how to better measure the speed, if I revisit this I'll try it!
Is there on 128d a FREE prg that load very fast samples with turbo routine and "EDIT" them (listen, see time-graph and some options to modify as well as a mini-mini-audacity)??!! Maybe in Geos??!!
Must BE FREE and FAST so i think there isn't!
Well done sir.
"I just should have looked at the disassembly"
I just learned again that all the books in the world are no alternative for this.. The code is the real documentation of how things work.. :-)
(this after wondering why some ancient program from a magazine din't work properly, and my own independent version of the same idea failed in the exactly same way).
So what was the issue?
I was loading a C64 program in 128 mode (starting the load at $1801) and after the load finishes, switch to 64 mode, move the code down to $0801, set the start of variables pointer properly, and try to run the program.
That works fine for smallish things, but.. it turned out the byte at $9004 did not have the original content. The address (originally $a004 before moving the program back to $0801) should have triggered some alarm bells..
What was at that address did look familiar ($55) as something likely put there by a ram test... this should have triggered more alarm bells..
But I did determine quickly this happened during c64 boot.. and tracing the boot process did make me end up at the ramtas code, unsurprisingly.
So... that code is nice at first glance. It reads a byte from ram, stores it so the original ram content can be resored later.. tests if it can write the address (in 2 ways) and if it can, and the data it gets back matches what it wrote, it will restore the original content.
So far so good.
Where it goes wrong is when it runs into rom. At that point, it will conclude it isn't reading back what it wrote, and doesn't try to restore the original content. Of course, due to how it reads the original content, it would try to restore a byte from rom anyway, so it would still fail even if it did.
But.. that also means a reset (without skipping the ram test) will always corrupt a byte of ram at $a004, and not just overwrite data below $0802. A good thing to know, its entirely logical it happens, but.. it did take a more carefull read of the actual rom code to spot why it was happening.
I did fix my code to work around it, and can now load any c64 program (which ends before $d000) in 128 mode, and start it in 64 mode.. which has some uses as those who use my C128 device manager will soon find out :-)
lovely!
brilliant!
Seriously, you need Jiffy DOS
Yes, I've got it on some of my computers, but not this one!
well done
Neat!
Awesome episode, great explanation! I made a small program that does the conversion based on measured loudness levels for the 10 volume settings and added a menu system allowing to save and load converted Digis. We also linked to your episode, the program is here: csdb.dk/release/?id=192738
Nice, thanks for the link! The reason I called it a hack was because the official documentation (such as the C128 Programmer's Reference Guide page 55, at least, my English North American edition) for the PLAY command says the volume change command requires both a "U" in front of the number, and then some documentation says it should be followed by a number 0 through 15, and other documentation says 0 through 8. So while the PLAY command may be working as designed by the programmers, when it's such a complete mismatch with the official documentation, it seems that there's a bug or a hack work-around somewhere!
Haha that's awesome!
Man, I know those samples have to be small, but most of them sound pretty awful. :/
The C128 can play much higher-quality samples using machine language. These examples are played 100% in BASIC which I previously thought was impossible. Even if they don't sound all that great, I'm amazed they work at all.
@@8_Bit Ah ok. Very cool!
when you use that basic commands you have a lot of jitter coming with it too, some from interrupts, some maybe from an inconsistent bus access (bad lines)
Nah, you guys and your "modern" (!) C64 samples. Try the "Kung Fu Fighting" sample from '86 :)
Seemed like hours of load time (especially on cassette!) and all for 20 seconds...
I've found a version of Kung Fu Fighting
csdb.dk/release/?id=56430
16:52 LOL =P
Hey I am not middle aged!
I said "If..." :)
cool!
your pic tho
Commodore BASIC is hideous. Even for its time.
That could be good wake up ringtone 9:19 or SMS...
I guess that it isn't the fact that they want you not to know, it is the fact that the sound quality is so bad. Better not speak about it. Softly softly catch a monkey.
Cool!