Sync audio to video in SX2?

This question is for those of you gentlemen who do audio/video post product work in SX2:
What is your workflow when you have to sync audio to video hit points (punches, footsteps, gunfire, etc.....) in Sonar?

Thanks for your tips.

dlion16
i can't imagine trying to do all that in sonar. it won't be frame-accurate, and you surely do not want to allow sonar to save in any video format.
 
i'm both musician and filmmaker, so i use vegas for anything visual. i find that i can do most of my sound design there too, as vegas was originally a multitrack audio editor.
 
i work on individual sequences that might be one clip or a group of clips in sonar,  i might do a stereo mix or stems and put it together in vegas. i export in native format (say 48/24), 
then use sound forge to convert to 48/16 wav for vegas. to me, i'm using each program for what it does best.

+1...for me, if Vegas did VST I would hardly even need Sonar

dlion16
i can't imagine trying to do all that in sonar. it won't be frame-accurate, and you surely do not want to allow sonar to save in any video format.

 
SONAR's video is definitely designed to be frame accurate. We have done tests with burn in frames comparing to SONAR's frame display on the timeline and they match up perfectly. There may be a few exceptions where this could be off by a frame but its certainly frame accurate for most normal use cases. Do you have a specfic scenario that you can demonstrate where it isn't accurate?
As Dan suggests, the best way to test is using a video that has burn in frames and to use an uncompressed file format.

What the heck does uncompressed video or uncompressed file format mean?
 
Could it mean anything but AVCHD G.O.P.?
 
Or is it 4:4:4:4 16bit 4k RAW?
 
 
Here are some practical suggestions:
 
Motion Jpeg uses spatial compression but no temporal compression; it's frame accurate. It is a basic intraframe codec that runs med-high bandwidth at low CPU overhead.
 
Cineform does a nice job with its intraframe HD streaming CODEC. Cineform is owned by Go Pro. They have some free stuff and some high priced stuff. It is medium bandwidth and medium CPU overhead.
 
If someone sends you a G.O.P. interframe video and you wish to do frame accurate work the easiest way to do it is to convert the video into a intraframe Intermediary CODEC that so that any time you stop playback your editor will stop on a complete and discrete frame.
 
Most dedicated video editors can fake displaying a frame from an interframe G.O.P. pretty good but it takes a lot of horse power to do it. Maybe that's why video editors don't do a lot of intensive audio processing?
 
The most important thing to remember is that playing back video takes a lot of CPU and or Bandwidth and the Intermediary CODEC you choose needs to reflect an appreciation of the need to conserve both of those resources for the audio work. If you have extra bandwidth, select a CODEC that uses bandwidth instead of CPU (maybe Motion Jpeg). If you have extra CPU headroom but worry about bandwidth try something with greater spatial compression; something like Cineform.
 
Greater compression requires more CPU power to uncompress but the bandwidth requirements are low. Less compression requires less CPU but more bandwidth.
 
If we worked in Mac OS then Apple Pro Res would be an obvious choice. I just mention that because you can find lots of discussion about intermediary codecs but it is usually about Pro Res.
 
Windows has different choices. I mentioned 2... you can find more.
 
Go look up the meaning of all the bold face terms and you'll be well along your way.
 
Good luck.
 
 
best regards,
mike
 
 

Animation CODECs and Image Sequences rarely play back with all the frames in a stream as it requires massive bandwidth.
 
One thing many audio edit workers don't appreciate about how hi tech the work you DAW makers do is that DAWs can only, maybe, sneak a soft drop out every now and then, while a Video app can drop entire frames and no one seems to care.
 
Let me repeat that: Video Edit apps routinely drop frames on preview playback and no one cares.
 
People get concerned when they can't stop on a discrete frame, it's been that way since the days of analog video, and so most apps will assemble a frame no matter where you stop.
 
When Audio apps have a drop out we all get freaked out. Video edit developers have it much easier.
 
 
 
In any event, running an uncompressed bitmap sequence takes up massive bandwidth.
 
If you happen to have a compressed bitmap sequence such as .jpeg or .png  you can balance a reduction of the bandwidth with a need for a little bit of CPU processing.
 
 
 
I think Cakewalk should provide some basic info about the nature of balancing the CPU and the bandwidth needs.
 
 
For example; working with AVCHD is a horrible experience. I wouldn't recommend it. The reason the company GoPro bought the company Cineform was because GoPro had so many dismayed customers that eventually found that purchasing a Cineform CODEC license made playback and editing more practical. GoPro bought Cineform, the codec company because GoPro AVCHD files are too CPU intensive for most folks to work with... including video professionals with dedicated video suites... and so now GoPro provides a solution for it's customers by giving away a lite package and selling an advanced version of the CODEC.
 
 
I'm not saying Cakewalk should buy a CODEC company :-)... but offering a tutorial page about how to... avoid the pain of working with AVCHD will be very helpful. edit to change sentence to: ...select a Intermediary CODEC for smooth and reliable use with SONAR. 
 
 
For today's HD work flows in Windows OS, when no specialized CODEC acceleration playback hardware is available, the Cineform CODEC is my personal favorite. It seems to provide the best balance of bandwidth and CPU requirements and it is a frame accurate intraframe CODEC.
 
 
best regards,
mike
 
 

dlion16
cakewalk won't respond about all the bugs that have been identified in x2a or when we'll get an update, you know, just common courtesy to people who buy your product, but noel has time to recommend using uncompressed video in sonar to "troubleshoot" trying to put music to picture? the horror... just another typical day in cakeland, folks...

What a strange comment. "How can cakewalk staff have time to come on here and help people, but not have time to divulge their future business plans to all and sundry? Bad Cakewalk."

I'm very grateful that knowledgeable people like Noel take the time to offer help to users on this forum. Noel helped me first week I was on here and solved my issue instantly.

Cakewalk have stated that they do not divulge development plans until they are ready. Seems fair to me.

dlion16
cakewalk won't respond about all the bugs that have been identified in x2a or when we'll get an update, you know, just common courtesy to people who buy your product, but noel has time to recommend using uncompressed video in sonar to "troubleshoot" trying to put music to picture? the horror... just another typical day in cakeland, folks...

Thats a bit troll like for this thread buddy.

vicsant
PT has a great feature where you can create a "sync point" (Ctrl + comma) anywhere in a clip (although you're limited to having just one sync point per clip), and with just one keyboard shortcut ("J"), move that clip's sync point to an existing marker/memory location/or hit point. This really speeds up the process of syncing audio to an EDL.
 
I know that we can create a marker in SX2 to indicate a hit point, but there doesn't seem to be a quick and easy way to select a specific point in a clip and move that point to the target marker....or is there?

Good point!
 
+1
 
 

Hi Daniel, thanks for the clip Snap Offset tip.
I'll give it a go :-)

 
I'd enjoy having a readout that displayed the time length of a selection.
 
That would be helpful.

I recommended 2 common codecs in a post above.
 
I asked you which you used in Vegas, in the other thread, to get some insight into your existing work flow.
 
You mentioned you work with HD footage. I was curious to learn what codecs are running smooth on your system... then it might be easy to select one that is relatively lighter for use with SONAR.
 
Are you working with Camera footage or footage that has been exported and sent to you from some one else's video edit suite? I'd like to know the actual codec... and I think I ask each time I've tried to help... maybe I can guess the codec if I can figure out where the source footage is from.
 
You mentioned a SD 720x480 widescreen export from Vegas. Was it the super light weight DV25 codec or was it one of the dozens of other high bit rate SD 720x480 widescreen codecs that are available?
 
Do you have any video acceleration on your DAW? If so is it just the "GPU" or is it a dedicated video I/O card from AJA, Black Magic etc.?
 
If you have hardware that is focused on decoding video than the CPU will have lots of room for SONAR.
 
If you use a codec that specifically tantalizes the instruction sets embedded in the latest system CPUs then you may find that the CPU starts focusing on the video play back while other apps get short changed. If the video or the DAW starts stuttering don't bother looking at Task Manager to see if the CPU had time to tell Task Manager it was real busy. The proof is in the experience you are having with the stuttering or black screen video.
 
A lot of the latest distribution codecs are meant to appropriate the CPU. The player apps play smoothly and they drop frames to make it look like it is all so easy.
 
The edit apps compete with the CPU intensive codecs and the timing gets sketchy.
 
The easiest way to deal with all this is to get used to the idea of knowing what codec you are working with so that you may compare an experience with it with experiences you have with other codecs.
 
 
all the best,
mike
 
 

I have mentioned my preference for both motion jpeg and Cineform numerous times and I mentioned them above as well.
 
Now that I see that you run a 1080 HDV codec I can see that you are running 25mbit/second streams with success so the Cinefrom CODEC is a possible choice for you.
 
I am assuming you are not employing the Vegas low data rate proxy file (a.k.a intermediary codec) system.
 
So 25mbits/sec that should be a good guideline for what you can expect to stream in SONAR.
 
Have you ever tried HDV 25mit/second in SONAR? It's a good balance of picture quality-data rate-CPU strain.
 
.wmv for example; will offer lower data rate and require much more CPU to decode.
 
DV25 (a standard def 720x480 widescreen choice) will use the exact same data rate as 1080 HDV and less CPU.
 
A codec like Cineform Intermediary will provide a better picture than HDV (of course it needs to start with something better than HDV to do that), lower data rates, and lower CPU strain.
 
Motion Jpeg data rates are traditionally defined per frame but they equate to anything from very tiny bit rates all the way up to 74mbits/second. You'll probably want to use something less than 25mbit/second for initial trials.
 
 
Good luck.
 
best regards,
mike