Importing FLAC-file exported from "Shotcut" to timeline freezes the application

What is your operating system?
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.10
Release: 20.10
Codename: groovy

What is your Shotcut version (see Help > About Shotcut)? Is it 32-bit?

21.01.29
No.

Can you repeat the problem? If so, what are the steps?
Yes.

  1. Get some audio or audio-video to the timeline!
  2. Copy the timeline to source, set the input and output and export the segment from source as FLAC without a container!
  3. Import the exported FLAC-file into the timeline!
  4. Suffer Shotcut freezing!

I saw this bug reported in 2019 and it was set to low priority and finally closed. Even low-priority tasks shouldn’t be closed before they’re done. Is it still a low-priority task? I don’t want to have FLAC-files in containers, I want to have pure FLAC files and please let me choose whether and into what container I’d put it if at all! Or please explain why FLAC-files should be in Matroska-containers.

Please see my accompanied video.

The container has a time stamp system that allows for random access seeking into the FLAC file. This allows the playhead to be randomly moved anywhere on the timeline with responsive seek times. This doesn’t work very well without a container, at least when MLT is in the chain.

Two thoughts come to mind that you probably already know:

  1. If audio is exported from Shotcut and brought back in, why must there be a requirement to have no container? The audience of the final video doesn’t see the FLAC file used during editing, so why place any restrictions on the format?

  2. Also related to audio being brought back into Shotcut… FLAC is pretty slow to decode as far as audio codecs go. CPU usage can be reduced by using WAV or ALAC which are both lossless like FLAC.

If the FLAC file is getting used for other purposes or added to a listening library, then granted, I see the goal of avoiding a double export to make the audio work in Shotcut.

2 Likes

I don’t know if this can be of any help, or if it is a waste of time:
I checked yesterday the Flac export without container from Shotcut and indeed importing the resulting file into Shotcut causes a freeze.
However I was able to play it with VLC and import it into Audacity.
The file resulting from the export in Shotcut, did not have an extension (maybe I did something wrong). I manually renamed and added the .flac extension, but the import in Shotcut of the new file with extension also resulted in freezing.
So I thought maybe FLAC could not be imported into Shotcut. So I took a song from my FLAC library and imported it into Shotcut.
No problem.
Noticeable differences between files:
Existence of cover art.


Existence of metadata.

So my file is a FLAC container that includes FLAC audio, metadata and cover art.
I suppose that when exporting an audio in Shotcut we can export FLAC in a container of the same name, however I don’t know if we need some prerequisites beforehand for it to work well in Shotcut again.

Do you mean MLT is the bad boy? Is there an alternative for MLT? What do MLT developers tell about that?

Is there a FOSS-alternative to FLAC? As far as I know, WAV and ALAC are proprietary and don’t want to use proprietary stuff. Should I want to use proprietary stuff, I wouldn’t use Shotcut but Premiere or something else more powerful. I want to support sharing and this is why I’m on Shotcut and this is why I use FLAC. In addition, WAV is uncompressed, FLAC can be compressed.

I use the exported segments for both other projects editable in Shotcut as for purely audio projects and also as just for playback.

There should be at least a warning if we choose both formats to be FLAC.

It’s not quite that simple. Best I can tell, MLT writes incomplete and/or inaccurate metadata when exporting FLAC without a container. However, writing FLAC metadata in a raw file is not as straight-forward or feature-rich as other formats, hence the complication when the goal is to be a generic media-handling toolkit like MLT.

Shotcut is built on MLT. Converting Shotcut to something else would be like holding a skyscraper in the air while the foundation is swapped out.

However, there is a FOSS workaround.

Export the audio from Shotcut in a Matroska container. The Audio > FLAC export preset may be a good starting point. Then, from a terminal window, run this command:

ffmpeg -i "My Shotcut Export.mka" -c copy -f flac "My Containerless Audio.flac"

[If ffmpeg is not installed, a copy can be found in the Shotcut installation directory.]

This removes the Matroska wrapper and is completely lossless with no re-encoding (at least for the audio data, not so much for the metadata). Now, the Matroska file can go back into Shotcut for further editing, then deleted when done. The .flac file can go directly to your audio library.

However, I noticed that when I played the containerless .flac file in VLC, there were similar problems such as no duration detected and difficulty seeking. In all frankness, while containerless FLAC is technically possible, I wouldn’t recommend it to anybody. Pretty much any program that’s FOSS enough to understand FLAC is also going to understand Matroska. Matroska fixes the metadata situation and enables random seeking.

It depends on how strict the definition of “proprietary” is. WAV was co-developed by Microsoft and IBM, whereas ALAC was developed by Apple. So yes, corporations made them. But WAV doesn’t have any usage restrictions or licensing fees, and the original format is well outside patent expiration dates just like MP3. Here’s a link to the Library of Congress recommending WAV for archive preservation due to “no licensing required”:

WAVE Audio File Format

Similarly, Apple released ALAC as open source under an Apache license in 2011. See:

Apple Lossless Audio Codec - Wikipedia

The ALAC source code is found here:

GitHub - macosforge/alac: The Apple Lossless Audio Codec (ALAC) is a lossless audio codec developed by Apple and deployed on all of its platforms and devices.

In regards to licensing, FLAC has zero sharing advantage over WAV or ALAC. They are all equivalent.

Heavy compression used by FLAC is great for the final export when stored in a listening library that needs to be small. But that compression takes a lot of CPU to unpack while trying to edit real-time in Shotcut.

ALAC is also compressed, but it’s specifically designed to unpack fast with extremely low CPU usage so that it doesn’t drain the batteries of mobile devices. ALAC could be a sweet spot between FLAC and WAV in regards to performance and size.

I totally get FLAC for the final result. It’s just not-so-great during editing when performance is more important than file size. Not to mention that audio sizes are a fraction of video sizes, so the savings are hardly noticed in most cases (unless Shotcut is being used to edit an audio-only podcast).

I’m just putting out the possibility that other formats exist which achieve higher performance than FLAC while editing. If performance is already fine and a smaller file size is preferred, then more power to you, you’ve already got the best that can be had.

2 Likes

Not necessarily. While the skyskraper still stands on its foundation, another skyscraper can be built nearby to another foundation.

Why couldn’t Shotcut include this command while exporting as pure FLAC? At least a warning could be in place with the link to this discussion here.

I also noticed this anomaly now using SMPlayer that’s the most powerful media player I’ve ever found. This raises the question: what does Audacity differently in order to avoid the mentioned anomaly?

Shotcut isn’t a good tool for editing audio-only podcasts as it lies in its waveforms.

Many things are possible if given an inexhaustible supply of time, labor, and money. :grin:

On an Audacity FLAC export:

ffprobe -i "Audacity export.flac" -show_entries stream
duration_ts=283136
duration=12.840635

On a Shotcut FLAC export:

ffprobe -i "Shotcut export.flac" -show_entries stream
duration_ts=N/A
duration=N/A

The duration (or the sample count) is not being written into the FLAC header by MLT. Writing this information is the true fix rather than Shotcut running Band-Aid post-processing commands.

Speaking of which, for today’s purposes, here’s a better ffmpeg command that should fix the unknown duration issue by forcing a re-encoding of the file, which will force a rewrite of the headers and will include the duration. Since FLAC is lossless, audio quality itself is not affected:

ffmpeg -i "My Shotcut Export.mka" -c:a flac -f flac "My Containerless file.flac"

“Lie” is a strong word that implies intent. “Imprecise” would be more fair because it handles audio at the video frame level rather than the audio sample level. You are correct that it is not intended to be a high-end DAW.

It is actually a graph of the RMS power of a subset of samples per video frame. I just call it a waveform since that is a relatable terminology.

What about a warning?

I edit my videos mostly based on audio. I cut out silence. I watch when the graph is low - this means that no meaningful voice is present. However, in reality, the silence starts some frames before the graph reaches the low point. So I split the video where the audible ends. After splitting, the graph gets corrected. The lag is even bigger while using proxies. Shouldn’t that RMS power of waveform of whatever you call that be in the correct position always?

This is fixed for the next version by fixing it in MLT so the output has a proper duration.

1 Like

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.