Billy Steinberg
March 2nd, 2014, 07:17 PM
Hi,
My needs for a field recorder are probably different from most here; I will not be connecting it directly to a camera, but will be using it to record feeds in a remote production truck or broadcast studio. I'm USA based, so I'm dealing with US frame rates 99% of the time. I've read through the manual, and read up as much as I can, but I still have a few unanswered questions.
Timecode:
I'm confused about (direct) control of Drop Frame versus Non-Drop Frame. (For frame rates that support DF, of course). I presume that SDI embedded time code will be whatever it already is, and DF will be used when timecode is set to time-of-day (else it wouldn't remain time of day). The manual shows a "Use Drop-Frame" control in the screen shots for record-run and auto-restart modes, but in both cases it's "N/A". Can I actually set DF/NDF in the record-run and auto-restart modes, even though the pictures in the manual seem to indicate N/A?
Audio Channel Assignment:
Are SDI embedded audio channels recorded as individual single channel streams or one multi-channel stream?
Pull Down:
I record mostly 1080i59.94, but occasionally I set the cameras to acquire in 23.98pSF or 29.97pSF. I'm not expecting any surprises with 29.97p embedded in a 59.94i signal, as nothing can really tell the difference without watching or analyzing the cadence, but I have a few questions about what to expect when my cameras are set to acquire in 23.98p.
When I'm feeding "true" 23.98p to the Samurai Blade, there won't be any confusion with Pull Down, since there isn't any. When I'm feeding 59.94i with embedded 23.98p, I have two choices as to how I want to record it. I can record it as-is (59.94i), which will leave the Pull Down intact, with its characteristic cadence (motion judder) present. Or I can have the recorder figure out the cadence and remove the Pull Down and record the signal as "true" 23.98p. My decision on which way to record the signal is driven by how I plan on using the recording. Can I specifically instruct the Samurai Blade which way to record a 59.94i signal with embedded 23.98p frame rate?
Bad Cadence:
When recording a show with multiple cameras acquiring in 23.98p and the cameras outputting it embedded in a 59.94i signal with Pull Down added, on rare occasion one camera will have it's Pull Down out of sync with the other cameras. This throws the cadence off every time the switcher takes the offending camera (or the editor uses that camera in post). It doesn't matter to any of the broadcast chain (including the recorders), but I wonder what effect it has on Samurai Blade, particularly if it's set to extract the embedded 23.98p out of its 59.94i wrapper.
pSF / progressive:
All the progressive signals I will run into are not "true" progressive, but rather are progressive Segmented Frame (pSF). This is done (mostly) to allow broadcast monitors and recorders to deal with a slightly different signal than they're used to. How does the Samurai Blade deal with this on output, in both E-E and playback? If I feed a 59.94pSF signal with embedded 23.98p, what shows up on the output BNC while I'm recording? If I have the Samurai Blade set to remove the Pull Down, will that effect what comes out the BNC while recording? When I input (non-embedded) 23.98pSF, will the Samurai Blade record it as pSF or turn it into "true" progressive? The reason this is important to me is that 90% of the monitors this may be playing to will handle pSF just fine, but won't handle true progressive. *Note to Atomos: If it's not too difficult to do, and if it's not there already and I just missed it, putting in a "Convert p to pSF on output" setting would be very useful, at least to me. :)
Action on Loss of Signal:
What does the Samurai Blade do when there's an interruption of the input signal while recording? I would hope it closes the file and waits for the input signal to show up again. Does it resume recording after the signal comes back, or does one have to press record again? This may happen more than I'd like because sometimes an engineer has to send me a different source via a patch cable change rather than a synchronous router.
Thanks for any help!
My needs for a field recorder are probably different from most here; I will not be connecting it directly to a camera, but will be using it to record feeds in a remote production truck or broadcast studio. I'm USA based, so I'm dealing with US frame rates 99% of the time. I've read through the manual, and read up as much as I can, but I still have a few unanswered questions.
Timecode:
I'm confused about (direct) control of Drop Frame versus Non-Drop Frame. (For frame rates that support DF, of course). I presume that SDI embedded time code will be whatever it already is, and DF will be used when timecode is set to time-of-day (else it wouldn't remain time of day). The manual shows a "Use Drop-Frame" control in the screen shots for record-run and auto-restart modes, but in both cases it's "N/A". Can I actually set DF/NDF in the record-run and auto-restart modes, even though the pictures in the manual seem to indicate N/A?
Audio Channel Assignment:
Are SDI embedded audio channels recorded as individual single channel streams or one multi-channel stream?
Pull Down:
I record mostly 1080i59.94, but occasionally I set the cameras to acquire in 23.98pSF or 29.97pSF. I'm not expecting any surprises with 29.97p embedded in a 59.94i signal, as nothing can really tell the difference without watching or analyzing the cadence, but I have a few questions about what to expect when my cameras are set to acquire in 23.98p.
When I'm feeding "true" 23.98p to the Samurai Blade, there won't be any confusion with Pull Down, since there isn't any. When I'm feeding 59.94i with embedded 23.98p, I have two choices as to how I want to record it. I can record it as-is (59.94i), which will leave the Pull Down intact, with its characteristic cadence (motion judder) present. Or I can have the recorder figure out the cadence and remove the Pull Down and record the signal as "true" 23.98p. My decision on which way to record the signal is driven by how I plan on using the recording. Can I specifically instruct the Samurai Blade which way to record a 59.94i signal with embedded 23.98p frame rate?
Bad Cadence:
When recording a show with multiple cameras acquiring in 23.98p and the cameras outputting it embedded in a 59.94i signal with Pull Down added, on rare occasion one camera will have it's Pull Down out of sync with the other cameras. This throws the cadence off every time the switcher takes the offending camera (or the editor uses that camera in post). It doesn't matter to any of the broadcast chain (including the recorders), but I wonder what effect it has on Samurai Blade, particularly if it's set to extract the embedded 23.98p out of its 59.94i wrapper.
pSF / progressive:
All the progressive signals I will run into are not "true" progressive, but rather are progressive Segmented Frame (pSF). This is done (mostly) to allow broadcast monitors and recorders to deal with a slightly different signal than they're used to. How does the Samurai Blade deal with this on output, in both E-E and playback? If I feed a 59.94pSF signal with embedded 23.98p, what shows up on the output BNC while I'm recording? If I have the Samurai Blade set to remove the Pull Down, will that effect what comes out the BNC while recording? When I input (non-embedded) 23.98pSF, will the Samurai Blade record it as pSF or turn it into "true" progressive? The reason this is important to me is that 90% of the monitors this may be playing to will handle pSF just fine, but won't handle true progressive. *Note to Atomos: If it's not too difficult to do, and if it's not there already and I just missed it, putting in a "Convert p to pSF on output" setting would be very useful, at least to me. :)
Action on Loss of Signal:
What does the Samurai Blade do when there's an interruption of the input signal while recording? I would hope it closes the file and waits for the input signal to show up again. Does it resume recording after the signal comes back, or does one have to press record again? This may happen more than I'd like because sometimes an engineer has to send me a different source via a patch cable change rather than a synchronous router.
Thanks for any help!