Synchronisation and SMPTE timecode (time code) | Hacker News Reader

Synchronisation and SMPTE timecode (time code)

philrees.co.uk

49 pointssublinear21 comments

Phil Rees products were an absolute godsend in the 90s when most hobby and budget studios were still mainly all hardware being recorded to tape of some description. You would often find multiple little red and black boxes doing various conversion and routing jobs. And they all powered straight off the mains without a big heavy internal linear supply, or external wall wart, which was a great help during late nights where the right PSU may have gone walkies.

I wish more cameras with GPSes supported SMTPE or something to mark the video with a time code. I get the sense that GPS time is accurate to within 1/30th of a second, if not way way more, but even if it just got me in the neighborhood so I could nudge it a frame or two one way or another.

I like recording things like my kids performances with a GoPro or two, and sometimes my wife or I get some shots on our phones. Multi-cam can be fantastic when you have people walking around in front of cameras, for example.

I used to have a majorly hard time syncing the multiple cameras shots, though the last time I did it (a couple months ago) I had much better luck with the "sync using audio" feature, in the past I've had problems. But why can't we have a timecode with the video stream, in the cases of GPS cameras (I think everyt camera I have now has a GPS)?

> I get the sense that GPS time is accurate to within 1/30th of a second, if not way way more

You are off by 6 orders of magnitude, GPS time is accurate to within 30 ns: https://www.gps.gov/gps-accuracy

A perfect resource, still as relevant as ever.

Genlock, Clock Gen and their friends are at the top of the "check all of the responsible hardware, the ports, and the cables" list when someone is having a flaky problem that doesn't make sense to anybody. Shortly followed by 44.1 vs 48khz and 59.94 vs 60fps being wrong somewhere

Not to forget someone using a 50ohm CB cable instead of a 75ohm cable. Or someone forgetting a terminator or having the signal double terminated.

Everyone I have worked with in the space is like, people throw "OG" around a lot, but these dudes are lifers. They don't make mistakes like that. It made me wish I was cooler with the theater kids in high school, I had no idea.

Ugh, the accidental complexity of drop-frame encoding, BCD, etc... This mess will likely be with us for a long time.

Troubleshooting SCC captions in the digital era is quite an experience. Haven't gotten any request for them in a couple years though.

Had to make an account just to comment.

I think many people here would be very surprised at how common these are still.

In my work, we get SCC ordered CONSTANTLY, even when the intended platform it’s for is fully digital.

I feel it’s a mixture of misunderstandings between that and SDH in addition to just people using subtitles and captions interchangeably.

Just because it's fully digital means what to you?

To the viewer relying on captioning, it makes no difference whatsoever. Captioning is decoded by the TV itself. Subtitles are overlaid by the app. Streaming sources when decoded send the embedded captioning to the same caption decoder as OTA broadcasts or decoded from a VHS tape.

From someone that has spent decades working with subs and captions, the differences are obvious. To everyone else, it's just text on screen regardless of what it is technically

People that roll their eyes when you correct them in stating captions and subtitles are NOT the same thing have clearly never worked with captioning. However, I'd much rather work with them as SCCs over the old way of using a CAP file and hardware encoder connected to a PC. Unfond memories of inserting captioning to to the same tape using pre-read where it reads from the tape, sends the signal to be captioned, and then records the data back to the same tape. In real time.

We once had an AKAI MPC1000 running as a master for a "big studio" ProTools rig using LTC. Good times.

Were you using a MIDI to SMPTE converter of some kind? The MPC 1000 only has MIDI I/O, no SMPTE tape sync. And the stock firmware only offered regular MIDI clock, not even MTC[1], though it is possible to get MTC in and out of an MPC 1000 using the unofficial JJOS OS[2].

[1] https://en.wikipedia.org/wiki/MIDI_timecode

[2] http://www7a.biglobe.ne.jp/~mpc1000/

You're holding it wrong. You can just record a real one and play it back. I use the same cursed approach with my 2500XL to intake/chop/modify/output cv/note signals to a modular setup (which has a handful of outs that don't need to be modified to do this)

JJOS is legendary though. Crazy how much it adds

>You can just record a real one and play it back.

A real what?

A real LTC timecode signal. It was designed to be recorded on tape and used to sync multiple tape machines together among other uses.

Did a similar thing too with a sample of a single square pulse which allowed us to "sequence" a Juno 60 arpeggiator.

Sorry, yes it was MTC, not LTC!

We used JJOS. It is such an awesome upgrade over the stock OS.

I built this, anyone interested? It was a wild ride

https://amiga.resource.cx/exp/phantom

It does seem fun indeed. I am curious what's involved.

Shout out to Chataigne, which supports SMPTE timecode via a 3.5mm jack for personal projects.

Reply on news.ycombinator.com