-
format for transfer drives
i’ve encountered a cross-platform issue recently. i was handed a portable drive to download to at a shoot only to find it was NTFS formatted and of course, my macbook pro can’t write to NTFS. most of the footage is being archived on a pc platform, but i still want to be able to hand off footage, leading me to suggest formatting the portable hard drive as fat32. which led me to the file size limit of 4 gigs.
does the camera impose a file size limit when it writes? a quick look at files i have on hand didn’t show any larger that 3.xx gigs. so am i safe from file size disasters with a fat32 formatted hard drive?
is there a more common or better solution?
thanks,
Michael
-
7 Replies
-
Hi Michael,
The SxS media and related hard disk recorders do utilize the Fat32 file system so there is a 4 GB limit on any files created by the camcorders. On long records the cameras create multiple <4GB files joined by an SMI file. So I think you’d be ok with a Fat32 drive. The only restriction would be that you would have to be careful if you use that same drive to hold the re-wrapped QuickTimes output by XDCAM Transfer. By default XDCAM Transfer and XDCAM Browser join spanned MP4s into single QuickTime files, and these will be larger than 4 GB. You could get around this limitation by importing the <4 GB sub clips individually from the ‘Sub Clips’ area in XD Transfer.
Ian
Ian Cook
Sony Broadcast and Professional Company -
SxS cards are formatted FAT32 so files from EX conform to the file size limit. There are several companies that make software that allow Macs to write to NTFS formatted drives.
I’m not making a specific recommendation but see below
MacFuse
https://www.macupdate.com/info.php/id/23729/macfuse
NTFS for Mac
https://www.macupdate.com/info.php/id/30449/ntfs-for-mac
NTFS3g
https://www.apple.com/downloads/macosx/system_disk_utilities/ntfs3g.html
Paragon NTFS Mac
https://www.paragon-software.com/home/ntfs-mac/ -
thank you, Ian. that’s a very thorough answer.
you have brought up another issue i had some concern over though – your mention of the SMI files to rejoin sub-clips. i have always dumped bpav’s into a common folder (say, for a given day’s shooting) through Clip Browser. however the producer for this job wanted different folders for each card off-load. will this create issues with re-joining sub-clips that span cards?
-
thanks Craig.
i’ve been warned against the 3rd party solutions for writing to NTFS from a mac, though i understand many people use these without issue. i was told (by someone who writes code for apple) that the efforts to speed up the 3rd party applications add a certain amount of instability. i’m sure they work fine, but that was enough for me not to want to find out.
-
No, this shouldn’t be a problem. When you copy the card you are also copying any clip-spanning pointers it contains (the SMIs live in the TAKR folder). As long as you don’t start manually breaking up the BPAV folders outside of Clip Browser you should be fine.
-
That should not be a problem. When you copy a BPAV folder you are also copying any spanned clip pointers that it contains (the SMI files reside in the TAKR folder, one directory below BPAV). As long as you don’t manually break apart your BPAV folders your spanned clips should copy and import correctly.
[apologies if this ends up appearing twice; my browser crashed just as I was posting this same message a few mins ago…]
-
excellent, thanks for the help.
Reply to this Discussion! Login or Sign Up