![]() FAT is un-journaled, hence risks loss not only of individual files but of whole volume (integrity).FAT is universal but is a riskier option:.Some people have experienced obscure issues of application functionality, beyond data-movement speed issues.File system translation add-ons (to operating systems) exist, such as MacDrive, to allow Windows to read/write Mac OS, or Tuxera NTFS, Paragon NTFS or Parallels for Mac to enable it to read/write NTFS, but these (reportedly, and in part of my experience) only really work well for standard “Office” type applications, not so well for heavy (big andd real-time) data applications such as video editing, where they can impede the data throughput.File system translation add-ons can add Windows read/write access to HFS+ (ordinarily it could not even read it) and add Mac OS write access to NTFS (ordinarily it could only read it), but not sufficiently transparent/seamless for big real-time data access as required for demanding video editing endeavours. ![]() Sony Vegas also generates sidecar-files, e.g.Certainly, Adobe (on Windows and Mac) could adulterate both files (by appending XMP data – being an Adobe media metadata dialect in XML) and the folders they occurred in (depending on uder-configuration) in terms of sidecar-files.I’m not certain, but got the feeling that maybe the source file (or folder) meta data, such as permissions or somekind of interpretation-change to media files in the quicktime ( mmedia format.The result was a “sidecar” file of similar forename to the analyzed source file, but a different extension, placed in the same folder as the source file. Its analysis phased was typically slow and heavy – not something one would wish to repeat. In Apple/Mac’s (erstwhile) Final Cut Pro 7 I regularly used their (moving) image stabilization effect, SmoothCam.would only ever read source media files, not write to them, or to the folders containing them. I initially, naively, imagined that video editing systems etc.NLEs), slightly disturbingly, may use (or for some functionality, even depend on) read/write access to source-files and the folders containing them. Some of the major video editing applications (e.g. Mac OS on its own is able to read NTFS but cannot write to it.It is is not practical to have just one volume (necessarily in that case, one file-system format), because: In the case of RAIDs I was advised against this by my system supplier, but got the impression they were just being defensive, not knowing of any definite issues, and to my knowledge I did not experience any issues. For example I have done this on RAIDs of various kinds and on an internal drive for Mac systems bootable to either Mac OS or (via Boot Camp) to Windows. My current solution is to split the drive into separate volumes, one for each OS. ![]() RAID array or SSD) for video editing, such that either Windows or Mac computers can connect to it, and a video project started on (and saved to) on one of those operating systems (OS) can be continued on the other (and vice versa). At least, that worked on the mutiple occasions I have taken that approach, and have not been aware of any issues.Ĭonsider the challenge of setting up a shared data storage volume (e.g. via partitioning) into more than one file-system. In either case, it is possible to split the local storage (e.g. Furthermore, for speed and responsiveness appropriate to video editing, the local storage should ideally be RAID or SSD. Mac OS can read NTFS, Winows can only read HFS+ via third-party add-on utilities. Migration and collaboration imply file copying/synchronization, which implies read-access to the “foreign” file-system. ![]() There’s no magic option, each workstation needs a local storage volume with block-level data access (as opposed to simply file-level access) and formatted to a file system that is native (doesn’t require translation) to that workstation’s operating system. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |