Jump to content

BR 7.25.1 + 702T sync issues


Zack

Recommended Posts

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.

It would be interesting to know this, esp since BR was AHEAD of the 744T files....

Philip Perkins

Link to comment
Share on other sites

It would be interesting to know this, esp since BR was AHEAD of the 744T files....

Philip Perkins

Not sure if you saw this Take, but it's from the past few weeks....there is a post of two screenshots of sync and BR.

http://jwsound.net/SMF/index.php?topic=6440.msg51263#msg51263

Phillip, seems you had a much better result feeding from your 744t than I did. I wonder if there is an issue with my TC out.

Link to comment
Share on other sites

This is indeed quite odd, my next question would basically be, what if you give two Boom Recorders the same timecode feed.

I can imagine there be a small fixed offset between Boom Recorder and 744T when both slaving from one timecode, as both are interpreting the start of a frame differently. As a timecode signal has 80 subframes (close to 100), and it is two subframes in front, means that either Boom Recorder or the 744T stamps the frame in the wrong place.

I checked my code and the sync-word (not a preamble, but a postamble) is behind the frame, the leading edge of the first data bit in the timecode is the start of the frame. I have not found anything in the standard about the exact position of the start of a frame, so everyone could interpret it slightly differently. Also to find the exact position of the leading edge of a data bit I needed extra programming to remember the position of each bit.

I am not sure why in your case BR was so far off compared to the 744T, maybe it doesn't listen to its own timecode and thus follows an other path to retrieve the timecode.

Link to comment
Share on other sites

This is indeed quite odd, my next question would basically be, what if you give two Boom Recorders the same timecode feed.

I can imagine there be a small fixed offset between Boom Recorder and 744T when both slaving from one timecode, as both are interpreting the start of a frame differently. As a timecode signal has 80 subframes (close to 100), and it is two subframes in front, means that either Boom Recorder or the 744T stamps the frame in the wrong place.

I checked my code and the sync-word (not a preamble, but a postamble) is behind the frame, the leading edge of the first data bit in the timecode is the start of the frame. I have not found anything in the standard about the exact position of the start of a frame, so everyone could interpret it slightly differently. Also to find the exact position of the leading edge of a data bit I needed extra programming to remember the position of each bit.

I am not sure why in your case BR was so far off compared to the 744T, maybe it doesn't listen to its own timecode and thus follows an other path to retrieve the timecode.

I will try syncing two computer systems/interfaces w/ BR to a 744T next week and compare.

Philip Perkins

Link to comment
Share on other sites

  • 3 weeks later...

Having established that there is a (small) offset between a recorder like a 744T and a BR system taking the 744Ts clock and TC (as snapped to TC position in a DAW), I finally got around to trying a sync test between 2 BR systems:

2 systems:

A:

G4 Laptop 1.3 GHz OS 10.5 w/ BR 7.25

Traveler Mk2 w/ Cuemix 1.06

2 FW 400 drives (Oxford chipset)

BR taking 22 tracks to 44 files in 2 folders, one per drive

B:

G4 Laptop 765 Hz OS 10.4.11 w/ BR 7.22

Traveler Mk 2 w/ Cuemix 1.06

2 FW 400 drives (Oxford chipset)

BR taking 22 tracks to 44 files in 2 folders, one per drive

Clock:

744T 48k, feeding WC input of "A" Traveler, WC out of "A" Traveler feeds WC input of "B" Traveler.

TC:

Both Traveler/BR systems jammed to 744T TC (one after the other) then disconnected.

TC ran for about 10 min before I started to record.

Recorded a metronome for 70+ min, started systems together (manually, so not exact).

Took one metronome track from each system into a DAW, snapped them to original TC.

Result:  Exact to-the-sample sync the whole way.  I looked at the wfms and they are in dead sync.  I spot-listened to the two tracks mixed--no phasing or changes the whole way.

