FLAC is available through the advanced exports, but since shotcut isn’t for audio editing I’m not sure why you’d want to use it to export a FLAC often enough to make it a preset.
Everything is available in advanced.
There is an entire audio category in Export.
I know it’s there, but I’m trying to figure out the usecase, you wouldn’t make the original audio in shotcut you’d be more likely to pull a FLAC in out of audacity or similar.
Well, since AAC and MP3 are there, it wouldn’t be out of place. But those are lossy and since FLAC is meant for archival purposes it would make sense to include an archival codec preset in the audio category.
Any thoughts on this one, Dan?
The intermediate category is not lossless; the lossless one is. Everything in the intermediate category is slightly lossy. I will add a ProRes HQ preset as well as ALAC and FLAC for the release version 20.02
Thanks for adding the new presets!
I guess by “slightly lossy” you mean “visually lossless”?
I thought that all ProRes were different forms of lossy with the best being visually lossless. Is ProRest HQ really lossless? Also, @Austin described his DNxHR HQ preset as equivalent ProRes HQ. But if so why have DNxHR in one category and ProRes HQ in another?
Austin also made this point:
If ProRes 422 is not meant as an intermediate and is meant for delivery then isn’t it more appropriate for it to be in the stock category?
After looking around the net a bit, I found a thread on Apple’s official forum where someone asked the different between 422 and HQ. This response was marked as the solution:
ProRes HQ is really best for formats that originated as 10-bit or higher…like Red, Alexa, AVCIntra. ProRes 422 is best suited for 8-bit formats, like HDV, XDCAM, DVCPRO HD, DSLR H.264.
If that’s the case, then does that mean ProRes 422 can be used as intermediate but when it’s 8-bit? If so, then does that mean that it’s this ProRes profile that’s the equivalent of the DNxHR HQ preset that was just added to the intermediate presets?
All prores variants are lossy .
“Visually losslesss” indicates high quality, but it’s still lossy . It means there is some quality loss, but a human observer might not be able to perceive the differences . If you zoom in or look closely on single frames you might.
“Lossless” mean mathematically lossless. “Losslessness” is boolean - true or false. It’s an either / or condition. If you measured PSNR, lossless would measure infinity. Everything else is not lossless
Yeah, I figured that which then would mean it wouldn’t be appropriate to put any ProRes in a lossless category of presets.
I do appreciate you taking the time to write up the differences between visually lossless and mathematically lossless but I already was aware of that.
Can you weigh in though on the comment I found in the Apple forums regarding the difference between ProRes 422 and HQ?
Yeah, when working on the preset, I learned HQ is not lossless. So, I put it in the intermediate category.
Not really, because different usage scenarios have different goals / tradeoffs they are willing to accept.
eg. if your goal is final delivery for youtube - is it going to make a huge difference if you use prores HQ vs normal for the intermediate editing ? Very likely not
The only factual statement ProRes HQ is just a higher bitrate version of Normal 422 profile , and both are 10bit422. Everything else is subjective , or based on specific usage scenarios and other factors
You could argue ProRes HQ is insufficient for Red/Alexa/raw etc… acquired formats, because it’s 10bit. And many people do. Ideally you’d use 12bit and higher bitrate versions such Prores 4444 XQ, or DNxHR 12bit. Many DP’s, and people in post production studios think ProRes HQ isn’t enough. You can definitely see the quality loss when looking closely, maybe not in motion, but certainly on single frames. You can compare it objectively with metrics like PSNR against competitors, it’s definitely lower than say AVC intra using a good encoder at similar bitrates. But it decodes faster, lower latency. People are willing to accept the lower quality for faster timeline performance . It depends on your perspective, how you are using it, what your expectations are, what tradeoffs you’re willing to make
When people test prores, they usually use the official implemenation such as from FCP/X . When you read the Apple board, that’s what they are using
But since this is shotcut, note that ffmpeg has 2 prores encoders, 2 variants
ffmpeg -c:v prores encoder is uncapped. It can give significantly different results than certified or genuine prores. It’s usually produces higher quality, higher bitrates than certfied prores .
ffmpeg’s -c:v prores_ks encoder is closer to Apple’s Prores. Supposedly it’s prone to fewer problems and “looks” closer to official prores. (Supposedly it’s more compatible in Apple programs, but I think those are largely issues from the past)
eg. here are bitrates of a 48s 1920x1080p24 test
certified prores hq 176 Mb/s
ffmpeg prores hq 286 Mb/s
ffmpeg prores st 201 Mb/s
ffmpeg prores_ks hq 186 Mb/s
ffmpeg prores_ks st 124 Mb/s
prores hq was 1.625x larger than official prores hq (and I don’t have to tell you the quality is higher, most people, even picky ones, would be happy with this quality level) . Even the standard profile yielded higher bitrates than certified prores hq on this test
Personally, I disagree with this statement. It cross-channels the significance of bit depth versus bit rate. It says ProRes 422 is suitable for 8-bit formats, but then lists “ancient” 8-bit formats along with “ancient” resolutions of 720p and 1080i/p. For these specific formats, ProRes 422 might be okay, albeit overkill since it is 10-bit. But for any 4K 8-bit work, or for sources that have very high H.264/H.265 bitrates (think Panasonic S1H), the ProRes 422 bitrate is too low for anything except final delivery (if even that). Instead of saying “ProRes 422 is good for 8-bit”, it would have been more accurate to say “ProRes 422 is good for lower bitrate (or possibly lower resolution) workflows”.
Similarly, the Apple forum solution says ProRes HQ is better for Red/Alexa work, but again the reason would be due to HQ’s higher bitrate compared to non-HQ. HQ as an overall format is still insufficient because these are 16-bit cameras with 12-bit log output being reduced to a 10-bit ProRes format, as @pdr already pointed out.
With that background, here are thoughts on your specific questions:
Only if the source’s bitrate is low enough to not notice any loss. As mentioned, ProRes 422 is a bad fit for 4K and high-bitrate sources from quality cameras due to its lower bitrate.
No. They are very different. ProRes 422 is 10-bit but at a lower bitrate. DNxHR HQ is 8-bit but at a higher bitrate. For 8-bit sources and outputs, visual quality will be noticeably higher with DNxHR HQ due to the higher bitrate. For high-quality 8-bit sources, ProRes 422 is the worst of both worlds because it wastes storage space using 10-bit numbers to store 8-bit data, all while throwing more data (visual details) away due to the lower bitrate.
@shotcut, I tried out the ALAC preset and the sizes of the files keep coming out bigger than both FLAC and WAV. ALAC is supposed to be compressed like FLAC so why are the files coming out bigger? The only time that the ALAC files came out smaller than a WAV export was with AAC files but they weren’t smaller by much in those instances and they were still far bigger than the FLAC exports.
ALAC is exporting as 24-bit only while the others are defaulting to 16-bit. Ideally, you could add something to Other to force it to use 16-bit, but it is not working due to a technical mismatch between FFmpeg and MLT with respect to indicating planar versus interleaved sample format. I have a change to MLT to better support the ffmpeg “sample_fmt” option for the next version; so, one could add “sample_fmt=s16p” to Other.
ALAC is designed to be low CPU overhead, which leads to less compression. ALAC is targeting lossless iTunes purchases that might make their way to mobile devices (meaning they don’t want to burn battery life on heavy decompression), and ALAC also gets used in the occasional editing workflow (meaning low CPU overhead is needed for speed).
FLAC can have much better compression, but at the expense of very high CPU overhead. FLAC and ALAC have entirely different design goals and target audiences. The file sizes follow suit.
I could be missing something here, but if I do
ffmpeg -h encoder=alac then s32p and s16p are the only sample formats that come back. To me, this suggests ALAC is creating a 32-bit audio file whereas FLAC and WAV may be creating a 16-bit or 24-bit audio file, which would obviously be much smaller due to bit depth alone.
That is correct, but s32p is the ffmpeg internal sample format for a 24-bit ALAC. This is shown as a log message when running ffmpeg:
[alac @ 0x55f7eec6dec0] encoding as 24 bits-per-sample. And since s32p is first, it is the default.
Interesting. I hadn’t watched the logs that closely. Thanks.
If I wanted to export FLAC as 24-bit what would I have to add to Other?