Forum Replies Created

Page 76 of 234
  • NTSC is perfectly REAL TIME in a closed system.

    Otherwise if you recorded a clock, it would play at a different speed than the clock itself.

    You’re getting caught up in the frame-rates.
    They have nothing to do with TIME.

    They are actually MEASURED by TIME.

    A video camera scene recording for 22 seconds rolling at 25 fps (PAL) and played PAL will play for 22 seconds.

    A video camera scene recording for 22 seconds rolling at 30 fps (NTSC) and played NTSC will play for 22 seconds.
    Even though the two were recorded at different frame RATES (per second) as long as they are PLAYED at the same rate, they will be exactly the same LENGTH in TIME.

    That’s why we say, “per seceond” instead of “per frames”.

  • [Joanie] “I tried exporting the CD audio track at 47.952 and reimporting, but it still drifts, It was 44.1 to start with”

    That’s what I was aluding to in my previous message above (it was posted as you were posting THIS one.)

    You want the DAT to the CD to be a perfect file conversion that results in a perfect one-to-one TIME MATCH.

    If the DAT plays the track at 46 minutes and 31 seconds.
    You need the CD to play at 46 minutes and 31 seconds.

  • Be careful.

    I’m not so sure that’s the specific problem.

    If they DO that, they WILL be changing the PLAYBACK length of the DAT audio.
    It just MIGHT work, BTW, but only IF they have been doing something otherwise WRONG in the previous transfers.

    Consider this:

    The camera is rolling, pointed at a clock with a sweep second-hand and a ticking pendulum.

    There is a DAT deck recording the audio of this independently of the video.

    The camera and the DAT deck both record for exactly 58 minutes and 32 seconds.

    What you WANT is the DAT files to play at exactly the same speed it was recorded (58 minutes and 32 seconds)… not “adjusted” to some different time (frame-rate).

    Likewise, you want the video file to play for exactly 58 minutes and 32 seconds.

    If the audio gets transfered at some OTHER rate (as I assume it has been in the PAST during the transfer to CD) the length of the audio will be wrong compared to “real-time” (the clock, in this case) and the sync will get farther off as it plays against the video.

  • [Michael G] “Dat to aif, burned to a CDRom doesn’t require a sample rate change from 48khz to 44.1khz. So if that is happening, it is unnecessary.”

    Yes, I added that to another post.

    Her new reply, states (as I first suspected, that the DAT audio is being converted to an audio CD.

    Since that’s the case, if the audio guy is correctly making the transfer, there should be NO drift.

    —————
    The DAT is not locked to the camera… its “locked” to TIME (real-world), as is the camcorder.

    Therefore:
    32 minutes, 22 seconds of VIDEO is the same length as 32 minutes, 22 seconds of AUDIO… IF there is not some sort of transfer error.
    —————
    There’s got to be something the audio guy is doing wrong in the transfer to the CD.

  • My 44 kHz CD reply was based on him burning an “AUDIO CD” (one that will play on any standard CD player).

    OR, is he burning a “DATA” CD with the raw DAT files recorded on it, that you then drag onto your HD and import to FCP?

    How are you getting the CD audio into FCP?

  • Well, without knowing anything about your setup or his setup. I’d suspect that the problem could be coming in at some point in his transfer process.

    Your original question was about DAT audio.

    Now there’s an extra “layer” of transfer and sampling conversion in going to the CD.

    If the audio tech probably recorded the DAT at 48 kHz sampling, but a CD is actually 44 kHz sampling.

    That alone should not be a problem, but he MUST use the proper conversion to burn a CD from the DAT files (I have no way of knowing what he’s doing from here.

    OTOH, you didn’t tell us what kind of cameras and format you are shooting.
    Or how you are capturing the video.

    DETAILS are ESSENTIAL for better response to your problem.

  • DF and NDF have nothing whatever to do with sync or timing.

    It is simply a numbering system.

    The same number of frames are recorded in either TC mode.

    I’m surprised that there is any drift at all.

    I have no problems with sync-slippage when using digital audio sources and digital video tapes. None.

    How are you capturing the DAT tapes?

  • Not much difference than shooting an hour of footage on 13 different days.

  • Make sure you have chosen “Fit to Window” for the size of the Canvas.

    Make sure you do not have any part of the Canvas “pushed off” of the edge of the computer screen.

  • The first thing to always try is to Quit FCP, Restart the Mac, Open your FCP project and try again.

    Next:
    THE FOLLOWING COMES FROM THE KEN STONE WEBSITE:
    “Over 5,000 years ago Confucius wrote: ‘If you are toiling away, you have changed nothing and FCP heads South on you, [starts behaving in strange ways] then it is time to trash your FCP Preferences.’ ”

    Click the following link for instructions.

    https://www.kenstone.net/fcp_homepage/trashing_fcp_prefs.html

    A great way to do this is to use “FCP Rescue” a free Apple Script that will Trash the Preferences for you (and restore nearly all of your user settings afterward).
    There are versions for FCP (Pro) & FCE (Express) and a new one for FCP 5.

    Download these free Apple Scripts at

    https://fcprescue.andersholck.com/
    or
    https://pistolerapost2.com/fcprescue/

    This is one FCP tip that has helped in solving hundreds of “odd” problems.

Page 76 of 234

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy