Hi, Robert,
Thank you very much.
After sitting through far too many meetings and briefings listening to
far too much carrying on about this issue, what you've written is the
most concisely accurate description I've ever heard of this issue.
Thank you very much.
Kind regards.
Horace
On 10/4/2015 6:02 AM, Robert Scott via Piano Technicians Guild wrote:
> Please do not forward this message due to Auto Login.
>
>
> The pitch of a sound is the number of cycles produced in one second. If one cycle of that audio is made up of 50 digitally sampled values, the pitch of the sound does indeed depend on how fast those samples are delivered to the speakers. The digitally encoded values themselves may not change with sample rate. But the rate at which they go through one complete cycle is certainly dependent on the rate at which those 50 samples are reconstructed.
>
>
> With regard to Internet pitch references, it is important to take into account how the Internet works. The Internet uses a protocol called TCP/IP. This same protocol is used when you access my.ptg.org or when you play on-line recordings of sound. Information is broken up into small packets and sent out.
>
>
> Each packet of information in the TCP/IP protocol is relayed through any number of intermediate nodes. Each node passes the packet on to another node whenever it gets around to it. The node does not guarantee timely delivery of that packet. What's more, different packets can be routed through different nodes, depending on the workload of each node in the Internet. These packets can be delayed by different amounts, often in the neighborhood of 0.10 to 0.15 seconds. The result is that packets can and do often arrive out of order. This is corrected by the fact that every packet is numbered. The TCP/IP protocol uses the packet numbers to reconstruct the data stream in the correct order at your computer.
>
>
> The result is that any precise timing information that might have been present at the source of the data is lost by the unpredictable packet delay of each packet of information. So if those packets happen to represent an audio stream, how does your computer decide how to deliver those audio samples to your speakers? It obviously cannot rely on the arrival times of the packets themselves, because they don't even arrive in the correct order, much less at a predictable time. So your computer (actually the browser software) buffers the audio data and sends it out to your speakers at a rate it determines. The data may be known to have been sampled at 44100 samples per second, but your computer does not know what a second is, precisely. The only way your computer can estimate time in the short run is to use one of its local crystal oscillators. If that crystal oscillator happens to be off by a few cents, the audio playback will be off in pitch by a few cents. The pitch accuracy
> does not come from the Internet.
>
>
> I did mention "in the short run" above, because in the long run, your computer can in fact get accurate pitch information from the Internet. If your browser buffers the data before it is sent out, there is a delay between input from the Internet and output to the speakers. If your computer's idea of time is a little slow, the size of the buffered data will gradually and irregularly grow without bound. Data is coming in faster than your computer is pushing it out. Eventually your computer notices this problem and it can slightly adjust the output speed to correct the problem. Similarly, if your computer's idea of time is as little fast, it will notice that the amount of buffered data is gradually shrinking. If this goes on too long, eventually an audio sample will be due to be sent out before that audio sample has been received. The only thing the software can do at that point is to give up and pause the audio briefly. Or it might recognize the problem early on and slightly
> slow down the audio rendering speed.
>
>
> The point is, this adjustment process is slow. An error of one cent may take 10 minutes before it can be recognized by the software. But nothing meaningful can be done to adjust the pitch reference to the Internet in the first few seconds. The pitch in the first minute or so is purely the browser's guess.
>
>
> With all that said, I should add that Apple seems to have gone to great lengths to trim the effective sample rate of their iPhones and iPads at the factory. Lately I have not seen an Apple product that is off by more than 0.05 cents. So perhaps that is why everything seems to "just work" even without software calibration.
>
>
>
>
> ------------------------------
> Robert Scott
> Real-Time Specialties
> Hopkins MN
> ------------------------------
>
> -------------------------------------------
> Original Message:
> Sent: 09-28-2015 02:03
> From: Geoff Sykes
> Subject: Pitch source
>
>
>
>
> Tapping in to an online signal source that is creating the tone in real time is never going to be as accurate as tapping into a source that is sending you a digitally stored sample. And I agree with Scott that relying on a signal created by the chip set in your computer is going to give questionable results. Any signal created in your computer is going to be questionable and about as reliable as the MIDI instructions built into that chip set. Let's clarify something. A tone generated by the chip set in your computer is not the same as playing back a digitally stored sample of an accurately created real tone.
>
>
> Contrary to what Robert Scott says, clock speed has nothing to do with pitch. In digital, the speed of playback cannot change the pitch. Digital, by design, simply, and deliberately, does not work that way. Regardless of the rate of conversion, or as Scott says, the sampling rate, the value of any given sample cannot change. As an example that has nothing directly to do with AD/DA conversion in audio, but has everything to do with how digital data, like audio, is stored and reproduced, the 16 bit value for the number 440, as in Hz, is 0000000110111000. No matter what speed you play that number back at, the value of that binary number cannot change. It's always going to be 0000000110111000. Play it back faster and the number will just go by faster. When you drive by a gas station at 35 mph and the sign displaying the price of gas says $3.65, the price on that sign is not going to change just because you drive by again at 60 mph.
>
>
> On the other hand, if the price on that sign is being created by the chip set in your computer, driving by at a faster speed could possibly change the price. The chip set in your computer is not playing back a digital sample. It is creating, from scratch, an analog signal. And yes, clock speed will affect pitch in that instance. As will whatever Java routine you are using to generate the chip instructions in the first place.
>
>
> I use a digital audio program called Audacity. With it I can manipulate playback speed, pitch and a whole slew of other qualities of an audio file. But I have to do it deliberately. In other words, if you play back, or stream, a normal digital audio file, through your computer, and don't run it through some additional hardware or software, your system will play back exactly what that file contains. 440 will be 440. If it's not then question the source, not your system. The providers may believe they are sending you a 440 sample, but they may really be sending you 440.5.
>
>
> I have several signal generator apps on my phone. They all function by telling the chip set in my phone to generate a 440 Hz tone. The tone is then created in my phone, electronically. Based on the accuracy of the instruction, and the accuracy of the electronics, that value can change. Not all the signal generators in my phone, when set to 440, actually produce 440. And that's because none of them are actually playing back a digital 440 Hz sample. They are all simply sending instructions to my phone to create a 440 Hz tone from scratch. Playing back instructions is never going to provide the accuracy of playing back an accurate digital sample.
>
>
> That said, thank you for speaking up in defense of reality. How close does A4 actually need to be to fall within the window of close enough? Under controlled conditions I'd venture to say that one decimal place is sufficient for an ETD. And nobody is going to be able to get a tuning set to three decimal places and have it stay for longer than you can hold your breath and avoid breathing on it. Up until modern technology helped us understand what we, as tuners, were actually listening to, and allowed us to develop an ETD that could accurately calculate tuning's based on that understanding, aural tuners did some mighty fine work. Probably not as accurate as today by ETD standards, but for more than a couple hundred years it satisfied the needs of even the most critical listeners.
>
>
> -- GS
>
>
>
> ------------------------------
> Geoff Sykes, RPT
> Los Angeles CA
> ------------------------------
>
> -------------------------------------------
> Original Message:
> Sent: 09-28-2015 00:26
> From: Ronald Nossaman
> Subject: Pitch source
>
> Okay. What do you get with a pitch played by an interactive java
> routine? Robert Scott cautioned us about the reproduction of pitch
> demonstrations processed through your sound chip set on line some time
> back. So it would make a difference how the playback was handled. I
> understand digital precision, but a precise clock cycle is still
> required for that too. I don't know enough details of this to dissect it
> to the bones, but an on line pitch source isn't necessarily absolute.
> It's generated by one clock, and reconstituted by another.
>
> From a realistically practical standpoint, if the sacrilege of
> practicality can be allowed, it's all well within the range of those
> furnace and AC cycles we routinely tune through, so it's not a real
> attainable item in practice. But for the recursively anal, it's a
> detectable thing, and might provide goals. This isn't intended as
> picking on anything, but an attempt at overlaying some perspective on
> the pitch precision thing.
>
> Just as well finish myself off while I'm here. How many of you have been
> called back because your A was 0.1 (cents) off of 440.00Hz? Hands? How
> many times?
>
> Again, I'm not trying to start a fight, but what is the actual real
> world tolerance for pitch in continually cycling climate control, and
> from week to week with the heat and A/C way down between uses? Sure, we
> should do our very best while we're there, but at what point does it
> qualify as excessive?
> Ron N
>
>
>
>
>
>
>
>
>
> Reply to Sender :
http://my.ptg.org/eGroups/PostReply/?GroupId=43&SenderKey=32a3aa32-8eb7-434c-a51b-6e76a2af10b9&MID=654295&MDATE=756%253a465459&UserKey=3feecf45-4a69-4cff-bbb2-fd6c7eaf0569&sKey=KeyRemoved>
> Reply to Discussion :
http://my.ptg.org/eGroups/PostReply/?GroupId=43&MID=654295&MDATE=756%253a465459&UserKey=3feecf45-4a69-4cff-bbb2-fd6c7eaf0569&sKey=KeyRemoved>
>
>
> You are subscribed to "Pianotech" as
hgreeley@sonic.net. To change your subscriptions, go to
http://my.ptg.org/preferences?section=Subscriptions&MDATE=756%253a465459&UserKey=3feecf45-4a69-4cff-bbb2-fd6c7eaf0569&sKey=KeyRemoved. To unsubscribe from this community discussion, go to
http://my.ptg.org/HigherLogic/eGroups/Unsubscribe.aspx?UserKey=3feecf45-4a69-4cff-bbb2-fd6c7eaf0569&sKey=KeyRemoved&GroupKey=2bb4ebe8-4dba-4640-ae67-111903beaddf.
Original Message------
The pitch of a sound is the number of cycles produced in one second. If one cycle of that audio is made up of 50 digitally sampled values, the pitch of the sound does indeed depend on how fast those samples are delivered to the speakers. The digitally encoded values themselves may not change with sample rate. But the rate at which they go through one complete cycle is certainly dependent on the rate at which those 50 samples are reconstructed.
With regard to Internet pitch references, it is important to take into account how the Internet works. The Internet uses a protocol called TCP/IP. This same protocol is used when you access my.ptg.org or when you play on-line recordings of sound. Information is broken up into small packets and sent out.
Each packet of information in the TCP/IP protocol is relayed through any number of intermediate nodes. Each node passes the packet on to another node whenever it gets around to it. The node does not guarantee timely delivery of that packet. What's more, different packets can be routed through different nodes, depending on the workload of each node in the Internet. These packets can be delayed by different amounts, often in the neighborhood of 0.10 to 0.15 seconds. The result is that packets can and do often arrive out of order. This is corrected by the fact that every packet is numbered. The TCP/IP protocol uses the packet numbers to reconstruct the data stream in the correct order at your computer.
The result is that any precise timing information that might have been present at the source of the data is lost by the unpredictable packet delay of each packet of information. So if those packets happen to represent an audio stream, how does your computer decide how to deliver those audio samples to your speakers? It obviously cannot rely on the arrival times of the packets themselves, because they don't even arrive in the correct order, much less at a predictable time. So your computer (actually the browser software) buffers the audio data and sends it out to your speakers at a rate it determines. The data may be known to have been sampled at 44100 samples per second, but your computer does not know what a second is, precisely. The only way your computer can estimate time in the short run is to use one of its local crystal oscillators. If that crystal oscillator happens to be off by a few cents, the audio playback will be off in pitch by a few cents. The pitch accuracy does not come from the Internet.
I did mention "in the short run" above, because in the long run, your computer can in fact get accurate pitch information from the Internet. If your browser buffers the data before it is sent out, there is a delay between input from the Internet and output to the speakers. If your computer's idea of time is a little slow, the size of the buffered data will gradually and irregularly grow without bound. Data is coming in faster than your computer is pushing it out. Eventually your computer notices this problem and it can slightly adjust the output speed to correct the problem. Similarly, if your computer's idea of time is as little fast, it will notice that the amount of buffered data is gradually shrinking. If this goes on too long, eventually an audio sample will be due to be sent out before that audio sample has been received. The only thing the software can do at that point is to give up and pause the audio briefly. Or it might recognize the problem early on and slightly slow down the audio rendering speed.
The point is, this adjustment process is slow. An error of one cent may take 10 minutes before it can be recognized by the software. But nothing meaningful can be done to adjust the pitch reference to the Internet in the first few seconds. The pitch in the first minute or so is purely the browser's guess.
With all that said, I should add that Apple seems to have gone to great lengths to trim the effective sample rate of their iPhones and iPads at the factory. Lately I have not seen an Apple product that is off by more than 0.05 cents. So perhaps that is why everything seems to "just work" even without software calibration.
------------------------------
Robert Scott
Real-Time Specialties
Hopkins MN
------------------------------
Original Message:
Sent: 09-28-2015 02:03
From: Geoff Sykes
Subject: Pitch source
Tapping in to an online signal source that is creating the tone in real time is never going to be as accurate as tapping into a source that is sending you a digitally stored sample. And I agree with Scott that relying on a signal created by the chip set in your computer is going to give questionable results. Any signal created in your computer is going to be questionable and about as reliable as the MIDI instructions built into that chip set. Let's clarify something. A tone generated by the chip set in your computer is not the same as playing back a digitally stored sample of an accurately created real tone.
Contrary to what Robert Scott says, clock speed has nothing to do with pitch. In digital, the speed of playback cannot change the pitch. Digital, by design, simply, and deliberately, does not work that way. Regardless of the rate of conversion, or as Scott says, the sampling rate, the value of any given sample cannot change. As an example that has nothing directly to do with AD/DA conversion in audio, but has everything to do with how digital data, like audio, is stored and reproduced, the 16 bit value for the number 440, as in Hz, is 0000000110111000. No matter what speed you play that number back at, the value of that binary number cannot change. It's always going to be 0000000110111000. Play it back faster and the number will just go by faster. When you drive by a gas station at 35 mph and the sign displaying the price of gas says $3.65, the price on that sign is not going to change just because you drive by again at 60 mph.
On the other hand, if the price on that sign is being created by the chip set in your computer, driving by at a faster speed could possibly change the price. The chip set in your computer is not playing back a digital sample. It is creating, from scratch, an analog signal. And yes, clock speed will affect pitch in that instance. As will whatever Java routine you are using to generate the chip instructions in the first place.
I use a digital audio program called Audacity. With it I can manipulate playback speed, pitch and a whole slew of other qualities of an audio file. But I have to do it deliberately. In other words, if you play back, or stream, a normal digital audio file, through your computer, and don't run it through some additional hardware or software, your system will play back exactly what that file contains. 440 will be 440. If it's not then question the source, not your system. The providers may believe they are sending you a 440 sample, but they may really be sending you 440.5.
I have several signal generator apps on my phone. They all function by telling the chip set in my phone to generate a 440 Hz tone. The tone is then created in my phone, electronically. Based on the accuracy of the instruction, and the accuracy of the electronics, that value can change. Not all the signal generators in my phone, when set to 440, actually produce 440. And that's because none of them are actually playing back a digital 440 Hz sample. They are all simply sending instructions to my phone to create a 440 Hz tone from scratch. Playing back instructions is never going to provide the accuracy of playing back an accurate digital sample.
That said, thank you for speaking up in defense of reality. How close does A4 actually need to be to fall within the window of close enough? Under controlled conditions I'd venture to say that one decimal place is sufficient for an ETD. And nobody is going to be able to get a tuning set to three decimal places and have it stay for longer than you can hold your breath and avoid breathing on it. Up until modern technology helped us understand what we, as tuners, were actually listening to, and allowed us to develop an ETD that could accurately calculate tuning's based on that understanding, aural tuners did some mighty fine work. Probably not as accurate as today by ETD standards, but for more than a couple hundred years it satisfied the needs of even the most critical listeners.
-- GS
------------------------------
Geoff Sykes, RPT
Los Angeles CA
------------------------------
Original Message:
Sent: 09-28-2015 00:26
From: Ronald Nossaman
Subject: Pitch source
Okay. What do you get with a pitch played by an interactive java
routine? Robert Scott cautioned us about the reproduction of pitch
demonstrations processed through your sound chip set on line some time
back. So it would make a difference how the playback was handled. I
understand digital precision, but a precise clock cycle is still
required for that too. I don't know enough details of this to dissect it
to the bones, but an on line pitch source isn't necessarily absolute.
It's generated by one clock, and reconstituted by another.
From a realistically practical standpoint, if the sacrilege of
practicality can be allowed, it's all well within the range of those
furnace and AC cycles we routinely tune through, so it's not a real
attainable item in practice. But for the recursively anal, it's a
detectable thing, and might provide goals. This isn't intended as
picking on anything, but an attempt at overlaying some perspective on
the pitch precision thing.
Just as well finish myself off while I'm here. How many of you have been
called back because your A was 0.1 (cents) off of 440.00Hz? Hands? How
many times?
Again, I'm not trying to start a fight, but what is the actual real
world tolerance for pitch in continually cycling climate control, and
from week to week with the heat and A/C way down between uses? Sure, we
should do our very best while we're there, but at what point does it
qualify as excessive?
Ron N