Audio out of sync AFTER importing

I found an easy fix.  Change the .mp4 suffix on your file to .mov.  Import the .mov into Premiere and the audio is in sync.  Easy fix.

Hey there Lee in Ohio,

Come on Adobe. For those of us who use so many of your products--FIX this.

Understood. Getting there on getting this feature implemented. As your advocate for this issue, I request that more of you file feature requests. Have you filed yours yet? Anyone else on this thread, we need more of you to request support for variable frame rate support. Your attention to this issue is appreciated.

Regards,

Kevin

Glad you got yours working. Others have had different issues. You had CFR

but you were setting a 30p frame rate in NTSC standard film count. When

you say 30fps or 30p, you're really saying 29.97fps average. This is a

simple explanation, going back to film history in the US. In most places

where PAL standards are the normal color and count list, you'll have exact

values, for much the same reason, just a few adjustments to the mechanism.

In film, or in celluloid days, you recorded audio and video separately and

synchronized as best you could. In the metal oxide days, or VHS\8mm\hi8,

you could record both in the same manner. However, there was a noticeable

delay in sampling and imaging already in many television cameras (using

electrical signal to broadcast), and bandwidth was precious, so rather than

up the transfer bandwidth and frequency (more power needed), many cameras

employed a slight delay in audio. When VHS came around it went the

opposite way. Of course the main speeds were 24i, or 23.93fields (halved

picture sets of tv lines) per second. This delay came as a result of

separate heads recording, and sending at different rates or frequencies.

The heads were independent, you could mute sound input and the head

wouldn't touch the tape. All this mechanism introduced slight sync

problems. By dropping the rate down to an average, the problem became

unnoticeable. That way the US way. When other nations wanted to be more

exact, the set the rates, and every so often time stretched and compressed

to fit. 25p, 30pPAL, 50p, 60pPAL; these were used mainly in Europe and

eastern nations. The difference isn't much, some bandwidth, and data, but

their mechanism corrects itself.

Just a note, 60p in the us is 59.94fps.

It's a hold over from sync problems in early film. Even today, the exact

frame rate isn't perfect in digital, and sync problems do occur at higher

rates. Drop frame is a great way to adjust, stretching the problem over so

long a string, it's infinitesimally small, and completely unnoticeable.

But the NTSC color schemas... ...yuck! "Never the same color" = NTSC

Glad you realized it was your set rate. For those with a similar issue,

most HD is drop frame, but a lot of telecoms speed hike or create the

frame. If you've set your sequence to a rate of exactly 30fps, and are out

of sync, try droping the sequence rate to 29.97. Some game capture devices

don't properly encode this value, hoping you'll use imovie or some other

home software that will re-time your audio for you, sensing they are out of

sync by checking track data and timecode. If you want to stay closer in

sync, try a 24p rate. This is standard video rate, but it matches up with

48k audio sampling in 24 exact, and 44.1k in drop frame.

For future reference, a pro workflow (for pro software like this) looks

similar to:

1. receive video

2. ingest video

3. process video

4. output video

2 and 3 have a lot more to them.

Ingesting is supposed to get rid of any sync problems, and you can set your

video rate as you please. Going from 29.97 to 30 isn't that big of a leap,

and AME can handle it if you turn on Frame blending in the options. I

usually output 2 files at once from ingestion (2 for each video clip), one

for editing and one for final pass through. There is a difference in the

time it takes to render. More data going in always takes longer, but the

output usually looks a little better. Ingesting video takes the guesswork

out of the whole thing. Ripping to a single codec saves render time, as it

doesn't need to open a new decoder for each clip. Color grading is better

when you use a heavily compressed and a lightly compressed version of the

same codec, and your end quality will be more accurate.

Processing your video requires precision in some instances. Knowing the

timecode's exact place, and that each and every video complies with that

speed means that your machine isn't constantly re-timing playback during

your edits.

It would be great if you could get perfect output from every video codec at

whatever speed and audio sample rate was preset all the time, just on a

whim. Professionals rely on fact, figure, number, and naming. They rely

on themselves, not everybody else, to do their work right. That's what

this software targets. It's important to remember that.

I remember watching an engineer with a PHD in Physics trying to get data

from his TI calculator to his pc to run in a program he built. He kept

crashing out of the program, and having to re-enter all the data. He

insisted there was something wrong with the calculator or the pc. There

was... ...He was using data measured in radians in a 4 dimensional plot in

his math, but his calculator was set to degrees, and kept sending error

data back to the pc, and his program would end up with bad output or a

crash. He had no Idea how to set the thing to radians. He read that it

computed radians, assumed it was the norm and went on pulling his hair

out. It never dawned on him to learn the tool before using it. After I

showed him how to set it, he sprang for a campus cup of coffee. Colleges

do worse than starbucks...

For those using Elements software, remember that it is derived from the

same core as the professional set. It is called PROSUMER grade, not

perfectly pro, but far above consumer grade. Saying "but isn't that

different?" means you should've bought the $20 POS your kid said was trash,

and been happy with it. It assumes there are problems, runs slower, and

you have to pay out to add functions to it, but it assumes no knowledge on

your part. It will baby you through it.

Personally, I like learning pro software and using it at the same time.

It's a walk back through history, and older workflows that were spot on for

"Perfectionism" and professional quality. It takes more prep, but once

through, the prep-stage makes you ready for everything else to happen at

tachyon speeds (particles traveling faster than light are called tachyons,

by the way).

Processing requires tagging and knowlege of each clip or subclip, so you

can quickly move them around. Nobody wants to worry about whether or not

the framerates line up, and you don't want your system to give you the

spinner (a computer's middle finger) that says it has to reprocess

something over and over again. It's harder on hardware, and on your time,

and your budget... ...not to mention your reputation. I urge you all to

adopt an ingest step, where you tag or name your clips as you export them

to an edit format. It will eliminate this problem completely. No more

guessing.

Pop goes the weasel... ...that ran away with my sanity.

MOV files are Quicktime file formats.  THey usually come from high end cameras with fast imaging sensors, and OIS that actually recalculates drop-frames or marks them for preprocessing.  In other words, it is handled BEFORE playback, not DURING.  When using MOV on windows, there really isn't a lot of support for playback, but adobe does have its own codec for them, and will process them with all adjustments on import.

There are two ways reframes are handled in the short workflow:

1. Drop audio samples

2. Retime Audio

These can result in acceptable results, but with worse cases, they don't help much.

The middleware method, which is my common operation (I do it every time, no matter what), is to run the video through Adobe Media Encoder with frame blending.  It helps with some short run drops, and allows me to see them, then I just do a freezeFrame if necessary.

Old Hat PRO's who are perfectionist or set in their ways will probably use the playback window to identify the dropped frames, then look before and after for areas of audio they might cut out.  This allows you to compensate for some problems and be exact if you do it by frame count.

I've also found that the Frame Blending works on the timeline, but you have to highlight the area + up to 3s on either side, and render previews.  This will create the blends, and play them back, putting the audio in sync.  I havent done an output but I'd wager turning on frame blending in the export will carry out any timeline based blending.