<div dir="ltr">Hi Chris, thanks for the help! See my answers inline. <br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 4, 2018 at 1:50 PM, Chris Caudle <span dir="ltr"><<a href="mailto:chris@chriscaudle.org" target="_blank">chris@chriscaudle.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On Tue, April 3, 2018 9:07 pm, robertlazarski . wrote:<br>
> The default of auto mute is off on Free Run and RTC mode and I didn't<br>
> change it.<br>
<br>
</span>Then assuming the behavior works like it seems to be documented (which if<br>
I understand correctly is that the time code is continuously output as<br>
long as the Zoom F8 is powered on) it seems that the video recorder should<br>
not have incorrect time code (i.e. not matching the audio).<br>
<span><br>
> The main issue might be some missing data in the first part of the LTC on<br>
> CH1 of the video.<br>
<br>
</span>Missing code could be because the phone has trouble adjusting to the time<br>
code audio.  As far as I know most phones would have some type of<br>
automatic gain control since you don't have microphone gain knobs on the<br>
phone, so perhaps it takes the phone AGC a few seconds to determine an<br>
appropriate gain setting for LTC.  The sound of LTC is definitely not like<br>
typical audio signals that the AGC behavior would be optimized to handle.<br>
<span><br></span></blockquote><div><br></div><div>Its a nasty signal. It might be severally clipping but I don't have meters on it. I have it going thru a Irig DUO which I use as sort of a preamp to usb adapter, that accepts 1/4 line level jacks. I'll try turning the volume down on the Irig, maybe the OpenCamera app I am using too. <br><br></div><div>I have a KT 1176 clone (among several other compressors), should I pass the signal thru it at 20:1 limit mode? I read somewhere you shouldn't compress LTC. <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
> I am looking at getting a hardware slate like a Denecke TS-3 - to keep my<br>
> sanity I only use software in post :-) .<br>
<br>
</span>You could get a hardware slate, but seems expensive.  If you were<br>
responding to my suggestion for a clap board, I meant old school,<br>
literally knock two sticks of wood together.  You should be able to step<br>
frame by frame  in the video to see the frame where the pieces hit<br>
together, and in the  audio editor it should be pretty obvious where the<br>
impact occurs as long as the room is otherwise relatively quiet. It lets<br>
you line up by hand in the editor if you want, but also gives you a<br>
reference point to check the timecode in that video frame, and check the<br>
time code where Ardour lined up that point in the audio track.<br>
<span><br></span></blockquote><div><br></div><div>I'm doing music performance videos with a lot of piano right now, so I have a pretty clear "first strike" moment. Clapperboards, even old school, is something I am trying to start using in my setup. <br><br></div><div>I'm fascinated by hardware slates - I prefer hardware in general as once in a lifetime purchases - but I can't wrap my head around why they are so expensive. Some of these hardware slates seem over a decade old. All they seem to do is accept a timecode signal into a 1/4 jack once a day to sync, and display some numbers. Sure they keep it accurate but my Zoom F8 does a lot more and costs half the price. <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
<br>
On Tue, April 3, 2018 9:43 pm, robertlazarski . wrote:<br>
>> That sounds like both recorders are free-running.<br>
> Might be, I tried using time of day timestamps and it didn't help.<br>
<br>
</span>No, by free running we were referring to the case where for example the<br>
camera generates  its own time code track, and the Zoom generates its own<br>
time code track, and even if they start out together they could drift<br>
apart over time due to inaccuracies in the individual oscillators used to<br>
track the time.  You have previously clarified that the camera does not<br>
generate any time code, you just cable the time code output of the zoom<br>
into one channel of the camera audio track.<br></blockquote><div><br></div><div>Still trying to get the terminology right, its important. <br><br></div><div>I didn't think this issue could cause a really large delay like over 10 seconds. I was expecting it to be a possible issue as I got everything lined up to under 1 second. <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><br>
>> Note that both audio and video may import at some late position in the<br>
>> timeline. e.g. at 14:00:00:00 and may not be visible with default<br>
>> zoom-level.<br>
>><br>
> I tried zooming in and out and didn't see an obvious misalignment.<br>
<br>
</span>It wouldn't be a misalignment per se, just that timecode is defined as<br>
starting at one second after midnight, and covering a full 24 hours until<br>
23:59:59 (hours:min:sec).  I don't remember if Ardour has a way to specify<br>
what hour and minute your project timeline starts, but by default it will<br>
just assume 00:00:00 (or maybe 00:00:01, I forget), so if you have your<br>
timecode set to follow wall clock time, and you record at say early<br>
evening at 19:22:13, Ardour will happily import your audio into a project<br>
starting at 00:00:00 and place the audio at 19:22:13 on the timeline so<br>
that you end up with a project that will play back silence for over 19<br>
hours and 22 minutes if you place the playhead at the project beginning<br>
and hit play.<br>
Just a detail to be aware of.<br>
<span><br></span></blockquote><div><br></div><div>Seems like all the examples of real world uses of timecode I found via google, do not use wall clock time but rather start at 00:00.01. That's the default of the F8. I am going to switch to that 00:00:01 format again at some point soon, but debugging seems easier in a wall clock format. As you mention, there is a lot of side issues to think about. <br>  <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
> On my latest files I am attempting to use "time of day" timestamps in the<br>
> timecode, using the F8 "Int RTC" mode.<br>
><br>
> The sync error pattern I am noticing, is the first entries of LTC in the<br>
> MP4 file seem to be missing or corrupted. The POS from ltcdump never<br>
> starts at zero. When I open the raw MP4 I see no such obvious problem.<br>
<br>
</span>What do you use to open the raw MP4?<br></blockquote><div><br></div><div>mplayer on Linux. Immediately as expected, I hear the super loud LTC on ch1, and a scratch track with a constant drum machine on ch2. The video and audio both seems fine, but that ch1 LTC could be clipping the ADC on the way in. For my next step, I am going to focus on lowering the ch1 audio level. <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Speaking of MP4, it just occurred to me that the phone is probably going<br>
to be encoding the audio tracks with AAC (or some other lossy codec).  I<br>
have no idea what effect that has on LTC decoding, and I could not find<br>
any reference to the effect of AAC on LTC recording with a quick google<br>
search.  Maybe Robin knows, or I can ask around to see if anyone else has<br>
experience with that.  Maybe the AAC encoding is causing some problems for<br>
the LTC decoder.<br>
I'll see if I can figure out a way to script up some tests for that.  Can<br>
you check to see if you phone is using AAC for sure, and what bit rate?<br>
Should be able to tell pretty easily with ffmpeg -i on one of the phone<br>
video files, that should dump the codec and bit rate detected.<br>
<br></blockquote><div><br></div><div>Seems like its using AAC, this is from 'ffmpeg -i' , let me know if it would be helpul to paste the entire output - its big. <br><br>Metadata:<br>      creation_time   : 2018-04-04T00:33:00.000000Z<br>      handler_name    : VideoHandle<br>    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default)<br><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I see later that the audio you extracted from the phone video is wav, was<br>
that recorded uncompressed native, or was the original audio compressed<br>
and you converted to wav when you extracted from the video file?<br>
<div><div class="gmail-m_9108500244362051103m_-8654968137434349017h5"><br></div></div></blockquote><div><br></div><div>The command that Robin recommended I use, 'sndfile-info -b' , only works on wav = not mp4. I'm just using it for debugging. <br><br>1) (phone video in MP4 format) ffmpeg -i VID_20180403_183123.mp4 -vn -acodec pcm_s16le -ar 44100 -ac 2 output_audio.wav<br>2) sndfile-info -b output_audio.wav <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-m_9108500244362051103m_-8654968137434349017h5">
<br>
> [linux-7cab(iksrazal)]<br>
>  /home/iksrazal> sndfile-info -b F8.wav<br>
><br>
> Version : libsndfile-1.0.25-exp<br>
><br>
> Description      : SPEED=29.970D<br>
> TAKE=004<br>
> UBITS=00000000<br>
> SCENE=180403<br>
> TAPE=180403<br>
> CIRCLED=FALSE<br>
> TR1=Tr1<br>
> TR2=Tr2<br>
> TR7=Tr7<br>
> TR8=Tr8<br>
> NOTE=EVE<br>
><br>
> Originator       : ZOOM F8<br>
> Origination ref  :<br>
> Origination date : 2018-04-03<br>
> Origination time : 18:31:09<br>
> Time ref         : 0x0bebdd5f1 (66669.002354 seconds)<br>
> BWF version      : 1<br>
> UMID             :<br>
> Coding history   : A=PCM,F=48000,W=24,M=multi,T=F<wbr>8;VERSION=1.10;1:1 0 0 R<br>
> 1   00;2:1 0 0 CNTR   00;3:0 0 0 CNTR   00;4:0 0 0 CNTR   00;5:0 0 0 CNTR<br>
> 00;6:0 0 0 CNTR   00;7:1 0 0 CNTR   00;8:1 0 0 CNTR   00;L:0 1 0 CNTR<br>
> 00;R:0 1 0 CNTR   00;<br>
><br>
><br>
> [linux-7cab(iksrazal)]<br>
>  /home/iksrazal> ltcdump phone_video_with_ltc.wav | head<br>
> Note: This is not a mono audio file - using channel 1<br>
> #User bits  Timecode   |    Pos. (samples)<br>
> #DISCONTINUITY<br>
> 00000000   18:31:21.29 |     2639     4239<br>
> #DISCONTINUITY<br>
> 00000000   18:31:22.00 |     4240     5841<br>
> 00000000   18:31:22.01 |     5842     7442<br>
> 00000000   18:31:22.02 |     7443     9044<br>
> 00000000   18:31:22.03 |     9045    10646<br>
> 00000000   18:31:22.04 |    10647    12247<br>
> 00000000   18:31:22.05 |    12248    13849<br>
<br>
</div></div>So the audio file begins at 18:31:09.<br>
The video seems to be missing the beginning, but position 4240 audio<br>
samples is decoded as 18:31:22.00.<br>
4240 samples is 4240/48000 = 88ms.<br>
<br></blockquote><div><br></div><div>I am starting the F8 first, then the video ... there should only be a few second delay but way under the 13 second gap. I am not sure if the video should start first or the audio recording on the F8 should start first. At the moment I have settled on the F8 starting first. <br></div><div><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
13 seconds should be 624 000 samples, so it does seem that the video<br>
starts later than the F8 audio, but the question is  whether that part of<br>
the video still lines up with the appropriate part of the audio recording,<br>
or if they are offset by that many (or some other non-zero) seconds.  That<br>
is where some common reference point, like wood blocks knocking together,<br>
would come in useful.<br></blockquote><div><br></div><div>I'm using a big piano octave with an extra arm gesture at the moment, to start things off. The music seems off by the same amount as the missing LTC, but I lack exact numbers since I am eye balling the video / audio sync difference. <br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
What is on the second channel of the phone/camera audio? You could also<br>
send a copy of the microphone feed with the clap board audio to F8 and<br>
camera second channel simultaneously, that would give you another<br>
reference point for comparison.<br>
<span class="gmail-m_9108500244362051103m_-8654968137434349017HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Yep, my scratch track for testing has a drum machine and a piano going to ch2 from one of the F8 master outputs. <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_9108500244362051103m_-8654968137434349017HOEnZb"><font color="#888888">
--<br>
Chris Caudle<br>
<br>
<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">Thanks Chris! <br><br></div></div>