The conversion of a raw audio signal into a digital representation is known as quanitization. The continuous, real-world audio signal, representable as a smooth waveform with positive and negative pressure levels, is recorded in a series of snapshots known as "samples". Each sample is, like a frame of video, a picture of the signal at that moment. Specifically, it is a picture of its amplitude. That, in the end, is all the recording system cares about: "what is the amplitude?". The succession of these amplitude measurements ("samples", shown below as dotted lines) results in a digital approximation of the original audio signal. The frequencies and notes we hear are the result of these changing amplitudes over time.
For every digital sample, our analog to digital converter asks "what is the amplitude?". The question that remains is, how is this amplitude represented? The answer is "bit depth" which determines both how many different amplitude levels/steps are possible and what the overall capacity of the system is...how loud of a signal it can tolerate.
For CD-quality sound, 16 bits are used. This means we will have 2^16 ("two to the 16th power") different amplitude values available to us, or 65,536 steps. Since the number of steps is divided between positive and negative values (our crests and troughs from before) this means it is divided into 32,767 positive (plus zero) and 32,768 negative values. For each sample taken, the actual amplitude must be "rounded" to the nearest available level...producing another "error" relative to the original audio signal. The signal is "quantized". This "quantization error" produces as small amount of "quantization noise", noise inherent to digital recording. A digital system is totally noise-less on its own, but as soon as it is recording a signal, it makes these errors and ends up with this small amount of noise.
The amount of inherent noise versus the system's capacity for the desired signal is called the signal-to-noise ratio, a concept I will illustrate in the next installment. The signal-to-noise determines both how loud and how soft a signal can be cleanly recorded. It determines the recording's "dynamic range".
The overall amplitude capacity of an digital system can be theoretically approximated as 6 decibels per bit. For our 16-bit CD-quality signal, this means our system can tolerate 96 dB.
So, is 16-bits enough? The threshold of hearing or the threshold of pain varies among individuals, but is often cited as 120 or 130 dB. So it may be that--unlike the CD-quality sampling rate and its accommodation for the range of human hearing--our 16-bit system is not enough. If one is not careful when recording, a signal can easily exceed the maximum amplitude, producing "clipping". In clipping, the waveform hits its amplitude ceiling resulting is a cropped waveform.
The changing peaks above the maximum amplitude end up flattened. The naturally fluctuation amplitude levels are just chopped off and the resulting sound is jarring and distorted. Increasing the bit depth will provide more amplitude "headroom" for these louder signals. 24 bits, for example provide 2^24 (over 16 million!) amplitude steps and 144 dB of theoretical overall capacity (24 x 6 dB). So, a higher bit depth has a higher tolerance for ampltude, up to and beyond our "threshold of pain".
As an added benefit, this higher bit depth also results in less inherent noise (!!). Our signal-to-noise, therefore gets a two-fold benefit: more capacity for our signal and less inherent noise.
The long and short of this is, if you have a higher- bit depth system available to you, absolutely use it. Of the two possible changes one can make to a digital conversion system, sampling rate and bit depth, the increase in bit depth will have the most profound impact on audio quality. You will also help increase the signal-to-noise ratio, avoid clipping, as the system can tolerate higher amplitudes before going over.
I wanted to follow-up on today's lecture on analog to digital conversion. My hope is both to clarify and provide a resource for further review. See below and please be in touch with me or with one of your TA's if you have any questions.
NOTE: In an effort to solve the confusion and technical problems accessing the Network Drive to hand in finished assignments, please see this brief post or check the UPDATED site FAQ on handing in assignments.
The goal of this assignment is to explore the editing/looping/slicing tools showcased in our lab session, aiming toward a "mashup" or remix of existing musical materials as we did with "The Jackson Six". Where tempo or musical key matching is a consideration, please use the techniques we discussed and practiced in class.
Be creative, experiemental, and TRY SOMETHING NEW. I am inviting you to play, to stretch out, and to use some very powerful tools in the Live editor.
The result should be a stereo recording of a "performed" piece, exported as a WAV or AIFF audio file. Map the clips and/or "scences" in Live via MIDI and/or the text keyboard to create a live performance, recorded, as we have done several times now, into the arrangment view. You may find "scenes" useful as a way of moving through a musical form (into, verse, chorus, etc). The result should be a short (1-2 minute) piece exported to WAV or AIFF format.
Please give me:
1. The Live project itself (it will be a Live folder with several subfolders and a .als "song" file)
---> I recommend using "Collect All and Save..." in the file menu to make sure all samples are copied/collected into this same root folder. Note: This is also a way to make Live projects portable between several computers.
2. The stereo WAV or AIFF audio file
The naming convention should also be retained:
If you plan to sample sources from video (online or otherwise), I recommend MPEGStreamclip (Beta version is recommmended) as a way to separate audio from video.
Finally, this assignment may freely include "commercial sources" as it is educational and will only be shared with me for the purposes of this assignment. You are not doing anything that has not been done for time immemorial, except you are doing it digitally!
Using Score11 example "granflute" as a base, create your own granular "clouds". You may wish to use your own sounds, documentation for mksffuncs (for creating Csound functional tables) is available here. For those needing a more general reminder, documentation for Score11 including the original "quick start" guide I handed out in class is here.
Chapters from Curtis Roads' book Microsound (e-cornell publication)
1. Time Scales of Music
3. Granular Synthesis
7. Microsound in Composition (optional, discussion of pieces using granular)
8. Aesthetics of Composing with Microsound (optional, good breadth)
Listening (see listening list for CD numbers):
Kontakte (with piano and percussion) - Karlheinz Stockhausen
Concrete PH - Iannis Xenakis
Vox 5 - Trevor Wishart
Idle Chatter; More Idle Chatter; Still More Idle Chatter; etc - Paul Lansky
timfeeney_homework.wav in /sflib/listening (psfl timfeeney_homework.wav)
MKSFFUNCS usage summary
mksffuncs – A script that creates Csound gen1 function definitions for soundfiles in a format suitable for inclusion in SCORE11 input files.
mksffuncs [-flag(s)] infile1 [infile2] [infileN] [> outputfile]
where valid flag options are
-f : the following argument(s) are ascii files containing
lists of soundfiles, rather than the names of soundfiles
-s : before creating the functions, sort the soundfiles by
pitch abbreviation (lowest to highest pitched, then unpitched)
-N : (must be in CAPS) the next argument gives the number for the first
(lowest numbered) function definition
Multiple flag option can be given one at a time or concatenated. Soundfile arguments are the names of soundfiles in your current working soundfile directory or in any of the 44.1 k or 96 k sflib directories.
To include soundfiles from one of your soundfile subdirectories, include the subdirectory name or the full path name.
(1) mksffuncs irishwhist.short.a4.wav fl.c4.wav
Result: Function definitions are created for the 44.1k sflib soundfiles wind/irishwhist.short.a4.wav and wind/fl.c4.wav:
* f1 0 262144 -1 "irishwhist.short.a4.wav" 0 0 0 ; < 3.473 sec
* f2 0 262144 -1 "fl.c4.wav" 0 0 0 ; < 3.473 sec
(2) mksffuncs -N 20 irishwhist.short.a4.wav fl.c4.wav
Result: same as above, but function numbers begin with f20 rather than f1
* f20 0 262144 -1 "irishwhist.short.a4.wav" 0 0 0 ; < 3.473 sec
* f21 0 262144 -1 "fl.c4.wav" 0 0 0 ; < 3.473 sec
(3) mksffuncs -fs playlist1 playlist2
(or mksffuncs -s -f playlist1 playlist2)
Result: Functions are made for the soundfiles listed in ascii files "playlist1" and "playlist2" and are sorted from lowest to highest pitched."
As an initial foray into Unix, please get comfortable with the contents of the CEMC soundfile library. To list the directories in sflib, run the command:
(list soundfile library)
The command "lsfl choir" will list the soundfiles in the library directory "choir". To play any file you find in the libary, simply type:
So, to play the file "stockhausen_gesang.wav" (this is the file we listened to in class together, you are welcome to listen again), simply do:
The command psfl will search the soundfile library and find the file on it's own.
To search for files in the library by name (character string), use findsflib, for example to search for all of the sounds with the pitch C4, do:
The findsflib command will allow you to play the soundfiles as they are found by adding the flag "-p" to the command.
findsflib -p drum
Remember that Ctl-C (Control - C) will stop any command in process, useful if you don't want to wait for sflib to find further sounds in the library.
READINGS AND LISTENING
Please read the following essays. You may also wish to research concepts of musique concrète, computer music, and electronishe musik as it was understood on the early 1950's.
Karlheinz Stockhausen's Gesang der Jünglinge
To listen to Gesang in the studio (quad version), use the psfl command shown above:
Pierre Schaeffer's Etude aux Chemins de Fer (Railroad study)
This assignment has two parts, one audio and one video using PureData and Gem. Each part comes with its own incremental tutorial (explained below), a set of patches that build piece by piece toward a larger concept. The goal is to accumulate a set of basic skills and then from them, extrapolate to build something more interesting. Each resulting patch should not take you much time to make, the key is to grok the concepts relayed in the tutorial in order apply it your work.
Part I: Audio
Download "PD_Tutorial.zip" above and uncompress it into a folder. This folder contains a series of numbered patches, each incremental, building upon one another toward a larger idea.
Here we are building a bank of bandpass filters, similar to the example from class. Patch #1 begins with one filter on a white noise signal [noise~]. Patch #2 uses 3 filters with difference center frequencies (sounding like a chord). Patch #3 adds control to the center frequencies via send/receive pairs, thus allowing for 3 different "chords" (you might wish to try creating more than this). Patch #4 adds the idea of "movement". The new chord frequencies are not sent directly to [bp~]'s center frequency. Instead they go a set of [line] (linear ramp) objects. The center frequency therefore "moves" from one tone to the next (in this case over 5000 milliseconds, 5 seconds). Note too that this last patch has amplitude/volume control for each [bp~] group (!)...simply an audio multiplier [*~].
Assignment: Build a patch that has half-a-dozen bandpass filters on a white noise signal. You may wish to use subpatches [pd name] to accomplish this task and keep everything neat and organized. Use the same [line] automation method to move amplitudes or each filter (you will use the audio multiplier [*~] object).
Part II: Video
Download "Gem_Tutorial.zip" above and uncompress it into a folder. This folder contains a series of numbered patches, each incremental, building upon one another toward a larger idea.
MAKE SURE TO CLOSE ONE PATCH BEFORE OPENING ANOTHER SINCE ALL PATCHES WRITE TO THE SAME GEM WINDOW AND WILL OVERLAP ONE ANOTHER!
Here we will be building a video mixer (!!). Patch #1 simply shows the use of [gemhead] to draw a square. You have to create the Gem window first, click [create ( in the upper-left to so this. Note that all cumulative additions to our video mixer patch will happen between [gemhead] and [square]. Patch #2 shows our first "drawing" on the square, chaning its color. Patch #3 shows a second manipulation, this time an object to rotate the square [rotateXYZ]. Patch #4 is the same thing but with a second square. Note the use of a second [gemhead]. Patch #5 shows shows how to add images into a shape...use one of the included Da Vinci "Last Supper" images as examples. Patch #6 shows how to "mix" multiple images onto one single shape. This time try using "da_vinci-norm" and "da_vinci_flipped" as the two images. Move the image "crossfader" and you should see the two images mixed. Patch #7 finally shows how to draw a movie/film onto a shape...essentially it is not different than an image.
Assignment: Create a patch that mixes two videos (or, using the included video clip, mixes one video with itself, perhaps with delay starts). You will simply be combining Patch #6's mechanism for mixing images [pix_image] with Patch #7's mechanism for loading video. In other words, [pix_mix] doesn't care if it gets images or video.
Below are patches, examples, and sound/video created using PD. This list will grow over time as there is a nearly constant accumulation of material available online.
Patches and examples from puredata.info (various artists, various types both audio and video)
Music made with PD from puredata.info (various artists)
FLOSS Manual audio tutorials (various topics, primarily analog synthesizer concepts)
Music making tutorials: http://www.obiwannabe.co.uk/html/music/musictuts.html