[linux-audio-user] SMPTE timecode reader

[plutek]

On 12/18/2006 07:03:31 PM, Robin Gareus wrote:
> plutek wrote:
> 
> > following up on my recent (unanswered) question
> 
> I was waiting with interest for replies, too!
> 
> > i am now interested also in software capable of parsing a SMPTE
> > timecode stream (audio, NOT MTC), and displaying the corresponding
> > numerical timecode, as the audio track is running.
> 
> you mean LTC: http://en.wikipedia.org/wiki/Linear_timecode ?!
> I don't think there is open source software to parse LTC just yet.
> There are a few emails and discussions out there (eg. LAD July 2000).

yes, LTC.
yes, i've read the discussions.
(yes, they're old!)

> 
> > i would like to be able to run multiple instances of such
> > software, to compare timecode in various audio streams.
> 
> I suggest to have a single jack application with <N> audio
> input-channels: a standalone application can easily do some maths,
> eg. display differences between SMPTE's. or record some tracks to
> disk.

yes... good suggestion, of course.

> 
> I was interested in having a tool that reads the first [LTC]SMPTE from
> a
> [analog] recording and use it as offset for the recorded [digital]
> file.
> At the end I would only be interested in the drift+jitter information
> (no varispeed). There's also "video sync to external LTC audio" on the
> xjadeo ToDo list (with varispeed), but I lost interest as all recent
> recordings I get are made completely digital.. no need for analog sync
> tracks! I do not even have analog recording hardware any more :-(

cool to hear it is (or was) on the xjadeo todo list, although once  
we're dealing with digitized video in xjadeo we don't, as you point  
out, really need ltc any more. i've needed this stuff recently while  
doing audio for live video shoots, just so we can all work from (and  
record) a common timecode reference, and confirm while shooting that we  
are actually locked.

> 
> >  alternately, does anyone out there have the ability to program such
> a thing?
> 
> could be done. the specs seem to be open, although there might be some
> patent issues for commercial users.
> 
> it should become a library to read/write LTC SMPTE.
> Let's see if the ardour or alsa guys can dig out some old code, but
> else
> I'll get started on a framework in the upcoming dark evenings of my
> ski-trip: It's not really hard to detect phase transitions and decode
> the signal, but I need to rely on you (or others) for testing.

i'd be happy to test.

> 
> Do you have hardware that can read or generate timecode, or just
> files?

yes, i can generate, but i cannot parse an incoming stream. i also have  
no way of knowing what time i'm spitting out (unless i also send MTC  
and lock i.e. ardour to it), since my generator (an old opcode  
studio64-xtc) just runs with no display of where it is. it CAN lock to  
incoming LTC, but again i must tell it to transcode to MTC and then  
lock software to it in order to know what's going on. i suppose that's  
not a big deal, except that the software which is necessary to set up  
reading and writing MTC only runs on windows, so i would need to dig up  
an old win95 machine and use that to set the user modes on the  
studio64, then take the box and run with it. (ick, i feel so DIRTY...)

maybe it's time to go hunting for that studio64 floppy....yikes.

> 
> I'd guess that it can get somewhat tricky with noise, variable speed
> and
> funny framerates... but the simple part should take less than a few
> days. and maybe others in the community can help out on the
> "professional touch" once there is some code to get started with.

robin... it would be awesome to be able to deal with incoming/outgoing  
LTC directly. i'm hoping there are some other interested souls who  
might crawl out of the woodwork here, if this gets off the ground.  
linux should get into the video/film shoots, and it needs LTC to do  
that. windows and mac can both deal with LTC directly.


.pltk.