According to a previous thread (http://discussion.autodesk.com/thread.jspa?threadID=539108), the audio offset value is specified relative to the video TC. But I'm seeing a very strange issue.
I have a clip with 0:00:00:00 Record TC and no audio slip. If I apply a positive audio slip of 10 frames, I get, as I would expect, a negative audio offset value. But I also get a negative TC, and the two cancel one another out! (I don't see this negative TC in the flame UI; it still says 0:00:00:00).
Is this a bug (maybe the "existing bug" mentioned in the thread), or am I misinterpreting how to use the TC and AudioOffset fields? (Everything seems to work as expected for negative audio slip; the TC stays the same and I get a positive AudioOffset.)
Here are some extracts from wiretap_get_clip_format
Original clip (video):
Kaidenwiretap_get_clip_format -h 192.168.2.20 -n /stonefs/Test/Audio/H_-1463806974_S_1174350064_U_493184
MetaDataStream NDF00:00:00:00Sun Mar 18 22:16:19 2007
Just want to add again, that this whole relative TC thing for reporting audio offsets is awful. maybe some people need that sub frame precision, but alot dont, and having to spend so much time dealing with what should be a real simple X number of frames, turns into a pile steaming heap.
Have finally gotten around to this. Sorry for the lengthy delay.
Good news is I've figured it all out and via Wiretap you do have all the information you need to re-construct the video/audio offsets.
Bad news is -- Alan you'll be happy to hear -- it's really complicated.
I need a little time to explain it properly... I have to leave now but will work on this on thr train home. Will try to post again tonight.
Short answer is:
get_clip_format always gives you the start TC of the clip whether the incoming media element is audio OR video.
get_clip_format always gives an audio offset value expressed in samples that corresponds to an absolute start TC.
If your clip has video/audio starting in sync, you're OK.
If your clip has video starting before audio, you're OK.
If your clip has audio starting before video, you need to get additional information about the video track by doing a get_metadata -s DMXEDL.
This will give you the start TC of the first video element, independent of the start TC of the clip, which is the start TC -- in this case -- of the first audio element.
Seriously, I'm going to try to document this with some visuals.
We're going to give some thought about how to make this easier, at least make it so that get_clip_format provides ALL the information you need without having to go to the EDL. Yes, we'll think about expressing audio offset in timecode... but it's not quite as straight-forward as you think.
yeah, fixing get_clip_format to provide ALL the proper info is important. Currrently, the XML SourceTimecode and AudioOffset values are now useless as they can't be trusted. In regards to "expressing audio offset in timecode", while that would be handy and easier, we have already accomadated the current method, albiet the previous concerns with get_clip_format.
Has there been any progress on this? I'm still a little fuzzy as to how to go about extracting the data I need. Alan has been able to figure out the correct parts of the EDL metadata experimentally. According to him, it's the 3rd time code on the 1st line that looks like this:
001 WT_DMX V C 00:00:00:00 00:00:29:23 03:25:34:15 03:26:04:14
Is that accurate?
Still, I'd feel more comfortable if someone could point me to document describing the format of the EDL so that I can be sure to parse it properly and extract the information I need. Does such a thing exist?
I think the issue for me is that I was coming to this project knowing nothing at all about the industry; that section assumes you at least have some clue about Autodesk software and EDLs and so on; so I was, of course completely lost.
Now I have a little more background info, but I never went back and read the docs again. They make much more sense now.
I'll see if I have any issues as I set about actually programming this.
FYI, the 2008 beta has "new and improved" documentation, with more fully commented samples, an example build environment, an HTML reference manual, XML schema descriptions, and more complete/accessible format and content.