|
View:
New views
14 Messages
—
Rating Filter:
Alert me
|
|
|
SMPTE trackHi,
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 trackOn 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>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 trackPaul,
> > - 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----- 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 trackJohn,
> > 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 trackHi 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 trackJohn,
> 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-----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-----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 trackOn 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 trackPaul 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 |
|
|
|
|
|
|
| Free Forum Powered by Nabble | Forum Help |