Recording speed issue with Audacity

Hi, i’m a newbie to the Forum and Audacity software.
I’ve installed Audacity v1.2.6 and hooked up my tape player to convert cassettes.

However, having the following problem:

When playing back after recording, i find that the recording plays much slower than the original. Not only that, it starts off ok and then about 2 or 3 minutes into the song, it slows right down.
I have tried to get around this by changing the speed in Audacity right down and then turning it back up to the original speed. However, as you can imagine, this is so time consuming as I have many tapes.

Has anyone experienced this and is there a ‘fix’ or some setting that I have to make?

Many Thanks

This is not a very common problem, but we had a very similar thing a couple of months ago:

(read the whole topic - there are a number of possibilities that get discussed).

I have a similar probleme, and with rather curious behaviors.
I use a usb sound card (Alesis IO2) and work under winXp and linux (ubuntu 7.10), with a laptop (dell précision) and a desktop PC (HP d330), and audacity v 1.3.4. I use a tunning fork (an old one at 435 hz) as reference, and record it.
Playing it back, i hear it in some cases a half ton too high or a half ton too low. Using the spectrum analysis fonction, i found either ~397 hz or ~473 hz.
More curious and interesting, on winXP it’s always too high, on linux it’s always too low.
Playing with CubaseLE (on winXP), I had the same problem, but which was resolved if playing with the sampling frequency (44.1 versus 48 kHz). Thinking it could be a harware issue, i’ve contact Alesis. They told me that trought the ASIO driver the audio interface can be configured up to 48 kHz, but without the ASIO (as with audacity) it work at 44.1 kHz by defect.
Configuring audacity in 48 kHtz, the first record is ok, but the next are shifted, as long a first track is open. It’s ok as long as only one track is open, that’s recording. It seems that there is a sampling frequency jam between the software and the hardware, as a new track is open.
The same configuration (24 bit/48kHz) tested with auacity 1.2 , on winXP, works with several tracks open, without problemes…
There are much combination, between the OS, software, settings, and I’ve not tried all of that, of coarse !

Has someone an idee where to look further ?

It is quite common for hardware to have a fixed sample rate - in this case probably 48 kHz. If the hardware is asked for a different sample rate, then it’s possibly that the driver re-samples the signal on the fly, but is doing so at low resolution so as to keep up with the data, which could account for the pitch shift. Setting the Audacity Project Rate to 48 kHz should fix it in this case. 24 bit recording can be a bit flaky on some machines, (especially Macs), I generally use 16 bit or occasionally 32 bit if I want the extra dynamic range.

Ok, that’s what I thought. Alesis was not very clear in their answer, if the ASIO driver convert a fixed 48 kHz signal to the requested frequency or if it configures the hardware itself. I’ll ask them again.

But this does not explain the track effect, and the difference in behaviour between v 1.2 and v 1.3. Why is the first track in v 1.3 ok, and the next shifted ? This seems more to be an audacity issue.
It does not explain too the difference between winXP and linux !

The ASIO driver for your hardware is most likely fixed at 48 kHz.

No it does not explain a difference between v.1.2.6 and 1.3.4 (did you say there was a difference?) If there is a difference, it may be due to different versions of portaudio, or it may be an unfathomable mystery (at least for us mortals).

Differences between Linux and Windows - different drivers and different sound systems leading to different errors (possibly one “rounding up” when converting and one “rounding down” when converting) - quite possible.

I’m not clear what you mean here (and I gather this is central to what you are saying).
With Audacity 1.2 , on WinXP, it works correctly and reliably when set to 48 kHz sample rate?
Can you reproduce this with v.1.3.4 on WinXP?
Can you reproduce this in Linux?

The test is the following : I start audacity V1.3, set the default values at 24 bit 48 kHz and make a first record, which is OK. Then, living this first track open, I make a second record. A second track is open, and after stoping the record, playing the two track back, the first is OK but the second is shifted. Recording a third track, it is shifted too. Now, I restart all from the beginning, but after the first record, I close the track. The next record is now a new first track, and it’s ok. And the second one is shifted again. And so on.
With v1.2, with the 48kHz setting, I can record two, three, four tracks, which are all ok.

