- Posts: 18
- Thank you received: 0
3 Post Moderation Rule for New Boarders (25 Jan 2021)
New boarders will have their posts moderated - Don't worry if you cannot see your post immediately.
Library updates - fcp(n) on clips
19 Mar 2021 11:49 #113496
by enonod
Library updates - fcp(n) on clips was created by enonod
Can I presume that the added notation fcp(n) to Original Media clips in Library Bundles is due to updates when new versions arrive?
If so, can any of them be deleted?
I ask because on some clips I have as many as 13 of these per clip, many attached to one clip have the same date so appear to be duplicates all have the same symlink size.
Can I further presume that the current one is the one without fcp(n) annotation?
If so, can any of them be deleted?
I ask because on some clips I have as many as 13 of these per clip, many attached to one clip have the same date so appear to be duplicates all have the same symlink size.
Can I further presume that the current one is the one without fcp(n) annotation?
Please Log in to join the conversation.
19 Mar 2021 12:44 #113501
by JoeEditor
Replied by JoeEditor on topic Library updates - fcp(n) on clips
A number in parentheses after a movie file is because it share a name with a previously imported file. Example; you can import two files names "My iPhone Clip". The first one retains that name untouched. The second one imported has (1) added to the name.
Please Log in to join the conversation.
19 Mar 2021 15:37 #113506
by enonod
Replied by enonod on topic Library updates - fcp(n) on clips
Many thanks Ben Balser. I actually mistyped, it should have been clip53 (fcp13).mov I cannot imagine how I imported 13 times, so I imagine I can delete all that do not have the annotation... unless they were individually used in earlier projects, but I am sure I could relink if that is so.
Please Log in to join the conversation.
19 Mar 2021 17:46 #113513
by joema
I would be very cautious about deleting those. When FCP imports media -- either "in place" or with copy to library, it does not internally maintain the original on-disk folder tree. If you have duplicate filenames which are segregated in separate folders, upon import those potentially cause a filename collision because FCP places those in a smaller # of internal folders. To avoid the filename conflict, it appends (fcp1), (fcp2), etc. as a "uniquifier" suffix to the internal filename or symlink.
Note the media files themselves may well not be duplicates -- the potential conflict is due to duplicate file *names* which are copied by FCP to a simplified internal folder structure.
This easily happens with older Sony Alpha cameras which restart the filename sequence each time a new SD card is inserted or formatted. Those cameras don't support any in-camera customization of video filenames. Thus you may have many files named C0001.mp4, but they are all different files. If symlinks, the size given in Finder is for the symbolic link itself, not the media file it's pointing to.
In Finder if you right-click the library and pick "Show Package Contents", then go to the Original Media Folder, you can select a symlink and do CMD+I to show the pathname to the file. In general if you do that on filenames differing only in (fcp) suffix, you will see those are different media files.
For that reason I would not suggest deleting any of those unless you positively verify they are truly duplicate media files. The symlinks may all be pointing to different files.
The best way to avoid this is rename all files before import and add a 5-digit incrementing suffix. Finder has a powerful batch rename tool built in. If you use the Format>Name and Counter option it will add the suffix starting with the number you specify:
Replied by joema on topic Library updates - fcp(n) on clips
enonod wrote: Can I presume that the added notation fcp(n) to Original Media clips in Library Bundles is due to updates when new versions arrive?...If so, can any of them be deleted?
I would be very cautious about deleting those. When FCP imports media -- either "in place" or with copy to library, it does not internally maintain the original on-disk folder tree. If you have duplicate filenames which are segregated in separate folders, upon import those potentially cause a filename collision because FCP places those in a smaller # of internal folders. To avoid the filename conflict, it appends (fcp1), (fcp2), etc. as a "uniquifier" suffix to the internal filename or symlink.
Note the media files themselves may well not be duplicates -- the potential conflict is due to duplicate file *names* which are copied by FCP to a simplified internal folder structure.
This easily happens with older Sony Alpha cameras which restart the filename sequence each time a new SD card is inserted or formatted. Those cameras don't support any in-camera customization of video filenames. Thus you may have many files named C0001.mp4, but they are all different files. If symlinks, the size given in Finder is for the symbolic link itself, not the media file it's pointing to.
In Finder if you right-click the library and pick "Show Package Contents", then go to the Original Media Folder, you can select a symlink and do CMD+I to show the pathname to the file. In general if you do that on filenames differing only in (fcp) suffix, you will see those are different media files.
For that reason I would not suggest deleting any of those unless you positively verify they are truly duplicate media files. The symlinks may all be pointing to different files.
The best way to avoid this is rename all files before import and add a 5-digit incrementing suffix. Finder has a powerful batch rename tool built in. If you use the Format>Name and Counter option it will add the suffix starting with the number you specify:
Please Log in to join the conversation.
19 Mar 2021 18:07 #113514
by enonod
Replied by enonod on topic Library updates - fcp(n) on clips
I am grateful for the precise description, which I fully understand, and I now realise how it has come about.
You are correct in that they are different files from restarted numbering. I am also grateful for the video, which will now allow me to avoid this in the future.
A truly enlightening day and thank you for it. Problem SOLVED!
You are correct in that they are different files from restarted numbering. I am also grateful for the video, which will now allow me to avoid this in the future.
A truly enlightening day and thank you for it. Problem SOLVED!
Please Log in to join the conversation.



