Inspired by this article (German), I decided to build a kitchen radio from my old cell phone and some car speaker last year. Here’s how it turned out, combined with an instruction.
I fell in love with synthesized bass sounds when listening for the first time to Joan as Police Woman’s performance of Holy Fire on Later:
After that I enthusiasticly tried to recreate this sound with the awesome Moog emulator Monark by Native Instruments.
Monark comes already with some quite good presets. Here you can download the one I have created to come as close to Joan’s bass sound as possible. It’s based on the preset “Humble Bee” but with tiny adjustments:
Currently, I’m doing some XML manipulation and transformation in the web browser. I have encountered some obstacles, tips and thoughts that I want to share with you.
I bought a record at HDtracks to see if it has any benefits in contrast to CD-like audio files at a sample rate of 44,1 kHz and a bit depth of 16. I want to share my findings with you.
I LOVE Web Audio. It’s one of the most fun things in the browser right now. But doing more and more stuff with it, I came to realize that there are three limits that prevent this technology from making traditional pro audio software obsolete, at least at the moment:
When I open a big session in Samplitude, it likely uses up to 2 GB of memory. Chrome on the other hand, allows about 200 MB memory per web page. If your script tries to allocate more, the site crashes. That’s a good thing. Older machines and mobile devices have their hardware limits and you don’t want to push them too hard. But if you deal with AudioBuffers with high sampling rates like 192 kHz, like pro users do, you may reach this limit very quickly, if the browser even supports such high sampling rates. I did reach the limit several times. Implementations have to support rates for an OfflineAudioContext “only” up to 96 kHz.
A browser is a browser. It’s a very universal piece of software you can do all sorts of things with. Since browsers are not dedicated pieces of software built for audio synthesizing/manipulation, they usually use your system’s standard audio driver. In Windows this is WASAPI (Windows Audio Session API). WASAPI (Shared Mode) isn’t suitable for pro audio applications, as it introduces round-trip latencies well over 20 ms. With Windows 10, this has gotten better. But it still cannot compete with drivers dedicated to real-time audio processing, like ASIO. In the best case, ASIO allows for latencies of about 2 ms. This could be less than the time a sound needs to travel from a speaker to your ear through the air.
People (like me) once proposed that Chrome would implement ASIO support. But let’s be realistic: That is unlikely to happen.
I made another little tool after CAAT, the WAV Builder. This time it’s not about testing filter algorithms, but synthesizing waveforms which are then rendered and saved as a WAV file. It helps me sometimes to test stuff. If it should help you too, that’s great!
WAV Builder uses the great Recorder.js.
CAAT, the custom audio algorithm tester is a page that let’s you try out your own simple audio filter algorithms.
Just (mis)use the textarea for coding and listen to what you get. There are some examples on how you would do basic things.
It helps me sometimes, when I just want to check something out very quickly.
Of course, this is a very unperformant way to implement audio filter algorithms for several reasons. This is just a demo. If you’re interested in how to implement algorithms the right way, I recommend using Web Audio API’s Audio Worklets or the talk “C++ in the Audio Industry” by Timur Doumler.
I hate squashed and over-compressed music. It leads to ear-fatigue quickly, is often distorted and sounds dull and low-fi compared to dynamic music. And although the Loudness War apparently is over, there’s still the need for proper loudness metering, so that people don’t fall into the trap of making their music too loud and destroy the liveliness of their precious recordings.
A few years ago, the European Broadcasting Union (EBU) has released a recommendation on how to measure loudness and how to distribute audio material with the right loudness. After that, some metering plugins for DAWs popped up but I haven’t seen anything like that for the web.
That’s why I created something called LoudEv, an open-source online loudness evaluator, which is compliant to EBU R128.
LoudEv uses the Web Audio API, Web Workers and the great wavesurfer.js by katspaugh to do its thing: Analyzing an audio file (on the client-side, no server upload necessary) and then creating a two-dimensional loudness map of the song as well as a dynamics map. The loudness map shows the song’s short-term loudness over time. The dynamics map shows the peak to short-term loudness and indicates if and what sections of a song are too loud. If it gets red-ish, the dynamic range is at or below 8 LU. If it’s black, you can hardly call that music anymore. If most sections of your song are green-ish, you’re on the safe side. This color scheme derives from the recommendations of mastering engineer Ian Shepherd. According to him, your masters should never become louder than 10 LUFS to prevent a potention loss of punch, impact and space in your mix. You should listen to him, he knows what he says and his masters sound great.
The technical side
To obtain the subjective loudness of a piece, the EBU reccomendation demands of R128-compliant meters to apply some filters (a lowpass and a shelving filter) to the signal. These filters are described in the ITU loudness standard document. But unfortunately, the document does not provide frequency, Q or gain values for these filters. Instead it gives us filter coefficients for a biquad filter that only works with audio of a sampling rate of 48 kHz.
Having obtained a 48 kHz version of my audio, I decided to implement the biquad filter function myself, after learning that, as of today, the creation of custom IIR filters with the Web Audio API hasn’t been implemented in Chrome yet.
Due to my initial lack of knowledge in implementing biquad filters myself, I had a tough time of it with the biquad filter equation, but then the great Audio EQ cookbook by Robert Bristow-Johnson came to the rescue and showed my code that I could use:
y[n] = (b0/a0)*x[n] + (b1/a0)*x[n-1] + (b2/a0)*x[n-2] - (a1/a0)*y[n-1] - (a2/a0)*y[n-2]
So finally, I had my R128-compliant values for the short-term loudness.
Measuring True Peak
After that, I tried to implement a true-peak meter which considers inter-sample peaks. The recommendation suggests the following way to do this: Resample (upsample/zero-stuff + interpolate) the signal to 192 kHz and then seek for the sample with the absolute maximum (see Annex 2 of the ITU document).
Even if it would work, I had to learn that by creating an OfflineAudioContext and an AudioBuffer of 192kHz often results in a crash.
Chrome allows for a memory limit of about 200 MB per web page. This limit is reached very quickly when you deal with 192kHz audio.
Next, I will try the filter suggested by the ITU document. It provides filter coefficients for a FIR interpolation of an upsampled (zero-stuffed) signal. Russel McClellan at iZotope has written an insightful assessment of this filter.
That is the end of the first chapter of bringing R128 onto the web. There’s a lot going on with the Web Audio spec at the moment so I expect to be able to do things soon that I cannot do now.
Let me know, if you know things that I don’t know or if you wish to contribute. The source code of LoudEv is on GitHub.
Try it out here and let me know what you think:
Please be aware, that it only works with mono/stereo files and audio file types that are supported by your browser. Both Chrome and Firefox accept MP3, for example.
Plex was my first baby. It was one of my first attempts to do something webby-appy that is more than a static HTML page or a site underlaid by some CMS that does all the tricks for you.
It was developed by the time that the first early Web Audio implementations shipped with Chrome.
The UI is a mess, as is the code, some stuff doesn’t work anymore. Maybe I’ll find the time to fix the broken stuff, but don’t expect anything but a relict toy.
But hey, maybe in 10 years or so this is a classic like http://www.warnerbros.com/archive/spacejam/movie/jam.htm is today.
PS: Use JSHint.
Hi there! So from now on, I’ll be here. This blog is called WebAudioTech because it will be about the web, audio, web audio, technology, audio technology and web audio technology. Doesn’t that make perfect sense?
These are topics that I have cared about quite a while now. My purpose is to give you, dear reader, insightful and interesting information and to record my thoughts and ideas. Drop me a line in the comments if you like, or get in touch with me via Twitter.