View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001454||OpenMPT||Audio I/O||public||2021-05-04 03:13||2021-05-05 15:55|
|Status||closed||Resolution||no change required|
|Product Version||OpenMPT 1.29.09.00 / libopenmpt 0.5.8 (current stable)|
|Summary||0001454: Timing Bugs While Rendering To 8-bit Mono FLAC|
When I render some songs to an 8-bit FLAC, sometimes, I get this awful glitch where rows of the song aren't timed right sometimes. Drums playing off beat, melodic instruments playing off beat, it happens for a bit before the rest of the song plays normally.
Not all songs have this glitch, and I don't know what causes the glitch either.
|Steps To Reproduce|
|Tags||No tags attached.|
|Has the bug occurred in previous versions?||No.|
|Tested code revision (in case you know it)|
MPTRenderTest.7z (4,436 bytes)
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?
I also cannot spot any timing problems.
Okay, here's the rendered file.
MPTRenderTestRender.7z (23,716 bytes)
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?
MPTRenderTest-2.7z (36,908 bytes)
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.
MPTRenderTest-3.7z (35,493 bytes)
Your attached FLAC still has the same issues on my PC in MPC-HC and my Chromium-based SlimJet browser.
MPTRenderNikkuPC.7z (164,996 bytes)
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
Works when decoded with reference decoder
|2021-05-04 03:13||nikku4211||New Issue|
|2021-05-04 03:13||nikku4211||File Added: MPTRenderTest.7z|
|2021-05-04 07:15||Saga Musix||Note Added: 0004743|
|2021-05-04 09:27||manx||Status||new => feedback|
|2021-05-04 09:27||manx||Note Added: 0004746|
|2021-05-04 13:41||manx||Note Edited: 0004746|
|2021-05-04 19:13||nikku4211||Note Added: 0004747|
|2021-05-04 19:13||nikku4211||File Added: MPTRenderTestRender.7z|
|2021-05-04 19:13||nikku4211||Status||feedback => new|
|2021-05-04 19:17||Saga Musix||Note Added: 0004748|
|2021-05-04 19:17||Saga Musix||Assigned To||=> manx|
|2021-05-04 19:17||Saga Musix||Status||new => feedback|
|2021-05-04 19:18||Saga Musix||Target Version||=> OpenMPT 1.29.10.00 / libopenmpt 0.5.9 (upcoming stable)|
|2021-05-04 19:18||Saga Musix||Description Updated|
|2021-05-04 19:18||Saga Musix||Steps to Reproduce Updated|
|2021-05-04 19:26||nikku4211||Note Added: 0004749|
|2021-05-04 19:26||nikku4211||Status||feedback => assigned|
|2021-05-04 19:40||Saga Musix||Note Added: 0004750|
|2021-05-04 19:40||Saga Musix||File Added: MPTRenderTest-2.7z|
|2021-05-04 20:15||nikku4211||Note Added: 0004751|
|2021-05-04 20:21||Saga Musix||Note Added: 0004752|
|2021-05-04 20:21||Saga Musix||File Added: MPTRenderTest-3.7z|
|2021-05-04 20:28||nikku4211||Note Added: 0004753|
|2021-05-04 20:28||nikku4211||File Added: MPTRenderNikkuPC.7z|
|2021-05-04 20:50||Saga Musix||Note Added: 0004754|
|2021-05-04 20:51||nikku4211||Note Added: 0004755|
|2021-05-04 20:54||Saga Musix||Status||assigned => closed|
|2021-05-04 20:54||Saga Musix||Resolution||open => no change required|
|2021-05-04 20:54||Saga Musix||Target Version||OpenMPT 1.29.10.00 / libopenmpt 0.5.9 (upcoming stable) =>|
|2021-05-05 08:51||manx||Note Added: 0004756|