Russ Croucher

Actually, digital 8 and mini DV are recorded at 30 Hz non-interlaced. So even running handbrake in the end you only need to do 60 Hz at most. I'm of the argument that your brain can't really see any over 30 Hz in gamers like high-speed refresh because of the latency of the video processing which is smaller on the higher-speed. So therefore they get faster response time in the computer. I was never much of a gamer because writing code in the Nvidia graphics engine may it seem like I was going to work. So I argue that running de-interlaced on 30 Hz is okay. I did run into a problem that if you're going to image stabilize digital 8 or miniDV with these later versions (later than version 8.95) you must say it is interlaced with the lower field 1st in the image stabilization part. Because handbrake also must be informed that is interlaced otherwise you can visually see a problem in the video.

I specifically chose a problem with moving video in the front so I can easy determine what version was the problem. That way I used a binary search to figure out what version 1st because the problem. Now I'm in the process of trying what to do all the customers I have digital FireWire files that were not processed correctl -0-0- I have a good workaround that seems to work fairly reliable until video pad comes up with a better solution. I always run the final product through handbrake and normally I keep interlace turned off for digital 8 and mini DV. But turning it on solves the problem. Again here is my cloud example that was a problem and I ran it through handbrake with interlace detection turned on. The problem goes away. Except for the last frame which is only 1/2 a frame in the interlace shows up that is correct and all other frames. https://1drv.ms/u/s!AuSetTxgq7JxqYoPFVOsOPXWtIeVHw?e=e32NxC

I have discovered a new problem with video pad. Being a software engineer I figure out what version I have that the problem 1st occurred. Version 8.97 was no problem. I 1st detected the problem with 10.04. This goes always back to January 2021. So all video pad versions after January 2021 writing digital files that were progressive is written as interlaced. Here are 2 short videos that shows the problem. I also included the source file and the project that I used to create these files. The final project version had been changed from version 12. So I changed the file to make it version 11 and it did load fine. Here is my cloud link to the 4 files. https://1drv.ms/u/s!AuSetTxgq7JxqYoPFVOsOPXWtIeVHw?e=e32NxC The source AVI is 8 GB so it will take a while for my cloud to load it. But you can look at the problem. Now I need to go back and figure out what customers are affected by this problem.

I support all resolutions from 640 up to 4K. I just chose the procedure of 1920x1080. Since I have lots of workstation that are extremely fast with lots of memory. So I get no slowing down with HD videos. But I have noticed that 2K seems to be the best resolution for speed. But because I am key stuffing keys into video pad I am limited on certain control loops and stuff like that in my batch procedure so I had be very specific about the keys I'm stuffing in the procedure. That's because the loss of focus from Windows of the where you're stuffing the keys. You have to stuff keys into the active process. So last year when I did all this manually I said the next year I will have a procedure that completely automates it. So I will be trying it out tomorrow at the beach.

I now have a nice solution that uses videopad to reduced large 4K videos to smaller HD during the editing process. This keeps video pad from buffering large 4K videos and not getting any work done. Here's how the solution works. The drone videos that I have only produce one video stream with no audio. However, the video pad likes to have a 2 streams with video and audio. So the solution is to read all the MP4 files into the computer and automatically write 4K video files back with two streams using video pad. It also loads all the files again and writes them to a different directory using 1920x1080 resolution (HD). Then the operator renames this smaller directory to the working directory so that all editing of the video pad files operate on this generic directory name. That way, all buffering is done with the smaller resolution files and video pad is very fast. Then for the final rendering process after all editing is completed the high resolution directory is rename to the working directory and the operation is run one final time with 4K video. Here is last year's video September 2021. I did all manually last year and now have I have a nice procedure. https://www.youtube.com/watch?v=ssVow_wpWRU Here is a link to the processing files. I use TCC_RT which the superset of CMD and free to download. The development version is like $100. https://1drv.ms/u/s!AuSetTxgq7JxqYgXcNNpmfvV3OnJ_A?e=YSDZd6 This uses v11.73 of video pad.

