-
XDCAM File Sizes Change when Copied in Mountain Lion
I transfer XDCAM media from Express Cards onto Raid1 drives for a safe backup. I have used the same MAC workflow with all my tapeless media for years. I copy the entire contents of the camera card into the target folder. When the transfer is complete I right-click and “Get Info” to verify that the BPAV folders are exactly the same size in bytes. If the number of bytes (often in the trillions) is consistent, I can be confident that the files are identical. It’s a simple process that has saved my butt several times when it’s been necessary to re-populate a card and have the camera restore the files.
HOWEVER, NOT IN MOUNTAIN LION. When using “Get Info” to verify the new copies of BPAV folders in Mountain Lion, at first one size appears momentarily, which immediately changes to another number, kilobytes larger. Not only am I unable to confirm that I have properly backed up my media, I am also concerned about the integrity of the original files. These backups of the cards are my “camera originals”. I do not want them altered in any way, which apparently the operating system is doing!
It does not seem to matter where I put the file, whether on an external drive or the desktop. I tested other camera files, from a GH2 and a Canon XA10. They DID NOT have this problem. I also found that this changing byte size only occurred to the new file. It does not appear to matter if the card is locked or not, the existing files on the card do not alter their original size. This would also seem to rule out Sony’s Cinemon plug-in which I use to preview clips in Finder.
Is anyone else encountering this issue? Can someone tell me why this is happening and how to stop it?
-
14 Replies
-
Are you using CRC when you copy to confirm the copy?
Not only “should” you, you “must” if you value your copies.
Is it possible you’re seeing a change between binary and decimal counting of bytes?
Note that Apple’s file size calculation changed with Snow Leopard.
https://support.apple.com/kb/TS2419?viewlocale=en_US&locale=en_USI’m not sure if this is relevant though. Have you compared Lion to Mountain Lion and seeing a difference?
-
Thanks for your response, Craig
I do not know what CRC is.
I have used the copy and “Get Info” verify system I described for years to transfer many terrabytes of P2, XDCAM, R3D, AVCHD and H.264 camera media. That way I am assured of saving all metadata and further, it allows us to treat our original card information exactly how we would treat an original tape. Further, should we have an issue with the camera files in the edit, we can copy the files back, remount the card and “restore” it in the camera. This has saved us in post several times. It’s simple and — until this issue came up in Mountain Lion — bombproof.
If I can’t resolve this issue however, I’m not sure what to do…
-
CRC is the error checking feature (for file transfer) in the new Sony XDCAM Browser and the legacy Sony Clip Browser app.
– Don
Don Greening
A Vancouver Video Production Company
Reeltime Videoworks
http://www.reeltimevideoworks.com -
Thanks Don.
Do you need to make the transfer within the program in order to take advantage of CRC?
-
Yes you do. CRC is only available within those apps. The size difference your seeing may be a bug in the new OS. To be sure, either use one of the Sony apps or find another Mac running an earlier OS and do your transfers the way you always did. If everything works normally again then it’s a Mountain Lion thing and not your codec.
– Don
Don Greening
A Vancouver Video Production Company
Reeltime Videoworks
http://www.reeltimevideoworks.com -
This is what I am coming to conclude as well, Don.
I started the process of filling out a bug report with Apple.
-
I thought I was going crazy here. I also recently made the jump to Mountain Lion on my data wrangling machine. Though I do have ShotPut Pro, XDCam Transfer, and P2CMS, I still prefer using the finder level copy routine to make my copies. I’ve noticed exactly the same behavior with both P2 and SxS cards.
My additional observations:
• This apparent file size increase ONLY occurs when there are sub-directories contained within the copied directory. If the directory only contains files, the file size remains correct. I can only hypothesize that this means that there is an increase in size of the hidden .ds_Store files contained in each directory.
• I’ve noticed that when copying to a FAT32 formatted drive (Windows), the directory size doesn’t change. This supports my .ds_Store theory, as those hidden files aren’t used on a Windows volume.
• The file size difference is ALWAYS larger than the original files. After comparing all of the files, and viewing them with their respective browsers to determine that nothing is missing, my takeaway is that as long as the copied directories are not SMALLER than the original, I’m okay. Of course, this is a poor substitute for the peace of mind of being able to see an exact match between the file sizes.
-
I agree, Louis. The added byte size is not that large (in the kilobyte range) and roughly correlates to the size of the folder.
I’ve been busy and haven’t had time to wade through the forms to make an Apple bug report yet.
QUESTION: Do you have Cinemon onboard your computer?
It does seem that only xdcam files trigger this weird, invisible response from Mountain Lion. I’m thinking that it might be a glitch where an xdcam specific program interfaces with the operating system.
Scott
-
No, I am not using Cinemon.
I don’t think this is unique to XDCam files. I see the same behavior if I copy a directory containing a subdirectory full of .wav files. If I move all of the files to the root level directory, the file sizes match.
Louis Block
video/audio technician
Flying Wombat Productions
San Francisco Bay Area -
Hmm. I haven’t tried wav files. But I haven’t seen it in any other than XDCAM files. I too drilled down and saw that the individual files were still identical sizes and that only the top, “BPAV” folder changed size. Have you seen this with other kinds of file/folders as well?
It’s especially worrisome to us because we use this same protocol when duplicating and backing up our media to drives, LTO tape, etc. It’s the only quick, bombproof way that I know to check that one folder is identical to another across a whole spectrum of situations.
Reply to this Discussion! Login or Sign Up