18 Dec
2006
18 Dec
'06
9:08 p.m.
On 12/18/2006 07:03:31 PM, Robin Gareus wrote:
yes... good suggestion, of course.
i'd be happy to test.
plutek wrote:
yes, LTC.
yes, i've read the discussions.
(yes, they're old!)
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). 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.
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.
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.