Timecode - How to sync audio only tracks? How to limit total tracks?

hambonio wrote on 4/17/2024, 9:05 PM

I just invested in the Atomos UltraSync system. I connected it today to 4 cameras and 3 audio recorders.

The cameras were only jammed and then the sync device disconnected - so were not actively synced afterwards 2x Sony a7S IIIs, and 2x Sony fx30s.

The audio devices were actively being synced with the Atomos Blue. 2x Tascam DR10L Pros and 1 Zoom FX3. All the devices were showing as connected to the timecode generator, and displayed the correct timecode and the Tascams for sure were flashing the timecode indicator when the generator was flashing (not sure if there was a display for the Zoom, but it did show as connected and timecode matched.)

Anyhow, I am very new to using timecode and my first attempt here. It looks like all of my camera tracks lined up properly even though they were not actively being synced. However none of my WAV files are importing, that for sure were timecode synced. Is there a way to get those in the project?

Also I was stress testing this so was starting and stopping each devices randomly at different times over the course of an hour, which resulted in many video clips. When I imported I tried both through the multicam options, and through the project media by "Lay out tracks using media timecode". Both ways it DID import my video clips correctly to a sense, but each and every clip was put on its own track, which resulted in over 50 tracks. Is there a way to limit the tracks, and possible keep each camera to its own track?

Thanks in advance for any help. I tried looking over timecode in these forums and it seems like there are 100 different ways to do things and could not easily find the answers to my issues.

Back to post

Comments

hambonio wrote on 4/24/2024, 1:00 PM

@hambonio

What if the timeline format is set to samples? Is it still misplaced then? In my tests TimeReference and the number of samples matched after running the positioning script.

You can see the actual TimeReference value in the media properties, I think.

Nils

I am happy to hear you may be on to something! Unfortunately I do not see those results on this end. Is there a step I might be missing or doing wrong?

NoKi wrote on 4/24/2024, 2:42 PM

Mmh, I only tested it for some of the F3 files and the sample numbers and positions matched. Will do it again for all of them. I'm a bit busy at the moment, so it might take some time, sorry.

Nils

NoKi wrote on 4/24/2024, 3:21 PM

Oh and I forgot one important thing: to see matching numbers of TimeReference and the starting points of the events, the projects audio sample rate has to be the same as the media sample rate.

Nils

hambonio wrote on 4/24/2024, 3:50 PM

Oh and I forgot one important thing: to see matching numbers of TimeReference and the starting points of the events, the projects audio sample rate has to be the same as the media sample rate.

Nils

Noki, I greatly appreciate your persistence in helping me out here! I do have the project set at 48,000 Hz already. The only difference is bit depth which can only be changed to a max of 24 bit (was set at 16 bit). So I am guessing all those 32 bit audio renders I have been doing to edit elsewhere aren't really 32 bit anymore, unless the render setting for the Wave files bypasses that setting? But I digress. Still dealing with the issue at hand.

B&H where I purchased this equipment from is closed for another week or I would definitely be talking to a rep there.

NoKi wrote on 4/25/2024, 1:45 PM

@hambonio

I think, I'm able to reproduce your problem now, using all the F3 files:
Depending on the position, where the bunch of files is dragged to the timeline, some files are incorrectly positioned by the script. Dragging the files to the timeline start showed the problem every time here. I have no idea why this happens yet, but an easy solution is to run the script twice.

I integrated this double positioning into a new script. Does it work for you also?

using System;
using ScriptPortal.Vegas;

public class EntryPoint
{
    public void FromVegas(Vegas vegas)
    {
        Timecode minPosition = vegas.Project.Ruler.StartTime;
        
        foreach (Track theTrack in vegas.Project.Tracks)
        {
            foreach (TrackEvent ev in theTrack.Events)
            {
                // if (!ev.Selected) continue;

                Timecode position = ev.ActiveTake.Media.TimecodeIn + ev.ActiveTake.Offset - minPosition;
                ev.Start = position;

                if (ev.Group != null)
                {
                    foreach (TrackEvent groupevent in ev.Group)
                    {
                    groupevent.Start = position;
                    }
                }
            }
            foreach (TrackEvent ev in theTrack.Events)
            {
                // if (!ev.Selected) continue;

                Timecode position = ev.ActiveTake.Media.TimecodeIn + ev.ActiveTake.Offset - minPosition;
                ev.Start = position;

                if (ev.Group != null)
                {
                    foreach (TrackEvent groupevent in ev.Group)
                    {
                    groupevent.Start = position;
                    }
                }
            }
        }
    }
}

Please keep in mind that the timecode precision for the F3 files is still limited to 1s, as the TimeRef. value is only a multiple of the samplerate.

Nils

hambonio wrote on 4/25/2024, 4:33 PM

@NoKi Still no luck. I tried in VP19 and VP20 as well. I do like that your modified script takes control of ALL the tracks, that is nice and streamlined!

The best I have going for me is after running the first script, at least it tells me the second that the track SHOULD be located, so I would just have to manually move it - but at least the info is there to limit guessing. I always have had to adjust tracks anyways - even using Pluraleyes. Some just show up a frame or two off. Especially in echo heavy environments. Even with this timecode some of the other more accurate tracks are a frame or so off "sometimes". But I guess I can't complain for a solution that for less than $500 lets me sync up 7 of my current devices!

Thank you again for all your time and effort looking into this.

NoKi wrote on 4/26/2024, 10:27 AM

Strange...

This is what I get with your files, first running the BWF-script on the WAVs and then the new positioning script on all files ("Edit Details" window):

The event start positions do match the "Timecode In" values. How does it look like when you run the scrips with the same files?

Nils

hambonio wrote on 4/26/2024, 11:56 AM

I have recorded 2 different workflows below, maybe it is something I am missing?

First video is just the audio and I skipped F3_BOARD_027_Tr1 on purpose just because it is an outlier.

I imported with File>Import>Broadcast Wave Format for each device. This places them mostly in the correct position as usual. Then I run your first script on all the files which adds the timecode in marks in the details panel. Then I tried running your latest script (labeled 2a in my script files) a few times and nothing moves any further on the timeline. Then I look up what should be the TC in on the F3 then move the corresponding clip to that time on the timeline. Then it pretty much lines up. I realize in this exact spot even the groom clip is about 1 frame off, but usually always within a frame for anything else I import. Much closer than the F3 does it.

The second video I pulled everything into the project media tab, then pulled each device to their own track. Then I ran your first scrip to load the timecode in details, then ran the 2nd script which moved everything to where it does with every other method, and still having to move the F3 track manually.

The project in the videos above is with SMPTE 23.976 timeline, but I get the same results if I start a new project and set to Samples before importing anything (and still have to switch it back to frame counter to see where I need to manually move the F3 track).

NoKi wrote on 4/26/2024, 2:07 PM

@hambonio

Can you make a screenshot of the window below from your 2nd workflow right after running the 2nd script and before moving events manually so I can compare the 'event start' to 'Timecode In' of all events? Thanks!

Nils

hambonio wrote on 4/28/2024, 7:00 PM

@hambonio

Can you make a screenshot of the window below from your 2nd workflow right after running the 2nd script and before moving events manually so I can compare the 'event start' to 'Timecode In' of all events? Thanks!

Nils

I will get to this as soon as I can. We had some water pipes burst so have been dealing with that for a few days. Thank you.

hambonio wrote on 5/2/2024, 9:33 AM

@hambonio

Can you make a screenshot of the window below from your 2nd workflow right after running the 2nd script and before moving events manually so I can compare the 'event start' to 'Timecode In' of all events? Thanks!

Nils

Sorry it took so long to get you this simple screenshot. Here it is. That is immediately after running your 2nd script.

NoKi wrote on 5/2/2024, 9:58 AM

@hambonio

OK, the 'event start' positions and the 'timecode in' values perfectly match, so the positioning script works properly.

Is the correction you have to do with the F3 files less than a second? This could be because of the 1 s resolution of the TimeReference in the BWFs. No Idea what causes this, my F6 has a resolution of 1 sample.

Nils

hambonio wrote on 5/2/2024, 10:44 AM

@noki The correction gets worse as time goes on and a new file is started. In the above case after 1:46:00:00 it is over 6 seconds off. In the window I sent you it is positioning FE_BOARD_26_Tr1 at 1:46:11:15. When I look at Project Media tab it shows timecode in at 1:46:18:00 which is the position is should be in. I had an overnight trial going on I am trying to find now that I set up before all the chaos happened here. But after 8 hours I remember it being close to a minute off. Not exact number there but the later you start a new file the further off it gets placed.

NoKi wrote on 5/2/2024, 1:07 PM

@hambonio

The BWF start timecode is recalculated when the timeline is set to non drop frame, causing this difference between project media (1:46:18:00, realtime equivalent) and timeline (1:46:11:15, ndf time).

I modified the script, so it compensates for this recalculation. Now, the project media list should show a wrong timecode, but the timeline position should be "correct" 1:46:18:00. Does everything line up now properly?

Nils

using System;
using System.IO;
using System.Drawing;
using System.Collections.Generic;
using ScriptPortal.Vegas;
using System.Diagnostics;
using System.Windows.Forms;



public class EntryPoint
{
    public static Vegas myVegas;
    
    public void FromVegas(Vegas vegas)
    {
        myVegas = vegas;
        Media[] selectedMedia = myVegas.Project.MediaPool.GetSelectedMedia();
    
        foreach (Media media in selectedMedia)
        {
            if (media.HasAudio())
            {
                FileInfo file = new FileInfo(media.FilePath);                                                
                string mediaFilePath = Convert.ToString(file);
                mediaFilePath = mediaFilePath.ToLowerInvariant();
            
                if (mediaFilePath.EndsWith(".wav") || mediaFilePath.EndsWith(".bwf"))
                {
                    string timeRefSampleRate = GetTimeReference(mediaFilePath);
                    // MessageBox.Show(timeRefSampleRate);
                    string[] array = timeRefSampleRate.Split('\n');
                    
                    if (array.Length > 2)
                    {                        
                        double samples = Convert.ToDouble(array[0]);
                        double sampleRate = Convert.ToDouble(array[1]);
                        samples = samples * 30/29.97;
                        
                        Timecode newTimeIn = Timecode.FromSeconds(samples / sampleRate);
                                            
                        media.UseCustomTimecode = true;
                        media.RulerFormat = RulerFormat.Time;
                        media.TimecodeIn = newTimeIn;
                        media.Comment = "Timecode from BEXT - NDF compensation";
                    }
                }
            }        
        }
        myVegas.Project.MediaPool.OpenAllMedia();
    }    
    
    static string GetTimeReference(string mediaFilePathTmp)
        {
            string exifToolParameter = "\"" + @mediaFilePathTmp + "\"" + @" -s3 -timereference -samplerate";

            Process processExifTool = new Process();
            processExifTool.StartInfo.FileName = @"C:\Program Files\ffmpeg\bin\exiftool.exe";
            processExifTool.StartInfo.Arguments = exifToolParameter;
            processExifTool.StartInfo.CreateNoWindow = true;
            processExifTool.StartInfo.UseShellExecute = false;
            processExifTool.StartInfo.RedirectStandardOutput = true;
            processExifTool.Start();

            string timeRefSampleRateTmp = processExifTool.StandardOutput.ReadToEnd();          

            return timeRefSampleRateTmp;
        }

}

hambonio wrote on 5/2/2024, 4:55 PM

@Noki Hey that works! I was about to say it made it worse until I realized I need to run the script on the F3 files and the other script on the other files. Also took me a minute to figure out why I was getting an error but I have the exiftoool in a different location so got that fixed.

Thank you very much for your persistence! I don't see any way to set NDF/DF in the Zoom itself, and I noticed when I try to go to the info screen on the timecode where apparently it might display that information the F3 completely freezes up and I have to pull power, or yank batteries to get it to turn off.

Now do you know how to fix that in Resolve? Just kidding.... If anything I have had success with XML transporting, and really don't know how to use that software much anyhow.

hambonio wrote on 5/2/2024, 7:33 PM

Also, from what it looks like it is not rounding the original posted timecodes to the nearest second. I am pretty sure what is happening is the F3 starts recording any track at the flat second, and not truly when you hit record.

Every time I match up to the second the old way, the audio was always within a frame of everything else. With so many recording tests I have done over the past couple weeks, you might assume that some of the audio would be off by as much as a half second, but in reality it has been nothing more than a frame.

NoKi wrote on 5/3/2024, 9:05 AM

I'm glad that it works now!

Regarding Resolve, maybe you should try to use drop frame timecode, not to have this realtime/timecode mismatch which has to be handled.

Nils