Okay I have narrowed down 11.86 crashing. It seems to be related to building the cache file. It also seems related to the lossless video export which it would use with the auto match input content. It does not crash when force, a reencoding here is the project file and the input MP4 I use for the problem. https://1drv.ms/u/s!AuSetTxgq7JxqYd4deGiMXWutrhBgw?e=WklRsu Let me explain what my batch file does as I did all of this without it just to make sure 11.80 works fine. When video pad loads up a brand-new file video is loaded 1st and the audio is loaded 2nd. Other things are going on in the background which I do not understand but my batch file specifically does nothing until video pad execution stops. At that point it starts loading up the exports. I have noticed that 11.85 and 11.86 the processor is used much better and faster whereas 11.80 only about 50% of the processor was used. After my lunch here in the states today I will make a bug report. I have noticed this problem with 11.85 and 11.86 only. After reviewing the problem with the sequencing I do believe that it should default to auto match input content. That would save me a lot of down arrows in the export.

I just tried 11.86 and it is also crashing in the export. So I need to document exactly what I was doing so the developers will be held understand what I was doing. But using the exact same program with 11.80 and 11.73 no problem. So I'm not sure what the batch files doing that doesn't like. I will keep working on. I have not added the control-shift-X yes in the sequence yet. I'm still doing the down arrows.

With 11.85, I was successful with 11.80 I'm going to stick with 11.73 until we have a successful version that works with this new commands. With the 11.80 they took out the ability to bring up the recent filenames and that's probably was the reason they added 11.85 to add my new key sequence control shift X. But 11.85 seems to be crashing and not sure what to do. So for now I'm sticking with 11.73. v11.80 keystack Alt f Down Down Down Down Down Down Down Enter Enter Enter tab tab tab Down Down Down Down Down Down Down Down Down Down Down Down Down Down Down Enter Enter Enter v11.85 keystack Alt f ctrl-shift-X Enter Enter tab tab tab Down Down Down Down Down Down Down Down Down Down Down Down Down Down Down Enter Enter Enter As you can see in the sequence above 11.85 does allow me to reduce a few keystrokes. However, the bigger one would be in the file export to move the auto match output to the same as the input. As you can see in the export command I need 13 down arrows to get what I need. It would be nice they move that up to write below the output so I would have to scroll through things I don't need or if they add one I would have to change it. It is nice that the 2nd and 3rd sequence to match the 1st sequence output. Actually in looking at the export all sequences format I would think you'd want to "auto match content". So this is questionable an unusable feature. I would think you'd want to match it. This is something that the software developers should think about.

I also want to point out that last week I was try to use that program Windows 7 and did not work because the number of keystrokes to get to the export all sequences must be a little different with Windows 7 over Windows 10. My solution to the problem then was just use Windows 10. So I never really looked into the actual problem but I know it did not work with Windows 7.

That is so cool that will give us a perfect reason for us to upgrade from 11.73 to 11.85.

Yes, as a general rule I do that. This last version was 10.78 I was using which was last fall. I figured it was time to upgrade. It seems like most the problems I ran in the last few months have been fixed. That particular batch file, I have a way of making the problem down to just several minutes so it doesn't take me very long to realize what version was the problem. I fixed the problem that's probably good for another year.

I had to update my split procedure again(split_1.3) because video pad changed their menu selections in version 11.38. I do not have a key for export all sequences yet and therefore had to increase my key stuffing by one more down arrow on the main selection. I requested that they give an export key for the export all sequences but have not seen nothing yet. From this procedure I need a key sequence so I can specify the output file type. In all cases I need to match the input resolution. This is actually the default if you don't have a project. However, a project overrides the default. If they were to move the auto match resolution to the top of the export list the problem would go away. However, a project file overrides the default export. Here is the link to my procedure again. This is specify higher in the thread. https://1drv.ms/u/s!AuSetTxgq7JxqOlcv7dQq5pVLdP4Jg?e=kUNGYH Here is the latest export and I had add several down sequences to accommodate the auto match export rem start videopad project loading the file with sound before continuing start %fname%.vpj gosub :waitVideopad rem we have no key shortcut for "export all sequences" keystack Alt f Down Down Down Down Down Down Down Down Enter Enter Enter tab tab tab Down Down Down Down Down Down Down Down Down Down Down Down Down Down Down Enter Enter Enter rem wait for videopad to export both sequence files gosub :waitVideopad rem quit videopad without saving keystack /W9 alt-F4 /w9 tab enter delay 5 thoughts?

I will migrate to it as I'm currently using the latest release 11.70. This is only a problem to me when I was using FireWire the pinnacle not with debut.

I don't see that at all. How are you testing this? I take the file "dv7ks.avi" on the one drive above and load into video pad with Windows 10 and using version 11.63 and hit the play button and it says "we are boarding a plane to China" with no problem. I then stabilize that file and the result is the audio is 2x.

It may have something to do with the fact that stabilizer produces AVI files. I have seen no problems with the audio if I read the AVI files in video pad and write it out as an AVI files - the audio is correct. You can see this in my example above I created "dv7ks.avi" the original file from pinnacle. Then I used v11.63 to write the exact same file, no changes, to "dv7-full.avi", where the audio is still fine. I use that base file when I image stabilize it with 11.63 The audio is 2x. At least we know it's being worked on. I will say back a few versions until I hear from you guys.

I have a business of converting files for customers and pretty much use video pad for most of my processing. Because of a previous problem that was discovered and fixed in 11.48 I have not upgraded to the latest version because the problem did not occur in 10.78. A few days ago I decided to upgrade to the latest 11.63 since I was having no problem that I can determine up to this point. Normally I use debut to capture videos with audio from a Matrox card. I do it this way because even though I can write MP4 crowed in the Matrox card I would rather use support that you pad uses with H265. The problem occurs during the image stabilization when the AVI file that is run through video pad was not created by and NCH product. I'm assuming somewhere in the header something is not correctly read and the wrong value is used for the audio. The audio axis sounds like some chipmunks but you can discern what they're saying. So the problem occurs when I use a digital 8 or miniDV to input the video file with FireWire. Since I have not been able to get FireWire to work appropriately with video pad I use a pinnacle 25. I prefer video pad for processing but pinnacle 25 dozen nice job of collecting the FireWire file. I then hand the FireWire file over to video pad to read the file in its entirety and image stabilize it. This must be done in Windows 10 because Windows 10 fixes a bug that was in Windows 7 that read the 720x480 file aspect ratio incorrectly and video pad loaded it as a 640x480 file. After the image stabilization occurs the have temporary file that video pad uses sounds like chipmunks. I have a complete folder list of the original file from pinnacle along with the same file read in and written now with a version of video pad both going to the image stabilization and the file that was from pinnacle sounds like chipmunks but the file that was from video pad is fine. Some somehow the processing of the file in the image stabilization is incorrect with the audio. Here is my cloud link with all the files. Should I send this as a bug request or is this link good enough. The original files were done with the 11.63 but I did verify it with 11.64 the same problem exists. https://1drv.ms/u/s!AuSetTxgq7JxqYQ_XUHkArRWvoS0LQ?e=xMKybO You will notice in the link "dv7ks.avi" is the original file from pinnacle. The file "dv7-full.avi" the original file from pinnacle rewritten with video pad I useg 10.78. But I think any version would've worked. Then you had 3 stabilize files that 10.78 was fine with any version and 11.63 was only okay with the version that was rewritten by video pad Tell me what I should do.

Yes that is exactly the problem! I have written lots of code that is backwards compatible but never forwards compatible. We can support all older versions of data using this version concept. However, sometimes we cause a problem with the latest version and customers like myself need to go back to an older version that works in our situation. Let's look at my particular situation. We currently have a beta version 11.48 which seems to work fairly nice and fixes some problems. However I am not using it yet because I'm still testing to make sure all my software will work with the latest version. I am currently using 11.78 from back in September. Why? Because 11.86 has a problem that the (CTRL-A) key sequence does not work and 11.87 is the 1st version that has a timing problem in the stabilization that you fixed 11.48. So until I'm absolutely certain all my software will work correctly in 11.48 I cannot upgrade yet. However, in the testing I have a problem because the data file with the latest version goes to version 12. Changing it to11 looks like it should work for my workaround. So working on these large projects, sometimes we inadvertently cause problems on something that has worked for years when trying to introduce newer features. The testing of these larger products can be very difficult. Our test groups took great pride in finding our problems that we did not catch in the developing of the software.

I was having a problem with video pad and image stabilization audio issues with an earlier release 11.38. So I created a thread to discuss the problem Image Stabilization Audio bug in latest version 11.38 This new version solves the problem. However, it produces a larger problem. Video pad project file that has been version 11 for 3 years and has been change to version 12. Probably some addition that only forward compatible. Version 11 has been around since video pad 7.11 dated June 2019. I understand software and we have to make things forward compatible people think we won't go backwards but users cannot afford to upgrade unless we are positive it will fix our problem. So by going to this new version we cannot go backward at all. Once the file is saved it'll be saved as version 12 and none of the previous versions can read it. Is there an internal program that can convert version 12 down to version 11? This would be very helpful. Last time I've seen this problem was in January 2019 with version 7.0. I want to stay current but I must also have to have some ability to use previous versions. If a problem arises.

