Jump to content

BR 7.25.1 + 702T sync issues


Zack

Recommended Posts

Yes.. I've been operating with BR v7.25.1 the last 4 weeks after Take made a revision for an issue I had, massive help he was :).  Anyways... I'm having some problems with sync and some pretty bad drift between files recorded on the 702T and BR, let me quickly explain the set-up:

702T is the master TC clock outputting the TC signal and word clock to a Motu Traveler which in turn is connected to a MacBook Pro running BR v7.25.1.  BR's sample rate and bit depth are set identical to what the 702T is, and BR is recognizing the TC signal and clocking perfectly to what the 702T is outputting.  This should all ensure that files created from BR would sync to those created on the 702 right?

I've been taking some files from the BR and 702T and tried sync'ing them up in FCP tonight using their TC values.  FCP had no issue marrying them together this way and all worked well.  When I play them all together, there are inconsistencies with how they playback.  Sometimes the BR files are either 1 to 2 frames ahead of the 702T files (I can hear the gap from the slate), sometimes they're behind the same timing, sometimes they are perfectly in sync, but in all cases after about a period of one minute the drift between the two recorders becomes a good 15 frames apart.  If they're clocked together, how could they be drifting apart?  Anyone else using a similar set-up or have had issues like this with BR?

Link to comment
Share on other sites

Zack,

What is the TC frame rate and the Sampling rate you are using? You never mentioned that at all.

I'm doing a show at 30NDF and 48.048 and after doing some tests - - prior to shooting there was a 2 second difference.

However, Take created a new version 7.26, which would clock to whatever you set the firewire interface to. In my case it is the Fireface 400 that serves as the master word clock, to drive my Yamaha 01V96 and of course Boom Recorder.

No need for a set up that "fools" Boom Recorder and tests demonstrated that it was pulled down in perfect synch.

Eric Benton of Modern Video suggests that when you do your roll ID and tones, do a time code count off so you can hear and read the code recorded as a check. I've been doing that for at least five years and telecine operators love it.

RL

Link to comment
Share on other sites

Oops...

TC rate is 23.976

Sample rate 48k

No need for a set up that "fools" Boom Recorder and tests demonstrated that it was pulled down in perfect synch.

Is that what I'm doing here with my set-up?  Do you happen to have an example of your count-off I might be able to hear?  Thanks for the reply Richard.

Link to comment
Share on other sites

Example? I just read the time code that I see out load onto the track of my Deva 5.

"Timecode 30 non drop, 11 hours 15 minutes 16 seconds, 17, 18, 19, 20 etc. etc."

I read about 15 seconds worth.

So your running 23.98, I have no explanation of what your problem is. If you are in contact with Take, see if he can link you to download v7.26.

RL

Link to comment
Share on other sites

Example? I just read the time code that I see out load onto the track of my Deva 5.

"Timecode 30 non drop, 11 hours 15 minutes 16 seconds, 17, 18, 19, 20 etc. etc."

I read about 15 seconds worth.

Oh I get what you're "saying".... cool idea.  I'll give 7.26 a run tomorrow and test, keeping my fingers crossed.  Thanks again RL.

Link to comment
Share on other sites

7.26 will not help for you, the only audio interfaces I know that can natively clock at 48048 are those from the Fireface family.

With the normal Boom Recorder if you are doing a pull-up/down situation, you will need to set the frame rate counter intuitively. For example, if you are driving the MOTU at 48048 and send a 30 fps timecode, then Boom Recorder needs to be set to 29.98 fps (Boom Recorder still thinks that the MOTU runs at 48000, so you need to compensate this).

These settings causes the timecode on the display to be wrong, and the timecode in the sound log to be wrong, but the stamp in the audio file should be correct.

Link to comment
Share on other sites

7.26 will not help for you, the only audio interfaces I know that can natively clock at 48048 are those from the Fireface family.

With the normal Boom Recorder if you are doing a pull-up/down situation, you will need to set the frame rate counter intuitively. For example, if you are driving the MOTU at 48048 and send a 30 fps timecode, then Boom Recorder needs to be set to 29.98 fps (Boom Recorder still thinks that the MOTU runs at 48000, so you need to compensate this).

These settings causes the timecode on the display to be wrong, and the timecode in the sound log to be wrong, but the stamp in the audio file should be correct.

So I'm ok at running 23.98 @ 48k for both BR and it's clock source?

Link to comment
Share on other sites

Yes, if you do not do any pull up/down, then it should work as advertised.

So in your case:

  702T word clock 48000

  702T frame rate 23.98

  Boom Recorder hardware sample rate 48000

  Boom Recorder file sample rate 48000

  Boom Recorder frame rate 23.98

Link to comment
Share on other sites

Yes, if you do not do any pull up/down, then it should work as advertised.

So in your case:

  702T word clock 48000

  702T frame rate 23.98

  Boom Recorder hardware sample rate 48000

  Boom Recorder file sample rate 48000

  Boom Recorder frame rate 23.98

That's how I've been running it, however that drift issue with v.7.25.1...... that's still a mystery to me, maybe I had something set wrong, or connected wrong, but I've been double checking often.  Boggled on that one still :P.  Thanks for chiming in though Take :)

Link to comment
Share on other sites

What is MOTU's clock source set to?

I never noticed this drift before... actually the version I noticed the most consistency with... (like frame accurate consistency) was with v.7.22.  Since upgrading from that version I've enjoyed being able to add notes without odd errors and using the reports again with 10.6.x .  I didn't notice the drift till just recently, however previous jobs didn't have such long rolls like the current, so it's hard to pinpoint this issue.

MOTU's TC source is always, LTC/SMPTE, clock source should be Word Clock ... don't have it hooked up right now so not sure the exact variable name that's listed.

Link to comment
Share on other sites

I never noticed this drift before... actually the version I noticed the most consistency with... (like frame accurate consistency) was with v.7.22.  Since upgrading from that version I've enjoyed being able to add notes without odd errors and using the reports again with 10.6.x .  I didn't notice the drift till just recently, however previous jobs didn't have such long rolls like the current, so it's hard to pinpoint this issue.

MOTU's TC source is always, LTC/SMPTE, clock source should be Word Clock ... don't have it hooked up right now so not sure the exact variable name that's listed.

Is the MOTU's TC source external, like from the 702T, or on its own internal generator?  In Motu audio setup the clock source would be Word Clock if you are hooked up to the 702T's WC.  Meanwhile--any whining from post about sync?  Could a FCP import issue w/ the files?

Philip Perkins

Link to comment
Share on other sites

I was thinking, maybe the audio files Boom Recorder took are accidentally recorded at 44100? If you use an other audio application next to Boom Recorder it may change the sample rate. Boom Recorder does not change the sample rate by it self, and needs to be set every time Boom Recorder is started by user or when an other application took control of the sample rate.

Boom Recorder will follow the sample rate correctly, so the audio files should be shown to be 44100. I do not know what Final Cut Pro does with audio files with sample rates different from the timeline.  I think Final Cut Pro resamples to the correct sample rate, however although the sample rate is set to 44100, the MOTU actually is clocked to 48000, making FCP adjustments an error again.

Ok, it is early in the morning, you may need to ignore my ramblings.

Take

Link to comment
Share on other sites

@ Philip, Im using the 702T's clock and I have it hooked up and set as you expected.  @ Takev, my first thoughts were to check that I was indeed recording files at 48k and not 44.1, but all files were stamped as 48k correctly.  Tomorrow I'll have all day to double check things and look it all over throughly, I'll report the results later that night.  Thanks

Link to comment
Share on other sites

Nah, I'm a tard... I found the issue.  I had all the software set correctly, but the MOTU hardware itself was set to sync from the wrong clock ..... I had it on SMPTE instead of Word Clock.  Fixed that then tested today's files from both recorders, and they were perfect. 

Link to comment
Share on other sites

Nah, I'm a tard... I found the issue.  I had all the software set correctly, but the MOTU hardware itself was set to sync from the wrong clock ..... I had it on SMPTE instead of Word Clock.  Fixed that then tested today's files from both recorders, and they were perfect.

