I was inspired by @andymilkis’s reverse user group submission to be able keep track of both our own internal name as well as the client name (or AD-ID, ISCI, whatever). This has been an issue for as long as I can remember.
Personally I’d try to attach the ISCI to the end of the internal name and then a producer or someone in I/O could use that to then know what the file links to. Regardless of the approach, the two names would always get separated.
The solution, then, is to leverage both Flame’s tagging system as well as QT’s vast tracks of metadata. This idea lead me to write tag_tools.
This is a collection of tools to help manage tags for internal_name, client_name and audio. It will allow you to easily set, change and read the tags to then be able to rename the sequences/files themselves as well as to export QTs with the tags inserted into the metadata.
Have a look at the README as I’ve gone into far more detail then here but the here’s the top-line summary:
What it does:
Sets/updates the internal_name or client_name based on the current sequence name.
Adds all audio files to the audio tag.
Rename sequences (both on the desktop and filesystem) to either the internal_name or the client_name.
Exports a pre-populated CSV file with the internal_name that you use to then add the client_name. You then re-import the edited file to automatically add the client_name tag to the selected sequences.
Exports a QuickTime with all the tags jammed into the metadata
I hope some of you find it useful. Let me know if anything isn’t working or if you have ideas of how to improve it. As always, massive shout out to @MikeV and all the work he’s done with PyFlameLib and his UI builder.
While I appreciate that you’ve been working away on this new set of tools that will no doubt be very useful when you decide to bestow it upon us plebs, the tool I’ve written was designed to scratch a very specific itch that @andymilkis brought up. It’s also a problem that I’ve wondered how to best solve for years. That said, perhaps the name of tag_tools is too broad and inspired you to post this screen shot without any further contribution.
I think what’s being overlooked is the ability to export a quicktime with the tags in the metadata. The included library is really the star of the show. Setting, modifying, removing tags is fairly trivial. It’s the injection of those tags into the metadata which can then be used later for whatever your imagination can think of that’s the big solve here. Much like the NCLC tagging issue of yesteryear, this is a way to offer something to the community immediately without relying on the developers adding new features.
It’s worth adding that this will work with 2025 which, as we’ve noticed, many are sticking with. Regardless of any new features that might be available to use in the future, this will help those who stay with 2025.
All that said, I think we can all agree that the introduction of tags is truly inspired as it opens up so many interesting capabilities that we didn’t have in the past.
Hey @kyleobley. Cool stuff, thanks!
I’ve been playing with this, but every quicktime I export gives me the “file isn’t compatible with QuickTime Player” warning. Have you experienced that? Is there something else these scripts require? I get the same error message whether I export from Mac or Linux. The exported quicktimes look fine and flame and Dump Tags to terminal is working.
Hey @john-geehreng hmm…that’s no bueno. No, nothing extra should. be required. Everything ought to be self contained.
On my end (MacOS 15.7.3) all the files I’ve been creating are fine. I can read the created QTs in both Flame and QT Player.
When you use the same export profile when you export via the media panel, do those QTs work? I assume so but might as well ask. Are you on Linux or Mac?
I’m getting the same error whether I export from Mac or Linux. The export profile works as expected from the media panel. I also tried bypassing the metadata injection in your script, but I still get the same error.
That was Cursor’s first thing to test. The next is codecs, so I’ll try something else. I was using ProRes 422 HQ. What are you using?
A different codec didn’t help. I’ve tried these:
Mac: OS 26.0.1 with Flame 2026.2 and a beta version
Linux: Rocky 9.5 and Flame 2026.2.2
Edit: Disabling the metadata injection (lines 292-294) allows me to export a file that’ll open in QuickTime, but it won’t have any extra metadata. I’ll dig around and let you know what I come up with.
No worries! I was getting an error about .set_focus, but everything else looks good. The export displays fine in the MediaHub and the Dump metadata to terminal works. It just won’t open in Quicktime or preview in finder. Agreed super weird. Even Cursor doesn’t know why it’s not working.
Don’t mind at all. The one and only error I see is about the UI:
Open Export Window execute callback [<class 'tag_tools.tag_tools_export'>((<flame.PySequence object at 0x333b968f0>,),)] failed because of an error of type AttributeError("'PyFlameEntryBrowser' object has no attribute 'set_focus'")
That library works for me: Written: 'com.apple.quicktime.comment' = 'Test or whatever you want'
That error is related to the PyFlame library but I’ll have a look into it.
Would it be possible to send me one of the files that isn’t working but exported via the normal media hub route? It’d also be good to have one of the files that isn’t opening in QT player.
I’m curious if it has to do with the length of the sequence. When Claude was writing the library there was issues with using the Python library corrupting the headers. That was eventually fixed and I thought the problem was solved but perhaps not.
The strange thing is that you say you can read it within Flame afterwards, just not QT player nor preview. You’d imagine if it’s corrupted, then nothing could read it. Sort of all or nothing type of situation.
Does it open in Resolve and/or Media Encoder (if you have them available)?
Hey @john-geehreng, there’s a chance Tahoe is being more strict when it comes to the QT standard. My guess is Flame is using it’s own library which is similar to that of MacOS 15 which is why they open fine there.
Try the qt_lib_fix branch. Working on MacOS 15. Let me know if it fixes it and then I’ll merge into the main branch.
