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

Copy the last sample to the beginning
and the first two samples to the end
as guardpoints.

For playback, skip the guardpoints, like this:

The worry in this thread is that Pd is playing at the wrong speed.

The only way this could happen is if [phasor~ 1] is running at the wrong speed, because in the demo patch, phasor~ is the only thing controlling the speed.

Therefore, if there is no evidence of phasor~ running at the wrong speed, then Pd must be playing the file at the true speed!

"But what if the system sample rate differs from the file's?" The file is at the lowest sample rate in common use. If Pd is playing it slower than Audacity, then Pd would have to be running below 44.1 kHz, which is unlikely to be supported in hardware. So I'm comfortable ruling that out (not to mention that scaling the phasor~ by the file's number of samples already accounts for this). Common scenario would be: 44.1 kHz file, 48 kHz system SR, without correcting for this then Pd would play faster, but that isn't the report.

is audacity running at 44100?

I'm pretty sure Audacity has no power to override the hardware sample rate. I've never heard of soundcards issuing separate, per-app interrupts at different rates (imagine how difficult that would be, to make it work, highly implausible). AFAIK Audacity does sample rate conversion when the file is at a different rate from the hardware... just like all other audio software.

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

hjh

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

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.

hjh

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

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.

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.

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.

a noticeable difference in such a short period of time.

how much is it off?

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

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

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.