[mattiasNYC]

JPSaxMan,

Here's what I would check:

See if there are independant sample rate settings for the soundcard and software. From what I read it definately seems like it could be a sample rate issue. I've had instances where hardware / software for whatever reason did not "set up" properly, and ended up with an audio file that in its header said it was at a specific sample rate, but where it actually was a different one.

Check the hardware: does it have separate settings (separate from recording software) for sample rate. Some hardware come with their own software utility that's used not for recording but for changing settings on the hardware.

Then do the same for software.

 

[mattiasNYC]

Sorry, but you're just waaaaay off base here....

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.

You know that any digital audio system has a clock, yes? You know what its purpose is? It's to make sure each sample is played back at the right time and frequency - i.e sample rate.

Now, remember that frequency = pitch.

So, if you record something at 44.1kHz and choose to play it back at 48kHz, the pitch WILL go up. It's just that simple. All those 1's and 0's you wrote are representing ONE value which is played back at ONE point in time, all 16 bits (or 24). It's the job of the clock to make sure that value gets played at the right time.

If speed was a problem during playback, IT HAS to be on the analog side. This is not up for argument.

The last sentence is right, because the preceding one is wrong.

There is no such thing as FAST or FASTER 000's & 111"s (0011010110010111).

Depends on how you see it. There is such a thing as faster playback of chunks of 1's/0's, meaning the speed of sample playback - sample rate. Sample = x Bits, Rate = Samples/second.

Once the digital code is converted to analog, that is where the speed
problem can manifest itself, and ONLY then.

Nope.

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.

You're not seeing all the possibilites. Files have headers containing info about what the file is ("Hi, I'm a .WAV file. I have 24bits of sample depth. Oh, and play me back at 44.1 kHz please."). Let's say it is a 44.1 kHz file and we have a Pro Tools session running at 48kHz, for example. On import the program will let you either sample rate convert the file to 48k, which will allow it to play back correctly (meaning at the same pitch), or you can import it without change. If you do the latter, it will play back at 48k, because that's the rate of the session. It doesn't matter that the file is at 44.1, it'll play back too fast with a higher pitch as a result.

So if your computer system somehow isn't "communicating properly", you could have different components running at different rates. Like I said, I once encountered screwed up headers in files, where the files said they were 44.1, but in reality were 48.

 

[mattiasNYC]

Hmm...ok...so I was wrong. I just put a metronome against my piano recording when I recorded. I went back and tried to match the same tempo against it, and it kinda is like when you have two windshield wipers and one is going faster than the other...the two start off in rhythm, then separate, then they come back together, and drift apart. So...the recording is being sped up!

And just for sakes of entertainment, I also disconnected the preamp from the computer and tried just doing a line-in with the keyboard...same thing happened, so it's not the preamp...in case that crossed anyone's mind by chance.

Would you mind checking what I wrote before?

The audio hardware may have a separate "control panel" or something similar, that may set the hardware differently than the software.

 

[mattiasNYC]

At this point, all I'm curious about is how it got to that new sample rate; I sure as hell didn't change it! LOL...well, actually JC, I noted that it was much sharper than 40 cents...almost approaching 60 cents. My keyboard can tune up to 100 cents so I set it about where it was playing back really sharp, and it was closer to 60 than 40.

But anywhoo...thanks for all the help, I guess!

Well, sometimes **** just happens! That's probably why the setting changed.

I'm glad you got your problem solved though.

m

PS. Just FIY, I too think that the discrepancy between the recorded sample rate / playback rate must have been other than 22 vs 44. Doubling in speed = doubling in pitch.....

 

[mattiasNYC]

The sample rate is NOT the issue here.

Really?

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".

Well, I figured it was safe to assume that we were talking about Hz, as we had stated that many times previously in the thread. What else would it have been? kMoron?

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).

No, sample rate doesn't refer to an amount of time, it refers to an amount of events, record/playback of samples, per second. Not an amount of time.

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

Yeah, there's sample rate and then there's clock rate. If you read the thread you'd seen that what I suggested was indeed a check of sample rate settings between software and hardware. That is clock related.

However, there's also the scenario where you record, successfully and on purpose, at 44.1 for example, and then play back that sample, successfully and on purpose, at 88.2. Without sample rate conversion the file will play back twice as fast, with a pitch twice as high - without any "fault" of the clock.

Agree?