Pretty cool.  I know the equipment in use here is a bit more trashy than most people around here would use, but I think it proves the concept that BR systems will stay in sync w/ each other given a common clock and TC.

phil p

Link to comment
Share on other sites

I hope you don't mind my minor hijack.  I was also doing some tests tonight and did not detect any synch issues, but I do have a possible software request.  (Synch will be investigated in the future when I can get this stable)

iMac I7 27"

WC - Nagra VI > Presonus FireStudio Lightpipe > Alesis AI4 (StudioLive clocked from FireStudio BNC WC via Firewire)

LTC TC - Naga VI > Presonus StudioLive line input > Firewire to BoomRecorder TC channel

Audio 1 - Nagra VI mic input to AES output > Alesis AI4 AES input to Lightpipe output > Presonus StudioLive Lightpipe input > Firewire to Boom recorder patchbay back out to StudioLive Firewire input returning Firewire to Boomrecorder audio channel 1

Audio 2 - Presonus StudioLive mic input > Firewire to Boomrecorder audio channel 2

There was a slight delay between channel 1 and 2, due to the extra AES to Lightpipe transcode in the AI4, plus extra roundtrip through the Firewire buss.

I was wondering if it was possible to request a feature where BoomRecorder can be given a per channel latency value, that will advance the BWF timestamp for that particular track, so that during playback or DAW / workstation ingest, the files will line up correctly?

While I'm on the subject of feature requests, I had this rig recording wide open and patchbay configured with 52x50 I/O, the maximum supported by Presonus / single firewire buss, at least in test bench conditions.  When looking at the meters, it was a little odd to have multiple columns of horizontal meters.  As most of us are used to looking at vertical meters, would it be possible to make this an option in Boomrecorder?

My final request, I'd love to make the hotkeys assignable.  As a Pro Tools user, I'm inclined to gravitate to the num 3 or F12 key for record.

Anyone have any bright ideas to get BR to support a contact closure / GPIO port for automatically putting an audio recorder into play / stop?

The whole point of this exercise is to see if I can use my Nagra VI as a front end for the StudioLive / Boomrecorder setup, but then be able to quickly dismount and go over the shoulder when required to do so, but I'd like to keep coherent timecode on all recorded tracks if possible.  So even when using BR, the Nagra would still be the front end for my primary boom and wireless mics.

Link to comment
Share on other sites

Options are nice, but lots of meters are horizontal?  (Metacorder, Sound Devices, Deva in one mode anyhow....).

Do you have an idea of exactly how far off your files were from each other (Nagra to BR)?  My 744T @ 48k was 2/100ths of a frame behind BR (where BR was taking WC and jammed to the 744T TC).

phil p

I hooked up my Digi 003 as the interface and recorded TC on line input 5 and the analog output of the Nagra to input 6 and came up with BR lagging the Nagra by 1.125/100ths of a frame.  Phase was also inverted.

realizing that I was also measuring the D/A latency of the Nagra recorder, I repeated the experiment, using an outboard preamp feeding the line input on the Nagra and the 003 simultaneously and came up with BR leading the Nagra by 0.75/100th of a frame...

Link to comment
Share on other sites

I bet it is related to the recorder's own A/D section.  You would think that the manufacturer would compensate for converter latency, but maybe not.  A good experiment for both of us to run is to repeat the test at 96khz and see if the offset is reduced by about half.  I wouldn't necessarily consider 1 or 2 one hundredths of a frame that serious, but it would be nice if BR could apply a global TC offset, and in my particular case, a per channel offset too to compensate for a FireWire buss roundtrip.

Link to comment
Share on other sites

I repeated the experiment at 96KHz and found that the Nagra lagged BR by about 0.3/100ths of a frame this time, a little bit better of an improvement than the 50% that I hypothesized, but close.  Given a bit of deviation for error in my measurements, I think it is close enough to call it half, so for the Nagra and BR, it seems to be in perfect synch, except for the fact that the Nagra is not compensating for its own A/D latency.

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...