SMPTE track

View: New views
14 Messages — Rating Filter:   Alert me  

SMPTE track

by Florian Faber-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

I'm looking for a way to interpret a track containing a SMPTE timecode
_as_ timecode. I couldn't find any means in ardour itself nor the web,
so:

- Is there a way to interpret a track as timecode?

- If not, what would be the best way? Adding a track mode "SMPTE TC",
interpreting the included data and importing it?


Flo
--
Machines can do the work, so people have time to think.
public key 6C002249          x-hkp://wwwkeys.eu.pgp.net
_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

Re: SMPTE track

by Paul Davis :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Wed, 2008-07-09 at 21:00 +0200, Florian Faber wrote:
> Hi,
>
> I'm looking for a way to interpret a track containing a SMPTE timecode
> _as_ timecode. I couldn't find any means in ardour itself nor the web,
> so:
>
> - Is there a way to interpret a track as timecode?

no.

>
> - If not, what would be the best way? Adding a track mode "SMPTE TC",
> interpreting the included data and importing it?

no. write a JACK client that interprets SMPTE audio data as TC and takes
control of JACK transport.

i have code (somewhere) to do the translation.

--p


_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

Re: SMPTE track

by plutek-infinity :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

>From: Florian Faber <faber@...>

>I'm looking for a way to interpret a track containing a SMPTE timecode
>_as_ timecode. I couldn't find any means in ardour itself nor the web,
>so:
>
>- Is there a way to interpret a track as timecode?
>
>- If not, what would be the best way? Adding a track mode "SMPTE TC",
>interpreting the included data and importing it?

hi florian!

you might want to be in touch with robin gareus <robin@...> about this. a while ago, i was looking for similar tools and he was working on jltc & libltcsmpte, which read and generate LTC (linear timecode -- SMPTE timecode recorded as audio, which i think is what you're talking about), displaying running timecode in sync.

i got busy, and didn't pursue it much, so i'm not sure what the current state of his work is.

cheers!


--
.pltk.
_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

Re: SMPTE track

by Florian Faber-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Paul,

> > - If not, what would be the best way? Adding a track mode "SMPTE
> > TC", interpreting the included data and importing it?
> no. write a JACK client that interprets SMPTE audio data as TC and
> takes control of JACK transport.

Then I won't see the timecode in ardour while editing. Basically I want
to extract the timecode and sample offset from the timecode track (the
timecode may start anywhere within a frame, so the correct starting
point would be the first edge after the sync word). This only needs to
be done once since audio and video are in sync.

I cannot do this manually, since I don't know the timecode when the
recording started.

> i have code (somewhere) to do the translation.

If it's no hassle, I'd be glad if you'd send it over since there's no
need to reinvent the wheel. But it's not that hard to look for a sync
word and decode the first LTC.


Flo
--
Machines can do the work, so people have time to think.
public key 6C002249          x-hkp://wwwkeys.eu.pgp.net
_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

Re: SMPTE track

by John Emmas :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

----- Original Message -----
From: "Florian Faber" <faber@...>
Sent: 10 July 2008 04:15
Subject: Re: [Ardour-Dev] SMPTE track
>
> Basically I want to extract the timecode and sample offset from the
> timecode track (the timecode may start anywhere within a frame, so the
> correct starting point would be the first edge after the sync word). This
> only needs to be done once since audio and video are in sync.
>
Hi Florian,

I've been editing sound and pictures for over 20 years, going right back to
the very earliest DAWs.  I don't know of any DAW where you have an actual
timecode track and I can't say I've ever felt the need for one.  However,
this statement strikes me as significant:-

>
> I cannot do this manually, since I don't know the timecode when the
> recording started.
>
Without knowing what exactly you're doing, I'd guess that it's the lack of a
'timecode stamp' (and/or the ability to retrieve it) that are really at the
root of your problem.  Are you needing to re-sync some audio *after* it's
been recorded?  Professional DAW's stamp every recording with it's original
recorded timecode (precisely to eliminate the need for a timecode track).
I've never delved deeply enough into Ardour to know whether it does this or
not but it shouldn't be a difficult feature to add.

Another feature that's common on the top-end DAW's is the ability to have a
'default' edit for a recorded clip (commonly used so that when you spot a
clip, it always starts and ends at a known place within the audio).  I'm
pretty certain this isn't yet available with Ardour but it's immensely
useful, both for music use and sound-for-picture.

The ability to select a range of timeline clips and offset them very
precisely (i.e. by typing in an offset or a new start time) is also quite
common in sound-for-picture use.

The bottom line is that I feel there must be better ways of solving your
problem, rather than implementing a timecode track.

John


----- Original Message -----
From: "Florian Faber" <faber@...>
To: <paul@...>
Cc: <ardour-dev@...>
Sent: 10 July 2008 04:15
Subject: Re: [Ardour-Dev] SMPTE track


> Paul,
>
>> > - If not, what would be the best way? Adding a track mode "SMPTE
>> > TC", interpreting the included data and importing it?
>> no. write a JACK client that interprets SMPTE audio data as TC and
>> takes control of JACK transport.
>
> Then I won't see the timecode in ardour while editing. Basically I want
> to extract the timecode and sample offset from the timecode track (the
> timecode may start anywhere within a frame, so the correct starting
> point would be the first edge after the sync word). This only needs to
> be done once since audio and video are in sync.
>
> I cannot do this manually, since I don't know the timecode when the
> recording started.
>
>> i have code (somewhere) to do the translation.
>
> If it's no hassle, I'd be glad if you'd send it over since there's no
> need to reinvent the wheel. But it's not that hard to look for a sync
> word and decode the first LTC.
>
>
> Flo
> --
> Machines can do the work, so people have time to think.
> public key 6C002249          x-hkp://wwwkeys.eu.pgp.net
> _______________________________________________
> ardour-dev mailing list
> ardour-dev@...
> http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

Re: SMPTE track

by Florian Faber-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

John,

> > I cannot do this manually, since I don't know the timecode when the
> > recording started.
> Without knowing what exactly you're doing, I'd guess that it's the
> lack of a 'timecode stamp' (and/or the ability to retrieve it) that
> are really at the root of your problem. Are you needing to re-sync
> some audio *after* it's been recorded?  

Ok, here's the situation: Recording of a concert, LTC comes from a HDW,
audio hardware is synced to the video. The multitrack record is then
mixed and mastered out of house. The easiest way I could think of to
survive all the steps and the different systems involved would be
recording the timecode as audio track. But I'm open to suggestions :)

Having the timecode track would also allow me to add the timecode meta
information later on, since it is exactly the same information that
would have been used to generate the timecode in the first place. I
don't see why that should be a stupid idea. And I wouldn't have to deal
with offsets or anything like that since I can identify the frame start
with sample accuracy.

[Paul, don't read this] I don't plan to record with ardour, I use
jackrec.

> The ability to select a range of timeline clips and offset them very
> precisely (i.e. by typing in an offset or a new start time) is also
> quite common in sound-for-picture use.

Yes, but to know the starting point I'd have to decode the timecode
track. I could do this by watching at the waveform, of course...


Flo
--
Machines can do the work, so people have time to think.
public key 6C002249          x-hkp://wwwkeys.eu.pgp.net
_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

Re: SMPTE track

by John Emmas :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Florian,

You've raised a large number of issues there.  In my experience, the
mastered multitrack (probably now in stereo) would normally be passed to the
video editor who would re-sync it (as best he could - given that video NLE's
can only work in whole numbers of frames).  Or alternatively, the video
editor would work with a rough mix and then the audio editor would perform
the re-sync.

Either way, the timecode in the finished video would bear no resemblence to
tthe original recorded timecode.  However, if you know the relevant offset,
that's all you need to perform an accurate re-sync.  This does mean however,
that whoever masters the multitrack must keep it at the same timecode as was
originally recorded (which may or may not be convenient for them).

Either way, the crucial information you need to know is the offset between
the master mix and the edited pictures.  A timecode track may or may not
help you with this.

Back in the days of multitrack tape, it was quite common to stripe one track
of the tape with LTC but I don;t think I've ever seen that done for a DAW.

Sadly, I'll be out for the rest of today - but I'll give this some thought.

John


----- Original Message -----
From: "Florian Faber" <faber@...>
To: <ardour-dev@...>
Sent: 10 July 2008 05:56
Subject: Re: [Ardour-Dev] SMPTE track


> John,
>
>> > I cannot do this manually, since I don't know the timecode when the
>> > recording started.
>> Without knowing what exactly you're doing, I'd guess that it's the
>> lack of a 'timecode stamp' (and/or the ability to retrieve it) that
>> are really at the root of your problem. Are you needing to re-sync
>> some audio *after* it's been recorded?
>
> Ok, here's the situation: Recording of a concert, LTC comes from a HDW,
> audio hardware is synced to the video. The multitrack record is then
> mixed and mastered out of house. The easiest way I could think of to
> survive all the steps and the different systems involved would be
> recording the timecode as audio track. But I'm open to suggestions :)
>
> Having the timecode track would also allow me to add the timecode meta
> information later on, since it is exactly the same information that
> would have been used to generate the timecode in the first place. I
> don't see why that should be a stupid idea. And I wouldn't have to deal
> with offsets or anything like that since I can identify the frame start
> with sample accuracy.
>
> [Paul, don't read this] I don't plan to record with ardour, I use
> jackrec.
>
>> The ability to select a range of timeline clips and offset them very
>> precisely (i.e. by typing in an offset or a new start time) is also
>> quite common in sound-for-picture use.
>
> Yes, but to know the starting point I'd have to decode the timecode
> track. I could do this by watching at the waveform, of course...
>
>
> Flo
> --
> Machines can do the work, so people have time to think.
> public key 6C002249          x-hkp://wwwkeys.eu.pgp.net
> _______________________________________________
> ardour-dev mailing list
> ardour-dev@...
> http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

Re: SMPTE track

by Florian Faber-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

John,

> You've raised a large number of issues there.  In my experience, the
> mastered multitrack (probably now in stereo) would normally be passed
> to the video editor who would re-sync it (as best he could - given
> that video NLE's can only work in whole numbers of frames).

Frame accuracy is fine for ear-eye-synchronicity. We normally layer all
the timecode-coupled HD video tracks, the live cut and an audio rough
cut (FOH or quick'n'dirty mix down) into the NLE's timeline, aligned by
the original timecode. So for each point in time we have the same
(realtime) timecode and don't have to worry about anything.

> Either way, the timecode in the finished video would bear no
> resemblence to tthe original recorded timecode.

Sure, the final video has it's own timecode. I only need the original
timecode for the first alignment (directly after logging the data) and
as a basis for calculating the offsets after the mastered clips return.

Anyway, since I seem to have a very rare need here, I think I'll just go
and write a WAV->BWF converter which can decode the timecode channel
and add it as metadata to the BWF. Seems to be the most practical
solution.

Thanks for your input :)


Flo
--
Machines can do the work, so people have time to think.
public key 6C002249          x-hkp://wwwkeys.eu.pgp.net
_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

Re: SMPTE track

by Robin Gareus :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Flo, and ardour-dev's!

plutek-infinity wrote:
>> From: Florian Faber <faber@...>
>
>> I'm looking for a way to interpret a track containing a SMPTE timecode
>> _as_ timecode. I couldn't find any means in ardour itself nor the web,
>> so:

Did you have a look at http://ltcsmpte.sf.net/  ? - well not the
web-page but the code there ;)

>>
>> - Is there a way to interpret a track as timecode?
>>
>> - If not, what would be the best way? Adding a track mode "SMPTE TC",
>> interpreting the included data and importing it?

not trivial - libltcsmpte allows you to decode or encode the SMPTE
timecode(s) for chunks of audio-data.

There's a small example client that uses jack-audio-in-ports to
read/display LTC/SMPTE in real-time and generate LTC from jack-transport
(the latency compensation of the latter is a bit quirky)

Synchronizing jack-transport to incoming LTC is as good as impossible.

Eventually I've used ltcsmpte to read the first LTC/SMPTE from a file
and applied this as an offset for the corresponding A/V track. - ..but
there's a hacked version of jplay2 that takes an audio-file and a
LTC-file as input and writes time-stretched audio from vari-speed
recorings.. that can be imported into ardour. - It may or mat not be too
hard to write a plugin that reads LTC and controls rubberband inside
ardour ?!

so long,
robin


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIdfOxeVUk8U+VK0IRAk4PAJ96AY1o9+AZWNSrWTuQrSGmij9UZgCfQH0Q
rwP8yZoFaTyvZpv2wetQhew=
=ZnzZ
-----END PGP SIGNATURE-----
_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

Re: SMPTE track

by Robin Gareus :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Emmas wrote:

>> [..]
> Another feature that's common on the top-end DAW's is the ability to have a
> 'default' edit for a recorded clip (commonly used so that when you spot a
> clip, it always starts and ends at a known place within the audio).  I'm
> pretty certain this isn't yet available with Ardour but it's immensely
> useful, both for music use and sound-for-picture.

This is a feature I've been missing in ardour for quite a while. yet an
easy workaround is to batch search&replace "<Region [^>]* name=XX [^>]*
position=" in the .ardour session file.. ;)


> The ability to select a range of timeline clips and offset them very
> precisely (i.e. by typing in an offset or a new start time) is also quite
> common in sound-for-picture use.

should we make a feature request out of these:
  * popup-dialog to edit start/end/duration time of a region
    (calc shift,offset to/from clip, reset region to clip-values)
  * move region to default position on right-click-menu
  * insert clip as new track using default position
  * popup-dialog to set/edit the default position for a clip/source.

ardour meta-data has always been some kind of pandora's box, Could you
guys comment on the use-cases and user-interaction before we ask to add
backend-support?

The default clip-position could come from an audio-file header or when
recording audio from jack-transport..

> The bottom line is that I feel there must be better ways of solving your
> problem, rather than implementing a timecode track.

sorry I've cut most of the original thread.. see there.

This will only solve the user-part. ardour still needs to know the
/default/ timestamp. nowadays most pro-equipment digitizes LTC early
using hardware converters under the hood.  Modern audio-formats have
more practical means to exchange time-stamp/timecode information than LTC.

cheers,
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIdhPFeVUk8U+VK0IRAhnqAJ9emRy7sgCYpGQ6uQMP5mwB49blmACfXYtE
O2z2iXrpbb9PvEX36oJiuhY=
=KEKc
-----END PGP SIGNATURE-----
_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

Re: SMPTE track

by Paul Davis :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Thu, 2008-07-10 at 15:51 +0200, Robin Gareus wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> John Emmas wrote:
>
> >> [..]
> > Another feature that's common on the top-end DAW's is the ability to have a
> > 'default' edit for a recorded clip (commonly used so that when you spot a
> > clip, it always starts and ends at a known place within the audio).  I'm
> > pretty certain this isn't yet available with Ardour but it's immensely
> > useful, both for music use and sound-for-picture.
>
> This is a feature I've been missing in ardour for quite a while. yet an
> easy workaround is to batch search&replace "<Region [^>]* name=XX [^>]*
> position=" in the .ardour session file.. ;)

I am still unclear as to what feature is being discussed here.

> should we make a feature request out of these:
>   * popup-dialog to edit start/end/duration time of a region

Already exists.

>     (calc shift,offset to/from clip, reset region to clip-values)

Not sure what these mean.

>   * move region to default position on right-click-menu

Alread exists.

>   * insert clip as new track using default position

Already exists.

>   * popup-dialog to set/edit the default position for a clip/source.

Don't know what this means. If it means editing the BWF header, pretty
dubious. I'd need some convincing that this was a good idea. Note that
file formats like WAV have no support for position.

--p



_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

Re: SMPTE track

by Robin Gareus :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Paul Davis wrote:

> On Thu, 2008-07-10 at 15:51 +0200, Robin Gareus wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> John Emmas wrote:
>>
>>>> [..]
>>> Another feature that's common on the top-end DAW's is the ability to have a
>>> 'default' edit for a recorded clip (commonly used so that when you spot a
>>> clip, it always starts and ends at a known place within the audio).  I'm
>>> pretty certain this isn't yet available with Ardour but it's immensely
>>> useful, both for music use and sound-for-picture.
>> This is a feature I've been missing in ardour for quite a while. yet an
>> easy workaround is to batch search&replace "<Region [^>]* name=XX [^>]*
>> position=" in the .ardour session file.. ;)
>
> I am still unclear as to what feature is being discussed here.

The idea is to move an audio-track to a specific start position and be
able to re-align it repeatedly. the use-case to synchronize sound-tracks
or recordings. it would be nice to have a simple method to re-align
chunks of audio to some initial (or default) timecode as well.

Maybe this is already possible, and I'm not aware of it - that's why I
asked before making a feature-request ;) - thanks for the quick reply.

>> should we make a feature request out of these:
>>   * popup-dialog to edit start/end/duration time of a region
>
> Already exists.

the region-editor in ardour2 misses an option to specify an offset where
to start in the audio-clip. - maybe I'm missing something on how to
cut/edit chunks by numbers with ardour.

>>     (calc shift,offset to/from clip, reset region to clip-values)
>
> Not sure what these mean.

audio-chunks that have been cut from a region should /inherit/ the
region's timecode. - maybe they already do? how can I make use of it?

Sometimes I end up dragging regions and moving chunks around and it'd be
nice to restore their initial position or duration.

A popup-dialog or menu could allow to select different modes:
 - cut a region from the original source for this absolute position
 - reposition this chunk of audio so that it's timecode matches
   the timecode (or offset) from the souce file. - optionally retain the
   absolute start or end position of the chunk.
maybe the latter is enough, the former can already be achieved with a
few extra clicks and the region-editor.

now that I think of it: it may be possible with a few marks, and cursor
jumps and "align-relative"..  but this is just brainstorm.

>>   * move region to default position on right-click-menu
>
> Alread exists.

Is it called "nudge-by-capture-offset" ?

>>   * insert clip as new track using default position
>
> Already exists.
>
>>   * popup-dialog to set/edit the default position for a clip/source.
>
> Don't know what this means. If it means editing the BWF header, pretty
> dubious. I'd need some convincing that this was a good idea. Note that
> file formats like WAV have no support for position.

The ardour session could /fake/ BWF headers for file-formats which don't
support it, and allow to edit/override the information. yes it's a bit
dubious. Are there any standalone BWF header editors/generators around?
- will ardour re-load the header-information on restart or would that
need to be done before importing the audio?

so long,
robin
_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

Parent Message unknown Re: SMPTE track

by Ben Loftis :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

OK, given that you want to record with a non-synced device (i.e.
jackrec)....

The "accepted" practice, I believe, is to make a recognizable "pop" of
some kind, either audio or visual, in the video recording, which can
then be synced with the "pop" sound which is recorded on one or more
tracks of the multitrack recording.

For best results (no A/V drift over a long recording time), you should
be running from wordclock that has been synced with the video clock.

I only get the digest, so forgive me if I am way behind here....

-Ben

_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

Parent Message unknown Re: SMPTE track

by Wolfgang Woehl :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Ben Loftis:

> The "accepted" practice, I believe, is to make a recognizable "pop"
> of some kind, either audio or visual, in the video recording, which
> can then be synced with the "pop" sound which is recorded on one or
> more tracks of the multitrack recording.

Can't use clapper events for multimic stage recordings, at least not
on stages that are bigger than your average vault. The audible part of
the clapper event would show up at precisely m (different) points in
absolute time, m being the amount of microphones.

Wolfgang

_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org
LightInTheBox - Buy quality products at wholesale price