I'm using Adobe stock music for my video clips. I searched for music clips that qualify for my needs and downloaded some preview files of to my hard-drive to have a handy pool.
When editing , i chose from these previews and edit my video in synch with the beat (mostly 120 bps). After the video clip is finished and i decide to stay with the chosen stock music, i go through the (short) licensing process and download the .wav file. Then i click "replace footage" and link the clip to the .wav file.
After that, the music is out of synch by one frame (in a 50 fps sequence). It's not much but it's annoying and technically incomprehensible.
Do i make anything wrong? Has anyone else noticed this behaviour? Is there a workaround?
Sorry, forgot to mention: Adobe Premiere Pro (15.0).
Doesn't matter what video editor i use, because it has nothing to do with the files being out of synch. I testet multiple .wav files against their .mp4 preview-counterparts (in various programms). They are all out of synch by about 1 frame.
I know know that i didn't do anything wrong. And the only possible "workaround" (/additional work) is to manually edit all used stock audio to be in synch after replacing the preview files with the licenced .wav file.
Lay both files one over the other in premiere. If they are synchronized, stock is not the culprit. In that case I would recommend asking the Premier forum.
The audio is out of synch after replacing the underlaying footage of a preview clip that is already edited into my timeline. I don't want to transfer all edits to a new soundfile that i import parallely to the preview file.
But maybe i should download a preview of an already licenced file and compare them in premiere...
It appears that the preview and full quality files sometimes have slightly different durations because of the encoding process and different formats (WAV vs M4A). We're talking a few milliseconds if not samples. Premiere Pro (and all video editing apps) operate on whole frames and if the audio file happens to land on a duration that is not on an even frame it has to snap to one or the other. I used to run into this issue often when I was a professional editor while syncing second source audio to the clapper. 1 frame left and it's early, 1 frame right and it's late, often the sound of the clapper was inbetween frames. Luckily there is a solution to edit audio in sub-frame increments in Premiere Pro. From the sequence hamburger menu, choose "show audio time units". You can then zoom all the way into the samples, but you shouldn't need to go that far. While zoomed in, nudge the audio left or right (Command/Ctrl + left/right arrow) until your audio is perfectly in sync. Hope this helps.
If the encoding process causes a different duration, it's flawed. If an encoded file shows differences (apart from sound quality) to its source, Adobe should use another encoder or file format. I deal with compressed audio since about 2000 and i know there are many file formats and encoders. If adobe chose a file format or encoder not capable of producing files that are perfectly in synch with the source, it should switch immediately.
Come to think about it: Why is Adobe using .wav? .flac produces lossless files that are significantly smaller and it natively supports tagging...
Maybe i should really compare some of my licensed soundclips to their preview files. I just can't believe Adobe would produce faulty preview files.
What you are suggesting works on simple edits. But as soon as complex operations are involved, that won't work as it would need to use multiple corrections. That's simply excessively time consuming.
Adobe needs to review its encoding process for the preview files. Its not off by samples but by a whole frame. To some it may seem like a small thing but it shouldn't even be a thing at all.
I did some further testing and compared several preview files to their licensed .wav counterparts. The .wav is always out of synch. In a 50 fps timeline its about 1 frame ahead.
To verify that it's not a Premiere Pro problem i opened the files with audacity and got the same result. They are out of synch by 0,043 seconds.
While that seems to be not too much, in my opinion it's unacceptable, because there ist no technical reason for this difference. Even if there would be, there also would be ways to keep that from happening.