kderbe

This essay says it's not possible to make a public-domain implementation of Opus. But it could be released under BSD (as libopus is), which is fine for games, as evidenced by the Licenses section of the credits in many games.

In the Hydrogenaudio discussion thread's metrics table, the new encoder scores better than Core Audio. But this is at constant bitrate (CBR) [edit: maybe not? see lesscraft's reply below]. Core Audio also has variable bitrate modes (TVBR) which the new encoder lacks.

So maybe Core Audio will continue to be the best when TVBR is available, but I'm hopeful the new FFmpeg encoder will be "good enough", especially if more folks find and contribute problem samples to help tune it.

I would read a follow-up about LimeWire's dynamic query routing. I enjoyed the writing style very much and now I'm reading Rick's other articles on topics that normally wouldn't interest me. Thanks Rick!

That's my verdict on Stephen's Sausage Roll too. My personal favorite sokoban is Patrick's Parabox (the name is an obvious nod to SSR) because its puzzles have a gentler and finer-grained difficulty ramp.

Rtings publishes charts in abundance, but the subjective quality of a monitor is more important. For example, a chart will tell you a monitor has low color deviation from sRGB after calibration, but won't tell you that the monitor UI takes 10 laggy clicks to switch from sRGB to DCI-P3 and will reset your selection every time you toggle HDR mode.

I admire Rtings' attempts to add more and more graphs to quantify everything from VRR flicker to raised black levels. They were helpful when I last shopped for a monitor. But the most valuable information came from veteran monitor review sites such as Monitors Unboxed and TFTCentral.

Steve Burke from GamersNexus tested eight games from their benchmark suite on Linux last month. Although his conclusion was generally positive, there were problems with nearly every game:

- F1 2024 didn't load due to anti-cheat

- Dragon's Dogma 2 and Resident Evil 4 had non-functional raytracing

- Cyberpunk 2077 with raytracing on consistently crashes when reloading a save game

- Dying Light 2 occasionally freezes for a whole minute

- Starfield takes 25 minutes to compile shaders on first run, and framerates for Nvidia are halved compared to Windows

- Black Myth: Wukong judders badly on Nvidia cards

- Baldur's Gate 3 Linux build is a slideshow on Nvidia cards, and the Windows build fails for some AMD cards

If you research these games in discussion forums, you can find some configuration tweaks which might fix the issues. ProtonDB's rating is not a perfect indicator (BM:W is rated "platinum").

And while Steve says measurements from Linux and Windows are not directly comparable, I did so anyway and saw that Linux suffers a 10-30% drop in average FPS across the board when compared to Windows, depending on the game and video card.

I would loosen the memory timings a bit and see if that resolves the ECC errors. x265 performance shouldn't fall since it generally benefits more from memory clock rate than latency.

Also, could you share some relevant info about your processor, mainboard, and UEFI? I see many internet commenters question whether their ECC is working (or ask if a particular setup would work), and far fewer that report a successful ECC consumer desktop build. So it would be nice to know some specific product combinations that really work.

Your first link doesn't seem to be about introducing noise, but removing it by averaging the value of multiple captures. The second is to mask quantizer-correlated noise in audio, which I'd compare to spatial masking of banding artifacts in video.

Noise is reduced to make the frame more compressible. This reduces the resolution of the original only because it inevitably removes some of the signal that can't be differentiated from noise. But even after noise reduction, successive frames of a still scene retain some frame-to-frame variance, unless the noise removal is too aggressive. When you play back that sequence of noise-reduced frames you still get a temporal dithering effect.

The article points out the masking effect of grain, which hides the fake-looking compression artifacts, and also the familiarity/nostalgia aspect. But I will offer an additional explanation.

Look around you: nearly all surfaces have some kind of fine texture and are not visually uniform. When this is recorded as video, the fine texture is diminished due to things like camera optics, limited resolution, and compression smoothing. Film grain supplies some of the high frequency visual stimulus that was lost.

Our eyes and brains like that high frequency stimulation and aren't choosy about whether the exact noise pattern from the original scene is reproduced. That's why the x265 video encoder (which doesn't have grain synthesis since it produces H.265 video) has a psy-rd parameter that basically says, "try to keep the compressed video as 'energetic' as the original, even if the energy isn't in the exact same spot", and even a psy-rdoq parameter that says, "prefer higher 'energy' in general". These parameters can be adjusted to make a compressed video look better without needing to store more data.