I made this two test only on winXP. On linux, I have only v1.3, but it behaviour is the same than on winXP, only the way of the shift is different.

About this shift, what is curious is that it is exactly the difference in frequency bewteen 44.1 and 48 kHz. In one way or in the other. It seems that the signal is reccored at one frequency, but replayd at the other, independently of the settings.

I’ll made some more tests tomorrow evening.

Ah ha! I think what is happening is the “latency correction” is messing things up.

Latency correction is a new feature in v.1.3 that makes tracks line up far more accurately than in v.1.2, but only when it is set up correctly.

When you play back a track, it takes a certain amount of time for the sound to wind its way from the hard drive, through the hardware, software and audio buffers and out through your speakers. Similarly, it takes time for signals that are being recorded to traverse the opposite route. In order to cater for this, Audacity 1.3 uses something called “latency correction”. In v.1.2 this was set automatically at a fixed amount and was usually quite close, but unlikely to be spot on, as the amount of correction varies according to your setup. In Audacity 1.3 it is adjustable and should enable new tracks to line up with previous tracks with an accuracy within a few thousandths of a second.

How it works is simple - after the recording is “stopped”, Audacity will “shift” the track by an amount set by the the latency correction setting.

It seems that switching to 48 kHz has solved the initial problem, but that the latency correction settings are way out.

Alatham wrote a nice little guide to setting up latency correction here:

First a precision : my native languge is not english, so i’ve perheps used the wrong words. When I said “playing back”, it is not listening one track during the reccording of an other. I always stopped the reccording, mute all other tracks and only played the last recorded track. In that case, there is no latency question. If it would be a latency question, one would have a lag in the timescale, as shown on the screen capture from the link you have indicated, not a shift in the audio fréquency. An A4 at 440 Hz would not been shifted to 475 Hz, but the beginning of the A4 sound would begin a few tenth of ms later than expected.

I’ve made some new tests which confirm what I wrote yesterday. : With V1.2, whatever sampling frequency is set by default in the preferences, all the tracks are always reccorded at 48kHz. It seems that at the starting of the reccording, le sound card impose its frequency, and audacity obey ! Even set at 22 kHz or lower.

With V1.3, all the tracks are indicated to have been recorded at the default sampling frequency, but there is always a constant ~4 kHz sampling difference (48 minus 44.1 kHz) between the first track and the following. Choosing 48 kHz as default, the first is right and the following are in fact at 44.1. But there is still 48 kHz written in all tracks ! Changing it after reccording, from 48 (indicated) to 44.1 corrects the frequency shift.

The question seems to be why V1.3 changes the effective used sampling frequency between the first track and the others, as V1.2 do not.

As long as I configure V1.3 at 48 kHz, I can correct the effect, but… it’s not satisfactory to reccord wrong and correct after ! Even if the correction is easy.

OK, I understand what you mean, and you’re right, it’s not a “latency” issue.

I’ve looked back through your posts, and this bit stood out:

As they indicate, Audacity does not support ASIO, but it sounds like it is only their ASIO driver that works correctly.
Audacity will use the WDM driver in Windows and (probably) ALSA in Linux. Although your hardware mostly supports the use of these drivers, there is clearly an issue that is dropping the sample rate back down to 44.1, even though Audacity is saying that it wants 48 kHz,

I’ve no idea why Audacity 1.2 should work correctly, but not 1.3.
Does v.1.3 work set to 44.1 kHz?

From the Alesis literature, it seems that they expect the device to be used on Windows or Mac using the ASIO driver. The hardware is certainly running at 24 bit 48 kHz internally, which is no doubt fine when using ASIO, but not fine when using Audacity (which cannot use ASIO).

Sorry I can’t help with this as I don’t have the same hardware, so I can’t reproduce the fault to find a solution. Perhaps you will need to do the recording in Audacity 1.2, save the project, then open the project for editing in 1.3 after you have finished the recording stage. (Note that Audacity 1.3 can open 1.2 projects, but v.1.2 can not open v.1.3 projects)