On a project we finished recently, we rendered out both .mp4 and ProRes deliverables out of Flame. They checked out fine and everyone was happy.
Today we tried to bring one of the generic master renders into Avid for a quick cut-down that we can do from the render rather than restoring the project and doing it from the timeline.
Except Avid rejected the ProRes file. After a bit of investigation we found that the ProRes file had its audio track encoded with AAC instead of PCM as is customary with ProRes files.
Running it through AME to transocde the audio channel back to PCM fixed the Avid problem.
But apparently you have to make sure when switching codecs and switching to ProRes in Flame, that you also check the audio codec. It will not automatically switch to PCM as it does in most other apps.
Agreed Tim! I’m perplexed as to why the mixdown is the default. I’ve always disabled it and forgotten about it. Never bothered with making a feature request to change it.
That’s the crux of it, it shouldn’t because no other software I know lets you even pick anything but PCM. Clearly Avid doesn’t think it’s a valid choice to start with.
Out of habit I always go to the audio tab to make sure it’s PMC w/no-mixdown to stereo(and ask about deselecting ColorSync compatible).
When Freelancing some places do not have custom ProRes presets or sometimes your newly created user is not given the presets and bookmarks, etc etc
The AAC default thing is rather incongruous with how we work for sure…
AAC is not the default audio encoder when you create a preset. All QuickTime presets use PCM audio encoder.
If you have used a preset using AAC (like the MP4 presets) and change the Video Format to QuickTime, the Audio tab uses the same encoder has what was defined for the preset you are editing. If we were to reset the encoder when you modify a preset you would really not be happy… So, when you edit a preset, make sure you visit the various tabs to make sure your selection matches what you need to deliver.
I validated that Avid Media Composer 2024.2 is able to not only encode QuickTime ProRes with AAC audio but also import back the file so it seems to be a valid combo of encoders. @allklier you might want to open a support ticket with your media file so we could have a look.
Was able to reproduce this with a test file with the same rendering preset from that project. The preset is to make an .mp4 file, and then I run it a second time with the only thing to change format to .mov and compression to ProRes HQ.
I suspect that may be the case. Though on our Windows system, if I export ProRes/AAC from Avid, it will read it. It must be a specific combination of settings or metadata that makes it invalid.
Did some online searches on this combination. Nothing says it’s unsupported, but it is unusual. As you’re pairing a mezzanine/mastering video codec with an audio delivery codec. Unless this for internal review for video primarily, it’s not a sensible choice. And as audio is small size wise, the savings is negligible.
Resolve and Avid mirror Flame’s behavior. Premiere will not allow you to select AAC, and I saw online yesterday that FCP does neither (though haven’t verified).
As it’s a corner case, we probably don’t need to spend more time on it. But good to know.
A quick comparison of the media info between the two test files shows a few discrepancies:
@Slabrie Looking at all the combinations, there’s something odd about Flame in this case, which maybe the root cause:
Every single export I do with AAC as audio codec, specifies the codec as ‘mp4a-40-2’. Including most tellingly the mp4/aac export on Flame of the same file with the same preset, which Avid on Windows can open without issue.
For some unexplained reason, only the Flame ProRes/AAC combination specifies the audio codec id as ‘mp4a’ but without the -40-2. Almost as if it was truncated for some unknown reason. That after all may be a real bug. Only Avid on Windows seems to care, though there may be others that we didn’t check yet.
Based on this document, the full string is the required/proper way of specifying the audio codec:
I’d at least confirm and log it as a bug, so if someone else runs into, you can locate it quicker. It’s quite possible that someone else uses that combo and some other software fails to read it where it’s not as easy to trace and isolate. But certainly not a high priority.
It has all the smells of a code path that is supposed to determine the proper post-fix, and it’s missing a ‘case’ statement when paired with ProRes and thus ends up with a blank default value. So the fix may literally be one line of code. But it still takes time to locate that line and test it.
