New Workflow From Apple

J

Jeff Deveraux

Well-known member
Hello all-
I've been working on a HVX production supported by Apple. The editor is the head of FCP development and has informed me a new workflow recommended by Apple HQ. I thought I'd pass it on...
You simply make a disk image of the P2 card. This workflow has it's pro's and con's. On one hand, it takes more time in post. On the other hand, it is much more reliable for avoiding corrupt files. I don't know about you, but I have had some files simply just disappear and that hurts.

-First you mount your P2 card on the desktop.
-Then navigate to Disk Utility in applications>utility and open it. (I put my Disk Utility in the doc)
-Click on the P2 card and click on "New Image".
-Give the new image a name (like reel #) and a location.
-Make sure that "Image Format" is "read-only", and "Encryption" is set at "None".
-Click "Save".

This will create a ".dmg" file that FCP will not recognize. So before you try to import or access the files you must first mount the disk image by double clicking on it (I usually skip the verification process).

I've done this workflow on two systems... A single 1.8 G5 tower and a laptop. The faster of the two was the laptop due to the speed of the PCMCIA bus. The tower workflow was conducted via camera and firewire.
On the G5 tower I made an image of a 4 gig P2 card an it took 9 min and 22 sec. Then I took the same P2 card, opened it and copied the contents of that card (old school method) to the same drive as the dmg file I just created. That took 4 min and 15 sec.
On the powerbook using the PCMCIA slot, these times were cut in half.

Obviously, if time is an issue you may want to stick to the old school method, but the reliability of this new workflow is so much more comforting. On this production we had two cameras with two 4 gig cards each. Once one card was full, the AC would deliver the P2 card and a camera report to the "logger" who would return the card after ingest. Not once did any camera not have a card to shoot on. In a narrative production such as this one, I noted that it is much more simple for the editor if you have only one card in the camera at a time. This way, the camera reports are assured to reflect what is on the disk image. With two cards in the camera, a take can cross over to the next card when the first card is full. This can get confusing in post.
All in all, this workflow worked very well. Enjoy!
 
Last edited:
Interesting. One of those "why didn't I think of that?" ideas. I'll try it. On the other hand, if copying to a folder with reel name or whatever is faster and does not require mounting the .dmg, I don't see the point.

Ned Soltz
 
nsoltz said:
Interesting. One of those "why didn't I think of that?" ideas. I'll try it. On the other hand, if copying to a folder with reel name or whatever is faster and does not require mounting the .dmg, I don't see the point.

Ned Soltz
Click to expand...

The point is reliability. It's a real bummer when you get a corrupted file. I shot some time lapse stuff for about 3 days and managed to fit it all on one card. When I went to put the footage on my reel, it was gone. The contents folder was there. The LASTCLIP file was there, but the rest... Gone! This would not have happened if I had ingested the footage via disk image.
Imagine if you have a client and you're shooting a commercial. How do you explain that you can't use the take they really liked because you lost it?
If you're a hobbyist, don't worry about the new workflow. If you're a professional, it's worth considering.

BTW, when I heard about this workflow that's exactly what I said... "Why didn't I think of that?"
 
Last edited:
I just got more info on why this workflow is more stable.
It seems that creating a disk image keeps the format of the information in it's native environment (FAT32 I believe). When you drag the contents folder to a new folder it gets copied in OSX's format (HFS+).
 
So basically, the files are in FAT32 on the P2 card. When you do a "disk image", it keeps the properties (FAT32) of your files and creates a .dmg file.

When you extract the .dmg file, wouldn't the files be converted to HFS+, exposing you to the same risks?

I'm worried that whatever flaw is causing those files to disappear will continue, whatever the workflow. Has anybody contacted Panny with the "disapperance" issue? What have they responded?

BTW, great post Jeff. Thanks for sharing your experiences...

MC
 
In the beginning day of Apple and P2 in order to ingest P2 into FCP you have to keep REC INH SW on P2 card on. Then Apple say in new it is not neccessory but I would still do it for the saftey of my footage. THis is fastest and safest way for FCP and P2 I think??????????????????
 
P2metoo said:
In the beginning day of Apple and P2 in order to ingest P2 into FCP you have to keep REC INH SW on P2 card on. Then Apple say in new it is not neccessory but I would still do it for the saftey of my footage. THis is fastest and safest way for FCP and P2 I think??????????????????
Click to expand...

You lost me...:(
 
mandycastro said:
When you extract the .dmg file, wouldn't the files be converted to HFS+, exposing you to the same risks?
Click to expand...

I don't even have an HVX, but I'm chiming in anyway... :)

It might expose you to the same risk, but so what? If it corrupts in transport from the image to the disk, YOU CAN ALWAYS TRY AGAIN if you have the image as the source! If you don't have the image, and it corrupted on ingest, and the card was re-used -- you've got NOTHING!

Another thing about the image is that you may be able to turn on a verification step (if it isn't already doing this), where once the image is created, it can be compared to the orignal image for verification. If the file is being transformed without the use of an image while going from FAT32 to something else, you can't really do that type of verification. With the disk image route, you could actually create an MD5 hash checksum of both the original image and the duped image, and you'd know for sure that you in fact got a perfect duplicate without any chance of corruption (but that might be happening in a verification step during the creation of the image anyway, not sure).

Just some thoughts...
 
Hey folks,

I had an idea. Would it be possible to use encryption when you copy from the P2 cards? If the archive becomes password protected, that could be useful to me in the field. I'm also wondering if you're using 8G cards, if you can split the image over 2 DVD's for archiving, I'll have a 2.4x DL drive in my powerbook, but it seems that it would be faster to burn single layer DVD's at 8x. What do you think?
 
Jeff Deveraux said:
You lost me...:(
Click to expand...

hahahahaha

Disk Image GOOD, Time it takes, not very good..

I import the P2 card directly into FCP, then copy the files to our clients external Hard drive.

If it gets lost in both places, well, houston we have a problem..

I'm not sure how files just go missing.. you might want to look into a P2 PI.. :-)

- - Justin
 
CAUTION: Don't believe everything you read. The argument that a disk image is safer than folders and files just doesn't make sense.

First, a folder copied from a typical card holds more than 100 files. If a single file becomes "corrupted" or "disappears", you've lost 1 file. But if your disk image file becomes "courrupted" or "disappears", you've lost everything. Putting all your eggs into one disk image is foolish and dangerous.

Second, a file is a file. Fat 32, Slim 32, Fatboy Slim, it makes no difference. Bits is bits. Data is data.

Third, why on Earth would you want to mount 10 or more disk images at the same time for a project? Juggling that many swap files and RAM pointers and virtual disks, you're begging for trouble. Now you're compounding disk problems with RAM problems.

This whole "workflow" sounds like voodoo. Somebody is pulling your leg.
 
Thanks, Jeff, for the info. Sounds like a good safety measure.

And, heeding hatchmo's advice, I won't "believe evyerthing {I} read". Meaning most of what hatchmo wrote.

It's just another option for safety's sake. If you got the time and REALLY want to have another backup, so be it. I happen to like the idea of another backup option that could fit a 4gig card on a DVD as a stand-alone disk image. As a working editor, this makes perfect sense.

That doesn't mean I'm going to "put all my eggs in one basket" based on "voodoo". If you REALLY don't like the idea of a disk image that much, simply don't do it.

:costumed-smiley-047
 
hatchmo said:
CAUTION: Don't believe everything you read. The argument that a disk image is safer than folders and files just doesn't make sense.
Click to expand...

I guess I was misinformed... Should I file a suit? (just kidding)


hatchmo said:
First, a folder copied from a typical card holds more than 100 files. If a single file becomes "corrupted" or "disappears", you've lost 1 file. But if your disk image file becomes "courrupted" or "disappears", you've lost everything. Putting all your eggs into one disk image is foolish and dangerous.
Click to expand...

Chances of this happening are slim. Besides I usually import into FCP form the disk image as soon as I make the image and before I erase the P2 card. So at any given time I have my eggs in two baskets.

hatchmo said:
Second, a file is a file. Fat 32, Slim 32, Fatboy Slim, it makes no difference. Bits is bits. Data is data.
Click to expand...

The Spanish language has nearly the same alphabet as the English language. Should I trust all translations?

hatchmo said:
Third, why on Earth would you want to mount 10 or more disk images at the same time for a project? Juggling that many swap files and RAM pointers and virtual disks, you're begging for trouble. Now you're compounding disk problems with RAM problems.
Click to expand...

You only have to mount the image for import into FCP. Once imported, you're dealing with footage that is now on your scratch disk in Quicktime format. 10 mounted disk images are not necessary, at any point.

hatchmo said:
This whole "workflow" sounds like voodoo. Somebody is pulling your leg.
Click to expand...

I feel I can trust this source.

Like fevercity said... Do what you're comfortable with.

:)
 
Last edited:
I'm not sure if you know the answer to this-

but couldn't I just copy the P2 card to the HHD, and then create the disk image? That way O would not have to tie up the card for additional time .....
 
235 Studios said:
I'm not sure if you know the answer to this-

but couldn't I just copy the P2 card to the HHD, and then create the disk image? That way O would not have to tie up the card for additional time .....
Click to expand...

No sir. That would be defeating the purpose. As I understand it, the most likely time for the file to get corrupted is when you are rewiting the format (i.e. Fat 32 or HFS+) that is supporting the file. When you copy the file from the P2 card you rewrite the format. When you make a disk image of the P2 you keep the file in it's native format.
 
Jeff Deveraux said:
No sir. That would be defeating the purpose. As I understand it, the most likely time for the file to get corrupted is when you are rewiting the format (i.e. Fat 32 or HFS+) that is supporting the file.
Click to expand...


Thanks for clearing it up. Not the answer I wanted ... oh well.


Jeff Deveraux said:
When you copy the file from the P2 card you rewrite the format. When you make a disk image of the P2 you keep the file in it's native format.
Click to expand...

I guess there is more to this then I had thought- I thought that all digital info was the same- just a bunch of 1's and 0's- and that when you moved info from one place to another you were making an exact copy of those 1's & 0's. I didn't realize that something got changed along the way.

Thanks for the update and for the workflow.

Do you know if this will be made public? Usually Apple puts up sometihng on their web site detailing work arounds.
 
235 Studios said:
Do you know if this will be made public? Usually Apple puts up sometihng on their web site detailing work arounds.
Click to expand...

Well I imagine that it's like the extra framerates on the HVX. Panasonic put the option there, but didn't tell us we can use them. If you have followed that thread you know that it is because Panny is still testing to make sure there are no conflicts with the framerates. In the case of Apple, they may be still testing before going official. They did tell me I could post the workflow, so maybe we are the poor suka's being used as guinea pigs.
 
You must log in or register to reply here.
Back
Top