Forum Replies Created

Page 1 of 3
  • Hi Sherril,

    Thanks so much for this. I followed your steps and most of my clips didn’t link automatically to the new files but a simple relink did the trick and now all are online and looking good.

    The only buggy thing I encountered is that all my AUX TC info disappeared after relinking. Judging from this thread it sounds like it’s a common issue. I followed the suggestion of exporting an ALE with the AUX TC and merging it after relinking the clips and that worked perfectly.

    Thanks again!

    Tory

  • Hi Sherril,

    I’d love to hear if you found a solution for this? I’m in a similar boat!

    Thanks,

    Tory

  • Hi all,

    Chiming in to report that I’m having the same problem and it’s making me tear my hair out. Finding this thread at least has given me the relief of knowing I’m not crazy! I’m working on a long doc and this bug is affecting about half of my media.

    I’d transcoded a lot of footage shot on the C100 to ProRes 422 (23.976fps) using Log & Transfer in FCP7, from disk images of the original cards, keeping the entire card structure intact. I added metadata, and synced using Plural Eyes before migrating the project to Premiere via xml. All seemed well. Since the migration to Premiere, I’ve transcoded all new footage using Prelude and imported to the Premiere project via the Media Browser.

    Since I’d heard negative things about merged clips, I instead made multicam sequences to link the dual recorded audio to the video clips and modified the audio channels on the multicams to reflect my preferred arrangement. This after losing a bunch of time modifying the audio channels on the video and audio clips themselves BEFORE making the multicams, only to find that offlining and relinking media knocks out those channel modifications and restores them to the file’s default.

    While making multicams from the synced up sequences (that I’d imported from FCP7 via xml) I noticed that many of my video clips on the timeline were a frame or two or three out of alignment. The placement of the clips on the timeline was correct, but there were diagonal lines/dead frames at the head of the clips. Slipping the clips solved the problem, but sure enough when I checked the timecode I discovered that the problem was that Premiere was reading the start TC typically 1 to 4 frames later than was correct. It seems to be completely erratic, other than that it’s limited to clips that were transcoded in FCP7.

    As Richard stated, every single other application I have installed that can read timecode reads the “correct” timecode, and Premiere and Prelude read the incorrect timecode. Not only that, but the incorrect timecode doesn’t even stay consistent on the clips themselves. After offlining and relinking several times, the timecode on the offending clips slipped even more. I modified the timecode in Premiere and checked to see if it affected any other programs and it did not, aside from Prelude. However, I have hundreds of clips that came over from FCP7 so double-checking all the timecodes against my old FCP7 project seems like it will take forever, and feels daunting and possibly futile since who knows if that will actually prevent the bug from manifesting again down the road.

    The only minor success I had was relinking clips in Premiere after “modifying” the timecode in FCP7. I copied the original start TC, changed the TC to something else, closed the modify window, reopened it, pasted the original start TC back in, closed the window, and confirmed that the file read as having been modified at the Finder level. I opened a dupe of the Premiere project with all the media offline, reconnected, and the incorrect timecode in Premiere changed to reflect the correct timecode. If I open those clips in Prelude, Prelude now reads the correct timecode. I thought this might be the solution but sadly it doesn’t seem to be sticking. I’m not sure what happened but after working in the project for awhile I noticed the clips were again registering the wrong timecode.

    Very interested to hear if anyone’s made any progress or had any insights since last month.

  • Tory Stewart

    May 23, 2012 at 3:56 pm in reply to: Subclips losing unique timecode

    Further tinkering has revealed that the problem does not seem to have to do with wavs vs. aiffs after all! The audio tracks only lose their timecode when made into subclips if they were not recorded with time of day timecode.

    Example of what I might be looking at: Twenty video clips shot on DSLR with unusable audio and two very long wavs recorded on the Zoom H4n while camera was rolling, leaving me with tons of audio that has no matching video and no time of day timecode. I sync the video to the audio with Plural Eyes, delete the bad camera mic tracks, arrange the zoom tracks the way I’d like them to be (ie lav on track 1, shotgun on track 2) trim the edges of the clips, link the video to the audio, lasso the clips in the timeline and drag into a bin called “Merged Clips.”

    Rather than work with the merged clips, which typically have a ton of excess audio hanging off the sides, I was advised to make subclips from those merged clips and work with those instead. Each time I make a subclip that includes audio from these tracks, the timecode of the Zoom tracks “zeroes out” at the head. For example, if I have an audio clip that starts at 00:00:00:00 and syncs up with video at 00:00:21:04, as soon as I subclip from the merged clip that track of audio lists 00:00:00:00 at the head of the clip instead of 00:00:21:04. If I option-command-F from the subclip, it does match me to 00:00:21:04 in the original audio file. If the zoom audio was recorded with time of day timecode, the tracks do not “zero out” at the head of subclips, whether those are wavs or aiffs. They retain their time of day timecode.

    This whole issue doesn’t affect my editing process so much as it makes me concerned about whether it will lead to any trouble in the finishing process. When I export an EDL of sequences that include these “zeroed out” subclips, I get an error message saying that the sequence contains clips that don’t have timecode, and those clips always are listed as starting at 00:00:00:00 in the EDL. If I export EDLs that include footage from the merged clips, I get the same message but the “time code” for those clips is correct in that at least it lists the proper point in the wav file.

    Is there any remedy for this? Should I work with the merged clips instead? I thought I had my workflow down with the merging and then subclipping but encountering these problematic audio files has thrown me for a loop.

    Thank you!

    Tory

  • Tory Stewart

    May 22, 2012 at 4:23 pm in reply to: Subclips losing unique timecode

    To reiterate: the polywavs do not lose their timecode when I create subclips, the only clips that lose timecode are the stereo wavs from the zoom.

  • Tory Stewart

    May 22, 2012 at 4:20 pm in reply to: Subclips losing unique timecode

    That leads to another snag: The majority of the audio for the project was recorded as 6-track polywavs. I synced the polywavs to the video, merged clips, and subclipped from the merged clips. The polywavs will not export to aiff. What do you suggest?

    From other posts on the board I gathered that this was the recommended workflow for dual recorded audio: sync -> merge -> subclip -> edit. Should I have isolated the tracks of the polywavs first? What is the best way to deal with the clips I have already merged with the polywavs and begun editing?

  • Tory Stewart

    May 18, 2012 at 7:51 pm in reply to: Subclips losing unique timecode

    Yes, merging clips before subclipping.

    I’ve exported batch lists of the subclips for my own organizational purposes but was thinking that if I ever wanted to compile a list of selects from those, import the list to FCP and capture the clips, the clips wouldn’t have the appropriate audio. I’m not sure what would be gained from compiling a Batch List in Excel rather than simply using the “find” function in FCP, other than that as the number of project files increases the “find” function becomes less efficient unless all projects are open all the time…

  • Tory Stewart

    May 18, 2012 at 3:33 pm in reply to: Subclips losing unique timecode

    Exporting to aiff worked! I’ll do the same for all zoom recorded stereo tracks and all audio from now on.

    Follow up question: I have been editing with a ton of subclips with synced audio in wav format that has retained its proper original timecode. Should I export all those wavs as aiffs and reconnect all existing subclips to the new files just in case?

    And finally: I wondered if there’s any way to export a batch list of a bin of subclips that contains the timecode and source information of all the component tracks of the subclips? I have batch lists of all my synced and subclipped dailies bins but realize that if I ever want to capture from those they only reference the video files and not the synced audio tracks. I’m not anticipating this being crucial at any ponit, just curious if it’s possible.

    Thanks so much for your help on this Jerry!

  • Tory Stewart

    May 18, 2012 at 1:40 pm in reply to: Subclips losing unique timecode

    The audio files are 48kHz 16-bit wavs. I’ll try batching exporting to aiff and see what happens.

    Tory

  • Tory Stewart

    May 18, 2012 at 1:06 pm in reply to: Subclips losing unique timecode

    Hi Jerry,

    Yes, all footage in the project has been transcoded to ProRes 422 before syncing with the Zoom tracks.

    Tory

Page 1 of 3

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy