18 Dec
2006
18 Dec
'06
11:13 p.m.
On 12/18/2006 09:44:11 PM, Robin Gareus wrote:
sure, i'll generate some samples, and also prepare a sample of what i
recorded from the camera. the video producer i'm working with now is
using 29.97 non-drop, but i'll send a range of frame rates
Hi!
during shooting. we were going to feed the studio64-xtc LTC to both the
cameras and ardour, but had trouble locking cameras to that code -- i
actually think this may have been a problem with the feed from my end,
but we didn't have time to debug it. we ended up feeding
camera-generated LTC into ardour in realtime while shooting.
cool to hear it is (or was) on the xjadeo todo
list,
it still is. one might get the idea to play a video file along to an
live audio-LTC, but no one requested that feature yet ;-) I guess it
could be useful for making video-walls using "old" computers without
MIDI and netjack...
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.
I'm confused by "live video shots", are you editing (offline) or you
were monitoring (online/live)? mmh. OTOH it does not matter, does it?
In case it's during shooting: Are you feeding a camera generated LTC
into the the DAT, or some external generator into both the camera(s)
(which also records audio) and the HDR/DAT? -> how good/noisy is the LTC signal?
-> is it raw audio data or has it been resampled/transcoded. (lossy MD
or mp3 recording ??)
i don't know how good the camera-generated LTC is. i have not yet tried
to lock the studio64-xtc to that, but will try tomorrow.
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.
don't get started on that windows machine... I've got some old files
where I know the timecode for reference (25fps). Hardware is
interesting for noise analysis (input) and to verify if proprietary
boxes can lock to the signal that "libltcsmpte" will generate.
If I can read my own files, I'll try some of yours. Could you email or
upload a minute of example LTC (wav or aiff - gzip ) or maybe better
make that more files: clean and noisy :-) what is your usual
framerate?
when the parser works it'd be interesting to set up a loop: Can your
studio64-xtc lock to incoming LTC and output LTC (w/o you installing
windows)?
i'll check tomorrow. i think so. i may just fire up my wife's old win95
laptop anyway, and play with MTC transcoding, just for the fun of it.
yes, i'm up for beta testing. i don't have cameras available to play
with, but i have a few computers here to sync together, along with the
studio64-xtc.
that should be good enough for preliminary tests. In
January
I can get my hands on a scope..
I'm leaving for Austria tomorrow, and be will online again at the
Chaos
Communication Congress in Berlin after x-mas.
cool. great to see this moving forward. it would be very cool to be
able to lock to LTC for post-production on this project.
you may have noticed that erik de castro lopo has stepped into the ring
as well.... wow; a flurry of activity!
i'll be in touch about samples.
.pltk.
19 Dec
19 Dec
10:36 a.m.
New subject: [linux-audio-user] SMPTE timecode reader
On Mon, 2006-12-18 at 22:13 -0500, plutek wrote:
during shooting. we were going to feed the
studio64-xtc LTC to both the
cameras and ardour, but had trouble locking cameras to that code -- i
actually think this may have been a problem with the feed from my end,
but we didn't have time to debug it. we ended up feeding
camera-generated LTC into ardour in realtime while shooting.
what do you think ardour is going to do with timecode during recording?
i just want to make sure that you're not thinking you could slave to it.
you should never record while slaved to a non-sample-accurate clock
source, and LTC is absolutely not sample accurate. slaving to timecode
is useful during playback, not during recording. this is true of not
just ardour, but everything else. if you want video/audio sync during
recording, you need to use blackburst or some equivalent to provide a
single clock source to the video and audio gear. this is actually
preferable during playback too, but most people don't have the equipment
for this. as was noted earlier, with digital audio, there are
alternatives to using timecode anyway.
10:57 a.m.
New subject: [linux-audio-user] SMPTE timecode reader
On 12/19/2006 09:36:33 AM, Paul Davis wrote:
On Mon, 2006-12-18 at 22:13 -0500, plutek wrote:
we were not trying to lock everything together (although the cameras
were jam-synced together); we simply wanted to end up with the same
timecode striped on a track of all devices, audio and video, as a
reference for post. yes, i take your point about blackburst, and we'll
see if we run into problems during post -- in the end, it should not be
a huge issue because the video edits will allow some "munging" along
the timeline. still, once we get to post, the ability to directly parse
and lock to incoming LTC might simplify things.
today i will be trying to lock with MTC via my opcode studio64-xtc, but
it looks like ardour may be lacking the framerate i need for this
project. the video producer used 29.97 non-drop. now, i must confess to
some slight confusion about the real meaning of all the combinations of
29.97, 30, drop, and non-drop, but ardour 0.99.3 doesn't show any 29.97
options for MTC, so am i out of luck here?
thanks!
.pltk.
during shooting. we were going to feed the
studio64-xtc LTC to both
the
cameras and ardour, but had trouble locking
cameras to that code --
i
actually think this may have been a problem with
the feed from my
end,
but we didn't have time to debug it. we ended
up feeding
camera-generated LTC into ardour in realtime while shooting.
what do you think ardour is going to do with timecode during
recording?
i just want to make sure that you're not thinking you could slave to
it.
you should never record while slaved to a non-sample-accurate clock
source, and LTC is absolutely not sample accurate. slaving to timecode
is useful during playback, not during recording. this is true of not
just ardour, but everything else. if you want video/audio sync during
recording, you need to use blackburst or some equivalent to provide a
single clock source to the video and audio gear. this is actually
preferable during playback too, but most people don't have the
equipment
for this. as was noted earlier, with digital audio, there are
alternatives to using timecode anyway.
11:55 a.m.
New subject: [linux-audio-user] SMPTE timecode reader
On Tue, 2006-12-19 at 09:57 -0500, plutek wrote:
today i will be trying to lock with MTC via my opcode
studio64-xtc, but
it looks like ardour may be lacking the framerate i need for this
project. the video producer used 29.97 non-drop. now, i must confess to
some slight confusion about the real meaning of all the combinations of
29.97, 30, drop, and non-drop, but ardour 0.99.3 doesn't show any 29.97
options for MTC, so am i out of luck here?
ardour2.0 supports several more frame rates,including 29.97. i don't
think you can get ardour 0.99 to do so, but to be perfectly honest, i am
not sure either :)
--p
noon
New subject: [linux-audio-user] SMPTE timecode reader
On 12/19/2006 10:52:23 AM, Paul Davis wrote:
On Tue, 2006-12-19 at 09:57 -0500, plutek wrote:
thanks paul.... i'll check it out and report back. looks like it's time
for me to compile ardour2!
.pltk.
today i will be trying to lock with MTC via my
opcode studio64-xtc,
but
it looks like ardour may be lacking the framerate
i need for this
project. the video producer used 29.97 non-drop. now, i must confess
to
some slight confusion about the real meaning of
all the combinations
of
29.97, 30, drop, and non-drop, but ardour 0.99.3
doesn't show any
29.97
options for MTC, so am i out of luck here?
ardour2.0 supports several more frame rates,including 29.97. i don't
think you can get ardour 0.99 to do so, but to be perfectly honest, i
am
not sure either :)
11:57 a.m.
New subject: [linux-audio-user] SMPTE timecode reader
On 12/19/2006 09:57:47 AM, plutek wrote:
i must confess to some slight confusion about the real
meaning of all
the combinations of 29.97, 30, drop, and non-drop, but ardour 0.99.3
doesn't show any 29.97 options for MTC, so am i out of luck here?
with further reading, i believe i have a clearer picture of smpte
formats:
--"30 non-drop" runs at 30 fps, with continuous counting.
--"29.97 drop" is the same as "30 drop", running at 29.97 fps, and
using discontinuous counting such that the frame times don't slip too
much from normal timepieces over longer durations.
--"29.97 non-drop" runs at 29.97 fps, with continuous counting -
usually used in i.e. commercials which, due to their brevity do not get
to the first dropped frame-count in the "drop" format.
so, my understanding is that we have 2 out of the above 3 formats
covered in ardour's MTC options, right? if one wishes to use "29.97
non-drop", it seems not currently possible.
.pltk.
23 Dec
23 Dec
12:12 p.m.
New subject: [linux-audio-user] SMPTE timecode reader
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
what do you think ardour is going to do with timecode
during
recording?
use it as offset.
I was interested in having a tool that reads the first [LTC]SMPTE from a
[analog] recording and use it as offset for the audio file that is
recorded along with. At the end I would only be interested in the
drift+jitter information (no varispeed).
In my experience that this is good enough for A/V sync (even to
sync snare hits on a music video!)
i just want to make sure that you're not thinking
you could slave to
it.
ack!
if you want video/audio sync during recording, you
need to use
blackburst [..] or some equivalent to provide a but most people
don't have the equipment for this.
I would not recommend to use LTC, but It seems to be good enough for
most [low budget] video productions!
I've started to write a simple parser (counting the zero crossing from
the signal and decode the Manchester). It seems that Maarten's code
(level Threshold) works better and even more so if combined with some
band pass filter..
I've got a jack app that reads LTC and am working on libltcsmpte to both
read and write LTC time code; but it's going to take until 2007.
merry X-mas,
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFFjPDieVUk8U+VK0IRAvfZAKCvDL22jMxcp8S9XcVPoy0vVZJUWACgkeZZ
3nyjswBo9dOlvtF3Y51pDCY=
=biTJ
-----END PGP SIGNATURE-----
6539
days inactive
6544
days old
linux-audio-user@lists.linuxaudio.org
6 comments
3 participants
participants (3)
-
Paul Davis -
plutek -
Robin Gareus