What is that hypothesis based on?

Rename the proxy file to a .MP4 extension and it works perfectly, both in every media player I tried and as a file dragged back onto the timeline, where you can proxy it again if you want.

If you drag it into a 29.97fps Project, Studio asks if you want to change the project to match the 23.976fps media, because that's what it is.

So MediaInfo is reading all the correct information from a file that's at the wrong framerate for the project.

It can't just take a 23.976fps proxy and 'adopt' it to a 60fps project. Well it could, but the results would be pretty skippy, with every frame having to be more than doubled. So the whole point of 'smooth' editing playback would be lost. Also cutting on specific frames would be hit'n'miss.

Alternatively, when you Prerender files, the segments already have a .MP4 extension, it also used XDCAM EX 35 files (at the size and quality you select) and all the other information in the header is correct i.e what you chose when you selected the Prerender files template.

If the only bug is that Vegas Studio puts the wrong information in the .svp0 header (along with all the other correct information?) it's still a bug.

My money is on the information being correct and the framerate is wrong because that's what the data shows.
 

It is not a bug. It's the way the Vegas Pro/Movie Studio proxy workflow works. The SFVPO files are solely meant to be used in the background of the proxy workflow. Any other use will break the way file properties will be correctly handled.
The header information of the SFVPO files' frame rate doesn't count in any way because it is not used by the workflow. It's what I said above. The fps information is not taken from the SFVPO file but from the source file. You can't/shouldn't use the SFVPO files themselves. The proxy workflow isn't designed this way.

There were official statements about it given by SCS staff when they introduced this proxy workflow. I can't find that ones at the moment but take a look at this information from Satevis.

So that SCS statement is pretty old?

Maybe making the resolution small and having fewer frames made sense way back when :
a) People didn't care so much about quality and were just happy to have faster scrubbing speeds.
b) CPUs and GPUs were slower, and
c) HDD space was expensive.

None of those apply any more.

Other programs that create proxies only adjust the bitrate and resolution, never the framerate.

It certainly is a bug if they think that using a proxy with a single frame rate of 23.976fps and conforming it in realtime to every other project framerate is a good thing. It'll produce inaccurate results on specific frames and it's probably more work to stretch the frames across the project's actual framerate than simply fetching the correct frame from a file. That's partially invalidating the whole point of keeping playback efficient and smooth running.

Incidentally, I created a Prerender file (with the correct 29.97 fps framerate), renamed it to have a .sfvp0 extension, and used that to replace the original proxy file. I had to make it of a clip that was only 300 frames long though, as that's all Prerender segments will render.

It worked perfectly as a proxy file and Studio didn't even notice what I'd done as .sfvp0 files are just ordinary video files with a different extension.

I guess I'll have to find an external program to create frame-accurate proxy files instead of using Vegas itself, which is disappointing.

Edit: Silly me, of course I can use Movie Studio to create it's own proxy files by rendering them all out in XCAM EX 35 format before I start. A waste of time, but doable.

It's bad enough for Vegas Movie Studio to have this problem, but I can't imagine it's helpful when using Vegas Pro.

The given proxy workflow is absolutely frame accurate. I use it for years now since it was introduced with Vegas Pro 12.
The only magic is to use it the way it is meant. ;)

It's bad enough for Vegas Movie Studio to have this problem

MS has not this problem, your unnecessary workflow/workaround creates this (yours only) problem.

Can you produce some evidence of that as it's not possible to confirm that if there are fewer frames in the proxy than there are in the project file it is a proxy of?

You already said if the project was 60fps, the proxy would adapt to 60fps, using only 23.976 frames to do so.

So, while it may cut the frame correctly in the actual Good (real) version of the video, you won't necessarily be looking at that same frame in the Preview view.

A simple test would be to have a timecode or individual frame numbers on a video, proxy it, then watch the playback and switch between Preview and Good to switch between it using alternate files types.

I guess I'll just have to go and do that then... but I'm currently looking through the various .ini and .cfg files to see if I can find where the proxy file specs are stored, as poking them directly to be correct would be a good deal easier than the alternative.

It's bad enough for Vegas Movie Studio to have this problem

MS has not this problem, your unnecessary workflow/workaround creates this (yours only) problem.

There are 23.976 fps in the proxy file. That's a verifiable fact. Go on and do it yourself, if you don't believe me.

How is that useful when editing 29.97 or 59.94 video?
What would be a good reason for it not having the same frame rate as the source file it is a proxy of?
If that reason is so good, how is it that no other editing program does that and instead has the same framerate in their proxy files?
Is everyone else doing it wrong, or is there some actual advantage, and if so: what is it?

Go on, I'm genuinely interested in valid arguments.

"You already said if the project was 60fps, the proxy would adapt to 60fps"

Nobody said this. It's not the project frame rate which is used for the proxy fps, it's the source frame rate.

The reputative problems always start when people try to use the SFVP0 files. Just leave them behind.

