Strange 44.1K v. 48K behaviour.

I have a file that was recorded via a MOTU 828mkII interface locked to 48K external wordclock but with AA1.5 accidentally set to 44.1K. Therefore the saved .wav file's header identifies it as being a 44.1K file. When played back via the MOTU, clocked at 48K as before, in AA1.5, using WDM drivers, it plays at the wrong pitch. But playing back in AA2 or 3 using ASIO with the MOTU it somehow plays at the correct pitch although the MOTU indicates it is still working from a 48K clock.

The duration of the file shows the same time in both AA 1.5 and 2/3. Sample rate converting the file to 48K makes the .wav header correct and gives the correct pitch in both old and new Auditions. Any explanations?

As I read it, you have 48kHz data in a file with a 44.1kHz header.  Playing to the MOTU using WDM, Windows takes it on itself to rate convert from the supposed 44.1kHz of the file to the MOTU setting of 48kHz, thus lowering the pitch because AA is handing the samples to Windows at the (too slow) rate of 44.1kHz.  ASIO drivers do not do this, so you got the correct result because AA just handed out the samples at the rate the MOTU asked for them, which was the correct 48kHz.  Changing the description of the data to be correct (as opposed to actual sample rate conversion) makes everything behave as expected.

Paul

I did try editing the header to make the file look like a proper 48K one but it still played incorrectly in AA 1.5.

Actually the pitch was higher than it should have been when played from AA 1.5!

If I've understood this correctly, doesn't this mean that there is a bug somewhere? I've always thought that AA queried the device sourcing the data and either sample rate converted as the data was incoming or gave a warning. I didn't think that under any normal circumstances you should end up with a header that didn't match the data.

I'll try to remember which of my interfaces allow me to lock the sample rate and try this here tomorrow.

I would guess this works similar to input via S/PDIF. If you don't tell the program the correct sample rate, the recorded audio plays at the wrong speed. There is no difference in the data. You get what was sent from the external device, the file control information is simply incorrect.

The Moto is external and sends only digital data, a finished product. "Normally" the recording program would determine the sample rate and control the Moto's clock. Since you chose an external clock, the program has no control and no ‘knowledge' of external events. It can only collect the incoming data into a file and label the file as what you told the program it is supposed to be.

If you use Adjust Sample Rate to reset the control information, and re-save the file, no data gets changed, only the header information is updated. Playback will now be at the new rate you set in the Adjust dialogue.

Andy, I agree with all that, but still think that Audition should and used to warn me if I was setting contradictory sample rates. I confess that I haven't tried this for years, which I why I feel the need to test for myself.

The reason for leaving it till tomorrow is twofold. I'm not near a machine where I can check at the moment and also I'm hoping someone else will try it first and let me be lazy

The only version I can speak to is CE2K. It won't tell you. But, how could it possibly know? There is no information about sample rate in the data it is receiving. The sample rate could be 16kHz, it could be 96kHz, the data would be the same: sample values, which are amplitude measures.

If I've understood this correctly, doesn't this mean that there is a bug somewhere? I've always thought that AA queried the device sourcing the data and either sample rate converted as the data was incoming or gave a warning. I didn't think that under any normal circumstances you should end up with a header that didn't match the data.

Andy's correct, and so are you - almost - when it comes to CEP/AA initiating a recording...

The software initiating a recording sends commands to the sound device telling it what rate to sample at, and what output format it would like to see. But when it comes to a S/PDIF feed, this doesn't work because those settings are over-ruled by the source. So for instance, if I connect my DAB radio to a sound device and let it provide sync for it, that's what the device streams out - regardless of what the software tells it.

But the software thinks it's issued a command - and doesn't check to see if has been obeyed. So the 48k stream from my DAB radio gets a 44.1k file header if I'm not careful. And plays a semitone wrong.

I did try editing the header to make the file look like a proper 48K one but it still played incorrectly in AA 1.5. Actually the pitch was higher than it should have been when played from AA 1.5!

pwhodges' explanation seems to be the correct one. If you just edit the header, then you've got 48k audio playing at 44.1k. But if you play this back into a device still being clocked at 48k you will stream 48k data 48/44.1k fast back into it, and that's why it plays back at a higher pitch. The other thing you'd notice after a while is bloody great clonks in the audio when the data clocks don't conincide any more!

The procedure for correcting this is to do a sample rate conversion, and simply save the resulting file. And I'm pretty sure that there's no other simple way around this at all, even though in theory there ought to be.

Everything that everybody has said makes sense. Except for the fact that the file plays back at the correct pitch in AA2/3

The sample mismatch is a two-way street.  Just as the incoming data can be 48Khz but Audition/Cool Edit flags it as 44.1, yet the sound card locks on and captures all the data correctly, the reverse can occur: upon playback, without WDM active to surrepetitiously resample, you can stream a 44.1 file back out at 48 if the clock is set to it and the program doesn't pay attention to whether or not it's being obeyed.  A real 44.1 file would sound a half-step fast.

Well it is pitched up when played back by AA 1.5 via WDM but at the correct pitch when played back from AA 2/3 via ASIO. So ASIO is taking no notice of the incorrect header but WDM is trying to correct it by sample rate converting upwards although the actual data doesn't need to be.

Hmmm... so it sounds like the WDM driver is recognizing the mismatch and is automatically trying to do something about it.