Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Undithered digital silence causing problems (Read 3972 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Undithered digital silence causing problems

On the FLAC github, quite a few people have shared that they have problems with live streaming or seeking in FLAC files that contain a lot of (undithered) digital silence. See here and here.

The issue is that when a FLAC encoder encounters digital silence, it uses the highly efficient constant subframes. On 44.1kHz audio using the default blocksize, the bitrate drops to about 1.3kbit/s for all bitrates and number of channels. For CDDA, which can peak to 1412kb/s this is a range of over 1:1000, for multichannel and 24-bit audio, this gets even worse. Seeking gets difficult because of the large fluctuations in frame size and streaming gets difficult because buffers run empty.

At first I thought this should be non-issue, as all audio should be dithered. However, requiring dithering isn't really lossless and not really user-friendly either. So, I wrote this bit of code which prevents the FLAC encoder from outputting frames that only contain constant subframes. With this code, the minimum bitrate the FLAC encoder uses (for 44.1kHz audio, irrespective of the number of channels or the bit depth) becomes 45.4kbit/s.

I could change libFLAC to include a switch somewhere to trigger this behaviour, but that would also require streaming software using libFLAC to be changed to benefit. Moreover, that wouldn't solve the seeking issue, which can be a problem to any user. I suspect the minimum bitrate increase isn't really an issue for normal users (i.e. it won't hurt compression for most music) because frames with only constant subframes won't happen often in music. Perhaps it should be disabled when --lax is used, because --lax can be used to create non-streamble FLAC files.

However, I'd like to know what you think.  :))
Music: sounds arranged such that they construct feelings.

Re: Undithered digital silence causing problems

Reply #1 –
Maybe add this safety padding to the default preset, which would be used by software where switches can't be configured. But keep the highest practical compression in the "best" preset. Automatic blanking of dither is a common feature in plugins. Silence would make up a greater proportion in a collection of short samples. I've never encountered this problem when seeking in albums with hidden tracks following silence. Players with this limitation should be fixed to handle the large number of existing FLAC files.

Re: Undithered digital silence causing problems

Reply #2 –
I have aa 15 years old Network Player that never struggled on silence. I second the vote to fix the players and not the codec.
If someone needs this or streams by purpose should have the choice with an additional command imho.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Undithered digital silence causing problems

Reply #3 –
Digital silence can be found frequently even in CDDA tracks. It doesn't seem as good idea to unnecessary bloat bitrate because of buggy players. Better just add some option that can be used by those who really needs it (for streaming).

Re: Undithered digital silence causing problems

Reply #4 –
Here is an example file. Only the first and last three seconds of the file contain audio.

When seeking to the middle of the file with VLC, Windows Media Player or Firefox, all kinds of weird things happen. foobar2000 and Chrome do fine though.
Music: sounds arranged such that they construct feelings.

Re: Undithered digital silence causing problems

Reply #5 –
Quote
Here is an example file. Only the first and last three seconds of the file contain audio.
When seeking to the middle of the file with VLC, Windows Media Player or Firefox, all kinds of weird things happen. foobar2000 and Chrome do fine though.
VLC and Firefox looks OK if the file is multiplexed into some containers (MP4/Matroska/Ogg).
WMP, on the other hand, seek suffers on Matroska.

Re: Undithered digital silence causing problems

Reply #6 –
Firefox jumps to the end of the file and stops. In Sound Forge 8 decoding takes several seconds, but is fast again after adding a seektable. Seeking with SMPlayer/MPV is broken. But these are not primarily music players; they should adapt to the standard not the other way around. Lossless audio on the web is uncommon. You wouldn't be able to seek in a live radio stream.

Most Windows software that I have, have no problem with this file, including Winamp native and old with the plugin, SMPlayer/MPV, Foobar old and new, XMPlay, AIMP, DirectShow/DC-Bass, iZotope RX5, OpenMPT, MPC-HC/old, MPC-HC/LAV, Reaper 6, SoX.

Re: Undithered digital silence causing problems

Reply #7 –
Well such files should go into the testbench - and then, I would not be surprised if a variable block size strategy would make for even bigger trouble. Try it with the ancient flake and with 96k too to make for blocksize 16384 within subset - provided flake does (/did, for the ancient) max out blocksize to merge several CONSTANT.

That said, ...

Quote from: j7n on
Maybe add this safety padding to the default preset, which would be used by software where switches can't be configured. But keep the highest practical compression in the "best" preset.
Thinking aloud on why this solution might be part of a bigger picture:

The chart for ktf's testbench is quite a decorated Christmas tree. Evidently, lots of players choke on lots of subset files - and that include hardware players, which aren't outright user-upgradeable. Fix the damn faulty player! simply won't happen.
That points towards further restrictions to today's "Subset". More layers of strictness/laxness wouldn't be optimal, but if the mountain won't come to Muhammad ...

And then, my limited testing testing on ktf's improved encoder, gave the impression that -6 is not the most useful preset anymore; -7 gives more value for money. So if one is to touch -5 to failsafe it further, then one would be free to re-think the options for a new -6 that means "default except I know my player isn't retarded".

Re: Undithered digital silence causing problems

Reply #8 –
Sample plays and seeks fine with a Slimdevices Transporter running together with Logitech Mediaserver 8.3
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Undithered digital silence causing problems

Reply #9 –
Quote from: j7n on
Most Windows software that I have, have no problem with this file, including Winamp native and old with the plugin, SMPlayer/MPV, Foobar old and new, XMPlay, AIMP, DirectShow/DC-Bass, iZotope RX5, OpenMPT, MPC-HC/old, MPC-HC/LAV, Reaper 6, SoX.
Then it is less of a problem than I feared.

Quote from: Porcus on
Well such files should go into the testbench
Yes, seems like a good fit.

Quote from: Porcus on
That points towards further restrictions to today's "Subset". More layers of strictness/laxness wouldn't be optimal, but if the mountain won't come to Muhammad ...
The reason I suggested it could be linked to using --lax is because this problem makes streaming difficult. Seeking is something that players must fix, but I think getting players to not stop playing because a buffer runs thin on a bitrate of 1.4kbit/s (that means a single TCP/IP packet of 1500 byte can contain more than 8 seconds of silence) is way more difficult. The goal of the FLAC subset is twofold: to enable streaming and to lower requirements on hardware implementations. This is clearly something that has to do with enabling streaming.

I see a couple of options
  • Link it to the usage of --lax, because it is streaming related. When someone uses --lax, the encoder no longer ensures no block with only constant subframes are created
  • Link it to a compression level. This can technically be done without changing the API/ABI, but this is not nice to users as they cannot choose for themselves to enable or disable it
  • Create a new option in FLAC and new functions in libFLAC API/ABI. While not really a problem, I prefer not touching the API/ABI when possible. It will also require modifying streaming server applications using libFLAC
  • Create a compile-time option, so a special libFLAC with this enabled can be distributed for use with FLAC streaming server applications. This can only be used for such applications where FLAC is dynamically linked (in other words, libFLAC is a dll or so)

The last option is probably the cleanest, and more or less what is happening right now as I asked a few people through github to test this patch for me.
Music: sounds arranged such that they construct feelings.

Re: Undithered digital silence causing problems

Reply #10 –
Those are not mutually exclusive.
4: Compile-time options that allow configuration of what is on or off on default? Maybe an idea in itself.
But once you allow for that, consider also an option --defaultconfig that switches off all compile-time configurations.

And still there can be a new option for --enforce-minimum-bitrate or whatever you call it, and a negative option.

Re: Undithered digital silence causing problems

Reply #11 –
Quote from: ktf on
Create a compile-time option, so a special libFLAC with this enabled can be distributed for use with FLAC streaming server applications. This can only be used for such applications where FLAC is dynamically linked (in other words, libFLAC is a dll or so)
And who can guarantee that some incompetent person will not include such special libFLAC into some application for offline encoding? And then users of this application will ask: "Why FLAC compresses digital silence so poor?"

Re: Undithered digital silence causing problems

Reply #12 –
Seems that it needs a vendor string saying "special needs only most of you please use something else libFLAC version 1.x.y"

Re: Undithered digital silence causing problems

Reply #13 –
I just tested your test stream okay in Firefox 94.0.2 on macOS. Seeked right to the middle, it continued playing to the end.