jonathanparham
Senior Member
Does anyone use this?
http://handbrake.m0k.org/
http://handbrake.m0k.org/
Locking Sound to Picture? What's your method?
- Thread starter Frederick Russ
- Start date
Synesthesia
Senior Member
mac dvd ripper
A quick recommendation for Cinematize.
Runs on OS X, nice and solid, can output dv, quicktime movies etc, and I've used it on a few shows when I couldnt get QTs with no timing issues or dropped frames, etc.
Nice looking output too. Use it alongside iDVD and imovie for assembling bits for my reel!
Cheers
Paul
A quick recommendation for Cinematize.
Runs on OS X, nice and solid, can output dv, quicktime movies etc, and I've used it on a few shows when I couldnt get QTs with no timing issues or dropped frames, etc.
Nice looking output too. Use it alongside iDVD and imovie for assembling bits for my reel!
Cheers
Paul
I use Quicktime.
I tried running it out to a TV video monitor (once converted to DV - otherwise it's grainy). But I didn't like it. Also will convert via ADC-100 if I have to, wich is rare now a days.
My new way of doing it is just running it in side DP then dragging the video over to another screen (dual screens on my G5). That way it's got it's own screen and the 23" Cinemaâ„¢ can be used entirely for DP. Then I dump it to the Quicktime file and it's ready to upload for them to see it.
My question is: how many of you guys are getting window burn now a days? Do you guys even bother with it when the times are all over the place (i.e. cuts).
On my last thing I was just running reel by reel. The whole reel in each cue. I'm not into trying to edit video..... I don't really understand it and don't wanna compress it and take a chance on F'ing up the timing. Besides, it takes too long.
I tried running it out to a TV video monitor (once converted to DV - otherwise it's grainy). But I didn't like it. Also will convert via ADC-100 if I have to, wich is rare now a days.
My new way of doing it is just running it in side DP then dragging the video over to another screen (dual screens on my G5). That way it's got it's own screen and the 23" Cinemaâ„¢ can be used entirely for DP. Then I dump it to the Quicktime file and it's ready to upload for them to see it.
My question is: how many of you guys are getting window burn now a days? Do you guys even bother with it when the times are all over the place (i.e. cuts).
On my last thing I was just running reel by reel. The whole reel in each cue. I'm not into trying to edit video..... I don't really understand it and don't wanna compress it and take a chance on F'ing up the timing. Besides, it takes too long.
A year ago I would have said Beta SP, but recently it's all been Quicktime with a 2-pop. I guess maybe it's time to finally take that old VO5850 3/4" deck out of the rack! :shock:
- Mike Greene
- Mike Greene
ComposerDude
Senior Member
Mike, what kind of header/preroll are they putting on the QuickTime? Color bars, slate, and countdown?
-Peter
-Peter
gamalataki
Active Member
As soon as you do, someone will send you a 3/4" tape from their 90's "hit" that never got sold. Besides who needs a hernia from lifting those things. They do make great boat anchors though. :mrgreen:
Sometimes a preroll or color bars, but generally just the 2-pop (that beep exactly 2 seconds before picture start).
Or else visual time code. If they give me just visual time code, then I'll add the 2-pop myself when I send them music.
Now I just need the boat! :mrgreen:
- Mike Greene
ComposerDude
Senior Member
Mike, thanks.
Patrick de Caumette
Senior Member
José Herring
Lost in Cyberspace
I'm doing the standalone computer thing. Thanks for the tip Frederick about quicktime pro. I'm receiving .mov files from the editor but they're like 2 gigs each. I'm using an old G3 with a copy of DP 3.1.1 on it. I'm cutting up the .mov file in quicktime pro and making the files smaller. Loading up the files in the mac g3. Then I set up DP to send mtc out and lock up my PC's running Cubase SX3 and one other computer as an FX teleport slave.
I'm done with running picture on my main machine. Once the orchestration starts to build up there's no telling what's going to happen with the picture. It's my firm belief that picture lock should be done the old fashion way. Away from the music machine. Turning a computer into a virtual video tape player makes the most sense to me.
I'm done with running picture on my main machine. Once the orchestration starts to build up there's no telling what's going to happen with the picture. It's my firm belief that picture lock should be done the old fashion way. Away from the music machine. Turning a computer into a virtual video tape player makes the most sense to me.
I've done 4 or 5 with a standalone setup. I usually get a dvd in need of a soundtrack. Most of them were made on Macs and require the viewer, but some have been regular dvds. In either case they all seem to drop right into a Sonar track and I can stick an lcd display on a keyboard stand and just play and record a midi track. Usually with gs3 supplying the instrument sound but I've also used NI instruments. Once the midi's recorded it can be nudged to video frame alignment... did that once for the soundtrack of an Air Force video of their 1st sinking of a battleship. Then I render it to wav (or freeze if I used an NI instrument) making sure the video track start and wav start are the same. Then I drop them into Vegas/DVD Architect and make an encoded DVD.
Howard
Howard
Hans Adamson
Senior Member
Using mtc, do you think physically routing the sync signal over midi cable to the other computer would introduce latency?
José Herring
Lost in Cyberspace
No. Using MTC it will after a period of half an hour of continous play slide a few frames behind. But if you start and stop the video again it will usually be in sync again.
I seldom write cues that are 8 to 10 min in length anymore. I use to but now even on a continous music sequence I'll divide it up into 2 or 3 smaller sequences. So I'm looking at 3 to 4 minute cues max these days. MTC is fine for that.
I'm sure there are better options. I'll look into them later but for now for general picture lock mtc is great.
Jose
ComposerDude
Senior Member
Regarding the info about apparent MTC slippage, there may be a hardware or software problem. Here's the technical background on both the latency question and how MTC works for sync.
At a nominal 30 frames/second (29.97 but who's counting) each frame occupies 1/30 second which is 33.33 milliseconds.
At normal MIDI transfer speeds of 31,250 bits per second, presuming roughly 10 bits per MIDI byte and a typical 3-byte MIDI message, it takes about 1 millisecond to transmit a 3-byte MIDI message.
Though there's probably a bit of additional latency in processing, the lag for MIDI sending as above is about 3% of a video frame.
MTC makes use of "full frame messages" that are a multibyte System Exclusive message sent for precise locating, and "quarter frame messages" that send the nybbles (4-bit values) from the SMPTE timecode during program running.
Eight quarter-frame messages are necessary to deliver a complete SMPTE timecode (which means it takes two video frames for quarter frame messages to transmit the entire code) but this works OK since the frame numbers increase in a defined way, and each quarter-frame message acts like a sprocket hole for synchronization.
The two key points about quarter-frame messages: they advance with the true SMPTE time, and they are CLOCKING messages, about 8.3 milliseconds (33.33mS / 4) apart. (They're only 2 bytes, and take up about 7.7% of the MIDI bandwidth: about 240 bytes per second out of about 3125 bytes per second total MIDI bandwidth on a port.)
If you are seeing drift even in a long cue, I don't think that can be blamed on MTC, since the SMPTE-to-MTC interface is responsible for correctly generating MTC to follow precisely the incoming SMPTE timecode, and should adjust the MTC quarter-frame interval to precisely track the frame rate.
One more issue, which is that when reading SMPTE in its audio "LTC" (longitudinal timecode) form, an entire SMPTE frame must be read before you know what the frame number is. This makes the "read" number one-behind the actual number. So customarily SMPTE readers will (optionally) advance the reported frame number by 1, so that the number it SAYS the frame is, IS that frame's correct number.
There is a quiz next period.
At a nominal 30 frames/second (29.97 but who's counting) each frame occupies 1/30 second which is 33.33 milliseconds.
At normal MIDI transfer speeds of 31,250 bits per second, presuming roughly 10 bits per MIDI byte and a typical 3-byte MIDI message, it takes about 1 millisecond to transmit a 3-byte MIDI message.
Though there's probably a bit of additional latency in processing, the lag for MIDI sending as above is about 3% of a video frame.
MTC makes use of "full frame messages" that are a multibyte System Exclusive message sent for precise locating, and "quarter frame messages" that send the nybbles (4-bit values) from the SMPTE timecode during program running.
Eight quarter-frame messages are necessary to deliver a complete SMPTE timecode (which means it takes two video frames for quarter frame messages to transmit the entire code) but this works OK since the frame numbers increase in a defined way, and each quarter-frame message acts like a sprocket hole for synchronization.
The two key points about quarter-frame messages: they advance with the true SMPTE time, and they are CLOCKING messages, about 8.3 milliseconds (33.33mS / 4) apart. (They're only 2 bytes, and take up about 7.7% of the MIDI bandwidth: about 240 bytes per second out of about 3125 bytes per second total MIDI bandwidth on a port.)
If you are seeing drift even in a long cue, I don't think that can be blamed on MTC, since the SMPTE-to-MTC interface is responsible for correctly generating MTC to follow precisely the incoming SMPTE timecode, and should adjust the MTC quarter-frame interval to precisely track the frame rate.
One more issue, which is that when reading SMPTE in its audio "LTC" (longitudinal timecode) form, an entire SMPTE frame must be read before you know what the frame number is. This makes the "read" number one-behind the actual number. So customarily SMPTE readers will (optionally) advance the reported frame number by 1, so that the number it SAYS the frame is, IS that frame's correct number.
There is a quiz next period.
José Herring
Lost in Cyberspace
I never doubted for a minute that it was hardware related. I basically am using an old Studio 4 on a mac g3 sending mtc to a USB Fast Lane. I haven't spent a lot of money on midi sync and don't really intend to since all the stuff I do is software based these days anyway.
The info you have is great though. I can see that with a little effort I can get perfect sync even over longish periods of time. That's usefull when screening films scores for producers and directors.
Thanks for taking the time.
Best,
Jose
The info you have is great though. I can see that with a little effort I can get perfect sync even over longish periods of time. That's usefull when screening films scores for producers and directors.
Thanks for taking the time.
Best,
Jose
ComposerDude
Senior Member
You're welcome, Jose!
I'm curious about the Studio 4 issue since my experience with Opcode stuff has been really positive, at least on the Studio5LX. I've never had a timing problem with Studio Vision as long as I stayed in non-drop-frame format (drop-frame would work also but sometimes was associated with system crashes - aargh!).
[EDIT: This involves driving the Studio5LX LTC input from the audio output from a VCR locked to crystal-controlled blackburst, maybe that's why my sync was solid...who knows.]
Anyway, "in theory" MTC should precisely be tracking the SMPTE, at least that's how it's supposed to be working.
Good luck with that!
I'm curious about the Studio 4 issue since my experience with Opcode stuff has been really positive, at least on the Studio5LX. I've never had a timing problem with Studio Vision as long as I stayed in non-drop-frame format (drop-frame would work also but sometimes was associated with system crashes - aargh!).
[EDIT: This involves driving the Studio5LX LTC input from the audio output from a VCR locked to crystal-controlled blackburst, maybe that's why my sync was solid...who knows.]
Anyway, "in theory" MTC should precisely be tracking the SMPTE, at least that's how it's supposed to be working.
Good luck with that!
José Herring
Lost in Cyberspace
The Studio 4 for 15 years has been on every Mac i've ever owned. I never made the swithc to OSX since I switched to PC instead. It's always been rock solid sync wise on one machine running one sequencer.
This past December I got a film and the producer gave it to me the old fashion way. On a VHS tape with sympt video burn and corresponding audio code on one channel and all other audio on the other channel. What I did was to run the video's audio timecode into the Studio 4 interfaced to my old Mac G3 running Digital Performer 3.1.1. That locked perfectly as usual. But....this time I then set up DP to send MTC out of the Studio 4 to a USB interface attached to my main DAW, Cubase, on a PC. It worked rather well when composing but when screening the film to the producer, the PC after about 20 minutes would drift as far as 15 frames behind MTC. I would then stop the tape and restart it and everything would be okay.
I think I know what the problem could be. Because you're saying that MTC should be pretty tight I'm now looking into my Cubase settings. Cubase has problems with midi timing and they solved it by adding a "use system time stamp" option for incoming midi data. What this does is it ignores the incoming midi time information for an interface and calculates it's own time. It works great for internal pluggins, but do you think that this may be the cause? Or, when I slave to external sync does it bypass all the internal sync mechenisms in Cubase? Curious, I'll have to run some more test with that same video tape.
I appreciate you helping me sort this out.
Best,
Jose
This past December I got a film and the producer gave it to me the old fashion way. On a VHS tape with sympt video burn and corresponding audio code on one channel and all other audio on the other channel. What I did was to run the video's audio timecode into the Studio 4 interfaced to my old Mac G3 running Digital Performer 3.1.1. That locked perfectly as usual. But....this time I then set up DP to send MTC out of the Studio 4 to a USB interface attached to my main DAW, Cubase, on a PC. It worked rather well when composing but when screening the film to the producer, the PC after about 20 minutes would drift as far as 15 frames behind MTC. I would then stop the tape and restart it and everything would be okay.
I think I know what the problem could be. Because you're saying that MTC should be pretty tight I'm now looking into my Cubase settings. Cubase has problems with midi timing and they solved it by adding a "use system time stamp" option for incoming midi data. What this does is it ignores the incoming midi time information for an interface and calculates it's own time. It works great for internal pluggins, but do you think that this may be the cause? Or, when I slave to external sync does it bypass all the internal sync mechenisms in Cubase? Curious, I'll have to run some more test with that same video tape.
I appreciate you helping me sort this out.
Best,
Jose
ComposerDude
Senior Member
Glad to help (hopefully this proves actually helpful!)...
MIDI intrinsically carries no timing information, it's just (typically) 3 bytes sent on a serial data line. So the time that the MIDI is "on the wire" establishes the time of the MIDI event.
Due to USB interface latency etc., various modern MIDI interfaces implement time-stamping of incoming MIDI messages to properly capture the highest resolution in timing, and also support time-stamped outbound MIDI messages to better deliver at the appropriate time. Though MIDI takes about 1 millisecond to send a packet of info, the start time of that packet can vary at a sub-millisecond resolution, so the onset of the event can be much more fine-grained than just a millisecond. USB is a host-polled protocol ferrying boxcars of up to 1K bytes every 1 millisecond. So the timing system at the interface level gets you potentially improved resolution.
I'm not really familiar with Cubase or its interfaces, but I think that if your interface is off a slight amount, any delay would be a systematic error that should not grow with time.
The divergence you're experiencing with your setup suggests that either 1) Cubase is somehow ignoring the SMPTE timing and running from its own clock which may drift relative to the VCR and the embedded LTC, or -- 2) if you could actually be off by 36 frames (instead of just 15) after 20 minutes, it could be some non-drop-frame vs drop-frame scenario. It's worth checking the type of code that's on the tape as well as what type of code Cubase is set up to handle.
I think the key is that when playing it for the producer you're starting at the beginning of the show and running through, playing back dialog off the VCR and merging with your music played "live" by your sequencer.
You may not have noticed the sync slippage during composing if you do the usual start-stop-start-stop stuff because the Full Frame messages would properly locate your Cubase to follow the current VCR location, presuming you're working on a segment at a time.
By the way, independent of what we're discussing above -- a sync problem can propagate back to the client if you were perhaps to use a VCR that didn't run precisely at the right speed, then compose and lay down music that was clocked to the off-speed video but was recorded on a crystal-controlled interface. Assuming the client's VCR was running at the correct speed, the client would then have to deal with non-sync'd music or would have to timestretch it somehow.
For VCR stuff it's useful to drive the VCR by a crystal-controlled blackburst "house sync" clock so the frame rate is exactly correct, especially if cues are delivered en masse instead of cue-by-cue.
MIDI intrinsically carries no timing information, it's just (typically) 3 bytes sent on a serial data line. So the time that the MIDI is "on the wire" establishes the time of the MIDI event.
Due to USB interface latency etc., various modern MIDI interfaces implement time-stamping of incoming MIDI messages to properly capture the highest resolution in timing, and also support time-stamped outbound MIDI messages to better deliver at the appropriate time. Though MIDI takes about 1 millisecond to send a packet of info, the start time of that packet can vary at a sub-millisecond resolution, so the onset of the event can be much more fine-grained than just a millisecond. USB is a host-polled protocol ferrying boxcars of up to 1K bytes every 1 millisecond. So the timing system at the interface level gets you potentially improved resolution.
I'm not really familiar with Cubase or its interfaces, but I think that if your interface is off a slight amount, any delay would be a systematic error that should not grow with time.
The divergence you're experiencing with your setup suggests that either 1) Cubase is somehow ignoring the SMPTE timing and running from its own clock which may drift relative to the VCR and the embedded LTC, or -- 2) if you could actually be off by 36 frames (instead of just 15) after 20 minutes, it could be some non-drop-frame vs drop-frame scenario. It's worth checking the type of code that's on the tape as well as what type of code Cubase is set up to handle.
I think the key is that when playing it for the producer you're starting at the beginning of the show and running through, playing back dialog off the VCR and merging with your music played "live" by your sequencer.
You may not have noticed the sync slippage during composing if you do the usual start-stop-start-stop stuff because the Full Frame messages would properly locate your Cubase to follow the current VCR location, presuming you're working on a segment at a time.
By the way, independent of what we're discussing above -- a sync problem can propagate back to the client if you were perhaps to use a VCR that didn't run precisely at the right speed, then compose and lay down music that was clocked to the off-speed video but was recorded on a crystal-controlled interface. Assuming the client's VCR was running at the correct speed, the client would then have to deal with non-sync'd music or would have to timestretch it somehow.
For VCR stuff it's useful to drive the VCR by a crystal-controlled blackburst "house sync" clock so the frame rate is exactly correct, especially if cues are delivered en masse instead of cue-by-cue.
José Herring
Lost in Cyberspace
Got it thanks. I'll check into my settings.
Jose
Jose
Waywyn
Senior Member
okay, one question left here.
i still mainly use QT for everything and it runs smooth, but when the session gets really busy i encounter that QT sometimes just uses too much ram. although you can put in big tracks like 3-4 GB which still runs fine, but it uses too much ram.
are you guys using QT had a chance to lower that ram usage by using another codec? i use the sorensen 3 but i think i might get a better result by using something different.
i still mainly use QT for everything and it runs smooth, but when the session gets really busy i encounter that QT sometimes just uses too much ram. although you can put in big tracks like 3-4 GB which still runs fine, but it uses too much ram.
are you guys using QT had a chance to lower that ram usage by using another codec? i use the sorensen 3 but i think i might get a better result by using something different.
