When you said next version did you mean CC23 or some other next version. What is the actual status of this request. Can we get an update from Adobe?

This is again half a solution. The proxie should take the frame rate of the original file and when we choose Interpret Footage, it should change to that value.

I make my proxies at the beginning of my project without knowing what framerate I will use some clips in. There is simply no time to wait 15 minutes to make a new proxie for each clip I want to slow down.

Thx for taking a look at this.

Hello Fergus, any update about the right way of fixing this problem? Your proposed solution is not the right one.

The right solution is quite easy: create proxies WITH THE SAME FPS OF THE ORIGINAL FOOTAGE. Then Interpret footage the same way both for the proxy and the original file!

I'm still unhappy that this stopgap fix isn't actually the real solution, but... it's better than a hole in the head and I'm using it today, as noted in the release notes for Media Encoder v22.6. Um... it doesn't work. I've interpreted some 59.94 and 29.97 fps clips in premiere to 23.976, and then sent them to ME to make proxies, and ME is continuing to read and render them at 59.94 and 29.97 respectively, rather than 23.976. Am I missing something?

Hey Adobe, you LOVE to say stuff like "please be nice to us, we're doing the best we can" but when you go and do something as wildly dumb and insane as this it makes it practically impossible for us to take you seriously. You can't take 4 years to fix a SIMPLE AND CRITICAL bug in your software and tell us that you're doing the best you can. You have to do much MUCH better than that if you'd like people to not make fun of you.

Right now, this is simply a joke and a slap in the face. So don't be offended when we reply with the same. You deserve it.

Very simple issue that needed to be addressed years ago. You should be able to import the footage, create the proxies, and then re-interpret the footage any way you want while editing without having to worry about proxies and without having to re-encode them each time you want to change the framerate in which premiere is reading those files...

Please it should be as simple as Premiere reading the proxies in the same way it's reading the original file.

We need to be able to re-interpret the footage on the fly without having to worry about re-encoding proxy files.

Proxies should be an exact copy of the original file in a lower resolution, am I wrong? So why are you working on a solution that doesn't solve the issue users are having? Do you guys really think that encoding proxies with different framerates than the original file is right? Do you really think that's a solution? Please address this asap its been years of having to deal with this annoying proxy workflow. It's a waste of time.

Samuel Neff: Tough but fair. You're exactly right.

Fergus, do you guys understand the problem we're having? There's no issue with creating proxies that needs to be fixed. Proxy creation is solid. The issue is that Premiere can't seem to treat the proxies the same as it treats the original media.

After many years of using a proxy workflow, I'm happy to report that this issue is no longer a problem for me because of my new system. I'm able to cut 6 angle, 4K multicams (gopros, sony a7s iii, and sony FX 9) with almost zero lag. No proxies used at all.

This was unthinkable before. I upgraded to the new Mac Studio, but after a lot of research, DID NOT opt for the top tier processor because the performance difference was so small for the money.

Just wanted to share my setup. See attached images. This new system is worth every penny.

Amazing. I'm the original person who posted this "idea" for Premiere Pro over 4 YEARS ago. Realistically, this should have taken 3 months for Adobe to see and fix this in a bug fix update. In fact, this was ignored for so long that I stopped my Adobe subscription and moved to greener pastures. Now Adobe is finally addressing it by...putting duct tape over it, and leaving the original headache entirely in place. All the other comments in the last day are hitting the nail on the head. This is not a solution. "whatever frame rate entered in Interpret Footage will be used by Media Encoder to create proxies" is NOT a solution. Any video editor can (and has) explained this below. Adobe needs to do better, and I'm not waiting around to see if they do. Bye.

It’s great that Adobe attempts to fix this issue but like the others have said it should create the proxies at native frame rate and interpret them as set in the project

I have to agree with the previous post that the proposed fix sadly does not seem suitable. It would be nice to change the behaviour of Premiere/Media Encoder to the expected one.

I add my protest to the other ones: this is not at all the solution has been asked by 200+ people here since 2018. Proxies should just behave like the real files, whatever you apply to them. I would prefer Adobe to take more time to work on the real solution (which is still for me the major problem on Premiere Pro right now) rather than this fake fix which will delay the real fix needed for who know how many more years...

I agree completely with these other posts. This proposed fix sounds like it will create more headaches. Proxies should be a clone of whatever the original source is. Premiere should apply interpret footage settings to the proxy as they’re being applied to the original source.

This proposed fix is good in as much as it makes the current method of working around the problem a bit easier to do, but it's more like automating the workaround than fixing the issue. What needs to happen is for proxy footage to behave just like regular imported footage whereby you import a clip and make decisions about it while editing, those decisions might include interpreting the playback speed to a particular framerate, they also might include changing that playback speed again, to a different playback speed, (maybe you chose the wrong one by mistake).

Ideally using proxies should be a mostly invisible process after the import stage of a project. You shouldn't really need to think about them, and the only consideration needed for using them once made is whether to turn them on or off. If the fix for this bug was directed towards this end, then interpreting clips with proxies should ultimately be no different to interpreting clips without proxies, there should be one proxy made at native frame rate of the source clip and interpretation should happen to it just as it does a normal clip and can be changed on the fly without the need to re-encode. It's evidently possible as any clip imported in to Premiere can be treated as such and interpreting clips doesn't intrinsically change any of it's constituent frames so I don't understand why there's an issue with marrying two versions of the same clip with the same native frame rate the way a proxy file is tied to it's original clip. Whatever the timecode address of a given frame in a clip, the frame number is unique and unchanging so it shouldn't present a problem when toggling proxies on or off, and again, it's evidently not a problem of Premiere itself somehow working differently to that under the hood because again it works with imported clips when sending them out to grade via XML.

Anyway though, up until now, given the existence of the bug, I have worked around it by importing clips with click and drag, highlighting those that need to be interpreted and adding those to the proxy queue first so I can cancel the process in AME and then interpret the clips in the queue correctly before restarting the queue so the proposed fix would be a slight upgrade by cutting 1 or 2 steps but still entrenches what seems like an unnecessary issue to begin with and all it's associated problems. Wasted opportunity.

4 and a half years waiting for this very obvious fix to one of the most used features, and the fix Adobe proposes is one that won’t work properly from the start. Brilliant. That’s what we pay our money for.

Frame count of proxies simply needs to match that of the original clip and then play back at whatever is set in the project. It’s extremely simple.

Crucially this also applies to clips that have been manually duplicated in the project - we need to be able to set different frame rates even if they’re sharing the same proxy.

Hello Fergus, thanks for the update. This is not the fix that is needed at all. Everyone creates proxies while importing footage. THEN we interpret footage only on clips those we need.

Proxies should be created using the same fps of the original footage AND they simply need to change footage according to the "interpret footage" setting.

Thanks for looking at this one! I don't believe it's the right fix. For most people proxies are made as part of the ingest settings. In other words they are made before the footage is interpreted.

The ideal fix is that when footage is interpreted, the proxy that already exists of the footage gets interpreted too.

Many thanks

This is unacceptable, a major known oversite and critical to make the Proxy workflow remotely usable with Offspeed footage.

Relying on Speed/Duration can make roundtrips with Resolve a nightmare ;)

I see this is in progress! It's about time. Thank you for prioritizing this critical issue.

It's 2022 and I still can't work with off-speed proxies.

This is a critical issue. Fix it already!!!