You can add location information to your Tweets, such as your city or precise location, from the web and via third-party applications. You always have the option to delete your Tweet location history. Learn more
This repeated transcoding is *not* a fabricated use case. In fact, I expect *5* or even *6* generations of lossy encoding for portions of an event I'm holding on Sunday (albeit the two gens I can control, at 320kbps, to minimize loss).
It does make it very clear that something is terribly wrong with ffmpeg AAC; I'm using it at 128kbps here as an example where *anyone* will be able to tell, so we don't have to argue over whether I can really hear the difference or not for more common 1 or 2 encode cases.
ffmpeg 4.2.2, source audio: https://mrcn.st/t/btc_bridge.wav … Command line: ffmpeg -i in.wav -c:a {aac or libfdk_aac} -b:a 128k out.mp4 (then decode to wav and repeat another 3 times)
And if anyone is wondering how you end up with 6 generations of lossy encoding, it goes like this: → original song (lossy fmt) → remixed (lossy fmt) → streamed by DJ to VJ for visuals → streamed by VJ to me for mixing → streamed to Twitch for broadcast → Twitch transcodes
None of those steps are possible to eliminate entirely with existing software stacks and reasonable configs. The best I can do is ensure steps #3 and #4 are using CoreAudio or libfdk_aac at 320kbps, and #5 is using libfdk_aac at 160kbps.
Obviously good remixers ought to be going off of lossless versions of the original song... but I bet many aren't. And most remixes are released in lossy formats only (mp3 256kbps or so).
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