The easy way to proof that frame rate of proxies are accurate to the source frame rate is using the proxy workflow for clips which frame rate differ a lot from 23,976.
Use a 60 fps source clip with fast motion in it. Create a proxy. Use the proxy workflow (and this means: Do not use the SFVP0 file!!!) while you step through the timeline frame by frame. Depended how resampling is set you would either see doubled frames or frame blending if the proxies really would use 23,976 fps. Neither of it happens. Proxy's frame rate will equal source's frame rate.

I don't know about how you work, but I generally have my project file set as the same rate as my source file, so in my case they're the same thing. Yes, I can mix footage speeds, but generally don't and did not in this test.

I start with a 29.97 fps source file in a 29.97fps project (same..) then I proxy it and get a...23.976fps proxy file.

So, yes, stepping through in GOOD or BEST mode would show frame blending if you'd stretched your footage, but have you ever seen it in PREVIEW or DRAFT Mode? No, because it doesn't do it in those modes. Never has.

And that is main reason people complained about Resampling being on by default, because they only saw it on their final GOOD or BEST render and then had to go back and turn off Smart Resample on all their individual clips because they forgot to do it before they cut them up.

So you'll ONLY see doubling and not Blending, because Proxy files are only used in PREVIEW and DRAFT modes, so....no blending. And I'll bet you wouldn't spot doubling unless there were numbers on the frames.

Which is why I explained what you'd have to do to detect it.: timecode or numbers on the frames.

Don't worry, I'll do it to prove what I'm saying is correct, rather than pulling guesses out of the air, but I'm busy right now on something else.

If you'll touch the SFVP0 file you'll never get the right result.

You could download this zipped demo project which already is set for the proxy workflow.
Unzip, open the Movie Studio project file, set your preview to "Preview/Half" and step through the timeline frame by frame.

If the proxy file would be used as 23,976 fps, each single frame would be repeated 5 times. But it is frame accurate to its 120 fps source file.

Tempest in a teacup. Instead of repurposing the internal proxy, use Render to New Track instead. You can set the parameters any way you want.

There are 23.976 fps in the proxy file. That's a verifiable fact. Go on and do it yourself, if you don't believe me.

Every videofile with whatever framerate swiched to a proxy file has, after renaming the sfvp0 file, that particular framerate.
But that's not the way the proxy workflow works.
If you like to rename them and used them as "normal" video files is your bussines and also your problem. It's not the way that workflow works and probable you refuse to understand that. So help yourself.

There are 23.976 fps in the proxy file. That's a verifiable fact. Go on and do it yourself, if you don't believe me.

Every videofile with whatever framerate swiched to a proxy file has, after renaming the sfvp0 file, that particular framerate.
 

What does that mean? "That particular framerate"? Are you just not getting that I did not set the frame rate and that it is different to that in the source file it is a proxy of? Do you think that renaming the extension of the file changed the framerate data stored in the header? Edit: Oh you mean they'll all have that same wrong fps whatever the original was? Yep. Sorry, I was still playing with the proxy project file from @Marco file when I wrote the first half of this post.

@MusicVid, good idea, thanks. T-in-a-T it might be to the incurious, but I like to know what's happening and I also want the Smart Resample Options back. Roll on the April update for those...

BTW, @Marco, I downloaded your file and when you rename the proxy file extension, then drag it into the project at a matching 23.976fps, it is 5 times longer, which means all 120 frames per second are in there.

Which means: The bug is (and I said it was an alternative possibility) that the header information that contains the framerate is wrong. Whoever wrote the proxy file exporter, just threw 23.976 fps in there whatever the actual frame rate is, just to have a number there.

It might as well have been 1 fps because it ignores that and just uses the actual frames themselves.

OK, so now it's been confirmed that I'm not losing frames, that's great. 😃

Thanks for all your help, everybody.

SCS could have saved us from lot of confusion if they'd made this SFVP0 files invisible … :D

I'd still have wanted to know what the resolution, bitrate and codec setting were. 😉

I'll do some tests on the performance, but now I know I'm not losing frames, they it might actually be useful to take them and use the files as proxies for other programs. All I'd have to do is rename the extensions and have the program override the 'incorrect' internal framerate in the header. I'm not a fan of DNxHD and ProRes needs Quicktime.

@Marco. "saved us"??????
No, saved some, who are, like we call it at home, "hardleers".

@Cornico no one was twisting your arm to come and spend your valuable time commenting here. 😜

"I'd still have wanted to know what the resolution, bitrate and codec setting were."

All this information is in Satevis' post I linked further above.

If you want to use proxy-kind files in other tools you'd much better do a regular render. Render to XDCAM EX and you'll get same compression/codec as used for the Vegas/Movie Studio proxy workflow. Or just use a different proxy workflow like the ones Vegasaur offers.

No problem about my time, I always love it to spend time reading people who think to be more clever than others.😄