[Al Stevens]

Does the playback speed change proportionately, too?

 

[Al Stevens]

You have to do some experimenting to eliminate various possibilites.

It's not your playback system. I downloaded the mp3, and it is sharp. Do you save the file as an mp3 or do you save it as a wav and then convert it? If the latter, is the wav file also sharp? If so, the problem is somewhere in your recording setup. If the former, try the latter and then check the wav file. If the wav file is okay, then the problem is in your mp3 encoder. If the wav file is sharp, the problem is somewhere in the recording setup.

The real clue is that it happens with Sound Recorder, so it cannot be an inadvertant plugin. That conclusion assumes that the wav or mp3 produced by Sound Recorded is sharp.

 

[Al Stevens]

I can't think of ANY way that the pitch changes in a digital recording setup, unless you had/have a pitch correction plugin or changed the bpm of the track.

I can't count the number of times I've said such a thing to myself when encountering yet another software error, many of which I created myself.

With no more information than we have, my vote is for bugs in the codec during MP3 compression.

 

[Al Stevens]

• It can't be faulty compression if it happens in sound recorder, because it uses no compression.

Yes it does if you tell it to. File/Properties/Recording Formats/Convert Now/Attributes. We can't eliminate compression because the original poster has not answered these essential questione:

1. Does it happen if you save the file as a .wav and do not convert to mp3?
2. Does playback speed change proportionately with pitch?

Until he answers those questions, everything points to faulty compression. And he hasn't run a comprehensive set of tests to eliminate all the things that could go wrong. We're just whistling in the dark.

 

[Al Stevens]

i stand corrected. still, the chances of this happening in both apps is near zero, unless he has a faulty mp3 codec.

Which is why I draw the conclusion I stated above, given what we know so far.

I guess the original poster doesn't understand those two essential questions. If he wants us to solve this problem he'll have to address them.

 

[Al Stevens]

Sample rate issues would not create speed problems on playback.

Digital code is 16 bit 000's and 111's. (0011010110010111) it either IS
read properly or not at all. If speed was a problem during playback,
IT HAS to be on the analog side. This is not up for argument. There is
no such thing as FAST or FASTER 000's & 111"s (0011010110010111).
Once the digital code is converted to analog, that is where the speed
problem can manifest itself, and ONLY then . If digital settings are affecting
playback, it has to be some code that is tied into the analog control stages somewhere.
This is still an analog problem, and not a decoding one.

Not necessarily true. The sample rate is the number of samples per second that were recorded and that, of course, must be played back. So, if you record something at, say, 22050 hz and then tell the playback mechanism that it is to be played back at, say, 44100 hz, well, you can figure out what it will sound like. All you have to change in a .wav file is one value to make that happen. All the samples will remain as recorded, i.e. the 16 bit words of ones and zeros that you mentioned, but playback will be kind of, well, off speed and off pitch. A lot.

So, if a bum codec diddles with the sample rate either when encoding or decoding and either on input or output, that is clearly a digital problem not an analog one, and that will definitely generate funny audio.

I'm not arguing that this it what happened here, but without more evidence, and given the OP's assurance that he did everything right, it is the most likely answer.

I doubt that it is an analog problem because the OP's mp3 file plays back on my system with the pitch problems that he complains about. It's a digital problem somewhere in his system. Or else he really plays sharp.

Of course, these mysteries are always less fascinating once we learn the real culprit. We might find that he recorded to a cassette on one deck and ripped it into an mp3 on another, and one of the decks is out of calibration, in which case you would be right. Stranger things have happened.

 

[Al Stevens]

Ok...sorry about not answering that critical question. No, the tempo was not changed at all.

Not even a tiny little bit? You wouldn't really notice the tempo change you get with that small of a pitch change unless you really listen for it and can compare it to the original.

Now, please answer the other question about the wav file.

And if you really think what we are saying is BS, then you really don't want the help of people who know about these things. So, if you want us to stop trying to help you, tell us again that what we are saying is BS, and I for one will gladly and quietly slip away and let you work it out on your own.

And, no, it can't be because you are running on battery power. It's all DC by the time it gets to the board irrespective of where it originates.

Unless, of course, you are using a turntable and use 60 cps where 50 is expected.

 

[Al Stevens]

The sample rate was different.

Sometimes it makes sense to pay attention to the BS.

 

[Al Stevens]

You can learn a lot by listening to folks debate a subject.

 

[Al Stevens]

And some of what you learn is how to tell whether it's useful.

 

[Al Stevens]

The sample rate is NOT the issue here.

Toobz is still right that sample rate issues would not create speed problems on playback. You all have to be more careful when you talk about these things: Statements like "it was recorded at 22.05k, and played back at 44.1k" don't make sense because a sample rate is in kHz, which is the unit for "samples PER SECOND". Therefore, a sample rate alone doesn't change pitch because a sample rate of is always referring to an amount of time (in units of seconds).

Therefore, the CLOCK of your sequencing software was not locked it and off!

Toobz is not right. And neither are you at least as far as this argument goes.

Change the sample rate as a value in the wav header, and you change the speed and pitch of playback. Period. Argue all you want, but this is a fact. If you record samples at one sample rate and then play back the same samples at a different sample rate, speed and pitch are indeed affected.

Consider this scenario:

You tell the playback device, "Take a second to play back the next 44100 samples." But you previously told the record device, "Capture and record samples at 22050 samples per second."

The effect is that it takes a second to play two seconds worth of audio. The result is double the speed and pitch. Twice as fast and up an octave.

Samples are just raw PCM (pulse coded modulation) digital data. A long stream of ones and zeros. Three variables, which are not a part of the sample data themselves, effect how samples are recorded and played back. These are, sample rate (samples per second), number of channels (typically 1 for mono, 2 for stereo), and resolution (sample size in bits, whether each sample is an integer or a floating point number, and byte order (lsb/msb, et al). If you change any of these variables so that its value is not the value with which the raw PCM data were captured during recording, you at best change the pitch and speed of playback, and, in some cases can make the audio unintelligible.

(Other variables come into play with MP3 compression. Here I'm talking only about uncompressed audio.)

 

[Al Stevens]

Well, with each of my sequencing software, I can record and play back at any sample rate I want, and it never changes the pitch because the software looks into the file and detects the sample rate.

Of course you can, unless you record at one sample rate and play the recorded samples back at a different sample rate, in which case the pitch and speed get munged up. Instead of continuing to insist that this is not the case, why don't you just try it? If you don't know how, I can tell you.