CompuServe Messages

I had to pick a recepient for this long replay but it is directed to ALL. You're it. Hope you don't mind. Doug Shannon of Sunrize sent me this today, and with his permission, I am uploading to the forum most of his letter: "I do have an answer for you as to why it worked in 2.0 and not 3.0. It does have to do with the timecode on your tape. Let me explain. "First, the reason your audio played faster than you recorded it is because of the SMPTE lock option in 3.0. If you record audio with SMPTE lock on, Studio16 will look at the incoming SMPTE (if any) and measure it. Studio 16 will make sure it samples 44100 samples for every SMPTE second it receives. Which means if you are recording audio while playing some SMPTE that is slow, let's say it's so slow that every SMPTE second is actually I and a half second period. During playback, SMPTE lock will play back 44100 samples during the 1 and 1 half second. This allows audio that was both recorded and played back with the same SMPTE timecode to lock accurately. "What's happening with you is your audio was recorded without SMPTE timecode coming in, so Studio 16 used it's internal timing crystal as source with SMPTE lock on. This means that 44100 samples were recorded for every second Studio 16 generated. When you played back those samples, you played them back with SMPTE lock on and with SMPTE timecode coming in. The SMPTE second produced by your timecode generator was not the same length as the second used to record the audio which means that the SMPTE lock played back the audio at a speed slightly different than the one used to record it. "Secondly, the reason version 3.0 triggers early but 2.0 triggers late is because of the new way Studio 16 locks to timecode. The 2.0 method was flexible but drifted audio playback (not triggering) over long periods of time, which people didn't like. Version 3.0, while being more accurate, is less forgiving. With video, the amount of drift you'll experience is normally minimal. VCRs by nature of their design have excellent timing, and so any drift you'll experience with them will be because of tape stretch. Studio 16 3.0 locks beautifully to SMPTE on video tape. But when Studio 16 encounters a substantial amount of drift (over 2%), the software can't correct for it, and your audio will become unsynchronized. Since your timecode generator doesn't lock to video, it's very likely that it drifts, which essentially means your timecode is stretched (or in your case squished) before it gets laid down onto your video tape. When you play your tape from the middle, everything looks fine, but it's starting to drift. It's only after 15 minutes that the drift builds up to the point of being noticeable. If your SMPTE was locked to video, it would be within the lock limits for Studio 16. Please remember when Studio 16 experiences drift you'll notice that the SMPTE monitor and the position flag are matched right up to the window burn. This is the case since Studio 16 is reading the timecode properly. "As far as the different timecode standards go on Studio 16 3.0, this is a labeling issue. 29.97 is the actual frame rate of color NTSC video. Most people call NTSC video 30 fps or 30 non-drop, but to differentiate it from 30 black & white we named it 29.97. 30 DF is also running at 29.97 fps, but it drops a frame here and there so that it's time counter matches real time. The reason switching between the two provides no audible difference is because Studio 16's lock capability will correct (to a point) for incorrect SMPTE preference settings. I do believe that the SMPTE output module will fix your 3.0 problem." Version 3.01 (not 3.1 as I reported) will report an error if the timecode fluctuates too much. The Sunrize SMPTE output module works with the Toaster to sync TC to the video. It hasn't arrived yet, but I will keep you posted. BTW the 44100 samples he is talking about is different from the sampling rate you set when doing your recording. My recording was only done at 20000. Glenn