Wiretap (Read Only)
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Negative TCs for clips with positive audio slip

8 REPLIES 8
Reply
Message 1 of 9
derrick
924 Views, 8 Replies

Negative TCs for clips with positive audio slip

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):
Kaiden[232]wiretap_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

Original clip (audio)
Kaiden[233]wiretap_get_clip_format -h 192.168.2.20 -n /stonefs/Test/Audio/H_-1463806974_S_1174350064_U_493184/audiostream_H_-1463798015_S_1174274179_U_300668
[....]
MetaDataStream 0

Clip with offset audio (video)
Kaiden[236]wiretap_get_clip_format -h 192.168.2.20 -n /stonefs/Test/Audio/H_-1463806974_S_1174350064_U_493099
[...]
MetaDataStream NDF-00:00:10:00Sun Mar 18 22:16:44 2007

Clip with offset audio (audio)
Kaiden[237]wiretap_get_clip_format -h 192.168.2.20 -n /stonefs/Test/Audio/H_-1463806974_S_1174350064_U_493099/audiostream_H_-1463798015_S_1174274204_U_319043
[....]
MetaDataStream -480480
8 REPLIES 8
Message 2 of 9
alatteri
in reply to: derrick

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.
Message 3 of 9
alatteri
in reply to: derrick

bump
Message 4 of 9
grattor
in reply to: derrick

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.

Clear?

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.
Message 5 of 9
alatteri
in reply to: derrick

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.

Still need that additional info and visuals.

Thanks,
A. Message was edited by: alatteri
Message 6 of 9
derrick
in reply to: derrick

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?
Message 7 of 9
Anonymous
in reply to: derrick

Is the SDK document not explicit enough? THere's a section talking about the EDL syntax at the back...

Please let us know what is missing so that we can include it for the next release (now in beta).
Message 8 of 9
derrick
in reply to: derrick

Ah, now that I re-read it, yes it's fine.

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.
Message 9 of 9
Anonymous
in reply to: derrick

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.

Cheers,

Dan

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report