I switched away from H264 while ago and now only use MPEG4. It seems be more constant and it's only an intermediate step for me.

Good news! IT WORKS! Here is a link to my current videos with the latest version working. https://1drv.ms/u/s!AuSetTxgq7JxqO5U0xD-ZpcY7rtceQ?e=JkqanM So 11.48 works great.

I currently have an older version of this program around v8.09. They've been advertising the newer version and I tried 10.15 today to see if it supports 16 bit TIF files. This would be 48 bit color which the program sees clearly and displays at the 48 bit color depth (16 bits per color). However, when I do a simple horizontal flip it outputs the TIF file as 24 bits or 8 bits per color. Are there any formats that support 16 bits of color or 48 bits? Right now I'm using an open-source program called "mogrify" which will do a TIF file in 48 bits but does not support the directory structure of your program. So I can use your program for JPEG which is limited to 24 bits but not TIF which is 48 bits. So does the new version support this format or can I turn it on. Nowhere in the documentation do I see it supporting 48 bits. Yet send supports raw format which is like 14 bits per color. When will it be available?

The link above has been updated to include the latest version 11.38 with stabilization in MPEG-4. The audio is most noted at 58 minutes into the file. It looks like it's off a good half a minute. This produces the same result with all versions prior down to 10.86 which works fine. 4/7/2022 - Posted 11 minutes ago I also want to make note I copied a DVD (drag-and-drop) with the later versions of video pad 11.38 and the audio was also screwed up. But everything working fine with the 10.86.

Unfortunately I have bad news. I was able to solve the J9 file with using MPEG instead of H264. However, that did not fix my J18 file. The latest version no matter how I configure it seems to give me the wrong audio output. So I took it on myself to use all my computers and figure out what version it works and where it's stopped working. As it turned out every version before 10.86 work fine. That means sometime in September 24 to September 26 of last year 10.87 fails. All version since then do not give the correct audio output. So something has changed. Below is the link to my cloud space that has all the files I'm referring to. I have a file called "j18-org.mp4" which is the original file. I will add shortly the output of the last latest version of 11.38 which shows the very much delay in the audio at 58 minutes into the file. So at this point until the bug is fixed I will stick with version 10.86 which seems to work okay from last year. Bug fix list that seems to imply what is in current versions are so I can make some decisions about do I incorporate this later version, or wait? https://1drv.ms/u/s!AuSetTxgq7JxqO5U0xD-ZpcY7rtceQ?e=JkqanM

I started with the full version with 11.08 and noticed the problem when the teacher was speaking at 11 minutes into the file. So then I took that file and cut it down to 12 minutes with a lossless export and then when I re-stabilized it with 11.38 it worked fine. So I thought maybe the problem was fixed. But then when I went and redid the full version with 11.38 it the problem still existed. I may try it again with the full version and different encoder output and see if that fixes the problem. I know that happen one time before and we standardize on using MPEG for a while the bug in a later version. I will keep you posted. Lucky me I have lots of computers for this testing. -0- Good news! The MPEG encoder works fine. My problem is specifically with the H264 encoder. So if you set the options to MPEG it all works. So from now on I'm just going to leave everything set the MPEG. I've updated the link above to show the 2 full files one with H264 and 1 with MPEG if you want to review.

I'm experiencing audio irregularity in the latest version of video pad 11.38. I 1st thought the problem was fixed with this version because I I only noticed this at 11 minutes into the file of this particular video so I created a lossless version at 12 minutes and stabilize that version. The problem seem to work fine so I assumed latest version fixed the audio irregularity. However, when I stabilize the entire file of 54 minutes. The audio situation came back. So I'm looking for a way to solve this problem temporarily and maybe you guys can help. The link below are the 4 files that are the raw versions and the image stabilize versions under 11.38 with Windows 10. Maybe you guys can help. https://1drv.ms/u/s!AuSetTxgq7JxqO5U0xD-ZpcY7rtceQ?e=JkqanM