[Shawn Hyper]

Thanks, it’s clearer now.

I just thought before that In the Sequence Setting, whatever the codec, we as users should not always have three options: Upper, lower and NONE. DV codec for example, it should be forced to lower first, we should have no option here.

If say a DV sequence, the setting is forced to lower first, then if we import a upper first footage, we can apply field-shift filter just as you said.

But in fact we can set a DV sequence to upper first, and we can adjust footage as needed. Then at last if we render the sequence to a QT movie using DV codec, the DV codec interface still have all the field options: Upper, lower and NONE. I wonder what will happen for each option in the DV codec?

Too Many Standards = No Standard = Chaos

FCP7, Mac OSX 10.7.4, BMD Extreme

Pro Tools HD 1 v 8.1cs1

[Shawn Hyper]

[Rafael Amador] But this is not to set a field order (QT do not manage field order), but to manage Chroma compression, that works different for interlaced than for progressive.

Thanks for explaination. I used to think that’s for how to compress fields or frame.

Then the setting should be the same as the sequence? If it’s upper first in the sequence, then it should be set upper first in the encoder? But waite, why for a DV sequence the setting can be upper first or no field?

[Shawn Hyper]

FYI, we have tried quit a few versions of the driver.

And finally version 7.3.1 updates the firmware successfully. And that’s on Windows system, since we have tried MB extreme on Win system. Then uninstall 7.3.1, install 9.6.1, no error occurs.

And we moved MB Extreme to MAC system, installed driver 7.3.1, no error either.

[Shawn Hyper]

Thanks for reply.

Maybe I haven’t express myself clearly.

Here is an example, we’ll render a sequence using DV codec, the DV codec has some settings, right? One of the settings is for field, you can choose up first, low first or no field. According to the standard, there should not be field option, since for DV, it’s low first, and it should be hard-coded. Why the codec has other options?

[Shawn Hyper]

Hi, is the driver OK?

After moving to a new Mac w/ OS 10.x, we have just installed the latest driver for our MB Extreme, and it’s asked to update firmware and software, but if click “OK”, then both failed, saying error encountered. Then uninstall the latest driver, and install a legacy driver, this time it’s asked to update firmware, and failed again.

The USB port of MB Extreme is connected to Mac which has access to internet.

Does the update occur locally or will it download file from Black Magic’s server through the net?

Thanks in advance for any help.

[Shawn Hyper]

Thanks for all the replys.

It seems obvious that Apple, at least the author who wrote those words, makes a mistake as for the explaination.

[Shawn Hyper]

Thanks for kind help.

My mind is kind of in chaos. I need time to think it over again.

[Shawn Hyper]

Thanks for reply.

But I’m afraid field order has no relationship to the swaping of lines — this is swaping of spacial order. It should be related to temporal order — whether it’s the top field displayed first then the bottom field or vise versa. As for still image, it should have no effect, well maybe the result depemds on how the 2 fields are combined to be displayed on computer monitor, anyway it should have no line swaping. But when the video is viewed on video monitor, the motion of objects may look like jumping back and forth, due to the reversed temporal order of top and bottom fields. Is it right?

And as for our case, it seems somewhere in the flow path the spacial order of the lines are changed.

[Shawn Hyper]

thanks for all your replys.

Sorry, I forgot to mention that the jagged edges are obvious while QT player was paused. And we noticed the problem on computer monitor.

Later, we changed the sequence of FCP to top field first ( it’s no field before), the same order as raw avi files, and the result is much better.

Here comes another question. Since QT player is paused, what we see is a complete frame having 2 fields displayed simultaneously, right? Then, the order of the fields should have no effect, right? But it seems that the order does have effect.

And as for our case, the raw avi files are top field first, sequence has no field, DV50 codec is bottom field first. When rendered to DV50 mov, does FCP deinterlace first then send the data to DV50 codec? Here the key point is sequence’s field setting. Since later on, we changed the sequence’s setting to top field first, and the result is much better, we guess that FCP does nothing to the raw materials’ field and send the interlaced data to DV50 codec.

One last question, it’s strange that different softwares have different reports about the same avi files’ field order. In FCP, it’s top field first. In G-Spot on windows platform, it has no field. And in another video app, it’s bottom field first. Terrible!

[Shawn Hyper]

Thanks to all of you for patient explanation.

But excuse me for my verbosity。

[Andrew Rendell ] However, whenever you are editing onto tape, the tape deck has to lock up it’s playback before dropping into record (i.e., be at the correct speed and sychronous with the reference signal), so you do actually need a few seconds of recording at the front of the tape in order to perform an assemble edit.

we can add extra black frames before whatever shoud be recorded. This will give the deck enough time to lock up. Can it work?

[Scott Sheriff ]This procedure is also called blacking….This is so you can do insert editing.

If we’re sure there’s no need for insert editing, can we just crach record? And the TC, CT , audio and video will be in sync with each other?

And if we crach record on a blank tape from the beginning to the end, can we say that we have blacked the whole tape in a special way? since there’s continous TC and CT on the tape.

[Joseph Owens]The easiest way to achieve that was to lay down a continuous recording, the “pre-stripe” to essentially plow the road for the actual program material to be inserted later. It really does lay all the ground work for revision inserts, technical corrections, audio laybacks, and all the rest of the insertion process.

Why not record the audio and video while plow the road? Yes, I see the need for the “pre-stripe” , it’s necessary for later insert edits, etc. But for assembling edit, I can’t see it. If say, assembling edit can’t be started from nowhere (no reference), the “pre-stripe” is from nowhere. Why not record AV while striping? The deck can’t do like that or something else?

Sorry for I’m entangled here. Thanks in advance for any help.