View Full Version : how record audio while shooting at 24fps
David Aliperti November 22nd, 2011, 12:14 PM a producer just sent me and e mai relating a short movie i am going to work on,
hey we will be shooting at 24 fps,
do I have to care about that?
or can i stay at 25 fps since recorder and camera will not have any digital sync connection and they will be using a normal clapboard ,
the camera will be a RED EPIC, ill give an audio mono track to camera via wireless or cable to help editor to sync the audio tracks I deliver
how should i set my recorder frame rate?
Jon Fairhurst November 22nd, 2011, 02:33 PM Unless you are running timecode, the frame rate doesn't matter. Record at 48kHz. When using timecode, set all units to the same frame rate.
David Aliperti November 22nd, 2011, 02:58 PM Do you mean an external unit generating time code and or wiring recorder to camera tc?
Jon Fairhurst November 22nd, 2011, 06:48 PM Where the timecode is generated depends on your setup and what your equipment does and doesn't support. (I've never shot on an EPIC, and I don't know your recorder, so I have no idea if you are even using timecode.)
The bottom line is that the camera records images in real time. The recorder records audio in real time. When you put them together you just need to sync them up. Regardless of the frame rate, real time is real time.
Timecode simply makes it easier to sync the audio and video. You don't have to scrub through manually or with software to match the two.
David Aliperti November 23rd, 2011, 01:08 AM My recorder is fostex pd6, it reads and generates time code, some time ago, we where shooting in ntsc (here in europe) and i set my recorder to 29, 97 fps
the audio editor later in postproductions complained about some trouble he had with audio, and someone suggested me to shoot always at 25fps (i am in italy)
Jon Fairhurst November 23rd, 2011, 02:27 AM I understand. You should set the timecode to the same rate as the camera is shooting. That way there will be one unique code per frame and the frames will be counted in the normal manner.
Be aware that there are two types of 24 fps: 24.000 (film) and 23.976 (4/5 NTSC). With 23.976, there are two sub types: drop-frame and non-drop-frame. Most NTSC editors use drop-frame. Drop-frame skips certain frame numbers to ensure that the minutes and seconds are accurate over long periods of time. Non-drop-frame counts 24 frames per second, so the minutes and seconds are 0.1% too slow.
If the camera is set to 24p, set the timecode in your recorder to 24 fps.
If the camera is set to 23.976p, set the timecode to 23.976 drop-frame.
Record at 48 kHz.
Best of luck with your shoot. :)
Steve House November 23rd, 2011, 07:17 AM BTW, Jon, it is generally recommended that location original code in the camera and recorder be recorded as NON-drop frame. The only reason drop frame is needed is so the timecode corresponds to actual clock time, important in the final edited program's timeline when destined for broadcast but irrelevant in the stages before that. And of course that only applies in the NTSC world, no such thing as drop-frame in PAL or true 24fps.
Jon Fairhurst November 23rd, 2011, 12:46 PM Thanks for that info Steve. I worked for Grass Valley Group for a number of years, so the preference I had heard for drop frame comes more from the broadcasting and master control side of things.
For production and shorter clips, non-drop-frame makes a lot of sense.
More important than anything - make sure that everything is on the same timecode setting. Drop frame on one unit and non-drop-frame on another is sure to cause problems.
In fact, David, the problem with your previous NTSC shoot might not have been 29.97 vs. 25 fps. It might have been drop vs. non-drop.
Steve House November 23rd, 2011, 04:39 PM Yep, the timecode recorded with a piece of video in-camera bears no relation to the timecode alongside that same image after it has been embedded into a larger program and the program rendered for broadcast.
David Aliperti November 23rd, 2011, 05:21 PM In fact, David, the problem with your previous NTSC shoot might not have been 29.97 vs. 25 fps. It might have been drop vs. non-drop.[/QUOTE]
thanks this make sense to me now.
David Aliperti November 23rd, 2011, 05:23 PM In fact, David, the problem with your previous NTSC shoot might not have been 29.97 vs. 25 fps. It might have been drop vs. non-drop.
thanks, this makes finally sense to me now
David Aliperti November 25th, 2011, 01:47 AM BTW, Jon, it is generally recommended that location original code in the camera and recorder be recorded as NON-drop frame. The only reason drop frame is needed is so the timecode corresponds to actual clock time, important in the final edited program's timeline when destined for broadcast but irrelevant in the stages before that. And of course that only applies in the NTSC world, no such thing as drop-frame in PAL or true 24fps.
I set recorder at 23, 97 as the camerA but i really don't know if it is drop or non drop frame, what are the risks in postproductions?
2 yesterday i imported in final cut time line some files and just could read the real time of start and end of file recorded ( the intrrnal watch in free run mode) but could not read nothing to do with fps, where do i get this info in video editors programs?
Steve House November 25th, 2011, 05:09 AM I set recorder at 23, 97 as the camerA but i really don't know if it is drop or non drop frame, what are the risks in postproductions?
2 yesterday i imported in final cut time line some files and just could read the real time of start and end of file recorded ( the intrrnal watch in free run mode) but could not read nothing to do with fps, where do i get this info in video editors programs?
It's not clear whether the files you're alluding to are audio files recorded in a timecode aware recorder or are the video files coming from your camera. The best practice is to talk to post before the shoot and give them whatever timecode format they want.
As said before, camera and audio should use the exact same timecode format. Note that if you're not sending code between the camera and the recorder or jamming the two clocks together so both devices have identical codes it doesn't matter anyway. Audio files per se have no frame rate themselves.
David Aliperti November 25th, 2011, 03:24 PM I asked to post dep, they asked me to record with same fps of camera.
probably at the time of trouble i had with 29,97 the problems were due to drop and non drop frame aspect,
thanks to all of you.
Rick Reineke November 25th, 2011, 06:52 PM If your not sure, make sure you clap slate it and are recording @ 48kHz. If there are sync problems, post could at least disregard the TC and align it with the slate, which is how it used to be done..
Steve House November 25th, 2011, 07:58 PM If your not sure, make sure you clap slate it and are recording @ 48kHz. If there are sync problems, post could at least disregard the TC and align it with the slate, which is how it used to be done..
And adding to Rick's wise advice, with a file-based workflow timecode only establishes a single sync reference point to align the audio and video files in the editor. It DOES NOT establish a speed reference or do anything about sync "drift" over the duration of a long take. So it really serves no function beyond that provided by a conventional clapper slate anyway. It's a convenience, nothing more.
David Aliperti November 26th, 2011, 12:54 AM Of course we are using a tradional clap slate and clock on my recorder is 48khz
I talked with the avid editor he said that that i should set fps as the camera otherwise he' ll have a pitch shift when importing audio. Well thats what i am doing and my job will finish when i deliver audio files.
Rick Reineke November 26th, 2011, 11:40 AM "The clock on my recorder is 48khz"
- Probably a translation glitch and you know 'Word clock' and 'Sample rate' are not one.
BTW, the Red Epic, has really LOUD fans, much more annoying than the previous build. Make sure the A/C knows how to access the menu to adjust the record mode fan speed.
You're still likely to experience a few "Red moments", despite the new build.
David Aliperti November 29th, 2011, 03:37 AM fan was ok, since it was very lound in stand by but silent during recording.
|
|