I'm a fellow TARD--I spent a lot of yesterday and  4 emails w/ Take trying to solve my BR TC issues before I realized roughly the same thing (sorry Take!).  After I got it all right I jammed BR from the 744, disconnected the TC from the Traveler, and then recorded a fast metronome beat on both the 744 and BR for 32 min.  (Traveler getting WC from the 744T.)  For a test BR was pulling 22 tracks to 44 files (22 per FW drive) w/ real audio (not tone) on all tracks, this on a G4 laptop.  I snapped the metronome tracks to their time stamp position in a DAW, and they were 2/100ths of a frame apart (BR ahead) for the whole distance--no change in sync relationship at all. 

Yay.  Sold.

Philip Perkins

Link to comment
Share on other sites

@ Philip

Interesting method.  Jamming BR, then letting it clock from WC.

Was this a test and only a test, or will you use this technique in the field?  Are you angling towards winning back an analog input on the Traveler that would otherwise be tied up with TC?  Or, IIRC, you may have already been using the G4's audio input for TC in?

I wonder what will happen to the Traveler TC over the course of a day if you jam it once at the beginning... will it drift?  If so, then BR files and 744 files will be stamped with differing TC.

Or does locking the Traveler to the 744 Word clock also affect the timecode in the Traveler/BR and keep it more accurate (ie, at least as accurate as a slate).

Sounds like you only tested one long file for "internal" drift, and that was on the money.

-Brian

Link to comment
Share on other sites

@ Philip

Interesting method.  Jamming BR, then letting it clock from WC.

Was this a test and only a test, or will you use this technique in the field?  Are you angling towards winning back an analog input on the Traveler that would otherwise be tied up with TC?  Or, IIRC, you may have already been using the G4's audio input for TC in?

I wonder what will happen to the Traveler TC over the course of a day if you jam it once at the beginning... will it drift?  If so, then BR files and 744 files will be stamped with differing TC.

Or does locking the Traveler to the 744 Word clock also affect the timecode in the Traveler/BR and keep it more accurate (ie, at least as accurate as a slate).

Sounds like you only tested one long file for "internal" drift, and that was on the money.

-Brian

Well, I'm no expert w/ BR, but I thought this method was covered in the manual, which is why I tried it (w/ Take's advice).  Yes, I am wanting to make this my SOP w/ BR for my multitrack work, because I need that 20th input on the Traveler (bad).  The deal w/ jamming BR via the Traveler has, I think, nothing to do w/ the Traveler's own TC generator (which I haven't set up or started in these tests)--the LTC is passed as audio through a Traveler audio channel, and BR senses it and starts counting from the jam.  The clock that governs the count is the sample rate coming to BR via the firewire from the interface, and that clock is slaved to the external clock of the device that is generating the TC (in my case, a 744T).  If I lost power I'd have to rejam.  I'm not sure I understand what you mean by "internal drift" in this case?  My standard tried and true clock and TC source has been the SD recorders for a long time, and if BR files stay in sync with that then I figure I'm good to go.  I did so some much longer runs w/audio only (3 hrs, 90 min) that looked good too, but they weren't as exacting as the metronome test.  I figure the TC sync relationship should stay the same whether BR is recording or not (all in free-run), but I wanted to test that so I loaded up BR with as many tracks as I could do for now.  PLEASE, if I am not understanding how this works set me straight, really. (SO over dealing w/ sync issues....)

3.5. Timecode / Frame rate

This shows the current timecode that will be recorded into the audio files. The timecode is shown in black when a timecode signal is found. If a timecode signal is not found the timecode will free- run in lock with the sample rate and be shown in gray. This means if the sample rate is accurate enough you can jam-sync Boom Recorder at the start of the session.

Philip Perkins

Link to comment
Share on other sites

It's a nice solution, Philip.  And it's right there in the manual.  RTFM, right?

Makes good sense for your long-record multi-track stuff.  For location shooting, it could be a gotcha to have to re-jam BR for each session, ie, with lots of cart moves, powering down, etc.

I'm not sure I understand what you mean by "internal drift" in this case?

By internal drift, I meant that your 744 files and BR files were not drifting apart from each other over the length of the recording.  That is, the 2/100ths difference is the same at the beginning and end.  There's really no reason they would drift, being locked together by WC.  I was just thinking out loud, I guess.

-Brian

PS - I'm less and less of an expert with Boom Recorder, these days.

Link to comment
Share on other sites

It's a nice solution, Philip.  And it's right there in the manual.  RTFM, right?

Makes good sense for your long-record multi-track stuff.  For location shooting, it could be a gotcha to have to re-jam BR for each session, ie, with lots of cart moves, powering down, etc.

By internal drift, I meant that your 744 files and BR files were not drifting apart from each other over the length of the recording.  That is, the 2/100ths difference is the same at the beginning and end.  There's really no reason they would drift, being locked together by WC.  I was just thinking out loud, I guess.

-Brian

PS - I'm less and less of an expert with Boom Recorder, these days.

I have to keep the computer and interface "up" all the time on the cart, even during moves, since the reboot deal is kind of an issue.  When I was using Metacorder the TC thing took care of itself since it was taken in thru the onboard Mac audio.  W/ BR it would make sense to leave it hooked up to an audio input if one didn't need the channel in that case, which is what I guess most film soundies do.

It does seem like fewer people on this board are using BR for production sound since the 788 came along...

Philip Perkins

Link to comment
Share on other sites

I am also puzzled about the 2/100th of a difference. When you did that test, where you aggregating with an other device? To be exact did you Jam on an other device then that you compare the metronome on?

The way Boom Recorder is designed if you use one interface, it should be accurate to within a sample. Unless the front edge of the LTC frame is not vertical enough and does not zero cross at the correct position.

To be true, I think in the specification of LTC it asks for the timecode signal to be passed through a low pass filter to reduce high frequency interference. So it may be that the LTC signal is according to spec and the edge is very slanted, I haven't read anything in the specification where exactly on the edge a new frame starts, I just assumed it would be the zero cross.

A long time ago someone else did a test in a sound studio and he got it accurate to 6 samples. 6 samples I can see happen because of a slanted edge. I think 2/100th of 30 fps is around 32 samples at 48000 Hz?

Link to comment
Share on other sites

I am also puzzled about the 2/100th of a difference. When you did that test, where you aggregating with an other device? To be exact did you Jam on an other device then that you compare the metronome on?

The way Boom Recorder is designed if you use one interface, it should be accurate to within a sample. Unless the front edge of the LTC frame is not vertical enough and does not zero cross at the correct position.

To be true, I think in the specification of LTC it asks for the timecode signal to be passed through a low pass filter to reduce high frequency interference. So it may be that the LTC signal is according to spec and the edge is very slanted, I haven't read anything in the specification where exactly on the edge a new frame starts, I just assumed it would be the zero cross.

A long time ago someone else did a test in a sound studio and he got it accurate to 6 samples. 6 samples I can see happen because of a slanted edge. I think 2/100th of 30 fps is around 32 samples at 48000 Hz?

No aggregation.  TC jammed in BR by passing TC (from the 744T) through an input of the Traveler (a Mk2, so no EQ etc possible in the signal path).  Diff was as consistent as I could measure it from beginning to end.  I'd be interested to hear what gear the guy who did the 6 sample studio test was using.  I also am not dead sure that the TC at the TC output of my 744T is exactly in sync with the TC as it is stamped on its own files.....to the sample.  Please correct me if I'm wrong, but 2/100ths of a frame seems like "close enough for rock and roll" to me, sync wise (if there is no drift)?

thanks Take

Philip Perkins

Link to comment
Share on other sites

According to the BBC standards I once read they want sync to within half a frame, so you should be good :-)

I actually read back the mail, it was not 6 samples, it was 52 samples, which is around the same as those 2/100th of a difference in your case.  He attributed this to latency in his rig (pro tools with 002R). Maybe I am using the wrong edge for the detection of the frame.

Maybe I have to skip the preamble or something. I will do some calculations tomorrow.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...