I think it would be worth it to add two presets in the Audio category in Export. One for ALAC and the another for FLAC.
FLAC I think goes without saying why should it be included as it’s so commonly known already.
ALAC is the codec that is used in iTunes and other music apps so I think it is important enough to include.
As for ProRes: Currently, the ProRes preset in the Intermediate list uses vprofile=2 which is from what I understand ProRes 422. However, I believe ProRes 422 is not visually lossless. ProRes 422 HQ is. So as an intermediate shouldn’t the preset be updated to be ProRes 422 HQ which is vprofile=3?
Regarding ProRes, it kinda depends on the design goal of the preset. If an export is a one-and-done type of thing, then ProRes 422 is widely considered sufficient for delivery. But if the resulting ProRes file is going to be brought back into an editor for more work and undergo multiple generations of transcoding, then HQ is the right choice.
Personally, I would be cool with the HQ option because I only use ProRes in an editing workflow, not for delivery, so an HQ preset would fit my most common use case. But if the preset is left as-is, I can see the use case there too. The question is whether it’s most common to use ProRes for generating an intermediate or generating a final delivery.
The current ProRes preset is in the Intermediate category. If that’s the case, then it should be ProRes 422 HQ. For delivery purposes like you talked about, then perhaps a preset for ProRes 422 should be made to be placed in the Stock category.
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.
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.
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
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?
Edit:
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?
“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
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)
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.
@pdr, @Austin thanks for taking the time to write your responses. Very informative.
@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.
