Just saw your post as I was writing the above. My suggestion--disregard file creation as shown in Windows altogether.

@wwaag Anyway. "The date format "yyyy-MM-dd HH:mm:ss" seems to be universally reported by MediaInfo, regardless of the local time format, and for that reason, I really don't want to change it."

Understandable, possibly a US author.

When I have this issue, my buddy has the knack of doing this quite a lot, so I have to adjust accordingly, although I am not without sin also :D.

So with photos I go by "Date Taken" in Directory Opus to align things up, I use the free program "EXIF Date Changer".

Up to now I just manually "fit" (using a leading number sequence) the remaining video clips into place with the still wrong date/time.

I see in DO using the Metadata tab that there is a "Release date" a "Date created" and "Date Modified" metadata fields. So for this particular case (I have an example of 4 photos and 2 video clips to fit) I used EXIF Date Changer to modify the photos and DO to change the video files "Date created" and "Date Modified" fields. I left the "Release date" as is, because if I mess up, (its tricky,) then I have an old starting point to go back to again.

Of course DO is not as fast as your new util, (DO's "Time Shifting" is ok once you get your head around it though) but there is that thing that I mentioned that adding the time amount means that it gets added, not to the modified time, but the created date, then shows as modified time. So an extra user calculation needs to be taken into account, ONLY IF THEY DIFFER. I found plenty of other video clips that did not differ, (ie Created date & modified date are identical) so using your util in that case is the way to go. So, important to first check if there is any difference in the video clips between the two dates. If none then your util is easy peasy. Thank you.

@JN-

"So an extra user calculation needs to be taken into account, ONLY IF THEY DIFFER."

That's the crux of the matter. I discovered that years ago with GoPro footage. The Encoded date is when recording "starts". The "File Modified" date is when recording ends. If you want the two to agree, you must add the duration. The problem is that not all cameras work that way and its the user that has to make that determination.

The "File Created" date is the date the file was last copied to a new location, and as such, bears no relation to the actual time the recording occurred (Encoded Date) or the time the file was last modified. The terminology is really confusing.

Regarding the app, it would be very easy to add a checkbox, when ticked, would then add the duration to the Encoded date. There's plenty of room on the UI. If desired, one could even change the File Created date to that time, although as stated before, I think that is pretty useless since its changed as soon as you copy the file to another location. In any case, I'm open to suggestions for changes.

@wwaag Directory Opus uses a "Release Date" for video clips. I'm pretty sure that that looks like the equivalent of "Date Taken" in photos. Not relevant to your app though, just in case anyone else is using it.

"Regarding the app, it would be very easy to add a checkbox, ..." Sounds good!

"The Encoded date is when recording "starts". The "File Modified" date is when recording ends. If you want the two to agree, you must add the duration."

Not significant, but with these 2 Xavc files, the subtraction value is about 2 seconds longer than the files duration. Maybe writing overhead of some sort. Not important.

I've put WIN 10 properties, Directory Opus, Mediainfo and WIN 10 Explorer in the screenshot. I incremented the original file ... "15 Hevc ....mp4" by 1 year 1 Month 1 Day 1 hour 1 minute and 1 second.

In Mediainfo, Encoded date/times increments just fine after adjustment.

The Directory Opus reported seconds for "Modified date" is odd. I see now that it's reflecting 1 second added to the original Created date and giving it to the modified date. i.e. Created date 51:36s becomes modified date 52:37s.

The Win 10 Properties dialogs for ("Modified date") seconds are odd. Same explanation as above ... Created date 51:36s becomes modified date 52:37s. Hours don't reflect change.

There are no seconds to show in Win 10 explorer, ("Modified date") so that' s ok but hours don't increment either.

The nice thing is that the DO "Release Date2" column reflects the changes via your util, (plus 1 hour). So it appears that "Releae date", as named in DO is reflecting the Mediainfo Encode date, (plus 1H) at least for this file. Some files don't display a release date after mod's, but most SOOC do. The plus 1h difference was already there between the modified date and the Encoded date, so it still works, sort of.

So I can use your util and in DO use the Release Date2 column for sorting, and I can also have seconds accuracy. But, now that I see the modified date/Created date seconds issue, maybe not

It is possible that the “Release date” (without UTC?) field in DO is similar to the “Encoded date” in Mediainfo.

@wwaag There appears to be a problem with the MP4 Date Changer when applying the seconds value.

This wouldn't have shown up on a test if the modified date and created dates were the same, but I used media where they weren't the same.

In essence when the seconds value is written to the Modified date seconds it's been taken from the Created Date value. I only found that today, see above post.

It's also there in my previous post, (I didn't see it then) previous page to this where I give an example of adding only 4 minutes 0s.

In the bottom left of the screenshot you can see the "before" Modified Date value of 42m:37s.

In the bottom right of the screenshot (where 4m 0s is added) the Modified date becomes 46m:16s. It should be 46m:37s.

It's picking up this 16s from the created date value and inserting it into the modified date value.

If the amount to change had been 4m:1s the result on the bottom right would have been 46m:17s whereas it should be 46m:38s.

Previous screenshot below ...

Can anyone explain why KwikProxy does not work in the 19th version of Vegas (sfvp0)? I mean files are created, but Vegas 19 does not use them. Even proxies created by vegasaur in Vegas Pro 19 "does not see" and the "create proxy" button is active.

Works fine here.

New Tool: Keyframe Adjuster

Just added a new tool, Keyframe Adjuster, which enables the user to adjust the position of all pan/crop keyframes for a selected event. Here's the UI.

It works in two modes. In its simplest, the user can change the position of all keyframes by a constant amount--e.g. adding or subtracting 2 sec from the position of all keyframes. In the other mode, and the motivation for writing the script (https://www.vegascreativesoftware.info/us/forum/how-to-lock-keyframes-to-actual-clip--132422/ ), the user can adjust the length of the event and keyframes will be adjusted to maintain their relative position in the event.

A demo can be found at. https://tools4vegas.com/wp-content/uploads/KeyframeAdjustDemo.mp4

Update: MP4 Date Changer

Additionally, the utility MP4 Date Changer has been updated with new features including: the selection of a timestamp source, the use of Windows time rather than time as reported by MediaInfo, the option to add or subtract the length of the media to the timestamp, where to write new timestamp information, and the option to add a comment to the file's metadata. The new UI is shown here.

Bug Fix: MP4 File Joiner. This utility now works with non-English versions of Windows.

Bug Fix: Zoom Tools. Fixed a bug in the Zoom Config script which led to a Vegas crash in some installations.

All tools may be freely downloaded at https://tools4vegas.com/library/

@wwaag, I am using the SlideLeft and SlideRight scritps and found that Auto-Ripple is not executed after invoking the script. Auto-Ripple ON or OFF, only the selected event moves, remaining event in the timeline do not move. Is this a limitation of the scripting engine or is there a way to respect Auto-Ripple with script actions?

@Illusion

There is no Auto-Ripple setting in the current slip-slide set of tools. You may be using an old version before the update earlier this year.

Here's the link to the new version. https://www.vegascreativesoftware.info/us/forum/happyotterscripts-free-tools--118349/?page=3#ca802099

I was using older version of the scripts that were .cs text scripts. This had the advantage of being assignable to a keyboard shortcut where no interaction with the mouse was needed. I duplicated those scripts to have 1/2s and 1s slip and assigned to a keyboard shortcuts. Can no longer do that with the new version.

@Illusion

Sure, you can. First, copy the scripts to the Vegas script menu folder. As shown, I created a new folder and copied all of the slid/slide scripts into that folder. If Vegas is running when you add the scripts, make sure that you run "Rescan the Script Menu Folder" from the dialog first.

Then go to Customize Keyboard and search for Slide (In this case, that name was also in the folder so all scripts are shown).

Then select and add whatever shortcut you wish. Make sure that Global is selected. That's all. You can launch any of my (or other) scripts using this procedure.

Thanks for the response. Assigning keyboard shortcuts was fine. What I did not understand from you new scripts is the config pop-up is not invoked each time a slip or slide is invoked. This is good. However, these newer scripts still have the same issue that if I slide an event on a track with Auto-Ripple set to ON, only the selected event will move. The ripple is not executed. The other events down the track do not move, not respecting the auto-ripple. If I move the event with numpad 1 or my mouse when auto-ripple is ON, all events down the track will also move. This is not happening with your script.

@Illusion

Now I understand what you mean--you're referring to the AutoRipple setting in Vegas--not something that was part of the script. In some of my scripts such as "Insert Freeze Frame" and "Set Event Length", I've included an AutoRipple option within the script itself. The scripting API does not have access to the AutoRipple function in Vegas so the only way to AutoRipple is to include it in scripting which can be a real bag of worms (just like AR in Vegas which for the sake of safety, I always turn off).

As a workaround, you can select all of the video and associated audio events to the right of the event you want to slide and they will follow along.

OK, thanks. Your suggestion of selecting all events make sense. I even modified one of your script to select events from cursor but only in selected track, not all tracks. I added this continue statement after the first foreach loop

// step through all the tracks
                foreach (var track in vegas.Project.Tracks)
                {
                    if (!track.Selected) continue;

This way, only the events in the selected tracks are selected, not all events from cursor.

New Tool: Regions to Projects

Just added a new tool, Regions to Projects, which creates nested projects from regions, the selection loop or selected events. Here's a screen grab of the dialog.

And a short demo.

And a link to the original thread requesting such a capability. https://www.vegascreativesoftware.info/us/forum/convert-regions-to-nests-simples--133448/

It is now available for download in the Happy Otter Free Tools Library. https://tools4vegas.com/library/ It is only available for Magix versions of Vegas.

Let me know if there are problems or any suggestions for improvement. Happy New Year!

@wwaag, first, Happy New Year!! HOS is amazing.

Now for the n00b question, how do you add it to the OtterInfoBar?

Very easy. Find an unused spot on one of the OtterBars and right-click. Then select Add Script Action in the context menu which launches the Open dialog.

I would suggest creating a folder where you save your freebie scripts rather than using the default HOS script location folder where all of the HOS scripts are located which is C:\ProgramData\HappyOtterScripts\Magix Vegas Pro\Scripts. In the event of a clean HOS install, you would lose those added scripts. Or you could just use the Vegas script menu folder, in which case, it could be launched from either an Otter toolbar or natively in Vegas.

New Tool: Show Proxies

Just added a new tool, Show Proxies, which simply shows all media files that have a Vegas-style proxy, that is, one with an sfvp0 extension. It also creates a Media Bin titles "Proxies" and adds all files with proxies to that bin for easy tracking. Here's a screen grab of the message box.

And a short demo.

And a link to the original thread suggesting the need for such a capability. https://www.vegascreativesoftware.info/us/forum/how-to-see-in-vegas-if-a-proxy-exists-for-a-media-file--134207/

It is now available for download in the Happy Otter Free Tools Library. https://tools4vegas.com/library/ It is only available for Magix versions of Vegas.

Update: Vegas Render Quality

VRQ now supports the new CuminCode FrameServer (CCFS). If CCFS is not found, it then resorts to use of the now deprecated DebugMode FrameServer (DMFS). Note that DMFS no longer works in the the latest builds of Vegas 19 and Vegas 20.

The new version can be downloaded at https://tools4vegas.com/render-quality/

New Tool: Interlace Detector

Just added a new tool, Interlace Detector, which can aid the user in determining whether a media file is progressive or interlaced.  It first provides information from MediaInfo.  It then applies the FFmpeg idet filter which tries to detect if the input frames are interlaced, progressive, top or bottom field first. It will also try to detect fields that are repeated between adjacent frames (a sign of telecine).  Single frame detection considers only immediately adjacent frames when classifying each frame. Multiple frame detection incorporates the classification history of previous frames. 

Here's a screengrab of the dialog.

My interest stemmed from the observation that sometimes, the metadata is simply wrong. For example, the resulting files using interlaced mpeg-2 encoding in FFmpeg are shown to be Progressive in MediaInfo and other apps including Vegas. A closer examination using the FFmpeg idet filter revealed that the encoding was correct and that they are indeed interlaced. The metadata is simply wrong. Likewise, for avi files, there is no metadata indicating scan order.

Here's a direct link where it can be downloaded. https://tools4vegas.com/interlace-detector/