While working on a sample player, I noticed that the sample sounded slightly different when played through Audacity and when played through my Pd patch. It's hard to notice the difference (unless you have perfect pitch, which I don't), but when played through Audacity, it has a slightly higher pitch. If you play them both at the same time, the difference is obvious.

So I extracted just the essentials from my patch to illustrate. I don't know if I'm doing something wrong in my patch, but I don't see any problem. I used Audacity to create the sample in the first place, which is exactly 44,100 samples long, at a sample rate of 44,100.

Anybody see any problem with my patch?

Patch: https://drive.google.com/file/d/151cvF_9_4ViebScR_zOS-IRaQXok0XIJ/view?usp=share_link

Sound file: https://drive.google.com/file/d/18UyB1o6mOfS1oW2OhIUtpA1KdJhHBTm9/view?usp=share_link

@dfkettle said:

That wouldn't explain the difference in frequency, I don't think.

True. log2(44100 / 44097) * 1200 = 0.12 cents, not at all easily detectable to the ear.

BTW here's one test of phasor~ duration (48 kHz) -- it's spot on.

hjh

@dfkettle no, phasor is running with it's speed (should be 1Hz) the readhead and 44100 samples is still one period.

Is it 100% guaranteed that Audacity is playing it at the right speed?

That would explain trouble we had with video-audio out of sync which was appearing after >30 minutes?, at that time we blamed the cheap audio recording device's clock for it, but could possible have been Audacity, too!?

I would test Pd by recording a few seconds of [phasor~ 1], and measuring the number of samples per cycle. Obviously this should be the system sample rate, give or take floating point rounding error.

I think phasor~ has jitter due to precision limits but that shoud be +- 1 sample, not more.

I rebuilt the essential logic in your patch and I get dead-on accurate pitch between Pd and Audacity.

hjh

