> my thought was that i could avoid this by actually emitting SMPTE
> itself, which is an audio stream, and thus can be generated with
> perfect sample accuracy as we go. this can then allow people with
> equipment that can read a SMPTE signal and/or convert it to MTC to get
> their devices to lock
>by the way, i quote from one of the messages:
>
>> i wish to god that SMPTE had never taken off. its the most ridiculous
>> thing since, errr, oh, something like APL. more precisely, its fine
>> for video timing, but its *insane* that its become accepted for audio
>> timing.
>
>written by paul dav
i just found the whole smpte discussion in the archives. it's a nice
read, complete forgot that it was such a long thread. it starts with
http://eca.cx/lad/2000/Jul/0287.html
by the way, i quote from one of the messages:
> i wish to god that SMPTE had never taken off. its the most ridiculous
> t
> i know that someone posted smpte-reading code here last year. does
> anyone have any pointers to source code to generate smpte?
that's me :-)
ftp://www.iua.upf.es/pub/mdeboer/projects/SMPTE/
you can find the sourcecode for the SMPTE decoder, and some reallife
SMPTE signals (from analog tape) t
Paul Davis wrote:
>
> i know that someone posted smpte-reading code here last year. does
> anyone have any pointers to source code to generate smpte?
>
> --p
iirc that was maarten de boer. look on the lad page under "members",
there should be a link under his name.
--
Jörn Nettingsmeier
K
On Tue, 3 Dec 2002 15:28:44 -0500
Paul Davis <[EMAIL PROTECTED]> wrote:
> i know that someone posted smpte-reading code here last year. does
> anyone have any pointers to source code to generate smpte?
Paul,
I think I had some. Its on backup media somewhere. Gimme a couple of
days to dig it up a
i know that someone posted smpte-reading code here last year. does
anyone have any pointers to source code to generate smpte?
--p
