This has been confirmed with clips coming from a variety of sources.
Using the tools provided in the API package.
Examine the audio delay settings of a given clip which the Slip value is 0 from within Flame.
With this bug, it means my clients are unable to use shrink as a "1 step" stone to quicktime tool. They must now resort to an un-natural and all together disturbing work around. This severely limits the marketability of my product, and un-fortunately will cost me users.
Sorry for the delays in getting to this, but I have answers on the AudioSampleOffset data you're getting.
AudioSampleOffset is a values expressed in number of samples, and the value is relative to timecode 00:00:00:00.
In the case of the clip you provided me with, which was a captured source, you have a video track starting at 01:57;29;08. The AudioSampleOffset therefore shows the 'start TC' of the audio stream expressed in audio samples: 338363963. The sample rate is 48kHz, so:
Not exactly the same as your source TC because you have to adjust further for drop-frame timecode.
When you gesturally edited the capture clip on top of a black frame, you edited it into a timeline that had start TC 00:00:00:00 -- that's why the offset value worked out for you.
All that to say (I'm not trying to be smug here) that the AudioSampleOffset is returning correct values -- you just need to know how to interpret them.
Can you work with this? You see, we have one developer that I know of that has a Wiretap client that reads clips and pulls out the audio streams for audio finishing. They ignore the video TC data and use these sample values to reconstruct an audio timeline. So I can't really pull the rug out from under them.
Let me know what you think. I'm going to talk to some developers here to see if we can come up with something easier for you to work with.
I will ask told to my developer, but since i come from a Flame background where the slip value is relative to first frame of video, that is how i believe the values reported from wiretap should work also. I really dont see any sense in the way you describe it working now. Can you just have wiretap report slip values in both ways?
Well, it is true that you are suffering because of your Flame background. Unfortunately, audio has more strenuous editorial requirements and after many discussions with people in house and a WT developers working with audio interchange, the AudioSampleOffset is the way to go, for the following reasons.
1. The AudioSampleOffset can be though of as the start Source TC for the audio channel. Much like the start TC returned for the video track, it is an absolute value that can be used to recreate editorial context.
2. The reason why the value is returned in # of samples instead of start TC is that Smoke supports sub-frame audio editing. Were we to return TC, we'd have to arbitrarily clamp to a frame, forwards or backwards.
3. We could conveivably provide a relative offset value, positive or negative, but that would involve getting the start TC for the video track and then going through the same math to figure out where to lay down the audio.
Ultimately, an absolute audio sample offset relative to midnight provides all the information you need -- though the onus is on the developer to translate this into timecode and/or sub-frame positioning.
Having made this argument, I'm open to objections, especially from anyone else in the group who has an opinion.
it would be so much easier if autodesk did this so every developer does not have to do it. Its tough enough getting stuff working as it is. Why duplicate work. Plus i still dont enderstand this philosophy behind the audio values, but oh well.