As for the missing guard points (even though they don't explain the difference in frequency), I loaded the file (which has exactly 41,000 samples in it) using [soundfiler] and the "-resize" option. So I guess [soundfiler] doesn't add guard points. Should it?

@dfkettle yes, you have to add them. This is for less artifacts only. And only if you playback at different speed and/or samplerate tabread4~ would be needed. For original speed, you can playback with tabread~ or tabplay~ without any interpolation, sample by sample.

I did not open your uploads.

EDIT: here is an abstraction for it https://forum.pdpatchrepo.info/topic/14301/add-delete-guard-points-to-a-table-for-4-point-interpolation-of-tabread4-ect

@ddw_music said:

I rebuilt the essential logic in your patch and I get dead-on accurate pitch between Pd and Audacity.

I don't really see any difference between your patch and mine, apart from the fact the you hard-coded the name of the file and replaced the horizontal slider with a constant value of 0.1.

@lacuna

That would explain trouble we had with video-audio out of sync which was appearing after >30 minutes?

Soundcard clocks are famously inaccurate -- if you record exactly 10 minutes of real world clock time, you probably won't get exactly sr * 600 samples. Normally this is not a terrible thing, but if you're trying to sync with video that was recorded according to a different clock, then yeah, it's a common problem. I've seen it myself. I have a SuperCollider script saved somewhere that will faster-than-realtime resample the audio to match video duration (based on by-hand duration measurements).

However, Audacity doesn't deal with video, so it can't be the problem here. If you read /n/ samples into Audacity and then export them to a different file, you should still have /n/ samples. Resampling is for playback. AFAIK if your sound card is at 48 kHz but the file is 44.1 kHz, there is no magic way that Audacity can "run at" 44.1 kHz while everything else is at 48 kHz. But the fx etc in Audacity should be working at the file's rate.

@dfkettle

So I guess [soundfiler] doesn't add guard points. Should it?

I would say no, because [soundfiler] doesn't know what you plan to do with the data.

hjh

clocks are famously inaccurate

As I have been writing, this is what we assumed - and still might be most likely, but as far as I remember Audacity on a Mac has been involved in the post-production, too.

@lacuna said:

clocks are famously inaccurate

As I have been writing, this is what we assumed - and still might be most likely, but as far as I remember Audacity on a Mac has been involved in the post-production, too.

I didn't record the file with Audacity, I used the generate function (Generate->Pluck... in the main menu). So I don't think the clock would even be involved in generating the file. Playing it back would involve the clock, I guess, but the file is only one second long. The clock would have to be very inaccurate to produce a noticeable difference in such a short period of time.

Yes, also Audacity and PD should rely on the same clock. And for playback of the same file, the recording clock doesn't matter.
But we don't know what Audacity does, that's all I wanted to say.
@dfkettle said:

a noticeable difference in such a short period of time.

how much is it off?

@lacuna said:

clocks are famously inaccurate

As I have been writing, this is what we assumed - and still might be most likely

In SuperCollider, after booting the audio engine, you can ask it .sampleRate and .actualSampleRate. The latter fluctuates, sometimes as much as a dozen or two samples per second (especially for built-in audio interfaces).

Once the signal is sampled, you're stuck with it, apart from resampling after the fact.

but as far as I remember Audacity on a Mac has been involved in the post-production, too.

Audacity should not resample anything unless you tell it to, by "Change Speed." It will not automatically fix a recording rate mismatch (it can't, because there's no way to determine from a stream of audio samples how fast it was actually recorded vs the nominal sample rate) and it should definitely not make matters worse. Let's nip this bit of folklore in the bud. Audacity, /n/ samples imported --> /n/ samples exported.

Audacity playback and Audacity export are different mechanisms.

hjh

@ddw_music You could well be right........ waspi soundcard rate mismatch in windows 10 (the screenshots look like Windows >7)..... https://forum.audacityteam.org/t/audacity-playback-is-too-fast/45964

Except that the sample was copied to Pd from a recording in Audacity, and the Audacity problem is famously intermittent.
David.

@ddw_music
agree with everything you said about how such an offline DAW, as Audacity, should be working, but do not remember how the recordings have been processed, just know it has been rather complicated, there might have been some resampling involved as well.

Is it 100% guaranteed that Audacity is playing it at the right speed?

was your question and I read it like: can we trust Audacity more than Pd? My answer was no, with my experience, which is most likely offtopic.
Now I realize that you might have adressed the settings with your question.
....
@dfkettle said:

The clock would have to be very inaccurate to produce a noticeable difference

Agree with this.

anyway

.actualSampleRate

is interesting. Do you know how SC measures this?

In PD, all I could come up is this:

clock-jitter-pd.pd

but feels like measuring bullshit, as it just compares the drift of two clocks against one another, or worse, one calculation on top of a clock against another, within the same system (while the control objects have a lower priority in the schedule, are not time-critical). I think a "real" measure would require an external calibrated frequency-counter device.

How accurate is [realtime] ?
[cputime] doesn't seem to work here on Windows.

re: guard points: You're still telling tabread4~ to go from 0 to 44099 in 1 second. The only thing that will happen is that the read point is clipped between the 2nd and 2nd-to-last samples, but that doesn't influence the playback rate at all. You'll get repeated values where you 'would' read the 1st and last samples, that's it.

@seb-harmonik.ar
to be precise: reading from sample 1 (skipping sample 0, as it is a guard point) to arraysize-2
makes still 44100 samples. And yes, doesn't influence the playback-rate, neither the perceived pitch at all.

also I don't think I can hear any difference in vlc vs. pd here in jack on linux. So I don't think it's a pd issue.
edit: maybe you could somehow record the stuff going to your soundcard (or some capture software) and try to figure out the difference between the sound files when they're played in pd vs. played in audacity, if you're really curious. To me it seems most likely to be an audacity playback issue.
edit: seems possibly like what's mentioned in david's forum link above. Check your device playback and recording advanced property settings in the windows settings. (specifically device sample rate)
https://forum.audacityteam.org/t/playback-is-too-fast-and-high-pitched/61159/2

@lacuna you tell it to read from 0 and go to arraysize-1, but where it would read the 1st sample it outputs the value of the read point for the 2nd sample (as the 1st is a 'guard point') and where it would read the last sample it reads the value at the read point for the 2nd-to-last (as the last is another 'guard point')
I'm not sure I'd say they get 'skipped', but maybe 'replaced' or 'clipped'

@seb-harmonik.ar

please try this help file:
https://forum.pdpatchrepo.info/topic/14301/add-delete-guard-points-of-an-array-for-4-point-interpolation-of-tabread4-ect

The Lagrange interpolation uses n-1, n, n+1 and n+2 for interpolation at sample n+frac.

The only way without harsh artifacts with such a small array of 32 samples + 3 guardpoints = 35 (sample 0 to 34)
is reading it from sample 1 to 32
reading the sine wave only and using the guard points (0, 33, 34) for interpolation.
As patched above.

Looking again into

else\Live-Electronics-Tutorial\Part.07-Sampling.Delay.Granulation\27-Sampling(buffer)\3.Interpolation

Yes, the read-points are clipped. But that clipping causes a discontinuity of the sine.

It gets less obvious and even non-perceivable with higher resolution samples, because the artifacts become more silent and phasor~'s frequency running it, stays the same.

B04.tabread4.interpolation.pd is using [+~ 1] instead of the [1( into the right inlet of [tabread4~] :

I'm not sure how many of these comments are addressed to me or the other David, but in any case, I'm getting a little confused. To get back to my original post (and ignoring the issue of guard points, which I know is important but not really relevant to my question), I'd like to reiterate:

1. I didn't use Audacity to record anything, I just used it to create a sound file with one of the built-in UGEN's (create a new track, then click on 'Generate->Pluck...' in the toolbar). Really, the file could have originated anywhere, and whether or not there were timing inaccuracies when it was created is completely irrelevant. I'm just comparing the way it sounds when played back in Audacity vs. when it's played back in my Pure Data patch.

2. Someone asked me "how much is it off by"; I'm not sure how to answer that, except to say that it sounds about one semi-tone higher in Audacity than it does in Pure Data, although I don't have a very good ear for pitch. (If the problem was in Audacity, wouldn't the frequency be lower in Audacity than in Pure Data or is that an over-simplification?)

3. I don't think I mentioned this, but I'm running both on the same computer, a HP-P6230F (with a quad-core processor running at 2.60 GHz running Windows 10 64-bit). I was going to provide a link to the specs on the HP web site, but they seem to have removed the page (it's an old computer). I'm running Pure Data 0.53.2, 64-bit, and Audacity 3.2.5, 64-bit.

4. Also not previously mentioned, I tried running Pd in both real-time and non-real-time mode, but it didn't seem to make any difference.

I appreciate everyone's help, but can we limit the discussion to my original question and ignore other issues like guard points, interpolation (which I don't think applies to my question, since I'm playing the file back at the original speed) and problems related to recording in Audacity? They probably deserve a thread of their own, anyway.

@dfkettle well sorry for my part in derailing (in my defense, originally clarifying that it wasn't the 'guard points' that were responsible for any pitch difference)
Now, the issue is not so much recording in Audacity as it is playing back in Audacity. Did you look at the link I posted above and the link from other David? What is your current system device playback sample rate?
edit: to clarify, it could very well be that audacity is generating plucks for 44,100 samplerate but playing them back at a higher one.