17 name matches were found, but 17 files are not compatible.
Relinked files must have the same media type and similar audio channels as the original files, and must be long enough to cover all the clips that reference the files.
Select a single item at a time to get information about why it is not compatible.
[Re-Titled by Moderator]
You have a remote Premiere Pro editor who has produced a timeline, exported a Premiere XML, then used the third-party SendToX utility to translate that to FCP XML, then you tried to load that XML and got the above relink errors.
SendToX has numerous restrictions on what things can be translated to from Premiere to FCP XML. See their web page for that list. Both you and the remote editor must be knowledgeable about and adhere to all those to have a chance at a workable XML timeline translation. There is a more comprehensive help page "sendtox-help" which you can Google, but it appears to not have been updated in a while.
I don't understand the "Transcode Media" dialog. You shouldn't see that when loading XML or relinking media. That may imply you and the Premiere editor do not have identical media trees, or the media is split between original and proxy media on your end or his end. The sendtox-help page says:
In addition, we know from experience that media operations like relink work much better on drives formatted MacOS Extended Journaled (HFS+) or APFS. Make sure any drives used with FCP are formatted that way. Normally, HFS+ is best for rotating hard drives, and APFS is best for SSD drives.
I think it can relink despite having duplicate filenames in different folders, provided the original and relink target folder structure is identical. It formerly required the volume name also be identical but that requirement was removed a few years ago -- at least for some cases. I need to re-test that.
I know the experienced people here know this, but for everyone else, it is very important to have globally unique filenames. Doing so can save endless trouble. If the camera supports filename customization and the ability to keep the filenames incrementing after changing memory cards, that helps a lot. But it can still be useful to rename the files, especially on a multi-camera shoot or if the material may be reused over time.
This can be easily done before ingesting to FCP by using Finder's multi-file rename feature. If nothing else, just add an incrementing index number to the end of the filenames. For details on Finder multi-file renaming, Google "Batch Rename Multiple Files On a Mac." There are even more sophisticated renaming tools such as "A Better Finder Rename." See attached for Finder batch rename dialog.
The "no shared media range" error means either the starting and ending timecode does not match or the clip duration metadata does not match between the original and relinked file.
The timecode and the duration of original and relinked files can be observed by examining the two files with Invisor or MediaInfo (both available on Mac App Store).
In some cases, you might not have the original clip, say you are working only with proxies. For that case I list below a procedure to read that by exporting the clip XML of the original file.
If the relinked files were transcoded by Resolve, Handbrake, FFMpeg or some other utility, those may not have preserved the original timecode, causing the relink to fail.
The opposite can also happen. Some MP4 formats may have "time of day" timecode but FCP may read that as 00-based timecode due to lack of standardization in how the MP4 container format represents timecode. It's possible to import MP4 files having "time of day" timecode which FCP reads as 00-based timecode, then someone else transcodes those using Resolve (which might read them as time-of-day timecode), then those transcoded files will fail FCP relink due to timecode mismatch. In some cases, the timecode can be manually updated using the third-party utility QTChange.
FCP Relink criteria:
- Files must have the same audio config (same number of channels), but sample rate can differ.
- Pixel aspect ratio should be the same, but it may relink even if different. This could result in a squeezed or stretched frame.
- Relinked file duration (as shown in the clip metadata) must be the same or longer duration than the original clip.
- File name including suffix must be *mostly* the same. However, FCP has some limited ability to relink to renamed files. If the end of the filename is changed and all other relink criteria are met, it will relink. IF any renaming is done after ingest, this implies a "trailing filename" renaming scheme might be possible. See item 5 on the page "Relink clips to media files in Final Cut Pro". Obviously, that should be well-tested before committing anything. See: Relink clips to media files in Final Cut Pro for Mac - Apple Support
- Codec need not be the same, e.g. you can transcode ProRes originals to 720p H264 and relink those.
- The constraints for multi-file relink are tighter than single-file relink. If you only have a few files to relink, it will sometimes work if you do them one at a time. For multi-file relink it superficially appears FCP also attempts to match folder structures, including volume name. However, there was apparently some enhancement to this within the past few years. If the filenames are unique, it now seems to relink even if the volume name, root folder name, child folder names and folder depths are different. That is on APFS, so maybe there is some optimization based on that.
- If the clip timecode does not match the original file, it will not relink. The error is "The original file and new file have no shared media range." This is due to metadata in the video header labeled "time code of first frame". In some cases, it's possible to re-write the timecode of clips to enable relink by using the EditReady feature Metadata>Set Metadata for All>Clip>Timecode or the utility QtChange:
- Due to FCP being unable to read clip timecode from some MP4 containers, even if both original and relink target have valid identical timecode, the relink may fail if one of them is MP4. A possible solution is using the QTChange utility which can read valid MP4 timecode and rewrite that in Quicktime metadata format so FCP can read it. If the original file is MP4 and the relink target has an FCP-readable timecode that conflicts with the MP4 00:00 timecode, the timecode of the relink target can be zeroed out with QTChange.
- After relinking to a different resolution file, the viewer may show a window-boxed screen. This is typically a cache issue and can sometimes be resolved by deleting the FCPX cache, which is either stored in the library or outside, as defined by the library inspector. The cache is a file bundle named LibraryName.fcpcache.
- You can export a clip XML of a clip that fails to relink, then compare the metadata in that XML to the target clip's metadata as shown by MediaInfo or Invisor. You can open the XML using TextEdit. How to interpret XML start and durations for clip:
duration="2291289/24000s" // 95.47 seconds
Use FCP Settings>General>Time Display>Seconds. That will display the time periods in fractional seconds. Compare that the the above quotient. It should be very close. If it's not, there is a mismatch between the starting and duration timecode values when the clip was imported vs the equivalent values in the relink target's metadata.
thank you very much for the immediate response
so
1.i do wedding videos and work in final cut.
2.i have an external editor who works in premier.
3.i have sendtoX and so i turn the whole project xml se final cut xml.
4.what you are doing is that i can't see the canon r6 files
5.i note here that we shot with sony a7siii by 85% and 15% with canon
6.is the editor doing something wrong???
in canon files I see also this
Please tell us more about these 17 files. What are they and where did they originate? Are they replacing proxies that were generated outside of FCP? As LocaAlicia requested, a screenshot of the error could be helpful.
Thank you for the screenshot. You have not yet replied to terryb's question:
"Please tell us more about these 17 files. What are they and where did they originate? Are they replacing proxies that were generated outside of FCP? "
Could it be filename collisions? Are there duplicate Cxxxx.mp4 filenames in other adjacent or sub folders that FCP is picking up? It would be very helpful to know the step-by-step media workflow used up to this point. Where are the files from? Why are they being relinked? Are there proxies involved? This info can help us to help you.
antonis81 wrote:
the archive is 1080p 50 frames
canon and nikon
If I import the wedding file from both cameras, will I be able to see the files normally?
Is there something wrong with my editor's xml????
in premier?
I am puzzled. If you have filmed an event with multiple cameras, I would not expect you'd try relinking from one to the other. If that is what you do, it seems plausible that it may fail.
Instead, I'd expect you might want to use media from both cameras in your edit...
Can you explain how relinking has to do with all of this?
Thank you
As the relink error indicates, select a single file and try to relink that one file. It will give more specific information about why the relink fails. Give us that information.
Please show us a screenshot of the warning.
As the message indicates, try relinking just ONE file and see what the error is, and let us know.
Why are 17 files not compatible in Final Cut Pro?
