So at this point the only thing that would make sense to me is that “non-pro” applications don’t read information correctly, but that Nuendo does. In addition to that then there would be a problem on the editor’s end. I don’t think Mufi’s question was answered, and I do recall there was a problem on Final Cut in some of the versions where if set up a certain way it would simply re-interpret the audio as being something it was not, compensate for that, and pull everything out of sync.
That’s really the only thing that makes sense at this point. It’d be a huge coincidence if both you and I are the anomaly as far as reading timecode from 23.98 in non-pro apps goes, meaning that it only differs for us - AND that I then have zero problems but you do. It just seems like most people would see this difference in addition to not having this issue which kind’a leaves the editor as the last unexamined part of the chain…
Thanks very much for testing this Mattias! The weird thing is that the difference is exactly the difference between 23.98fps and 24fps. I have tried to import the audio into a 24fps project and there it reads 01:28:49:17. So the length of the wav file is interpreted differently according to which frame rate the project has. There must be some way in which the wav file stores the fps information. Otherwise this does not make sense. Or there is some kind of other metadata in the wav file. Otherwise seconds should be seconds.
Audio framerate shouldn’t matter for any application.
A file of one hour is one hour, regardless if it is devided into 24 frames, 25 frames, seconds or bars & beats.
My first reaction would be that upon import, Nuendo has “forced” 23.98fps into 24, making the whole thing longer.
But you say that the BITC is matching the Nuendo timeline, so that can’t be it.
So, if it isn’t Nuendo, then …
A quick “FCP 23.98 bug” -google gave me this:
I know the bug in FCP 7. This film was edited in FCP X of all programs, which I understand is the successor of imovie.
But a bug In FCPX would only explain the out of sync in FCP. Or it couls explain a faulty film file export. The file that I have send however is an export out of Nuendo. And Nuendo interprets the length of this file differently, whether the project is set at 23.98fps or 24fps. How is that possible? Because as you said, in audio, it is all about sample rates. Frame rates should not matter.
But hold on a second: Is it not still possible that the problem lies elsewhere? Nuendo correctly interprets this because otherwise we’d surely have seen the issue many places. Perhaps simple consumer apps just “round up” to 24 frames for whatever reason and then displays the wrong duration.
So again the issue would be if FCP or the editor messes it up. I would recommend reading through that entire thread and try the workarounds, despite it referring to FCP7 originally and being a few years old. Re-stamping the file or changing format or whatever…
It is possible that the mistake originates outside of Nuendo. But how can it be an outside error, if Nuendo interprets the length of a wav file, that was exported from Nuendo, differently according to what frame rate is set in the project. At the very least, the film file from the editor need to have corrupted something in the Nuendo project. And this corruption makes it in some kind of meta data into the wav file.
You lost me now. And I’ve only had one beer… so far…
The length of the audio file is what it is according to the amount of samples and sample rate. The time code is just a division of that into frames per second. Basically what I’m saying is ‘how do you know it’s interpreting it differently from the project frame rate?’…
I honestly don’t see how that could be the case though. Surely the two engines (audio/video) are decoupled enough for that not to happen. Besides, I had a discrepancy as well when looking at a project / audio files that worked all the way through production, so it’d be odd if we’d see “the same thing” yet it’d work for me and not for you.
“Basically what I’m saying is 'how do you know it’s interpreting it differently from the project frame rate?”
I have exported this wav file from a Nuendo project. The result is a simple wav file with 48kHz sample rate. Whatever the film file in that project does, should not matter. Maybe it does not have the same length as the editor’s session, or maybe I have set the frame rate wrong. Maybe I have even pulled the session up or down. The result is still a wav file with 48kHz.
Now I am making a new project in Nuendo with 23.98fps and import the file at 00:00:00:00 the file now ends at 1:28:44:10. I close Nuendo and create a new project next. This time with 24fps. I again import the wav file and put it in at 00:00:00:00. This time the file ends at 01:28:49:17.
How is that possible? It is the same file now having a different length, more than 5s longer, because I changed the sample rate of the Nuendo project. Whether I divide a second into 23.98 frames or 24 frames, it is still a second. The only place where I would not be surprised to see a difference is at the very last two digits, because that is where the frames are counted. And incidentally, now it has the length that all other programs say the file has.
The files that you receive from FCPx can have incorrect embedded metadata in the header.
If you make a 44.1kHz file “think” (change header) that it is a 48kHz file, then you wll have the exact same problems.
And you won’t be able to solve the problem, except by changing the header information.
Just do a small test with this application and to see what happens when a file has a wrong header. http://www.railjonrogut.com/HeaderInvestigator.htm
So, I think that in some way you are facing the same problem.
Thanks for that Fredo. Unfortunately I do not have a Windows computer. Does anyone know a good similar software for mac?
What header information would I be looking for though? In both the 23.98fps session and the 24fps one I had a sample rate of 48kHz. So no matter what the header says about the sample rate of the wav file, it should at least have the same length, even if it is the wrong length. Is there any header information that stores fps?
Now I am making a new project in Nuendo with 23.98fps and import the file at 00:00:00:00 the file now ends at 1:28:44:10. I close Nuendo and create a new project next. This time with 24fps. I again import the wav file and put it in at 00:00:00:00. This time the file ends at 01:28:49:17.
I can repro that here…and I can repro it not only with your audio file but also with a mixfile of another 90 min project…
I do not think that your audio is in any way wrong (header etc).
i think Nuendo on 23.98fps does something we do not expect…But what exactly?
@Max, on the Mac I use MediaInfo (MediaInfo) from the Mac App Store. It’s a $1 tool and shows you all the media info there is I think. Downside is that you cannot change the header info, just read it. Very handy when working with video files as it shows the used compression format, fps, etc to figure out what’s going on.
I also use AudioFinder (http://icedaudio.com) that has a file info tab and is a simple and cost efficient SoundMiner replacement.
All say the same though for the file you uploaded. The file is Mono, 48kHz, 24Bits, 01:28:49.740.
My empty Nuendo project says @23.98fps:___1:28:44:09 @24.00fps:___1:28:49:18 @24.98fps:___1:28:44:10 @25.00fps:___1:28:49:18 @29.97fps:___1:28:44:12 @29.97dfps:__1:28:49:22 (what’s dfps?) @30.00fps:___1:28:49:22 @30.00dfps:__1:28:55:02
…
I think this is a Nuendo calculation issue. The question is, what’s the real length! Audio has no fps, it only has samples per second. 44.1kHz, 48kHz per second. So a file has a defined length that’s NOT tied to the fps. It’s the speed with which you play those samples that defines the length. Do you play it at 44.1 or 48? So I don’t know where those strange differences in seconds come from when switching fps in Nuendo’s Project Setup window.
I exported this WAV file in 24/48 both in 30fps and 29.97fps. Nuendo shows a different length, but after export both files are, of course, the same length. Same amount of samples. And both times the length is shown identical in all the softwares mentioned above. Something feels wrong here in the length calculation!
When it comes to the duration reading Pro Tools behaves the same; if you select 23.98 and “bounce”/“consolidate” a region from 01:00:00:00 to 02:05:00:00, then of course the duration is 01:05:00:00. If you then leave the region where it is and change to 30fps drop, the duration is 01:05:07:25.
However, any frame of reference other than “timecode”, like minutes:seconds, bars:beats, samples etc retains duration as you change the timecode. This is true for both Nuendo and PT. So I’m inclined to think that we all need to drink more coffee and that Nuendo is doing this correctly after all.
This is true for both Nuendo and PT. So I’m inclined to think that we all need to drink more coffee and that Nuendo is doing this correctly after all.
But what could the coffee make us lern? What is the difference between the Frame Rates with whole numbers 24/25/30, where seconds stay the same, as we expect. And the other ones where we get more ore less seconds for the same lengh?
This is indeed an interesting technical question. Understanding how this internally works helps avoiding confusion in the future. And learning is always helpful. So I’d be interested what’s behind this, too. Why is timecode different than time other than that it shows frames rather than milliseconds and is absolute rather than relative? And why is 24/25/30 timecode different compared to the .98 counterparts?
Apart from that, I’d like to quickly revisit the original question.
From all I’ve read here it seems to be only a display issue, where different framerates show a slightly different time in the timecode display. But what is described here is that the editor says the sound was out of sync. So I’m wondering if the sound then is really out of sync?
My theory: Probably the editor just looked at the length of the file outside of his software and saw a different time length than what he sees as timecode in his project. Which would explain the confusion and rejection. Had the editor imported the file and checked, he/she would have seen that it aligns perfectly with the project.
Is that assumption correct? Apparently .98 timecode is calculated a little differently. But when the editor imports the file, it should align and be in sync.
I think the different timecode displays and the fact that the audio was out of sync in the editor’s session are probably two different issues. It just so happened that I discovered these different timecode displays through the fact that he complained about the sync. But the out of sync is probably a problem on his part. But I can only tell that for sure, once I understand the different timecode displays.