Wiretap

Wiretap

Reply
Valued Contributor
88 Posts
0 Kudos
Registered: ‎06-26-2003
Post 1 of 10

Big problem with wiretap and audio delays.

273 Views, 9 Replies
01-31-2007 09:33 PM
Hey,
So take a clip with audio and cut it somewere. Now look at the audio delay reported by WT. Even worse then commit that cut clip and look at the delay.
IBM 6221 Flint 2007 SP1.
A.
Valued Contributor
88 Posts
0 Kudos
Registered: ‎06-26-2003
Post 2 of 10

Re: Big problem with wiretap and audio delays.

02-01-2007 09:02 AM in reply to: alatteri
Make sure to save to resulting clip between these steps.
Valued Contributor
88 Posts
0 Kudos
Registered: ‎06-26-2003
Post 3 of 10

Re: Big problem with wiretap and audio delays.

02-14-2007 02:36 AM in reply to: alatteri
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.

milky-way:~ alatteri$ /Users/alatteri/Documents/Code/shrink.quicktime/wiretap/api/tools/Mac/OSX/wiretap_get_clip_format -h 192.168.1.55 -n /stonefs/Tether/audio_references/H_-1463798015_S_1171303214_U_26898/audiostream_H_279747890_S_1170425448_U_86522
Format dlaudio_float_le
Width 48048
Height 1
BitsPerPixel 32
Channels 1
BufferSize 262144
PixelRatio 1
FrameRate 48000
ScanFormat field1_odd
MetaDataTag IFFFS_XML
MetaDataStream 338363963


You can see here that it is reporting a audio offset of about 2 hours.
Now take that clip and gesturally drop it over a BLACK frame while in V12 mode. Analyze clip.

milky-way:~ alatteri$ /Users/alatteri/Documents/Code/shrink.quicktime/wiretap/api/tools/Mac/OSX/wiretap_get_clip_format -h 192.168.1.55 -n /stonefs/Tether/audio_references/H_-1463798015_S_1171430393_U_13233/audiostream_H_-1463798015_S_1171430391_U_429083
Format dlaudio_float_le
Width 48048
Height 1
BitsPerPixel 32
Channels 1
BufferSize 262144
PixelRatio 1
FrameRate 48000
ScanFormat field1_odd
MetaDataTag IFFFS_XML
MetaDataStream 0

Now it is reporting the proper audio offset of 0.

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.
Distinguished Contributor
103 Posts
0 Kudos
Registered: ‎05-11-2004
Post 4 of 10

Re: Big problem with wiretap and audio delays.

02-14-2007 06:12 PM in reply to: alatteri
We think this may be related to an existing bug. We're looking into it.

Dan
Valued Contributor
88 Posts
0 Kudos
Registered: ‎06-26-2003
Post 5 of 10

Re: Big problem with wiretap and audio delays.

02-20-2007 08:51 AM in reply to: alatteri
any update to this?
Contributor
16 Posts
0 Kudos
Registered: ‎12-05-2006
Post 6 of 10

Re: Big problem with wiretap and audio delays.

02-20-2007 11:30 AM in reply to: alatteri
Hi Alan,

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:

338363963 / 48000 = 7049.25 seconds
7049.25 / 3600 = 1.958215 hours
1.958215 = 1 hour, 57 minutes, 49 seconds, 15 frames.

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.
Valued Contributor
88 Posts
0 Kudos
Registered: ‎06-26-2003
Post 7 of 10

Re: Big problem with wiretap and audio delays.

02-21-2007 07:33 AM in reply to: alatteri
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?
Contributor
16 Posts
0 Kudos
Registered: ‎12-05-2006
Post 8 of 10

Re: Big problem with wiretap and audio delays.

02-21-2007 08:28 AM in reply to: alatteri
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.

Cheers,

rcg out
Contributor
16 Posts
0 Kudos
Registered: ‎12-05-2006
Post 9 of 10

Re: Big problem with wiretap and audio delays.

02-21-2007 08:30 AM in reply to: alatteri
Posted twice by accident... Message was edited by: grattor
Valued Contributor
88 Posts
0 Kudos
Registered: ‎06-26-2003
Post 10 of 10

Re: Big problem with wiretap and audio delays.

02-21-2007 09:13 AM in reply to: alatteri
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.
Post to the Community

Have questions about Autodesk products? Ask the community.

New Post