[JCBigler]

JP, are you using the full version of Adobe Audition, or the demo version?

 

[JPSaxMan]

Well, for what I just did, I used Sound Recorder. I'll go back now and try using Audition to see if that eliminates the problem. But it happened in Audition to start with, so maybe an act of God can fix everything now?

 

[JPSaxMan]

JC,

In Audition, when I record, it looks like the cursor that indicates the time is further ahead then where the recording is actually taking place. I'm sure this means something?

 

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

 

[JCBigler]

okay. In Adobe Audition, over on the left hand side of the screen, there is a groups of menus. In the one labels "Effects", there should be a group called "Time/Pitch".

Open those an make sure they are set to the default settings. For the "Stretch" setting, the default setting is 220.

 

[JPSaxMan]

Wow guys...I'm gonna feel really friggin' retarded when I tell you all this.

The sample rate was different.

I hadn't changed it, so I thought it was the same. However, just upon checking my sample rate at AA, it was at 22050...not 44100. Well, voila, when I fixed it and recorded, it was fine!

So, I fixed my own problem, through my own stupidity. Sorry for all the gray hairs that came out of my neglegnece to check the sample rate. I wouldn't have even thought to do that, though, because I hadn't changed it. Anyone know why it might have changed on me?

Wow...wonderful end to a long day :drunken: :banghead: :dontknow: .

 

[JCBigler]

my sample rate at AA, it was at 22050...not 44100. Well, voila, when I fixed it and recorded, it was fine!.

Interesting. Though I would have figured that if it was recorded at 22.05k, and played back at 44.1k it would have been pitched up an octave.

 

[JPSaxMan]

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!

 

[princeganon]

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.

as others have pointed out... this is total BS. the sample rate is simply the number of samples per second. there absolutely IS such a thing as faster 0s and 1s. if a one minute sound clip at 96k/16-bit has a bigger file size than a one minute sound clip at 44.1k/16-bit, then clearly, since they both take a minute to play back, and the samples are the same size, then the 0s and 1s MUST be read faster in the 96k version of the file.

I deal with digital audio and video all day for a living, and i've seen these kinds of problems before. They can certainly happen on the digital side. In fact, it would be near impossible for this type of problem to occur after the digital to analog conversion seeing as it would require a TIME MACHINE in order to play the file faster than it was being coverted.

The only difference between files of different sample rates, is the header information. I could go in and manually edit the header of a 44.1k wav file and change it to 96k. the file would then playback much faster and higher in pitch. thus, if the header information was written incorrectly, the file could play back at the wrong speed.

you can say this isn't up for argument all you want, but you clearly have no idea what you're talking about. I'm sorry if I sound rude, but it's a major pet peeve of mine when uninformed people spread disinformation and negate the advice of those who actually do know what they are talking about and are trying to help.

 

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

 

[Al Stevens]

The sample rate was different.

Sometimes it makes sense to pay attention to the BS.

 

[JPSaxMan]

Haha, Al, I meant the BS that was going on with arguing about the sample rates...not necessarily about what was being brought up truthfully.

 

[Al Stevens]

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

 

[Carl H.]

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

Some of it is even useful!

 

[Al Stevens]

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

 

[Giganova]

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!

 

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

 

[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?

 

[princeganon]

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

Actually, it's the unit for "thousands of samples per second," but yes close enough.

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

This is incredibly backwards logic. First of all time = pitch when talking about samples. faster samples = higher pitch. that's why pitch is also refered to as "frequency", as in how frequent the waveforms repeat. faster samples = faster waveform cycles. I suppose you could say that the sample rate refers to an amount of time... for example a sample in 44.1khz could be said to take up 1/44100 of a second... of course there's nothing in the actual sample data itself that has anything to do with frequency or sample rate. It is simply a string of numbers. The sample rate data is all in the header of the file, and changing it, will change how fast the computer plays back the samples. faster samples = faster tempo & higher pitch.

I think that some of the confusion here might come from the fact that your computer will atomatically convert sample rates in most instances. If my soundcard is set to 48khz and i try to play back a 44.1 khz file, it still plays back correctly, but that is only because the computer is compensating for the difference and converting the sample rate. This process is hidden from you, but it happens. If the computer didn't know that it was supposed to be a 44.1khz file and played it back just like any other 48k file, the pitch would be higher and the tempo would be faster.

FROM WIKIPEDIA: (the bold is mine)

SAMPLE RATE CONVERSION
Sample rate conversion is the process of converting a (usually digital) signal from one sampling rate to another, while changing the information carried by the signal as little as possible. When applied to an image, this process is often called scaling.

Sample rate conversion is needed because different systems use different sampling rates, for engineering, economic, or historical reasons. The physics of sampling merely sets minimum sampling rate (an analog signal can be sampled at any rate above twice the highest frequency contained in the signal, see Nyquist frequency), and so other factors determine the actual rates used. For example, different audio systems use different rates of 44.1, 48, and 96 kHz. As another example, American television, European television, and movies all use different numbers of frames per second. Users would like to transfer source material between these systems. Just replaying the existing data at the new rate will not normally work - it introduces large changes in pitch (for audio) and movement as well (for video), plus it cannot be done in real time. Hence sample rate conversion is required.

I really hope that settles this nonsense.