Philip Perkins Posted August 7, 2010 Report Share Posted August 7, 2010 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 Quote Link to comment Share on other sites More sharing options...
Michael P Clark Posted August 7, 2010 Report Share Posted August 7, 2010 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. Quote Link to comment Share on other sites More sharing options...
takev Posted August 7, 2010 Report Share Posted August 7, 2010 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. Quote Link to comment Share on other sites More sharing options...
Zack Posted August 7, 2010 Author Report Share Posted August 7, 2010 Takev, the 7 series recorders stamp their TC with 00 for frames at the start and stop of each file (something that is not adjustable from what I can tell). Could this be causing issues perhaps? Quote Link to comment Share on other sites More sharing options...
takev Posted August 7, 2010 Report Share Posted August 7, 2010 No, that shouldn't be an issue, it will just delay the start of the recordig until it reaches 00. Quote Link to comment Share on other sites More sharing options...
Philip Perkins Posted August 8, 2010 Report Share Posted August 8, 2010 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 Quote Link to comment Share on other sites More sharing options...
Philip Perkins Posted August 26, 2010 Report Share Posted August 26, 2010 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 Quote Link to comment Share on other sites More sharing options...
Richard Lightstone, CAS Posted August 26, 2010 Report Share Posted August 26, 2010 Phil, A very worthwhile test and thank you! Take will be pleased as well. Quote Link to comment Share on other sites More sharing options...
Philip Perkins Posted August 26, 2010 Report Share Posted August 26, 2010 I was pretty stoked that they were so close--I think it means that I can use multiple BR rigs as a single multitrack. phil p Quote Link to comment Share on other sites More sharing options...
takev Posted August 26, 2010 Report Share Posted August 26, 2010 I am pleased :-) I still wonder why I am not in sync with the other recorders though. Quote Link to comment Share on other sites More sharing options...
Tom Visser Posted August 26, 2010 Report Share Posted August 26, 2010 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. Quote Link to comment Share on other sites More sharing options...
Philip Perkins Posted August 26, 2010 Report Share Posted August 26, 2010 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 Quote Link to comment Share on other sites More sharing options...
Tom Visser Posted August 26, 2010 Report Share Posted August 26, 2010 I'll make a recording and measure the offset, probably won't be able to get to it until tomorrow. Quote Link to comment Share on other sites More sharing options...
Tom Visser Posted August 28, 2010 Report Share Posted August 28, 2010 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... Quote Link to comment Share on other sites More sharing options...
Philip Perkins Posted August 28, 2010 Report Share Posted August 28, 2010 So to what would we ascribe the diffs between the Nagra / BR TC and the 744/BR TC? How each device sees the frame edge? Latency introduced by the hardware recorder's own circuitry between the TC gen/output and when it can be added to the metadata of its own file? phil p Quote Link to comment Share on other sites More sharing options...
Tom Visser Posted August 28, 2010 Report Share Posted August 28, 2010 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. Quote Link to comment Share on other sites More sharing options...
Tom Visser Posted August 30, 2010 Report Share Posted August 30, 2010 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.