The timing seems just fine here, but the audio is heavily distorted due to incorrect format conversion. There's no reason why exporting to a specific format should mess up the timing, so if what you mean is not in fact the distorted audio that I'm also seeing here, can you attach the exported audio for comparison to show the timing issues?

Distorted 8bit FLAC output has been fixed in r14789 (1.30) and r14790 (1.29).
Test builds are available at <https://builds.openmpt.org/builds/>.

I also cannot spot any timing problems.

Okay, here's the rendered file.

Yeah, I see nothing wrong with the timing of that FLAC file, only the distortion problem mentioned before. Can you confirm that using the latest test version mentioned above fixes the issue for you?

I just rendered using the latest test version, and it did not fix the issue.

And if it helps, I hear these timing issues when listening to the .FLAC in MPC-HC, and when playing the .FLAC in my SlimJet browser and when playing the .FLAC in the Discord Windows application, too.

I have attached a FLAC file as written out by OpenMPT using that latest version, and it sounds perfectly fine. Can you compare if that file sounds alright in those applications? Does the file that you exported sound fine when exporting it into OpenMPT as a sample?

The file you attached has the same problems when listening to it in MPC-HC, my Slimjet browser, and my Windows Discord application. However, it does sound fine when imported into OpenMPT, and so do the other versions of this render test.

OpenMPT uses the reference libflac implementation so I would assume that there's a problem in whatever those applications use for decoding FLACs (possibly MediaFoundation). Can you create a recording what the problem sounds like? You can use e.g. Audacity, choose the WASAPI driver there and select the loopback device from the dropdown list that matches your output device.

Also please compare the output against the attached FLAC file, which was created by re-saving the previous FLAC file in WaveLab.

Your attached FLAC still has the same issues on my PC in MPC-HC and my Chromium-based SlimJet browser.

I have now re-encoded this FLAC file in several applications and my conclusion is: Whatever MPC-HC, Chromium or Discord (which is also just based on Chromium) are using must be broken. No matter which application is used to create a FLAC file based on this audio clip, no matter if the source was a FLAC or a WAV file, in the end those players always skip those parts of the FLAC file that are 100% silent. There is nothing broken in OpenMPT, it's those applications that are broken. The only thing you can do to circumvent this is avoid having 100% silent passages in your tracks.

Alright, then I'll be sure to let them know about their broken 8-bit FLAC playback.

This appears to be an ffmpeg bug (which is used presumable by mpc-hc and chromium (pretty sure about chromuim here))

Reproduced broken via ffmpeg -i something.flac something.wav with ffmpeg version 4.4-full_build-www.gyan.dev or ffmpeg version 4.2.4-1ubuntu0.1.

Works when decoded with reference decoder flac -d something.flac with flac - Command-line FLAC encoder/decoder version 1.3.3)

@nikku4211 Would you report this issue to ffmpeg upstream (<https://trac.ffmpeg.org/>)? If so, please provide a link here for future reference.

https://trac.ffmpeg.org/ticket/9270