MacIntosh video/audio out of sync after 30 mins or so
- Thread starter jpham
- Start date
jamedia.uk
Well-known member
Not sure it is the Mac. I have no problem. If there was a problem with the MAC no one could use FCPX.
More likely to be the recording device.
What is the camera you used?
What audio recorder did you use?
What editing SW are you using?
More likely to be the recording device.
What is the camera you used?
What audio recorder did you use?
What editing SW are you using?
Rick R
Veteran
I've seen audio/video drift on a few computer playback systems. Especially high bitrate and size. If its constant, the Video Lan player has sync adjustments.
Otherwise if recording on a double-system, drift is expected over time, the only thing for absolute drift free sync is a gen lock system.
Otherwise if recording on a double-system, drift is expected over time, the only thing for absolute drift free sync is a gen lock system.
Noiz2
Sound Ninja
It's better generally if you start out assuming you did something wrong, works for me anyway. A good 90% of the time it is operator error not a hardware problem.
Mac does not, as a blanket thing, have a sync problem. They are used almost exclusively for film post in the US.
What it sounds like to me is a frame rate mismatch. It could also be a software issue. Some programs will prioritize video and so if the data rate is too high they will skip some audio and thus get out of sync.
BTW doing a search I didn't find anything that wasn't many years old, as in 2011 and 2003, and they were problems with iTunes. So feel free to post a link or two.
The operator error could be the user also? And I wouldn't rule out QT being wonky, but I would check your file first. A not uncommon issue is for a NLE to do the "video first" thing and glitch the audio on layback. If you are like most of us you probably didn't do a Q&A watching of the output file, it's usually a waste of time if you aren't sending it to a client where a error would be unacceptable.
Mac does not, as a blanket thing, have a sync problem. They are used almost exclusively for film post in the US.
What it sounds like to me is a frame rate mismatch. It could also be a software issue. Some programs will prioritize video and so if the data rate is too high they will skip some audio and thus get out of sync.
BTW doing a search I didn't find anything that wasn't many years old, as in 2011 and 2003, and they were problems with iTunes. So feel free to post a link or two.
The operator error could be the user also? And I wouldn't rule out QT being wonky, but I would check your file first. A not uncommon issue is for a NLE to do the "video first" thing and glitch the audio on layback. If you are like most of us you probably didn't do a Q&A watching of the output file, it's usually a waste of time if you aren't sending it to a client where a error would be unacceptable.
^^This is what I was thinking. I had this very same problem once on a feature I did. After a while there was drift. Turned out picture editor was at 23.976 FPS and I was at 24 FPS. After a while the sound and picture would get out of sync, and they got further out of sync the longer it went, which makes sense.
Other than that, I've never in my career experienced drift because it was a Mac and have that be the sole reason why.
It sounds like frame rate mismatch to me. Frame rate can be 23.976, 24, 29.97, 30 etc etc. If you shoot at one rate, record sound in another rate, and edit in a timeline of a different rate, things can get weird quickly. To add to the problem, most Sony cameras say 24 fps, but actually record at 23.976. You, as a trusting soul, select "24 fps" in the Sony menu, and choose 24 fps in your Premiere timeline. Guess what happens? In short scenes it might not be enough to notice, but as you go longer the drift will keep increasing.
Go through the production chain and and I bet you'll find a mismatch between sound, video, and NLE somewhere.
Go through the production chain and and I bet you'll find a mismatch between sound, video, and NLE somewhere.
Digital Frank
Member
Another thing to check is the audio... is it 41.1Khz audio exported as a 48KHz video?
Last edited:
BrianMurphy
Veteran
If you hit the space bar to stop it and then hit it again to play is it still out of sync?
Noiz2
Sound Ninja
Audio doesn't depend on frame rate at all, so if you go searching for problems there, you won't find a solution.
Everything in the sound world depends on sample rate, and an audio recorder that has TC sync is actually using the 48kHz word clock and merely stamping TC headers as metadata. Audio for video runs at a native 48kHz, and drift comes from slight inconsistencies in sample rate especially with non-sync (and doubly so with low-cost) recorders. The timing crystals in a camera and a non-sync audio recorder may vary slightly from an absolute 48,000Hz, +/- a few (single-digit) Hz. The computer is playing back at an absolute 48,000Hz, so those imperfections cause drift over time. Nowhere does TC frame rate have any impact on this.
Digital Frank
Member
Yes I did. Thanks for correcting me.
Not to be argumentative, but this is incorrect. If I set my audio recorder to 23.976 FPS on production, and the camera is set to 24 FPS, there will be drift (a problem I've fixed too many times to count for people). If picture editorial is working at 29.97 FPS and I'm working at 30FPS in pro tools, and I hand off my stems to them for layback to final picture, there will be drift. If the picture editorial assistant sets their session up at 30 FPS and the production sound they are trying to sync is at 25 FPS, there will be drift. I know this is true because I have encountered these exact scenarios a BUNCH of times and have had to fix them, either for myself or for others. I've had to troubleshoot drift issues countless times from productions and it always came down to camera and sound not being at the same frame rate.
Noiz2
Sound Ninja
Yes and no.
While it is perfectly correct that audio is not clocked by TC some applications (and old school some wiring) will make TC affect the audio. FCP famously would SR convert audio based of mistaken frame rate settings, with analog video mismatched frame rates (or more often drop frame settings) would clock the DAW at an incorrect rate when laying back.
So at a root level you are completely correct but at a practical level sometimes the TC is the only variable you can control and IF the connection software is altering things based on how it is looking at TC then TC in a back handed way is what you have to "fix".
So in the context of the OP the things I have dealt with that have caused drift between audio and video are.
#1 (old school and FCP) mismatched frame rates. Either drop frame or FCP reading 23.986 as 24 or 29.97 as 30. Old school TC was used to generate wordclock so a mismatched frame rate resulted in an incorrect sample rate in the FCP case it would SR convert on import.
#10 (hardly ever seen) folks working at 44.1 sending a file to an app that expects the standard 48 and doesn't handle to "wrong" SR well. I have seen it where it plays it as if it were 48 so everything is sped up.
Between #1 and #10 are mostly things like a wrong sample rate file in a session in a DAW that doesn't work with mixed sample rate files. And other less generic software issues. The crux of the problem is that the software is written by programers who have little and often erroneous understandings of how TC and SR are used in post and production.
If we are going to be totally accurate, then no, FR doesn't effect the sound. But it does effect the video. I usually shoot at 29.97 for internet use, but I shot a series of interviews at "24 FPS" at the request of an AD. I set my Sony FS700 to 24 FPS (I found out later, actually 23.97). I brought the footage into a Premiere project setup for "24 FPS", single system sound, so sound should have matched video no problem. Sound played back at correct speed, but video was slightly sped up due to mismatch. You could actually see the video and sound files were not the same length in the timeline. So the sound didn't actually "drift", it was out of sync on frame 2, it just wasn't obvious to the eye until about a minute into the clip. Changed the project sequence setting to "23.97" and bingo, picture & sound now exactly same length and no "drift".
Frame rates won't effect the length of the audio recorded, but you do need everything to match correctly. You can't change the frame rate on audio files and have it change their length or "sync". They are what they are. The timecode on them is just a time stamp at the beginning of the file. However, as has been pointed out, if things aren't the same, there are issues, and if you are dealing with files that have the wrong time stamp on them from production because the frame rate was not correct, it will screw with you in dialogue editorial. So, whereas it doesn't effect the sound in playback speed, it does effect it in terms of timeline placement and sync later on.
I think the main lesson here is everyone needs to be on the same page with what frame rates they are running and be as explicitly clear as possible. Whenever someone tells me "we're running at 24", I always ask "do you really mean 24 or 23.976?". Most of the time they go "Oh yeah, it's 23.976". So many people don't realize you can't just round up.
I think the main lesson here is everyone needs to be on the same page with what frame rates they are running and be as explicitly clear as possible. Whenever someone tells me "we're running at 24", I always ask "do you really mean 24 or 23.976?". Most of the time they go "Oh yeah, it's 23.976". So many people don't realize you can't just round up.
David W. Jones
Veteran
Back to our regularly scheduled program....
Follow up question.... does the file lose sync on your computer, or on other playback test devices besides the clients computer?
What troubleshooting steps have you taken?
Does the file lose sync on the clients computer using other playback apps?
Tested delivery and playback using a different codec?
Follow up question.... does the file lose sync on your computer, or on other playback test devices besides the clients computer?
What troubleshooting steps have you taken?
Does the file lose sync on the clients computer using other playback apps?
Tested delivery and playback using a different codec?
Noiz2
Sound Ninja
Frame rate mis matches can get you in trouble in editing also, which is why as Dave said you need to make sure everything is at the same rate. This is an issue with software and not intrinsic to frame rate since as many have pointed out digital audio doesn't have a frame rate, it has a sample rate. As long as your DAW or NLE leaves the audio alone it will play the same as it was recorded. Most of the problems come from assumptions that programers make about how you will use things. The classic example is the tried and true practice of using odd sample rates when shooting film so that the sound would be in sync after a 3:2 pull down for video. It worked because the files would be played back clocked at 48 and would be slowed down the same 0.1% as the images. Then some programers decided that they would auto correct audio on input and started sample rate converting the files in the background when they were imported and nothing was in sync anymore. Major PITA.
So as David mentions where exactly things go off is important. With the FCP "bug" one thing that often complicated things is that editors would "fix" the drift while cutting and then hand it off to sound post with out mentioning the drift issue, so the error got built in. If you corrected any "drift" or wonky sync when you cut that may mean that the issue started there.
It could have crept in at various points and could even be an issue with how your client is viewing it. If they are looking at a streaming version it could be the internet connection being slow.
I would check the file on a number of machines that are not your editing machine.
Also the reason folks are focusing on frame rates is that it was a "classic" of the analog era for audio to be off by the pull down rate of 0.1% or for video to be on drop frame and audio not. In both cases the drift is so small that it takes awhile to be noticeable. So the fact that they only notice it 1/2 hour in implies a small drift.
Another possibility that hasn't been mentioned is that it's possible that there isn't a drift but that there was a glitch when you laid it back and that it just pops out of sync at that point. I have seen that happen. Also everyone is assuming an all digital work flow. If you are going to tape then other issues may be at play like not having everything locked to black burst or word clock.
So as David mentions where exactly things go off is important. With the FCP "bug" one thing that often complicated things is that editors would "fix" the drift while cutting and then hand it off to sound post with out mentioning the drift issue, so the error got built in. If you corrected any "drift" or wonky sync when you cut that may mean that the issue started there.
It could have crept in at various points and could even be an issue with how your client is viewing it. If they are looking at a streaming version it could be the internet connection being slow.
I would check the file on a number of machines that are not your editing machine.
Also the reason folks are focusing on frame rates is that it was a "classic" of the analog era for audio to be off by the pull down rate of 0.1% or for video to be on drop frame and audio not. In both cases the drift is so small that it takes awhile to be noticeable. So the fact that they only notice it 1/2 hour in implies a small drift.
Another possibility that hasn't been mentioned is that it's possible that there isn't a drift but that there was a glitch when you laid it back and that it just pops out of sync at that point. I have seen that happen. Also everyone is assuming an all digital work flow. If you are going to tape then other issues may be at play like not having everything locked to black burst or word clock.