Sampling rate too high/time-code incorrect

Installation & Configuration Linux
#1

Hello,
i am very new to this forum and kind of new to ardour too. I couldn’t find anything for my problem, i tried but i don’t really know what to look for. If there already is a topic for this, please tell me.

I am running ardour 5.5 on a Laptop with Debian 9 and yesterday i pretty much fucked up.I know this is not really a software Problem but more a big mistake i made, but maybe there’s a solution nevertheless.

I recorded a 17-track session through a Behringer x32 Mixing Console. The x32 is able to do 44.1kHz and 48kHz sampling-rates. For whatever Reason (i don’t know why i did it) i started a session with 192kHz and started recording. Now the console sent audio at a lower sampling-rate (48kHz probably) but ardour recorded at 192kHz which led to the time-code being wrong (i.e. a second in ardour was much longer than a real second). So i have audio at 48k samples/second which is recognized as 192k samples/second and thus played “too slow”. If i play it back in ardour everything sounds the way it should but if i export it, no matter at what sampling-rate, it’s pitched too high.

Now i see three solutions for this problem but none of them are very desirable to me:

  1. redo the whole session (which would be horrible as we spent 7 hours recording)
  2. play it back through my interface (so to speak, convert it back to analog) and re-record to another computer. I’m afraid to loose quality here
  3. Import th exported files to audacity and just change pitch and speed. This will definitely make a poor sound.

So does anybody know of a different, more elegant solution to this problem? Is there a way to “tell” ardour what i did wrong and to change the timecode so the sampling-rate will go down to 48kHz without actually changing any of the audio?

#2

Go into the project directory, into the interchange directory, go into the directory with the project name, into the audiofiles directory.
There you will find the audio files which Ardour is using in the project. Use sndfile-info (in Fedora part of the libsndfile-utils package, not sure what the equivalent is for Debian) to print the format of one of the wav files in the project.
You should get something like this on the output:
File : Pilot-1.wav
Length : 2252856
RIFF : 2252848
WAVE
fmt : 16
Format : 0x3 => WAVE_FORMAT_IEEE_FLOAT
Channels : 1
Sample Rate : 48000
Block Align : 4
Bit Width : 32
Bytes/sec : 192000
fact : 4
frames : 563200
data : 2252800
End

Unless you changed the defaults you will probably have the same format, check the sample rate and see what rate Ardour thinks the file is recorded at.
Based on that there may be a couple of ways to go. I am suspicious of your interpretation of what is happening because Ardour should usually display an error if the audio device rate does not actually match the session rate.
After you verify what the file header reports, double check the session file, that will be the file ending in .ardour at the top level of the project. The second line shoud have a sample-rate= field indicating the session sample rate. That should match the file header.

If the session file and the wav file header both indicate 192kHz sampling rate, you may be able to copy the entire session directory (as a backup in case you break something in this process), change the .ardour file to indicate 48000 for the sample rate instead of 192000, then modify the headers of the wav files to indicate 48000 instead of 192000.

I think sox may be the easiest way to change the file header on linux, but I’m still researching that. Check the man page for sox, look at the -r or --rate command, make sure to give it for the input file only, if you use that on the output file side it will run sample rate conversion which is not what you want.

#3

Thank you very much, you saved my ass. I still don’t know why ardour didn’t print an error or a warning. I changed the sampling-rate in the project-file. Sox works fine for changing the header of the wav-files, but that wasn’t necessary. Now, the files are listed as 192kHz but are effectively 48kHz, ardour plays them back at the right speed, because the project is 48kHz but the files aren’t. Thanks again. In the end all it took was changing the project-file.

#4

hi, Willi, and everyone,

I’ve just had the exact same problem…
months ago I had recorded some music, and I don’t know for what reason, but I had set the sample rate to 192khz :slight_smile: :slight_smile:

(for science’s sake: my interface runs at 48khz – although I think this should be irrelevant)

so, when I opened the session now, it played fine, like always…
(this has been my only 192hz session among all)

But I wanted to join two sessions, cause the two sessions consisted of one track each :slight_smile:

and normal logic told me to just import the original wav file
but it played screwed up… at a wrong speed, high speed, the “file” became 39 seconds instead of almost 3 minutes… – that fast :slight_smile:

then I wanted to import the original file into a new session, with 48khz sample rate…
sounded the same, mice singing…

then I exported the track, and also the session, at session rate and at other rates and formats, too…

even I opened the files in Audacity…

ALL FAILED…
it played FAST… and the duration was 39 seconds instead of nearly 3 minutes…

… solution:
THEN I read a forum post here, by Cyrus Adkisson, and he said he didn’t take “NO” for an answer which he had got regarding if he could change the project’s sample rate…

and I learned from him the idea:

open the ardour project file | AFTER MAKING A BACKUP, and ONLY AFTER THAT | in a text editor, and look at it…

and right in the second line of the XML code there it was:
<Session version="3002" name="guit-R---theme--note" sample-rate="192000"

and that was it…

I copied the entire directory to a new name: “name-new”,
and changed the name of the ardour file so it would match the directory name…
and now opened it in the text enditor and change 192000 to 48000
and that was it…

and then opened it…
NOW the 192hz project / session was 48hz…

and I could export it like normal, I could open its original files, and it played like normal too, I could edit, etc…

It took me an hour…
thank god it was just an ad hoc recording :slight_smile:
but it was really annoying, cause Ardour is a robust, safe and reliable, and professional application, and I would have felt sick if I hadn’t been able to make it work perfectly in this situation, too…

– sorry for the length, I hope this will help somebody some day, like Cyrus Adkisson’s post helped me now :slight_smile:

#5

Chris,
you’re absolutely right:

“Ardour should usually display an error if the audio device rate does not actually match the session rate”

also, your help that you gave to Willi was pretty sophisticated!!!

and now I see that what I’ve just said above, that “I don’t think it should matter at all whether my audio interface’s sample rate is lower than the recording session’s” is wrong…

it absolutely does matter…
that’s why we should never use a higher sample rate when recording that our interface allows us for…

also, that’s why an error message is necessary when the recording session’s sample rate is higher than the audio interface’s…

options above the interface’s session rate should be grayed out, by the way…

anyway: all is well!! :slight_smile: