forgive my ignorance...

[Daniel L Miller]

hey guys, i was looking through the forum here to try to find an answer to my question and it only gave me another question. im looking into buying a DAT deck (i just started using two system sound) and i originaly thought that i would find one that connected to my comp via firewire, that never happened, but i started to hear about S/PDIF I/O. i tried to google what that was, but all i got was a bunch of sites selling gear that had this feature, none of them told me what it actually was. from what it looks like this type of connection hooks to a special input on some soundcards and along with the audio it also transfers the timecode from the tape as well?

[Dan Keaton]

Dear David:

S/PDIF stands for Sony/Phillips Digital Interface.

This allows the audio from a device, such as a DAT tape or other unit, to be sent digitally to another device, such as to your computer. Since this is a digital transfer, there is no loss in audio quality.

Some sound cards have S/PDIF inputs, and your DAT tape should have S/PDIF outputs as well as being capable of recording sounds using S/PDIF as an input.

However, while many sound cards have S/PDIF input, few have S/PDIF input and output.

I do not know if the timecode is transferred with the audio or not.

If all you are interested in is transferring the audio from your DAT to your computer, then a computer sound card (or built in feature of your computer) will allow you to do that, if it has S/PDIF.

[Steve House]

Originally Posted by Dan Keaton

....

Some sound cards have S/PDIF inputs, and your DAT tape should have S/PDIF outputs as well as being capable of recording sounds using S/PDIF as an input.

However, while many sound cards have S/PDIF input, few have S/PDIF input and output.
...

If all you are interested in is transferring the audio from your DAT to your computer, then a computer sound card (or built in feature of your computer) will allow you to do that, if it has S/PDIF.

Actually it's the other way around - a lot of the consumer soundcards have S/PDIF outputs for surround sound etc but very view have S/PDIF inputs. Pro-grade audio interfaces, OTOH, often do and some are switchable between S/PDIF, which is basically a consumer format, and AES/EBU which is the professional broadcast version.

Time code could be recorded on tape on a spare audio channel if you have a multitrack DAT but with most DV cameras there's no timecode output to provide the signal or input to accept an external master clock so it's moot as there's nothing to be recorded anyway. DAT is being used less and less these days in favour of flash-card, microdrive, or minidisc recorders. These usually have good enough internal timebases that they'll maintain sync over a reasonable timeframe without the need for recording timecode from the camera. If possible set the recorder to use 16bit 48 kHz or 24 bit 96 kHz (sample rate the same or an even multiple of the DV rate in other words), roll sound and camera, use an old fashioned clapstick as a sync marker (and it looks so cool!) and you shouldn't have any problems.

[Daniel L Miller]

well, the DAT i have has a TC generator that can output to a slate weve been using, and id like to be able to use the the slate to its fullest potential which requires getting the TC from the tape into the computer along with the audio. the TC generator on my DAT also has inputs for camera TC so it would be possible to sync them all up right then and there and be done with it, but again, id need to be able to get the TC off the tape and into my computer. i have a dual 1.8 G5 tower with the production bundle. i guess id be using soundtrack pro to capture the audio, or perhaps straight into FCP, im not sure which is more efficient.

[Dan Keaton]

Dear Steve,

Yes, you are correct. I do not know what I was thinking. Sorry for the error.

[Steve House]

Originally Posted by Daniel L Miller

well, the DAT i have has a TC generator that can output to a slate weve been using, and id like to be able to use the the slate to its fullest potential which requires getting the TC from the tape into the computer along with the audio. the TC generator on my DAT also has inputs for camera TC so it would be possible to sync them all up right then and there and be done with it, but again, id need to be able to get the TC off the tape and into my computer. i have a dual 1.8 G5 tower with the production bundle. i guess id be using soundtrack pro to capture the audio, or perhaps straight into FCP, im not sure which is more efficient.

You'd also need to get the TC off the camera and over to your DAT while shooting so the first consideration is whether your camera has TC output. But in any case, it's probably not necessary and doing it wouldn't give you any benefits. I'm not an expert but as I understand it, recording timecode on DAT is really more for shooting film than video and if you're shooting DV any TC on the audio tape is redundent.

In film, picture and sound are edited separately and married to each other late in the final production processes. For editing, the flm is transferred to video through telecine but this changes the speeds slightly. Having the DAT running in sync with the camera and the same timecode on the sound as the picture allows the sound to be speed adjusted to compensate for the picture when it is resolved. You also have a reference between picture and sound so that you can match up the sound to the conformed negative via the Edit Decision List that is output in the editing process.

But shooting on video is different. The timebase that is used for editing both picture and sound is not the code recorded during shooting, it's the timebase generated by the NLE program itself. As long as you have both a visual and an audible slate and a log so you know which audio clip goes with which video clip, audio timecode is unnecessary to sync up the sound after importing it or to maintain sync between them through the clip. They both run in sync to the internal timeclock of the NLE so once aligned they won't drift away from each other. You just don't have the various speed changes and conversions along the way that you do with film. So you capture your video clip, separately capture the audio as a wav file, put 'em both on the timeline in your NLE and match them with the slates. If you want to be double careful, record both head and tail slates so you can match the head and then check the tail to see if it's still in perfect sync - if not, most editing software allows you to fine tune the length of the audio without shifting pitch so you can lock the head and then shift the tail in the audio track to line 'em up perfectly (and FCP is one that can do this). Once aligned, they'll stay aligned unless you move 'em.

[A. J. deLange]

There is a great advantage to having the audio sampled synchronously with the video and that is that they will stay in sync throughout a clip of any length. If not synched in this way the crystals of the camera and DAT or audio capture board will drift appreciably in a matter of minutes and it is then necessary to stretch or compress the audio in the NLE or sound editing software to make it match the video. The problem is, of course, that even prosumer cameras do not make synch available. I believe the LANC standard calls for output of SMPTE time code and many devices, like the DAT and Firewire audio capture devices are capable of deriving their sampling clocks from time code but I don't know which if any cameras with LANC ports actually put out the code. If any one knows if the XL2 does please reply.

[Steve House]

Originally Posted by A. J. deLange

There is a great advantage to having the audio sampled synchronously with the video and that is that they will stay in sync throughout a clip of any length. If not synched in this way the crystals of the camera and DAT or audio capture board will drift appreciably in a matter of minutes and it is then necessary to stretch or compress the audio in the NLE or sound editing software to make it match the video. The problem is, of course, that even prosumer cameras do not make synch available. I believe the LANC standard calls for output of SMPTE time code and many devices, like the DAT and Firewire audio capture devices are capable of deriving their sampling clocks from time code but I don't know which if any cameras with LANC ports actually put out the code. If any one knows if the XL2 does please reply.

Many users report results at odds with your statement here. If you were talking about film or analog video cameras and recording double-system audio on a DAT then you'd be absolutely right. But for DV cameras and audio recorders that record in PCM WAV or BWF format set to 48kHz sampling (or an even multiple thereof) many users find they will maintain sync within 1 frame anywhere from 15 minutes to an hour or more. If you're really picky, getting both a head and tail slate when shooting and using an NLE like Vegas or Nuendo makes it a simple click and drag operation to allow you to make any slight adjustments in timing necessary to keep it dead-on. Mixing 48kHz video with 44.1 kHz audio files is more of an issue, especially if you're not resampling the audio.

[A. J. deLange]

It is possible that two pieces of equipment will stay in sync and doubtless they have but it is more likely they will drift if not synchronized. This is why pro's tie everthing to a common black burst generator. Typical clock stability for an uncompensated crystal (and I don't think the one's in our cameras are ovenized but they may be temperature compensated) run to 10's of ppm. Two cameras or a camera and DAT with time bases 10 ppm apart will drift 2 frames in an hour. Two devices 50 ppm apart will drift 10. In my experiments with pairs of cameras and camera and audio capture device the drift rate has been closer to 50 than 10 (i.e. a frame in a few minutes). Age of the crystal, temperature battery condition etc. have an appreciable effect on clock rate. This is precisely why sync is used in pro work.

In the prosumer audio world the ability to clock multiple pieces of equipment exists at reasonable cost. For example, I'm fiddling with a MOTU Traveler for recording 4 channels of sound. It's a great little box (runs off Firewire power from the laptop you record to) and accepts external sample clock or SMPTE time code. Problem is that the XL2 doesn't supply either (unless it's on the LANC port and I can't seem to find out whether that's the case or not). So I'm tantalizingly close to being able to tie audio and video together. I guess I could cobble up something to pull the sync off the composite video and use a PLL to generate sample clock from that but I'd rather wave my credit card around than a soldering iron. It's frustrating because, obviously, SMPTE code and audio sample sync are both available within the camera. If anyone from Canon is reading this (and we know you are out there) I'd hope that consideration will be given to putting these signals on a connector in future models.

[Steve House]

Originally Posted by A. J. deLange

...

Age of the crystal, temperature battery condition etc. have an appreciable effect on clock rate. This is precisely why sync is used in pro work.

In the prosumer audio world the ability to clock multiple pieces of equipment exists at reasonable cost. ...

The ability to genlock cameras is more a matter of keeping their frame rasters in perfect sync so you can switch live without the picture jumping or losing sync, allowing you to super or dissolve between video streams without image sync problems more than it is to maintain sync to audio. Likewise, the ability for an audio interface like your MOTU to lock to a common clock is for a similar purpose, to allow you to mix multiple digital audio streams from different sources without clicks, pops, and distortion caused by the samples in the separate streams not exactly coinciding. If you're feeding a digital audio signal into your MOTU and mixing it with a file already recorded, the samples must coincide exactly.

[Daniel L Miller]

soooooooo, while i have learned allot from this thread, i never found out if s/pdif transfers TC as well as the audio. if it doesnt is there a way to get the TC off the tape. i know with video it may not be needed, but its something id like to know how to do. thanks again guys.

-daniel out

[A. J. deLange]

Daniel,

For Daniel: The answer is a definite "maybe". Most modern DV cameras are equipped with a LANC port and the LANC spec requires that the time code be available on that port. There used to be a little box (http://www.spcomms.com/ltcexport) that drew power from the port and converted the LANC time code to SMPTE time code which could then be recorded on a free audio track, used to run a display (such as on a timecode displaying slate) or used to sync external audio equipment (if one appreceiates the value of doing this). That little box is no longer made, unfortunately, but the supplier has an alternative which costs twice as much and runs on mains power but still produces a copy of the LTC with which you can do whatever you like.

The reason for the "maybe" is that not all implementations of LANC necessarily follow Sony's spec so before investing in any equipment you'd want to insure that your particular camera actually puts the time code out on its LANC port.

Once you have SMPTE timecode there are devices that can use it produce sample clocks for audio recording (such as the MOTU traveller I mentioned earlier).

There is another MOTU gadget called a "Timepiece" which can generate various sync signals (and time code) from a video input. This would allow tying a DAT recorder to your camera without extracting the cameras timecode should it not be available.

For Steve: Genlock was developed way before digital audio recording and the reason for it was as you have stated (and also to align color burst reference phases) but the ability to have audio and video in sync simplifies workflows greatly. If, for example, one wants surround and records two extra channels for this using an external device tied to the video and mics connected to the camera for the front channels only simple alignment is required. Once this is achieved front/rear phase will be maintained throughout the cut at all frequencies because the relative group delay is fixed and correct throughout. I suppose you could say in this case that it is not audo/video sync that is being maintained but audio/audio using the video as the reference but clearly claps at the beginning and end of a 1 hour tape will be in perfect alignment as well if this method is being used with no processing of the audio.

Technical arguments aside we wonder why manufacturers make this equipment and why people buy it if it is of no value.

[Steve House]

Originally Posted by A. J. deLange

...
For Steve: ....

Technical arguments aside we wonder why manufacturers make this equipment and why people buy it if it is of no value.

Never said it was of no value. It's extremely valuable, even mandatory, in any number of scenarios. I only say it's overkill and unecessary for the specific case of maintaining lipsync between video recorded on a single DV camcorder such as an XL2 and double-system audio recorded digitally on a DAT and imported into the NLE as a 48kHz WAV or BWF file through the audio interface's s/pdif input. Once aligned via a slate the timebases are close enough that the clip should maintain sync over any reasonable shot length and any slight drift is easily corrected.

Where the clock *is* critical in that setup is the audio interface will need to be set to get external sync from the s/pdif stream so its timebase is synced to the clock coming in from the DAT. If not, the incoming audio will have noise and/or distortion introduced. I may be wrong but I think most interfaces automatically use the incoming reference sync when presented a signal at the s/pdif input - others may need to be set specifically to do so.

The "Timepiece" would be used when you have multiple digital devices in use simultaneously, say a DAT, a digital mixer, perhaps some digital signal processing, maybe a MIDI device or two, and perhaps multiple audio cards as well. In order for them all to be on the same page with their samples perfectly coinciding at the same rate, you'd use the Timepiece unit to generate and distribute "house sync" and set all the other digital devices' internal clocks to slave to it.

In the NLE, sample level sync is maintained automatically between all of the various audio and video tracks since the clock used during playback and rendering is generated by the editing system itself and the various source track samples all line up to the same master clock. After 1 second, 48,000 samples of video have been played, and in the same 1 sec 48k samples of audio 1, 48k samples of audio 2, 48k samples of audio 3 etc etc etc.

This is also why it's crucial for sources such as mp3's, cd audio, etc recorded at 44.1 or some other sample rate to be *resampled* to the project's 48k sample rate when they're imported. Some NLE's do it automatically when the track is imported but some others might not or might have had their resampling disabled in the setup. If the video track is at 48k but the audio track is left at 44.1 wthout being resampled, as 48k samples, 1 sec worth, of video is played, 48k samples of audio will also be played but at 44.1 kHz that represents 1.09 seconds worth of original audio instead of 1.00 and you'll lose sync very fast. 1.09 seconds of sound played back in 1.00 seconds represents about a 10% speed increase and you'll find the sound rapidly leads the picture, almost 3 frames lead for each second of program running time. (Offered as a cautionary note to those of our companions here recording double system sound in mp3 format.)

As far as Daniel's specific question about the presence of SMPTE timecode at the s/pdif output of the DAT, I might be wrong but AFAIK it would not be. SMPTE occupies an audio track all to itself on the recorder but s/pdif is a 2-track stereo format and would be full-up with a stereo audio signal. TC would require a third track at least. (I wonder if it might be present in an ADAT multi-channel output - anyone know?) OTOH, the DAT's digital CLOCK signal, discussed above, *is* present as part of the digital data stream but that's not the same thing as SMPTE code.

[A. J. deLange]

S/PDIF does not pass time code to my knowledge. There are "subframe bits" which could be used for this if the manufacturer chose to do so (they are free to use these bits for whatever purpose they choose but AFAIK they are only used for copy protection indication at this time). The standard allows for up to 4 channels so certainly one could add an extra channel and put time code on that but again I am not aware of anyone doing this.

Time code transfer between ADAT and other devices is through an ADAT sync port (I believe the connector is a DB-9) and this port also allows control of the machine by a computer.

In reading back over the thread it appears that the goal is to have audio and video tagged with the same time code. This could be done provided that the camera puts time code out over its LANC port. One would then have to purchase a LANC to SMPTE LTC converter - around $700. As the DAT has LTC input it is clearly capable of resolving its sync to it and so the sync problem is solved. That leaves getting the time code into the computer. This requires a synchronizing device with ADAT sync capability (e.g. the Timepiece AV - another $500) and associated software but I think this would get you where you want to be - audio and video with the same time code.

If the camera does not put out LTC over its LANC port all is not lost (and you'd save $700) by use of just a synchronizer such as the Timepiece which will generate SMPTE time code from the video from the camera. Lock the ADAT to this time code and you will now have time tagged video and audio in synch but the time codes will not be the same though the offset will be constant throughout each cut. Slate claps or other means could be used to determine those offsets it's possible to put fixed offsets into the ADAT contol for playback which might make editing easier.

[Steve House]

Seems a lot of money and hassle for very limited benefit in the typical DV production, AJ. And while having the same code on audio and video might be a convenience, I'll stand by my guns that it's not necessary to achieve professional results for simple single camera video, double-system sound shoots.