Music is, fundamentally, a set of variations in air pressure that our ears are able to interpret in a meaningful way. Making music means creating those air pressure variations from scratch. Reproducing music means using a representation of these air pressure variations to create as close a facsimile as possible. For that to work we need a means to store that representation. Analog systems exist to store them as variations in the magnetic field on a tape, or as variations in the depths of a groove spiralling round a disc or a cylinder. These systems work, but there are limitations imposed by the physical properties of the tapes, discs, and cylinders, which dictate just how much information can be stored on them. Digital systems can store the same information as a set of numbers, and, as with analog systems, there are limitations imposed upon digital systems, this time by mathematics rather than by any fundamental physical properties of the digital storage medium.
The idea behind a digital representation of an analog waveform is that you measure the analog waveform on a periodic basis and store the resulting numbers. It has to be a periodic basis, because when it comes time to re-create the original waveform, you have to know the exact time when the measurement was made as well as the exact value that was measured. You could choose to store the time value as an additional data point of its own, but that would make for an extremely complicated system. Instead, we adopt the convention that the measurements are made on an exact regular basis, a certain specific number of times per second. This is what we call the sample rate, and we call this method of digital representation PCM (Pulse Code Modulation). The sample rate turns out to have a major impact on how the PCM resultant recording will sound.
Music is generally held to occupy the frequencies between 20Hz and 20kHz. Very few people can hear frequencies as high as 20kHz, and for pretty well all of us, this upper limit of hearing falls progressively as we age. But, in general we hold to the idea that to record music faithfully, we need to record all frequencies from 20Hz to 20kHz. How does this impact the choice of sample rate for a PCM system? The main consideration here is the well-known Nyquist-Shannon sampling theory, which tells us that in order to make a digital representation of an analog signal of a certain frequency, it is necessary that the sampling rate is at least double that frequency. It should be noted that this is not an approximation. It is a mathematical fact. We call the frequency which is one-half of the sample rate the Nyquist Frequency. Nyquist-Shannon theory informs us that a PCM system can capture only those frequencies which lie below the Nyquist Frequency.
If music occupies a frequency range which tops out at 20kHz, then in order to represent it faithfully in a digital system Nyquist-Shannon says that we need to sample it at a sample rate no lower than 40kHz. If that was all there was to it, life would be simple. But Nyquist-Shannon theory tells some other things too. What happens if we try to encode a frequency that is above the Nyquist Frequency? The answer is that it gets encoded very well. But, unfortunately the result is indistinguishable from what you would get if you instead recorded a certain frequency below the Nyquist Frequency. If the Nyquist Frequency was 20kHz, then a 21kHz signal would be encoded exactly the same as a 19kHz signal; a 22kHz signal would be the same as a 18kHz signal; a 23kHz signal would be the same as a 17kHz signal; and so on. This effect is called Aliasing (or Mirroring). All information existing in the recording above the Nyquist Frequency would be Aliased (or Mirrored) to a corresponding frequency below it. Such effects are - surprise! - destructive to the sound quality.
The solution to this problem is to pass the analog signal through a low-pass filter whose function is to filter out all the high frequencies. This is not as simple as it sounds. In theory you would want a filter that massively attenuates everything above 20kHz and nothing below it. This type of filter is called a brick-wall filter, for obvious reasons. The problem is that a real-world brick-wall filter makes the transition from flat to attenuating over a range of frequencies that you might think of as a no-man’s land. Within the no-man’s land the attenuation of the filter is not high enough to prevent aliasing, and not low enough to avoid audibly affecting the music signal. Therefore the no-man’s land must occupy a range of frequencies above the maximum frequency of the music content, but below the Nyquist Frequency. For this reason, the Nyquist Frequency should always be higher than the maximum signal frequency.
It turns out that, making this no-man’s land as small as it can practically be is a question of how we design the brick-wall filter, something I will come back to in a moment. Anyway, applying this kind of thinking to the case in point, we end up moving the Nyquist frequency up a bit from 20kHz to 22.05kHz. Recall that the sample rate is twice the Nyquist Frequency. That puts the sample rate at a familiar number - 44,100 samples per second. This is the thinking that gave birth to the CD format.
At this point we are still not quite finished with Aliasing. Recall that signals above the Nyquist Frequency that are encoded into the data stream cannot be distinguished from their Aliased counterparts below the Nyquist Frequency. The same is true in reverse during playback. For every frequency the DAC generates below the Nyquist Frequency, it also generates a companion at its Alias frequency. All those aliases are above the Nyquist Frequency, and we need to filter those out during playback. This requires another brick wall filter similar to the one we implemented for the recording process.
Summarizing the above, then, all we need is a sample rate a little bit above twice the maximum frequency we want to record, plus a brick-wall filter, and we’re good to go. Whoa boy! Not so fast…
There were two assumptions that we made along the way, one overtly, and one covertly by accepting something blindly without questioning it. The first assumption was that it is acceptable to restrict the frequency content to 20kHz because nobody can hear anything above that. It turns out this is not quite correct, depending on how pedantic you want to be about defining the word “hear”. Hot off the press, the latest research has thrown up an interesting result. Working with subjects who have taken a conventional listening test, and who are clearly unable to discern any audio above 20kHz, scientists have wired their brains up to the latest in scientific instruments, and have shown that their brains do in fact react quite unambiguously to the presence of audio signals at frequencies significantly above 20kHz, which the subjects themselves appear to be blissfully unaware of. This is ongoing research, so it is too early to draw conclusions as to what this means, but maybe it points to a rationale for extending the bandwidth of our recordings up from 20kHz. But how far? 30kHz? 50kHz? We don’t have any answers yet.
The second assumption is less esoteric. We dismissed the brick wall filters as just another circuit element that we could add at our whim. We declined to consider what - if anything - their audible contribution might be. This was not wise. With 16-bit audio, this filter’s job is to be flat up to 20kHz, and thereafter to roll off rapidly to the point where it is 96dB down by the time it reaches 22.05kHz. That is one monster mother of a filter, and typically would involve a huge component count including capacitors, inductors, and in many cases op amps, all of which are the sorts of components high-end audio circuit designers go to fantastic lengths to eliminate from their signal paths. Even with the best conceivable design in the world, where the filter’s frequency response is nice and flat, and its phase response is nice and linear, and it still meets its attenuation requirements, such filters are going to have an audible impact on the signal passing through them. And you have one of them at each of the A-to-D and D-to-A ends of the digital audio chain. There is an argument to be made that the sound of CD is not so much the sound of 16-bits and 44.1kHz, as much as the sound of an analog brick-wall filter.
So how do different sample rates help here? I will discuss this tomorrow in Part II.
Saturday, 2 November 2013
Friday, 1 November 2013
The Sum Of All Fears - III. Jitter as an Analog Phenomenon
In the last two posts I have introduced jitter as a digital phenomenon,
explained what it is, what it does, how we can measure it, and
discussed whether or not we can hear it. All this was started off by
the observation that different "Bit Perfect" audio players can sound
different, even though all they are doing is using the same hardware
to send the same precise data to the same DAC. We postulated that, in
the absence of anything else, the only possible mechanism to account for
those difficulties had to be jitter. So we took a long hard look at
jitter to see if it fit the bill. And maybe it does, but we didn't
exactly explain how software can affect jitter. Before doing so, we are
going to take a fresh look at jitter, this time from an analog
perspective.
You see, although it is easy to think of digital data in binary terms (it's either a one or it's a zero), that we process at some specific instant in time (defined to the picosecond so we can account for "jitter") - in reality it is never quite so simple as that. Let's look at a simple circuit, designed to take a digital input and, at a point in time defined by a clock signal, output a certain analog voltage. For the purposes of understanding the operation of jitter, there are two things happening. First of all, the circuit is monitoring the voltage which represents the tick-tock of the clock signal, in order to determine when it is ticking and when it is tocking. And secondly, once the clock is triggered, the output circuitry is applying the desired voltage to the output.
We'll start with the tick-tock of the clock. A clock signal is typically a square-wave waveform. It oscillates sharply between fully "on" (a high voltage) and fully "off" (a low voltage), and it does so very abruptly. Our circuit measures a "tick" when it detects the signal transitioning from low to high, and a "tock" when it detects a transition from high to low. Tick is generally the point at which the clock signal triggers an event, and the function of Tock is generally to mark the point at which the circuit starts looking again for the next Tick. Digital electronics are very easy for the layman to comprehend at a functional level, because the concepts are very easy to visualize. We can easily imagine a square-wave clock signal, and the nice, clean, rising and falling edges of the Tick and the Tock. At some point most of us have seen nice, helpful diagrams. What's the problem?
A real-world clock signal has some real-world problems to deal with. First of all, we need to look at those high and low voltages that we are measuring. If we look closely enough, we will see that there is usually a lot of high-frequency noise on them. They are not the nice clean square waves we expected them to be. The impact of all this noise is that it gets harder to guarantee that we can distinguish the "high" voltage from the "low". It is no use getting it right 99 times out of 100. We need to get it right a million times out of a million. The higher the speed of the clock, the worse this gets. But it is quite easy to fix. If the problem is caused by high frequency noise, all we need to do is to filter it out using a Low-Pass Filter. Let’s do that.
Now two things have happened. First, the trace has indeed thinned out, and we can accurately determine whether the clock voltage is "high" or "low". But now we see that the transitions between high and low now occur at a more leisurely pace. The exact point of the transition is no longer so clear. There is some uncertainty as to precisely when the "Tick" actually occurs. Because of this filtering, there is a trade-off to be had between being able to detect IF a transition has occurred, and exactly WHEN it occurred. If our Low-Pass Filter rolls over at a frequency just above the clock frequency, we do a great job of filtering the noise but it gets correspondingly less certain WHEN the transition occurs - in other words we have higher jitter. The amount of uncertainty in the WHEN can be approximated as the inverse of the roll-over frequency of the filter. The roll-over frequency is therefore normally the highest we can make it without compromising our ability to be certain about detecting the IF. Therefore, if we need be able to function with a higher roll-over frequency and so reduce the uncertainty in the WHEN, we need to re-design the circuit to reduce the noise in the first place.
The take-away from all this is that the presence of high frequency noise is in itself a jitter-like phenomenon.
One way to design an accurate clock is to run the clock "N" times faster than we actually need, and rather than count every Tick, we count every Nth Tick. We call this process "clock multiplication", and we can - in principle - achieve an arbitrarily low jitter on our clock by continuing to increase the clock multiplier. This is, in fact, the way all real-world clocks are built. Any way you do it, though, it gets exponentially more expensive the faster the clock gets, due to an increasingly more arduous noise problem. Wickedly so, in fact. If you are DAC manufacturer, it really is a simple question of how much you want to pay to reduce your master clock jitter!
And it's not just the clock itself that has to be high speed. For example, any circuit anywhere in your DAC that needs to operate such that events can be synchronized to within 1ns must, by definition, have a bandwidth exceeding 1GHz. That, dear reader, is one heck of a high bandwidth. Not only does your clock circuitry have to have GHz bandwidth, so does the converter circuitry which is communicating with it to synchronize its measly 44.1kHz operation with your GHz clock. Otherwise - in principle at least (because nothing is ever so black and white) - you would be wasting the expense you went to in generating your super-clock in the first place. In any case, it becomes a given that a real-world DAC will be constructed with electronics having a bandwidth which - if not necessarily in the exotic territory of GHz - will still be much higher than the sample rates of the conversions it is tasked to perform.
Designing a circuit with RF (Radio Frequency) bandwidth, and having it exhibit good immunity from RF noise, is generally a no-win prospect. When dealing with RF, every problem you solve here results in a new one popping up there. RF circuits are inherently sensitive to RF interference, and so you need to design them - and package them - in such a way as to make them immune from the effects of external RF.
External RF is everywhere. It has to be, otherwise your cell phone wouldn’t work. In a circuit, RF does not just flow neatly along wires from one component to the next. It also radiates from the wires and from the components, all the time. And it is not just RF circuits that generate RF. Your house wiring is rife with RF. Just about every electrical appliance you own - all the way down to the dimmer switches on your lights - emits RF. My central heating just turned on - sending a massive RF spike throughout the house, not to mention through the electrical mains line to my neighbour’s house. As a DAC designer, you can do your job diligently to protect yourself from all this, and at least minimize the ability of RF to sneak into your circuit from the surroundings. But you can’t do much about the RF that sneaks in through connections that are designed to transmit RF bandwidths in the first place! Such as the USB and S/PDIF connectors through which your music data enters the DAC.
A USB connector is by design a high bandwidth port. The USB spec calls for it to be so. Within its defined bandwidth, any RF noise injected at one end will be faithfully transmitted down the cable and out the other end. And, in your case, straight into your DAC. This will be so, even if you don’t need all that bandwidth to transmit the music data. The USB connection is indeed a very noisy environment. This is because, in order to just transmit raw data, you are fully prepared to sacrifice timing accuracy (the WHEN) for data accuracy (the IF). Therefore, so long as the amount of spurious RF interference injected into the link is not so much as to compromise the data transmission, the intended performance of the USB link is being fully met. So, if the internals of a computer are generating a lot of spurious RF, there is good reason to imagine that a lot of it is going to be transmitted to any device attached to it via a USB cable. Such as your DAC.
What are the sources of spurious RF inside a computer? For a start, every last chip, from the CPU down, is a powerful RF source. And the harder these chips work - the more cycles they run - the more RF they will emit. Disk drives generate lots of RF noise, as do displays, ethernet ports, bluetooth and WiFi adapters.
So it is not too much of a stretch to imagine that playback software which uses more CPU, more HD access, makes things happen on the display, and communicates over your networks, … it is not too much of a stretch to see how those things have the potential to impact the sound being played on the DAC connected to the computer. Not through 'classical' digital jitter, but through RF interference, whose effects we now see are all but impossible to distinguish from those of jitter.
This, we believe, is the area in which BitPerfect does its thing. Through trial and error, we have established what sort of software activities result in sonic degradation, and which ones don’t. We have a number of very specific objective measurements that we make when optimizing our playback engine which correlate rather well with our subjective assessments of sound quality. It doesn’t mean we have the exact mechanisms nailed down, but it does mean that we have at least the basics of a handle on the cause-and-effect relationships.
You see, although it is easy to think of digital data in binary terms (it's either a one or it's a zero), that we process at some specific instant in time (defined to the picosecond so we can account for "jitter") - in reality it is never quite so simple as that. Let's look at a simple circuit, designed to take a digital input and, at a point in time defined by a clock signal, output a certain analog voltage. For the purposes of understanding the operation of jitter, there are two things happening. First of all, the circuit is monitoring the voltage which represents the tick-tock of the clock signal, in order to determine when it is ticking and when it is tocking. And secondly, once the clock is triggered, the output circuitry is applying the desired voltage to the output.
We'll start with the tick-tock of the clock. A clock signal is typically a square-wave waveform. It oscillates sharply between fully "on" (a high voltage) and fully "off" (a low voltage), and it does so very abruptly. Our circuit measures a "tick" when it detects the signal transitioning from low to high, and a "tock" when it detects a transition from high to low. Tick is generally the point at which the clock signal triggers an event, and the function of Tock is generally to mark the point at which the circuit starts looking again for the next Tick. Digital electronics are very easy for the layman to comprehend at a functional level, because the concepts are very easy to visualize. We can easily imagine a square-wave clock signal, and the nice, clean, rising and falling edges of the Tick and the Tock. At some point most of us have seen nice, helpful diagrams. What's the problem?
A real-world clock signal has some real-world problems to deal with. First of all, we need to look at those high and low voltages that we are measuring. If we look closely enough, we will see that there is usually a lot of high-frequency noise on them. They are not the nice clean square waves we expected them to be. The impact of all this noise is that it gets harder to guarantee that we can distinguish the "high" voltage from the "low". It is no use getting it right 99 times out of 100. We need to get it right a million times out of a million. The higher the speed of the clock, the worse this gets. But it is quite easy to fix. If the problem is caused by high frequency noise, all we need to do is to filter it out using a Low-Pass Filter. Let’s do that.
Now two things have happened. First, the trace has indeed thinned out, and we can accurately determine whether the clock voltage is "high" or "low". But now we see that the transitions between high and low now occur at a more leisurely pace. The exact point of the transition is no longer so clear. There is some uncertainty as to precisely when the "Tick" actually occurs. Because of this filtering, there is a trade-off to be had between being able to detect IF a transition has occurred, and exactly WHEN it occurred. If our Low-Pass Filter rolls over at a frequency just above the clock frequency, we do a great job of filtering the noise but it gets correspondingly less certain WHEN the transition occurs - in other words we have higher jitter. The amount of uncertainty in the WHEN can be approximated as the inverse of the roll-over frequency of the filter. The roll-over frequency is therefore normally the highest we can make it without compromising our ability to be certain about detecting the IF. Therefore, if we need be able to function with a higher roll-over frequency and so reduce the uncertainty in the WHEN, we need to re-design the circuit to reduce the noise in the first place.
The take-away from all this is that the presence of high frequency noise is in itself a jitter-like phenomenon.
One way to design an accurate clock is to run the clock "N" times faster than we actually need, and rather than count every Tick, we count every Nth Tick. We call this process "clock multiplication", and we can - in principle - achieve an arbitrarily low jitter on our clock by continuing to increase the clock multiplier. This is, in fact, the way all real-world clocks are built. Any way you do it, though, it gets exponentially more expensive the faster the clock gets, due to an increasingly more arduous noise problem. Wickedly so, in fact. If you are DAC manufacturer, it really is a simple question of how much you want to pay to reduce your master clock jitter!
And it's not just the clock itself that has to be high speed. For example, any circuit anywhere in your DAC that needs to operate such that events can be synchronized to within 1ns must, by definition, have a bandwidth exceeding 1GHz. That, dear reader, is one heck of a high bandwidth. Not only does your clock circuitry have to have GHz bandwidth, so does the converter circuitry which is communicating with it to synchronize its measly 44.1kHz operation with your GHz clock. Otherwise - in principle at least (because nothing is ever so black and white) - you would be wasting the expense you went to in generating your super-clock in the first place. In any case, it becomes a given that a real-world DAC will be constructed with electronics having a bandwidth which - if not necessarily in the exotic territory of GHz - will still be much higher than the sample rates of the conversions it is tasked to perform.
Designing a circuit with RF (Radio Frequency) bandwidth, and having it exhibit good immunity from RF noise, is generally a no-win prospect. When dealing with RF, every problem you solve here results in a new one popping up there. RF circuits are inherently sensitive to RF interference, and so you need to design them - and package them - in such a way as to make them immune from the effects of external RF.
External RF is everywhere. It has to be, otherwise your cell phone wouldn’t work. In a circuit, RF does not just flow neatly along wires from one component to the next. It also radiates from the wires and from the components, all the time. And it is not just RF circuits that generate RF. Your house wiring is rife with RF. Just about every electrical appliance you own - all the way down to the dimmer switches on your lights - emits RF. My central heating just turned on - sending a massive RF spike throughout the house, not to mention through the electrical mains line to my neighbour’s house. As a DAC designer, you can do your job diligently to protect yourself from all this, and at least minimize the ability of RF to sneak into your circuit from the surroundings. But you can’t do much about the RF that sneaks in through connections that are designed to transmit RF bandwidths in the first place! Such as the USB and S/PDIF connectors through which your music data enters the DAC.
A USB connector is by design a high bandwidth port. The USB spec calls for it to be so. Within its defined bandwidth, any RF noise injected at one end will be faithfully transmitted down the cable and out the other end. And, in your case, straight into your DAC. This will be so, even if you don’t need all that bandwidth to transmit the music data. The USB connection is indeed a very noisy environment. This is because, in order to just transmit raw data, you are fully prepared to sacrifice timing accuracy (the WHEN) for data accuracy (the IF). Therefore, so long as the amount of spurious RF interference injected into the link is not so much as to compromise the data transmission, the intended performance of the USB link is being fully met. So, if the internals of a computer are generating a lot of spurious RF, there is good reason to imagine that a lot of it is going to be transmitted to any device attached to it via a USB cable. Such as your DAC.
What are the sources of spurious RF inside a computer? For a start, every last chip, from the CPU down, is a powerful RF source. And the harder these chips work - the more cycles they run - the more RF they will emit. Disk drives generate lots of RF noise, as do displays, ethernet ports, bluetooth and WiFi adapters.
So it is not too much of a stretch to imagine that playback software which uses more CPU, more HD access, makes things happen on the display, and communicates over your networks, … it is not too much of a stretch to see how those things have the potential to impact the sound being played on the DAC connected to the computer. Not through 'classical' digital jitter, but through RF interference, whose effects we now see are all but impossible to distinguish from those of jitter.
This, we believe, is the area in which BitPerfect does its thing. Through trial and error, we have established what sort of software activities result in sonic degradation, and which ones don’t. We have a number of very specific objective measurements that we make when optimizing our playback engine which correlate rather well with our subjective assessments of sound quality. It doesn’t mean we have the exact mechanisms nailed down, but it does mean that we have at least the basics of a handle on the cause-and-effect relationships.
Thursday, 31 October 2013
The Sum Of All Fears - II. Jitter as a Digital Phenomeno
Yesterday, I introduced you to the concept of Jitter, and showed how it has the potential to disrupt the accuracy of digital audio playback. We saw how the measures necessary to eliminate jitter as a problem can impose unpleasant and challenging constraints upon the designer of an audiophile-grade DAC. It would be reasonable for us to ask what the audible effects of this jitter actually are, and how we can determine the efficacy with which a DAC design has addressed it. This post attempts to address these questions.
This analysis is all about jitter as a digital phenomenon, by which we mean that we are concerned only by the notional effect of playing back the wrong signal at the right time (or vice-versa). We assume that the only effect of jitter is that which we have described here as arising from fanatically precise timing errors. Can we calculate what audible or measurable effect such timing errors can have? Lets take a look.
The first thing we have to consider is what we call the distribution of jitter timing errors. As a trivial example, let us imagine that every single timing point is subject to a jitter-based timing error of 100ns (100 nanoseconds - see yesterday's post for an explanation). 100ns is a large value, and experiments have suggested that jitter of this magnitude is quite audible. In our trivial example suppose each and every sample is delayed by exactly 100ns. What we have in fact accomplished is to simply take perfect playback and delay it by 100ns. We could achieve exactly the same thing by moving our loudspeakers back by a hair's breadth. It certainly won't affect the sound quality. So just having 100ns of jitter is not in and of itself enough to cause a problem. What we need to see is an uncertainty or variability in the precise timing of the sampling process, in other words the individual samples end up being off by unknown amounts which could average out to 100ns. In this case, some samples are delayed, some are advanced, and some are not affected. Some of these errors are large, and some are small. We don't know which are which. All we know is that, on average, the errors amount to some 100ns. In other words, there is a "distribution" of timing errors. Clearly, it is possible to imagine how the audible effects of such a collection of timing errors might be affected by exactly how these errors are distributed.
In order to analyze what the effects of jitter might be, we have to classify those effects according to different types of distributions - the way in which the precise jitter values vary from one sample to the next. The best way to begin is to divide these distributions into two categories - correlated and uncorrelated jitter. Uncorrelated jitter is the easiest to understand. The jitter value for any sample is totally random. It is like rolling a dice - there is absolutely no way to predict what any one given jitter value will be. As we will see, uncorrelated jitter is the easiest form of jitter to analyze. All other forms of jitter are, by definition, correlated jitter. The jitter values correlate to some degree or another with some other property. Correlation does not necessarily mean that its exact value is determinable. It can be more like rolling a loaded dice. Some values end up being more likely than others. Analysis of correlated jitter is way more challenging.
Uncorrelated (or random) jitter turns out to be very similar to dithering, which I treated in an earlier post. Uncorrelated jitter introduces a random error into the value of each sample. The effect of this is quite simple - it increases the noise floor. The analysis is slightly complicated by the fact that the amount of noise is dependent on the frequency spectrum of the signal, but in general this analysis shows that noise floor increases of 10dB and more across the entire audio spectrum can obtained with as little as 1ns of uncorrelated jitter. However, as with dithering, this noise may not be perceptible, as it may lie below the noise floor introduced by other (analog) components in the audio playback chain. Qualitatively, uncorrelated jitter is not normally considered to be a significant detriment to the sound quality.
Correlated (or deterministic) jitter is a more complicated beast. Correlated jitter may correlate with a number of factors, including the audio signal, the power supply (mains frequency and its harmonics), clock circuits, external sources of RF interference, and other factors which may be very difficult to pin down. Its frequency spectrum and bandwidth need to be taken into account. If the jitter behaves in a tightly deterministic manner, we can perform some very accurate mathematical analysis of its behaviour to determine its effect on the audio signal, but deviations from even the simplest forms of deterministic jitter make the analysis and its interpretation exponentially more difficult.
Lets take the simplest case of an audio signal comprising a single pure tone, and a jitter function which behaves as a pure sinusoid. A simple Fourier Transform of the resultant audio signal will be found to exhibit the single peak of the original audio pure tone, plus two symmetrical side lobes. The magnitude and separation of the side lobes will permit us to calculate both the frequency and magnitude of the jitter signal. This is a highly specific and limiting case, and it is highly unlikely that any real-world jitter scenario would ever be that simple. But for the most part it is all we have!
At this point, I would normally go into a little bit more detail on how real-world jitter measurements are performed, but it really is too complicated. Suffice to say that it typically depends on Fourier Analysis of an audio signal with a single tone, in some cases further modulated by a very low-level lower-frequency square wave which produces a family of reference harmonics, based on the analysis I described above. The technique involves looking for pairs of symmetrical side lobes and attempting to infer the corresponding jitter contributions. As you can see, this type of analysis will fail to take into account distributions of jitter which are not properly described by the (highly simplified) underlying mathematical model, and its accuracy will be limited by the validity of the model, which, as I have observed, gets waaaay more difficult to interpret as the modeled system gets more complicated. The net effect is that these more elaborate analyses are limited by the assumptions that have to be made in order to make the math more manageable, and the accuracy of the results is in the end limited by the validity of these assumptions. The disconnect between the two is a very real problem - compounded by the fact that the person using the analysis tool is not normally familiar with the underlying mathematics, nor the assumptions upon which it rests.
The audibility of these jitter modes are far more difficult to predict, even with the assistance of the limited mathematical modelling. Unlike the results with uncorrelated (random) jitter, correlated jitter often results in specific frequency peaks. This type of behaviour is more like distortion than it is noise, and we know that the human ear tends to be far less tolerant of distortions than noise, with some distortions (such as intermodulation distortion) being much worse than others (such as even harmonic distortion). At this point, it is not possible to entirely dismiss the notion that some classes of jitter may be both impossible to observe and measure, yet at the same time deleterious to sound quality.
But is jitter really what I have described, and does it really impact the system in the way I have described it? Or could something else be in play? Tomorrow, in the final installment of this short series, I will start to consider this idea further.
This analysis is all about jitter as a digital phenomenon, by which we mean that we are concerned only by the notional effect of playing back the wrong signal at the right time (or vice-versa). We assume that the only effect of jitter is that which we have described here as arising from fanatically precise timing errors. Can we calculate what audible or measurable effect such timing errors can have? Lets take a look.
The first thing we have to consider is what we call the distribution of jitter timing errors. As a trivial example, let us imagine that every single timing point is subject to a jitter-based timing error of 100ns (100 nanoseconds - see yesterday's post for an explanation). 100ns is a large value, and experiments have suggested that jitter of this magnitude is quite audible. In our trivial example suppose each and every sample is delayed by exactly 100ns. What we have in fact accomplished is to simply take perfect playback and delay it by 100ns. We could achieve exactly the same thing by moving our loudspeakers back by a hair's breadth. It certainly won't affect the sound quality. So just having 100ns of jitter is not in and of itself enough to cause a problem. What we need to see is an uncertainty or variability in the precise timing of the sampling process, in other words the individual samples end up being off by unknown amounts which could average out to 100ns. In this case, some samples are delayed, some are advanced, and some are not affected. Some of these errors are large, and some are small. We don't know which are which. All we know is that, on average, the errors amount to some 100ns. In other words, there is a "distribution" of timing errors. Clearly, it is possible to imagine how the audible effects of such a collection of timing errors might be affected by exactly how these errors are distributed.
In order to analyze what the effects of jitter might be, we have to classify those effects according to different types of distributions - the way in which the precise jitter values vary from one sample to the next. The best way to begin is to divide these distributions into two categories - correlated and uncorrelated jitter. Uncorrelated jitter is the easiest to understand. The jitter value for any sample is totally random. It is like rolling a dice - there is absolutely no way to predict what any one given jitter value will be. As we will see, uncorrelated jitter is the easiest form of jitter to analyze. All other forms of jitter are, by definition, correlated jitter. The jitter values correlate to some degree or another with some other property. Correlation does not necessarily mean that its exact value is determinable. It can be more like rolling a loaded dice. Some values end up being more likely than others. Analysis of correlated jitter is way more challenging.
Uncorrelated (or random) jitter turns out to be very similar to dithering, which I treated in an earlier post. Uncorrelated jitter introduces a random error into the value of each sample. The effect of this is quite simple - it increases the noise floor. The analysis is slightly complicated by the fact that the amount of noise is dependent on the frequency spectrum of the signal, but in general this analysis shows that noise floor increases of 10dB and more across the entire audio spectrum can obtained with as little as 1ns of uncorrelated jitter. However, as with dithering, this noise may not be perceptible, as it may lie below the noise floor introduced by other (analog) components in the audio playback chain. Qualitatively, uncorrelated jitter is not normally considered to be a significant detriment to the sound quality.
Correlated (or deterministic) jitter is a more complicated beast. Correlated jitter may correlate with a number of factors, including the audio signal, the power supply (mains frequency and its harmonics), clock circuits, external sources of RF interference, and other factors which may be very difficult to pin down. Its frequency spectrum and bandwidth need to be taken into account. If the jitter behaves in a tightly deterministic manner, we can perform some very accurate mathematical analysis of its behaviour to determine its effect on the audio signal, but deviations from even the simplest forms of deterministic jitter make the analysis and its interpretation exponentially more difficult.
Lets take the simplest case of an audio signal comprising a single pure tone, and a jitter function which behaves as a pure sinusoid. A simple Fourier Transform of the resultant audio signal will be found to exhibit the single peak of the original audio pure tone, plus two symmetrical side lobes. The magnitude and separation of the side lobes will permit us to calculate both the frequency and magnitude of the jitter signal. This is a highly specific and limiting case, and it is highly unlikely that any real-world jitter scenario would ever be that simple. But for the most part it is all we have!
At this point, I would normally go into a little bit more detail on how real-world jitter measurements are performed, but it really is too complicated. Suffice to say that it typically depends on Fourier Analysis of an audio signal with a single tone, in some cases further modulated by a very low-level lower-frequency square wave which produces a family of reference harmonics, based on the analysis I described above. The technique involves looking for pairs of symmetrical side lobes and attempting to infer the corresponding jitter contributions. As you can see, this type of analysis will fail to take into account distributions of jitter which are not properly described by the (highly simplified) underlying mathematical model, and its accuracy will be limited by the validity of the model, which, as I have observed, gets waaaay more difficult to interpret as the modeled system gets more complicated. The net effect is that these more elaborate analyses are limited by the assumptions that have to be made in order to make the math more manageable, and the accuracy of the results is in the end limited by the validity of these assumptions. The disconnect between the two is a very real problem - compounded by the fact that the person using the analysis tool is not normally familiar with the underlying mathematics, nor the assumptions upon which it rests.
The audibility of these jitter modes are far more difficult to predict, even with the assistance of the limited mathematical modelling. Unlike the results with uncorrelated (random) jitter, correlated jitter often results in specific frequency peaks. This type of behaviour is more like distortion than it is noise, and we know that the human ear tends to be far less tolerant of distortions than noise, with some distortions (such as intermodulation distortion) being much worse than others (such as even harmonic distortion). At this point, it is not possible to entirely dismiss the notion that some classes of jitter may be both impossible to observe and measure, yet at the same time deleterious to sound quality.
But is jitter really what I have described, and does it really impact the system in the way I have described it? Or could something else be in play? Tomorrow, in the final installment of this short series, I will start to consider this idea further.
Wednesday, 30 October 2013
The Sum Of All Fears - I. A Touch of the Jitters
I want to address a critical phenomenon for which there isn't an adequate explanation, and provide a rationale for it in terms of another phenomenon for which there isn't an adequate explanation. Pointless, perhaps, but it is the sort of thing that tends to keep me up at nights. Maybe some of you too!
Most of you, being BitPerfect Users, will already know that while BitPerfect achieves "Bit Perfect" playback (when configured to do so), so can iTunes (although configuring it can be a real pain in the a$$). Yet, I am sure you will agree, they manage to sound different. Other "Bit Perfect" software players also manage to sound different. Moreover, BitPerfect has various settings within its "Bit Perfect" repertoire - such as Integer Mode - which can make a significant difference by themselves. What is the basis for this unexpected phenomenon?
First of all, we must address the "Flat Earth" crowd who will insist that there cannot possibly BE any difference, and that if you say you can hear one, you must be imagining it. You can spot them a mile away. They will invoke the dreaded "double-blind test" at the drop of a hat, even though few of them actually understand the purpose and rationale behind a double-blind test, and have neither organized nor ever participated in one. I tried to set up a series of publicly-accessible double-blind tests at SSI 2012 with the assistance of a national laboratory's audio science group. They couldn't have shown less interest if I proposed to infect them with anthrax. Audio professionals generally won't touch a double-blind test with a ten foot pole. Anyway, as far as the Flat Earth crowd are concerned, this post, and those that follow, are all about discussing something that doesn't exist. Unfortunately, I cannot make the Flat Earthers vanish simply by taking the position that they don't exist!
For the rest of you - BitPerfect Users, plus anyone else who might end up reading this - the effect is real enough, and a suitable explanation would definitely be in order. That is, if we had one for you.
If it is not the data itself (because the data is "Bit Perfect"), then we must look elsewhere. But before we do, some of you will ask "How do we know that the data really is Bit Perfect?", which is a perfectly reasonable question. But it is not one I am going to dwell on here, except to say that it has been thoroughly shaken down. Using USB it is actually quite easy to do (from the perspective of not being technically challenging), although using S/PDIF requires an investment in very specific test equipment. Bottom line, though, is that this has been done and nobody holds any lingering concerns over it. I won't address it further.
As Sherlock Holmes might observe, once we accept that the data is indeed "Bit Perfect", the only thing that is left is a phenomenon most of us have heard of, but few of us understand - jitter. Jitter was first introduced to audiophiles in the very early 1990's as an explanation for why so many people professed a dislike for the CD sound. Digital audio comprises a bunch of numbers that represent the amplitude of a musical waveform, measured ("sampled" is the term we use) many thousands of times per second. Some simple mathematical theorems can tell us how often we need to sample the waveform, and how accurately we need those sample measurements to be, in order to achieve specific objectives. Those theorems led the developers of the CD to select a sample rate of 44,100 times per second, and a measurement precision of 16-bits. We can play back the recorded sound by using those numbers - one every 1/44100th of a second - to regenerate the musical waveform. This where jitter comes in. Jitter reflects a critical core fact - "The Right Number At The Wrong Time Is The Wrong Number".
Jitter affects both recording and playback, and only those two stages. Unfortunately, once it has been embedded into the recording you can't do anything about it, so we tend to think of it only in terms of playback. But I am going to describe it in terms of recording, because it is easier to grasp that way.
Imagine a theoretically perfect digital audio recorder recording in the CD format. It is measuring the musical waveform 44,100 times a second. That's one datapoint every 23 microseconds (23 millionths of a second). At each instant in time it has to measure the magnitude of the waveform, and store the result as a 16-bit number. Then it waits another 23 microseconds and does it again. And again, and again, and again. Naturally, the musical waveform is constantly changing. Now imagine that the recorder by mistake measures the reading a smidgeon too early or too late. It will measure the waveform at the wrong time. The result will not be the same as it would have been if it had been measured at the right time, even though when the measurement was taken, it was taken accurately. We have measured the right number at the wrong time, and as a result it is the wrong number. When it comes time to playback, all the DAC knows is that the readings were taken 44,100 times a second. It has no way of knowing whether any individual readings were taken a smidgeon too early or too late. A perfect DAC would therefore replay the wrong number at the right time, and as a result it will create a "wrong" waveform. These timing errors - these smidgeons of time - are what we describe as "Jitter". Playback jitter is an identical problem. If the replay timing in an imperfect real-world DAC is off by a smidgeon, then the "right" incoming number will be replayed at the "wrong" time, and the result will likewise be a wrong waveform.
Just how much jitter is too much? Lets examine a 16-bit, 44.1kHz recording. Such a recording will be bandwidth limited theoretically to 22.05kHz (practically, to a lower value). We need to know how quickly the musical waveform could be changing between successive measurements. The most rapid changes generally occur when the signal comprises the highest possible frequency, modulated at the highest possible amplitude. Under these circumstances, the waveform can change from maximum to minimum between adjacent samples. A "right" number becomes a "wrong" number when the error exceeds the precision with which we can record it. A number represented by a 16-bit integer can take on one of 65,536 possible values. So, a 16-bit number which changes from maximum to minimum between adjacent samples, cycles through 65,536 distinct values between samples. Therefore, in this admittedly worst-case scenario, we will record the "wrong" number if our "smidgeon of time" exceeds 1/65535 of the time between samples, which you will recall was 23 millionths of a second. That puts the value of our smidgeon at 346 millionths of a millionth of a second. In engineering-speak that is 346ps (346 picoseconds). That's a very, very short time indeed. In 346ps, light travels 4 inches. And a speeding bullet will traverse 1/300 of the diameter of a human hair.
I have just described jitter in terms of recording, but the exact same conditions apply during playback, and the calculations are exactly the same. If you want to guarantee that jitter will not affect CD playback, it has to be reduced to less that 346ps. However, in the real world, there are thing we can take into account to alleviate that requirement. For example, real-world signals do not typically encode components at the highest frequencies at the highest levels, and there are various sensible theories as to how to better define our worst-case scenario. I won’t go into any of them. There are also published results of real-world tests which purport to show that for CD playback, jitter levels below 10ns (ten nanoseconds; a nanosecond is a thousand picoseconds) are inaudible. But these tests are 20 years old now, and many audiophiles take issue with them. Additionally, there are arguments that higher-resolution formats, such as 24-bit 96kHz, have correspondingly tighter jitter requirements. Lets just say that it is generally taken to be desirable to get jitter down below 1ns.
If you require the electronics inside your DAC to deliver timing precision somewhere between 10ns and 346ps, this implies that those electronics must have a bandwidth of somewhere from 100MHz to 3GHz. That is RF (Radio Frequency) territory, and we will come back to it again later. Any electronics engineer will tell you that electrical circuits stop behaving sensibly, logically and rationally once you start playing around in the RF. The higher the bandwidth, the more painful the headaches. Electronics designer who work in the RF are in general a breed apart from those who work in the AF (the Audio Frequency band).
The bottom line here is that digital playback is a lot more complicated than just getting the exact right bits to the DAC. They have to be played back with a timing precision which invokes unholy design constraints.
Tomorrow I will talk about the audible and measurable effects of jitter.
Most of you, being BitPerfect Users, will already know that while BitPerfect achieves "Bit Perfect" playback (when configured to do so), so can iTunes (although configuring it can be a real pain in the a$$). Yet, I am sure you will agree, they manage to sound different. Other "Bit Perfect" software players also manage to sound different. Moreover, BitPerfect has various settings within its "Bit Perfect" repertoire - such as Integer Mode - which can make a significant difference by themselves. What is the basis for this unexpected phenomenon?
First of all, we must address the "Flat Earth" crowd who will insist that there cannot possibly BE any difference, and that if you say you can hear one, you must be imagining it. You can spot them a mile away. They will invoke the dreaded "double-blind test" at the drop of a hat, even though few of them actually understand the purpose and rationale behind a double-blind test, and have neither organized nor ever participated in one. I tried to set up a series of publicly-accessible double-blind tests at SSI 2012 with the assistance of a national laboratory's audio science group. They couldn't have shown less interest if I proposed to infect them with anthrax. Audio professionals generally won't touch a double-blind test with a ten foot pole. Anyway, as far as the Flat Earth crowd are concerned, this post, and those that follow, are all about discussing something that doesn't exist. Unfortunately, I cannot make the Flat Earthers vanish simply by taking the position that they don't exist!
For the rest of you - BitPerfect Users, plus anyone else who might end up reading this - the effect is real enough, and a suitable explanation would definitely be in order. That is, if we had one for you.
If it is not the data itself (because the data is "Bit Perfect"), then we must look elsewhere. But before we do, some of you will ask "How do we know that the data really is Bit Perfect?", which is a perfectly reasonable question. But it is not one I am going to dwell on here, except to say that it has been thoroughly shaken down. Using USB it is actually quite easy to do (from the perspective of not being technically challenging), although using S/PDIF requires an investment in very specific test equipment. Bottom line, though, is that this has been done and nobody holds any lingering concerns over it. I won't address it further.
As Sherlock Holmes might observe, once we accept that the data is indeed "Bit Perfect", the only thing that is left is a phenomenon most of us have heard of, but few of us understand - jitter. Jitter was first introduced to audiophiles in the very early 1990's as an explanation for why so many people professed a dislike for the CD sound. Digital audio comprises a bunch of numbers that represent the amplitude of a musical waveform, measured ("sampled" is the term we use) many thousands of times per second. Some simple mathematical theorems can tell us how often we need to sample the waveform, and how accurately we need those sample measurements to be, in order to achieve specific objectives. Those theorems led the developers of the CD to select a sample rate of 44,100 times per second, and a measurement precision of 16-bits. We can play back the recorded sound by using those numbers - one every 1/44100th of a second - to regenerate the musical waveform. This where jitter comes in. Jitter reflects a critical core fact - "The Right Number At The Wrong Time Is The Wrong Number".
Jitter affects both recording and playback, and only those two stages. Unfortunately, once it has been embedded into the recording you can't do anything about it, so we tend to think of it only in terms of playback. But I am going to describe it in terms of recording, because it is easier to grasp that way.
Imagine a theoretically perfect digital audio recorder recording in the CD format. It is measuring the musical waveform 44,100 times a second. That's one datapoint every 23 microseconds (23 millionths of a second). At each instant in time it has to measure the magnitude of the waveform, and store the result as a 16-bit number. Then it waits another 23 microseconds and does it again. And again, and again, and again. Naturally, the musical waveform is constantly changing. Now imagine that the recorder by mistake measures the reading a smidgeon too early or too late. It will measure the waveform at the wrong time. The result will not be the same as it would have been if it had been measured at the right time, even though when the measurement was taken, it was taken accurately. We have measured the right number at the wrong time, and as a result it is the wrong number. When it comes time to playback, all the DAC knows is that the readings were taken 44,100 times a second. It has no way of knowing whether any individual readings were taken a smidgeon too early or too late. A perfect DAC would therefore replay the wrong number at the right time, and as a result it will create a "wrong" waveform. These timing errors - these smidgeons of time - are what we describe as "Jitter". Playback jitter is an identical problem. If the replay timing in an imperfect real-world DAC is off by a smidgeon, then the "right" incoming number will be replayed at the "wrong" time, and the result will likewise be a wrong waveform.
Just how much jitter is too much? Lets examine a 16-bit, 44.1kHz recording. Such a recording will be bandwidth limited theoretically to 22.05kHz (practically, to a lower value). We need to know how quickly the musical waveform could be changing between successive measurements. The most rapid changes generally occur when the signal comprises the highest possible frequency, modulated at the highest possible amplitude. Under these circumstances, the waveform can change from maximum to minimum between adjacent samples. A "right" number becomes a "wrong" number when the error exceeds the precision with which we can record it. A number represented by a 16-bit integer can take on one of 65,536 possible values. So, a 16-bit number which changes from maximum to minimum between adjacent samples, cycles through 65,536 distinct values between samples. Therefore, in this admittedly worst-case scenario, we will record the "wrong" number if our "smidgeon of time" exceeds 1/65535 of the time between samples, which you will recall was 23 millionths of a second. That puts the value of our smidgeon at 346 millionths of a millionth of a second. In engineering-speak that is 346ps (346 picoseconds). That's a very, very short time indeed. In 346ps, light travels 4 inches. And a speeding bullet will traverse 1/300 of the diameter of a human hair.
I have just described jitter in terms of recording, but the exact same conditions apply during playback, and the calculations are exactly the same. If you want to guarantee that jitter will not affect CD playback, it has to be reduced to less that 346ps. However, in the real world, there are thing we can take into account to alleviate that requirement. For example, real-world signals do not typically encode components at the highest frequencies at the highest levels, and there are various sensible theories as to how to better define our worst-case scenario. I won’t go into any of them. There are also published results of real-world tests which purport to show that for CD playback, jitter levels below 10ns (ten nanoseconds; a nanosecond is a thousand picoseconds) are inaudible. But these tests are 20 years old now, and many audiophiles take issue with them. Additionally, there are arguments that higher-resolution formats, such as 24-bit 96kHz, have correspondingly tighter jitter requirements. Lets just say that it is generally taken to be desirable to get jitter down below 1ns.
If you require the electronics inside your DAC to deliver timing precision somewhere between 10ns and 346ps, this implies that those electronics must have a bandwidth of somewhere from 100MHz to 3GHz. That is RF (Radio Frequency) territory, and we will come back to it again later. Any electronics engineer will tell you that electrical circuits stop behaving sensibly, logically and rationally once you start playing around in the RF. The higher the bandwidth, the more painful the headaches. Electronics designer who work in the RF are in general a breed apart from those who work in the AF (the Audio Frequency band).
The bottom line here is that digital playback is a lot more complicated than just getting the exact right bits to the DAC. They have to be played back with a timing precision which invokes unholy design constraints.
Tomorrow I will talk about the audible and measurable effects of jitter.
Tuesday, 29 October 2013
Schubert's String Quintet, D956
Chamber Music. Even the term itself is enough
to put people off. It is a genre which many people file under the same
folder as waterboarding. And in truth, on occasion it does feel like
it belongs there.
There is one chamber work, though, which I would encourage anybody for whom music is - in whatever form - an important part of your life, to take some time aside to sit down and listen to. Arguably the greatest chamber work ever written, Schubert’s String Quintet D956, composed only two months before his untimely death from syphilis, aged only 31. Listen to this in a dark room, on headphones, accompanied by a glass of your finest single malt scotch, having secured iron-clad assurances, on pain of death, that under no circumstances will you be disturbed. This is music that entwines itself with your very soul, poses questions you cannot answer, and satisfies longings you never knew you craved.
A String Quartet is a standard musical ensemble, comprising two violins, a viola and a cello. A String Quintet, on the other hand, is a more flexible designation - the fifth player is usually another viola, but in this case a second cello is called for. Two cellos would suggest a sonic imbalanced in the bass, but in the expert hands of Franz Schubert it instead adds an almost symphonic depth to the soundscape. A great performance can make you think you are listening to a chamber orchestra. Performances of D956 fall into two categories. Because of the stature of the piece, it is often performed by an ensemble of soloist superstars, gathered for the task, more with an eye on the box office than an ear to the music. The standard alternative is to take an established String Quartet and add an accomplished solo cellist. The choice and performance of the second cellist is an existential one for the performance, since this part drives and leads much of what will come to define the performance.
I have alluded to the symphonic nature of the piece. Indeed, on closer inspection it can come across as a chamber transcription of a bigger piece. Go play Wagner’s “Siegfried Idyll” and imagine what his orchestration of D956 could have sounded like. On the other hand, we are talking about one of music’s great masterpieces here, and as Fats Waller said, “If you don’t know what it is, don’t mess with it”. Written merely four years after Beethoven’s iconic ninth symphony, D956 looks more forward to Mahler more than it does back to Beethoven. It is more profound and introspective, less overtly melodic than Beethoven - you won’t be humming its tunes on your way home from the office - and its developmental structure is more complex and elaborate. D956 is all about soundscapes, textures, and moods, right the way through to the bizarre final chord, which comes across like a bum left hand note played by an over-excited pianist who leaps too high on his final flourish and lands in the wrong place (I confess, I don’t know what Schubert had in mind there).
I have yet to come across a “definitive” recording of D956. I have four, by the Emerson, Takács, Tokyo, and Vellinger string quartets, each with a guest cellist. Each has something to be said for it. The Emerson is notable for its great tonal beauty, the Takács for its liquid playing, the Tokyo is the most classically refined, and the Vellinger offers an ascetic, soul-baring honesty. As a purely personal opinion, I tend to gravitate to the Vellinger, which is hard to come by because it was a free giveaway with the BBC Music Magazine about 20 years ago, so it is unfair to recommend, but to me it best captures the soul of the piece. But all four paint dramatically different pictures, with the contrast between the Emerson (imagine Iván Fischer conducting) and the Vellinger (imagine Pierre Boulez conducting) occupying the extremes. Continuing with that analogy, the Tokyo could be Arturo Toscanini, and the Takács perhaps even Carlos Kleiber. They’re all very, very good, and the differences are primarily of style rather than musicianship.
It may be Chamber Music, but it is magnificent.
http://www.robertgreenbergmusic.com/2012/04/27/miracles-franz-schubert-and-his-string-quintet-in-c-major/
There is one chamber work, though, which I would encourage anybody for whom music is - in whatever form - an important part of your life, to take some time aside to sit down and listen to. Arguably the greatest chamber work ever written, Schubert’s String Quintet D956, composed only two months before his untimely death from syphilis, aged only 31. Listen to this in a dark room, on headphones, accompanied by a glass of your finest single malt scotch, having secured iron-clad assurances, on pain of death, that under no circumstances will you be disturbed. This is music that entwines itself with your very soul, poses questions you cannot answer, and satisfies longings you never knew you craved.
A String Quartet is a standard musical ensemble, comprising two violins, a viola and a cello. A String Quintet, on the other hand, is a more flexible designation - the fifth player is usually another viola, but in this case a second cello is called for. Two cellos would suggest a sonic imbalanced in the bass, but in the expert hands of Franz Schubert it instead adds an almost symphonic depth to the soundscape. A great performance can make you think you are listening to a chamber orchestra. Performances of D956 fall into two categories. Because of the stature of the piece, it is often performed by an ensemble of soloist superstars, gathered for the task, more with an eye on the box office than an ear to the music. The standard alternative is to take an established String Quartet and add an accomplished solo cellist. The choice and performance of the second cellist is an existential one for the performance, since this part drives and leads much of what will come to define the performance.
I have alluded to the symphonic nature of the piece. Indeed, on closer inspection it can come across as a chamber transcription of a bigger piece. Go play Wagner’s “Siegfried Idyll” and imagine what his orchestration of D956 could have sounded like. On the other hand, we are talking about one of music’s great masterpieces here, and as Fats Waller said, “If you don’t know what it is, don’t mess with it”. Written merely four years after Beethoven’s iconic ninth symphony, D956 looks more forward to Mahler more than it does back to Beethoven. It is more profound and introspective, less overtly melodic than Beethoven - you won’t be humming its tunes on your way home from the office - and its developmental structure is more complex and elaborate. D956 is all about soundscapes, textures, and moods, right the way through to the bizarre final chord, which comes across like a bum left hand note played by an over-excited pianist who leaps too high on his final flourish and lands in the wrong place (I confess, I don’t know what Schubert had in mind there).
I have yet to come across a “definitive” recording of D956. I have four, by the Emerson, Takács, Tokyo, and Vellinger string quartets, each with a guest cellist. Each has something to be said for it. The Emerson is notable for its great tonal beauty, the Takács for its liquid playing, the Tokyo is the most classically refined, and the Vellinger offers an ascetic, soul-baring honesty. As a purely personal opinion, I tend to gravitate to the Vellinger, which is hard to come by because it was a free giveaway with the BBC Music Magazine about 20 years ago, so it is unfair to recommend, but to me it best captures the soul of the piece. But all four paint dramatically different pictures, with the contrast between the Emerson (imagine Iván Fischer conducting) and the Vellinger (imagine Pierre Boulez conducting) occupying the extremes. Continuing with that analogy, the Tokyo could be Arturo Toscanini, and the Takács perhaps even Carlos Kleiber. They’re all very, very good, and the differences are primarily of style rather than musicianship.
It may be Chamber Music, but it is magnificent.
http://www.robertgreenbergmusic.com/2012/04/27/miracles-franz-schubert-and-his-string-quintet-in-c-major/
Geek Pulse
Check out Light Harmonic's new crowd-sourcing
campaign - the "Geek Pulse"! Yes, the same Light Harmonic, maker of the
mega-buck Da Vinci DAC, are now developing a product at the other end of
the price spectrum, bringing ultra high-resolution
PCM, together with the very latest in DSD playback support, to the
market at a VERY affordable price. I can't wait to get my hands on one!
http://www.indiegogo.com/projects/geek-pulse-a-digital-audio-awesomifier-for-your-desktop
http://www.indiegogo.com/projects/geek-pulse-a-digital-audio-awesomifier-for-your-desktop
Thursday, 24 October 2013
iTunes 11.1.2
It
has taken me longer than usual to finally pronounce on iTunes 11.1.2,
but here I am. I wanted to take a little longer, because a very small
number of users have posted on our FaceBook page, and also through the
e-mail support line, that they have encountered unexpected problems
after installing the combination of OS/X Mavericks and iTunes 11.1.2.
Here at BitPerfect I have been running that combination for two days solid and have not had a single problem. Furthermore, one or two of those users who did encounter problems have reported that these problems have suddenly vanished.
On balance, therefore, I don't really see any good reason why you should not all make the update if you want to. I suspect, by the way, although I am not certain about this, that if you upgrade to OS/X Mavericks, you might get iTunes 11.1.2 as part of the package, whether you want it or not.
Here at BitPerfect I have been running that combination for two days solid and have not had a single problem. Furthermore, one or two of those users who did encounter problems have reported that these problems have suddenly vanished.
On balance, therefore, I don't really see any good reason why you should not all make the update if you want to. I suspect, by the way, although I am not certain about this, that if you upgrade to OS/X Mavericks, you might get iTunes 11.1.2 as part of the package, whether you want it or not.
Subscribe to:
Posts (Atom)