I want to encourage everyone who doesn't like the WYSIWYG input box to use `/feedback` directly from within Slack to let the folks over there know about it. I believe this is one of those occasions in which tons of user feedback is crucial to at least make that awful thing optional.
While the little hack is surely fun, this is an underrated comment. The tuning that SONOS speakers do at setup will also not help if the speaker's own signal characteristics are taken into account for generating the system transfer function between input signal, speaker, and room. That's how SONOS, BOSE, et al. achieve a consistent sound in the first place.
So the result with different speakers will be mediocre at best and indeed far from high quality, even with a high quality speaker strapped on to it.
> (...) very hard for small projects, like the team running Homebrew, to fund their security, yet they are likely to be a target for quite high end attackers, (...)
I disagree. Homebrew’s security considerations in this case have nothing to do with their funding. There are lot of terrific services available for next to nothing for open source projects, Jenkins is one of them. It must have been a conscious decision the way HB set up their CI, unaffected by funding.
And such lapses are not an open door jyst to “high end attackers”. This was a single person with just internet access and a little knowledge about how modern OSS projects work.
Gosh, I hope there will be a #MovingToMattermost movement coming. This feels like a dangerous move to me, and bad for the market, competitiveness, and users. One more thing the tech world does not need right now, is even further increasing its reliance on a single service (and even more so one with a mediocre track record of uptime).
From what I quickly gathered from the specs^1, Replay Gain (RG) and Dymanic Range (DR) are indeed similar in the grand scheme of things. Both algorithms employ percentile-based statistic of RMS values. While RG is determined by the 95% percentile of RMS values on 50ms audio frames, DR uses the 80% percentile on 3-second-long audio frame RMS values. So RG is definitely on the side of short-term analysis, while DR is long-term.
What differentiates RG more plainly though is its stronger psycho-acoustical foundation in regards to frequency response: It applies a so-called "Loudness filter" (modelled after the Equal-Loudness contour^2 found in human hearing) before doing the RMS statistics. The Equal-Loudness contour (also known as "Isophone" where I come from) is in turn modelled after non-linear response of the ear to sound pressure levels in relation to the frequency. It basically adjusts for what in layman's terms I'd call "Importance" of the different ranges.
Therefore I'd say RG is very much focused on what human hearing will perceive as loud (too loud, or just loud enough), while DR focuses on "exposing offenders in all ranges of the spectrum". My educated guess would be: Loud bassy sounds would not harm an RG score, while having a significant impact on the DR, as its not attenuating low frequencies.
Would be interesting to see a comparison of the two!
Interesting idea, but personally I like the Dynamic Range (DR) measurement developed by the Pleasurize Music Foundation more. It also provides a one-value output that has a direct relation to the statistics of the input audio, and AFAIK it is a somewhat established measurand in audio engineering.
Self-plug: A while back I reverse-engineered the DR algorithm and implemented it as a Python script. It's [DRmeter on GitHub](https://github.com/janw/drmeter).
The level of hypocrisy is beyond measure. If "Open Science" was a real thing already, nobody would care about Nature, Elsevier, et al. If there has ever been a danger to open access to scientific research, it's publishing conglomerates that provide little to no value — the exact opposite of what GitHub has been doing the past few years.
Before complaining about others, clean up your own act, Nature.
As per my personal anecdotal evidence: diet is always key to Acne. I have been suffering from Acne vulgaris, Acne conglobata, and—worst of all—Acne inversa for all my life (26yo), and whenever I fell into bad eating habits with lots of (saturated) fats and carbohydrates, my skin issues are worsening. Western food is just poor quality in general, being heavily processed and “enhanced” and all.
I do understand why people would want to speed up their podcasts backlogs—I'm currently about 50% in, working my way through >500 hours of 5by5's Back To Work with Merlin Mann. I've tried speeding that up but one thing in particular causes me to stick with 1.1x at max: it's the connection with the hosts. It's just information (both useful and less so) condensed to be hastily consumed but it discards the dedication the hosts have put into it. Playing off of each other. The inside jokes, the subtle differences in tone and timing.
Maybe I'm just not as good in processing such social interactions at a faster pace than real-time. But I love "sharing a laugh" as if it's happening right now. That feeling completely goes away when the audio is sped up.
Nevermind the clever writing but the issue has been known for years—and beautifully exploited with the selfhostable ready-made solution WhatsSpy Public since Feb 2015: https://gitlab.maikel.pro/maikeldus/WhatsSpy-Public/ It's not actively maintained anymore but Maikel deserves some credit for it.
People™ should learn about how to properly self-host their stuff, apply adequate licenses that allow for remixing, etc. If "this music culture you're a part of" really matters to you, and grows larger than the initial toe-dipping, becoming self-sufficient should be one of the main objectives of your craft. Being part of a culture should also imply caring for its heritage, should it not?
Sure, this subculture would have probably never existed without a platform to grow on. But the going-away part is actually a large scale problem, not only regarding SoundCloud. This applies to other ~corporation~ startup backed platforms as well.
I strongly disagree. Jails have been fine for … forever on FreeBSD. Looking at tools like ezjails etc., I'd even consider them truly superior to containerizing all the things.
The problem probably lies in the toolset that shipped with FreeNAS up to this point. So doubling-down on it might actually make a difference and make people utilize one of (Free)BSDs biggest strengths properly in FreeNAS.
Unfortunately that alone would not have allowed Git to be fast on such a huge repository. Normally (without tools as sparse-checkouts) Git would read all files for example on git status. Therefore IPFS would also download all files locally, making it a moot addition.
It was stated in Saeed Noursalehi's talk "Scaling Git at Microsoft", held at Git-Merge 2017. Until the conference recordings are available, here is the closest thing to a "source": https://twitter.com/no_more_ducks/status/827479795185364993
It was explained in the talk at Git-Merge that their problem is not large files per se. The codebase is huge in the amount of source files alone. It was stated that the repo contains about 3.5 million files. Having IPFS here wouldn't help, would it?
They do. Durham Goode (Tech Lead on Source Control at Facebook) just held a talk at Git-Merge about how they scaled Mercurial at Fb. They seem to be quite happy with it, albeit applying quite a few restrictions on their internal users that are not really transferable to the general (outside-corporate) usage of VCS (for example only rebases are allowed, directly committing to master all the time, etc.)
> I have used lz4 compression as it has high performance and data deduplication dedup=on to save space.
Nice writeup but IMHO it's wrong to assume enabling dedup will make sense under any circumstance, especially regarding the performance drawbacks on systems that can't handle it. It might deserve a little more consideration than just setting it on by default in a somewhat copy-pasteable command. Oracle published a nifty guide on how to proceed with dedup: