Weird Timing Issues in Sonar X3

I came back to an audio project that I recorded over two days a week apart about a month ago. All the tracks recorded on the first day played back perfectly, but the tracks recorded on the second day came out playing slow and detuned by about 2 semitones. They are all in the same project on the same screen and there is no visual or any other indication of any change; I just happen to know which was the last song of the first session and the first song of the second.
 
The project tempo is 120, sampling rate 44.1/24 bits. I thought maybe I did another project at a different tempo in between the sessions, so tried altering the tempo of the project. Aside from reducing/enlarging track sizes and messing up edits it had no effect on what I heard: detuned audio. 
 
It seems bizarre: How can this happen within the same project where all tracks are covered by the same tempo settings???
 
I tried copying one of the songs to a new project with the same tempo setting. Unfortunately doing that cause Sonar to crash... not impressive! After closing and re-starting the program and trying aagin a couple of times with more crashes, I managed to copy one clip of the detuned songs to a new project file without Sonar crashing. Hey presto, it played in tempo at perfect pitch!
 
This problem shut down a whole session, and I need to get it fixed before the musicians come back. Please help!
 
BP
 
 

Sounds like your interface was running at 48kHz during the second session, but the driver didn't report that change properly so SONAR wrote 44.1kHz file headers per the project setting and is now plaything them back at that lower rate.
 
The simplest solution is probably to Google for a free WAV file editor that can change the  file header to 48kHz, and then re-import the file into the SONAR project; SONAR will write a new file at 44.1kHz to match the project setting.

Sorry, I had no way of knowing how many clips were involved. If you did that much recording and editing in the second session, I'm really surprised SONAR didn't report a problem at some point.
 
Normally SONAR would have requested the interface to change sample rates to match the project when it was loaded, and if the interface didn't respond, SONAR would have thrown an error about the mismatch, and not allowed you to record more audio. That's why I say the driver must not have reported the original change to 48 or falsely reported that it had switched back to 44.1. I switch back and forth between 44.1 and 48 frequently, and have never ended up with audio recorded at the wrong rate, but I know this can happen with some interfaces/configurations; I suspect this is more common with WDM drivers that can be used by the O/S and generic multimedia apps.
 
The first step would be to confirm that the problem with the detuned clips is what I surmised: that the file headers don't match the content. Unfortunately, if that's the case, you have no option but to correct them outside of SONAR, and re-import them to the 44.1kHz project. Possibly there's an app out there than can do the header re-write as a batch job, but the manual re-import of every clip to its proper location in SONAR is unavoidable. You could try re-sampling them to 44.1kHz outside of SONAR after fixing the headers, and just opening the project with the modified files using the original names, but the way SONAR references clip lengths internally by the number of samples can result in truncated audio when going from a high rate to a lower rate.

This was the first hit searching for "wave header edit" in Google
http://sound.stackexchange.com/questions/32980/wav-file-recorded-with-wrong-header
It suggests a few ways to fix the header. There were quite a few other hits on Google.
 

Cool. I did not suggest that because I thought you would just end up with the the detuned audio being exported.