It is a known issue that FLAC files exported from FFmpeg often have broken progress bars, inaccurate durations, or inability to seek in Windows Media Player and foobar2000 because of
incorrect metadata headers and missing seek tables. For a summary ask Gemini “Why a flac exported from ffmpeg has a broken progress bar?”
The reason why I am writing here is that exporting FLAC with ShotCut worked well last year with ShotCut version 25.10.31 but with the current version 26.1.30 it doesn’t. I can fix the flac files by reencoding with ffmpeg (ffmpeg -i input.flac -c:a flac output.flac), but of course it would be better if it worked out of the box. I attach a file that has been exported with the stock flac preset, for demonstration.
I think you mean a seek or scrub bar in an external media player. I export a FLAC and VLC could play it and even seek with an accurate playhead even though it could not show a duration. I see more of a problem in Windows Media Player and Clementine music player. The fix is non obvious, and I doubt we will get around to implementing a workaround by post-running ffmpeg for one export preset.
If this is reproducible, you might want to submit a bug at the ffmpeg bug tracker if one doesn’t already exist. That’s really where this should be fixed!
Also, don’t automatically believe everything Gemini tells you. I don’t know that FLAC files “often” have these issues when I’ve used ffmpeg hundreds of times to extract stuff in FLAC formats without running into this issue — perhaps it’s the way you’re calling it (from what I could see, it seems to happen when extracting a part of one file using -c:a copy and that’s why the reencoding works). Anyway, you really should submit to the FFMPEG bug tracker or look for an existing bug to contribute to. That way, everyone wins!
Just for documentation, let me confirm that I made this observation at Foobar2000 which has been my favorite audio player and I tested with Windows Media Player as kind of reference. Both apps play the FLAC file but in Foobar2000 (current version) no scrub bar slider appears, in WMP (Win10) the slider appears but does not move and is not movable. VLC works well and today I installed Clementine which works well, which shows that some players handle flac files with tolerace for a non conforming file header.
I assume you updated the FFMPEG version included since ShotCut version 25.10.31 which produced different FLAC files, and you did not change anything else in the usage of the FLAC encoding? In this case an explaination could be that the FLAC encoder changed the file structure, or FFMPEG changed it’s implementation and some older players like foobar2000 need an update to keep track with these changes. If so, my next step would be a bug report with foobar2000 support, because other players cope with the flac structure, and yes, also FFMPEG bug tracker, but this can easily become a long term project.
No, I exported a part of an MP2 audio track from a TS container, using a (18 second) Shotcut marker and the stock export preset for FLAC audio. So MELT was calling the encoder, that’s why I asked if that call has been changed or needs adaption to changes in FFMPEG.
My external call of ffmpeg.exe worked out to repair the FLAC file structure, so Foobar2000 and WMP can handle it.
Ah, right it’s however MELT is calling it. If you can easily reproduce it, I think it’s worth filing bug reports at ffmpeg (since that’s what’s actually making the file). Can you check if running ffmpeg -c:a copy -i input.flac output.flac fixes the issue as well? Basically, don’t re-encode (which is what you’re doing when you use -c:a flac) but actually copy the audio data directly. If so, that would point to an issue with the container (which I think it is) rather than with the audio data itself.
this as written makes a syntax error, but:
”ffmpeg -i input.flac -c copy output.flac” does not repair the file structure, while
”ffmpeg -i input.flac output.flac” without any option triggers the default re-encoding for the file extension given, and again re-encoding repairs the file.
As FLAC is lossless, re-encoding does not degrade the quality.
Whoops, you’re right, it should be ffmpeg -i input.flac -c:a copy. But that’s interesting that copying the audio stream doesn’t fix the issue, but reencoding does…
For testing I replaced the ffmpeg.exe dated 2026-01-30 in the shotcut installation folder C:\Program Files\Shotcut by older official ffmpeg builds, first with ffmpeg-2025-12-18 master build and then with ffmpeg-7.1.1 release build of March 2025 from Builds - CODEX FFMPEG @ gyan.dev with the finding, that the current SC version seems to export bad FLAC files also with older ffmpeg builds. I tried various ts and mp4 source files.
A final test I can run next weekend is to install an earlier SC version, and if this also fails I must think completely different with my installation here.
BTW: Have you tried to export any audio track to FLAC only, recently?
I repeat: Shotcut and melt are not ffmpeg command line frontends! They use the FFmpeg libraries and APIs. There are only some exceptions in Shotcut where it transcodes to make edit-friendly and proxies. So, you have not really tested anything useful by doing this.
Upon further review, I did find a change I made in MLT that caused this. The usual case of a reported bug fix causes another bug.