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.