You can install 'code-server' with termux's pkg and access it from a browser.
$ pkg install tur-repo $ pkg install code-server
HN user
You can install 'code-server' with termux's pkg and access it from a browser.
$ pkg install tur-repo $ pkg install code-server
"The audiophile community is full of fanatics as extreme as religious fanatics.."
No it's not.
One guy who I would describe as a genuine 'Audiophile Genius' is Nelson Pass. See: https://passlabs.com/
Nelson Pass has designed a series of innovative amplifiers that he sells as commercial products. He also releases circuit diagrams and build instructions his amplifiers, and helps out DIYers on public forums.
In contrast, it is great that NwAvGuy has designed a budget headphone amplifier, and released the design with a no derivative works allowed Creative Commons license. But that falls a long way short of what Nelson Pass has produced over the years in my opinion.
I think if you asked Nelson Pass whether or not all 'decently made' amplifiers sound the same, he would suggest you need do a bit of listening to different high quality designs.
Red book CD quality at 16/44.1 isn't 'mathematically perfect' at all anyway. The 22 khz Nyquist frequency is too close to the audio band, and there are unavoidable effects in the audio band of the 20 khz brick wall anti aliasing filtering needed.
With digital audio going to a DAC even with cheap cables, the '1's and '0's should be arriving OK and will be in "working perfectly" mode. You have to hope that is the case with USB audio as there is no error checking.
But when bits arrive is very important in audio, and whether or not the devices and cables in the chain before the DAC have introduced noise on the ground plane is also considered very important by some.
I can't see how an ethernet cable can affect timing, as the packets with the digital signal might even arrive out of order. The earthing of the ethernet cable might influence how much noise is introduced the ground plane though. It might explain why the Audioquest cables are directional, if their earthing arrangement is directional perhaps.
It doesn't mean that the cables or other equipment differences, can change the 'beats per minute' of a music track.
If the bass is reproduced poorly and sounds 'woolly' it will subjectively mess up the timing of the bass playing with respect to the rest of the music, as though the bass player is less skilful. Whereas listening to the same track with equipment that has tight, clear and dynamic bass can make the music sound more lively and subjectively 'faster', and it is more likely to make your foot tap.
In over 100 audiophile bashing posts, at last someone who actually understands the issues. USB cables have an 'eye pattern' which affects the timing of the signal presented to the DAC.
If USB cables make a difference, then there is probably an argument for doing something else (not ignoring the problem because USB cables must be 'perfect'). Like putting the DAC and computer driving the DAC in the same box and connected by I2S with the DAC as the master.
There are some good articles on the Audiostream site about why 'bit perfect' doesn't cut it in the context of audio:
Most modern audiophile DACS have asynchronous USB inputs, and hardly any have HDMI. I assume that is because the designers of the DACs all think USB works better than HDMI for high quality 2 channel audio.
"I don't think you need to worry about only accessing the web via apps - it just won't happen."
That's all right then.
You don't need to be an native english speaker to understand what the site is about - it is mostly pictures. We don't need some 'pompous twat' (as we say in the UK) explaining blindly obvious stuff in pretentious language.
And defending the Daily Mail newspaper to top it all (they are a poisonous bunch of scumbags in case any non-UK people don't know it).
I think the idea was to start a conversation. A conversation about why so many companies are thrusting these stupid apps on you. The idea was most certainly not to start a conversation about swearing, which is what 90% of the comments seem to be about.
You've completely missed the point. At the moment we have a free web and we can use a variety of browsers to access it.
If instead we can only access the web via apps and those app are controlled by the likes of Apple or Google, then we don't have a free web anymore. Maybe today the apps are free (as in beer), but maybe tomorrow they won't be. We would no longer be in charge and the web would have been appropriated by business interests.
Dead right. It's people with pitchforks outside the Bastille. It's starving people rioting to reclaim common land taken as 'enclosures' by the rich people.
I somehow think that saying something like "Relax. For fuck's sake." isn't going to help.
Thank you for explaining the jokes to us.
No it won't because the Raspberry Pi uses an older ARMv6 CPU type that isn't supported by Ubuntu.
I found the first NeXT keyboard was very uncomfortable to use, as the keys had very little spring and you would ram home hard against the 'end stops' all the time. I suppose keyboards are pretty subjective.
They did a second ADB based version for the later model NeXTStations, which I found a lot better to use. It had an interesting 'command bar' feature too, with a long bar like a space bar at the bottom for typing command sequences.
I've been a professional programmer since 1978 and the article seems 'off-beam' to me. He thinks that because programmer was harder 30 years ago, that would be there was a higher barrier to entry and therefore only really good programmers would get programming jobs. That idea is just completely wrong. There were the same number of people who could program as opposed to those who weren't very good as there are today.
Most programming goes on in your head in my opinion, and it is very much the same today as it was in the 1970s. You need to be able to run programs in your head if you are writing a COBOL program on coding sheets, that are sent away to be turned into a deck of punched cards, and once the cards are punched you can get them compiled into a program at most twice a day. If you want to be a really good programmer today, you need to be able to visualize what you are working on in your head. To me that is the ability that separates average programmers from really good ones - a good programmer doesn't need a computer to program, although having one is obviously handy..
For me there have been two big changes in how you conduct a programming career. The first was the introduction of personal computers that were cheap enough for a programmer to buy and use them to learn new programming skills in their spare time. The second big change was Free Software where you could publish your own code, and collaborate with people over the internet. I bought a Macintosh in 1984 and used it to learn Pascal with MacPascal. Then I got a programming job using Pascal. More recently I did a Ruby/C++ Free Software project and got jobs as a Ruby programmer and as a C++ programmer as a result.
Only really good programmers can write Free Software and handle open reviews of their work, and so if the article was about 'better self selection of programmers', then people who write software in public today are way better than the average programmer of 30 years ago. The very best programmers of today are much the same as the very best programmers in the 1970s, it is just that they are easier to find today. That is assuming you think people like Linus Torvalds or Rails DHH are examples of the best programmers in the 21st century.
If writing language bindings for Qt based C++ apis is harder than writing language bindings for GTK C based apis, how come there are at least as many high quality language bindings for Qt as there are for GTK?
Just because an api is C based doesn't make language bindings 'happen automagically', otherwise Gnome wouldn't need the GObject Introspection project. KDE has a similar project called 'Smoke' and some language bindings based on that.
There are different technical challenges to writing bindings for a C++ based api as opposed to a C based api, but it is just not true to say that one is better than another in my opinion. This is based on my experience doing a lot of work on Qt C++ language bindings, and a project using GObject Introspection.
The are a couple of very helpful articles on the Blue Jeans cables sitee about what is wrong with HDMI.
"HDMI is a horrid format; it was badly thought out and badly designed, and the failures of its design are so apparent that they could have been addressed and resolved with very little fuss. Why they weren't, exactly, is really anyone's guess, but the key has to be that the standard was not intended to provide a benefit to the consumer, but to such content providers as movie studios and the like. It would have been in the consumer's best interests to develop a standard that was robust and reliable over distance, that could be switched, amplified, and distributed economically, and that connects securely to devices; but the consumer's interests were, sadly, not really a priority for the developers of the HDMI standard."
HDMI Cable: An Overview: http://www.bluejeanscable.com/articles/hdmi-cables.htm
What's the Matter with HDMI?: http://www.bluejeanscable.com/articles/whats-the-matter-with...
I don't have any HDMI based devices fortunately, but on the basis of these two articles a Blue Jeans cable might be a good option to go for as opposed to the cheapest possible.
OK, thanks I've read the paper.
If we are talking about whether 16 bits is sufficient dynamic range (the main subject of this Hacker News discussion) they say:
"In one brief test with two subjects we added 14 dB of gain to the reference level quoted and tested the two sources with no input signal, to see whether the noise level of the CD audio channel would prove audible. Although one of the subjects was uncertain of his ability to hear the noise, both achieved results of 10/10 in detecting the CD loop. (We have not yet determined the threshold of this effect. With gain of more than 14 dB above reference, detection of the CD chain’s higher noise floor was easy, with no uncertainty. Tests with other subjects bore this out.)"
To me, this confirms that a bit depth of 16 is insufficient for high dynamic range music such as classical orchestral music. Maybe we don't need more than 20 bits (or about 16 bits plus 14 dB), but as we have the disk space, internet bandwidth and electronics to comfortably handle 24 bits I don't see the problem.
As far as sampling rate is concerned, they aren't comparing 24/192 PCM with 16/44.1 and so it isn't really relevant to a discussion about whether it is possible to hear the difference between these two formats using a current state of the art DAC.
I've no idea about the pros and cons of convertings SACD to 16/44.1 and doing a comparison as I don't personally care about SACD and don't think it has a future in downloadable non-physical formats.
They only talk vaguely about the actual equipment used which isn't normal for a Hi-Fi review. They say they inserted a comparator:
"always in the 16/44.1 signal path. Audio switching was handled by an ABX CS-5 double-blind comparator"
Have they done a double blind test to ensure that the effects of the comparator were inaudible?
They don't say what DAC or CD player they were using:
"For the CD loop we used a well-regarded professional CD recorder with real-time monitoring."
I don't have enough to go on here. Certainly DAC and CD players have improved a great deal in the last five years since these tests were made. From the description I can't tell whether of not the CD player and its DAC were state of the art five years ago.
So overall I agree the paper is an interesting read, but hardly the last word in answering the question of whether we should move to 24 bit recordings, or whether a sampling rate of 44.1 KHz is sufficient.
I thought I listed some of the possible flaws in blind tests - there is nothing unscientific about that.
If you value the results of any sort of blind test, no matter how badly conducted, over the opinions of recording engineers, then it doesn't seem to be a purely scientific matter to me.
Why would you value a 'blind test' over what an expert recording engineer, such as Barry Diament, thinks?
There are a lot of problems with blind tests, and there has certainly been much discussion about the arguments and counter arguments.
If you wheel in a bunch of untrained listeners off the street and get them to listen to recordings they are not familiar with, using a Hi-Fi that they are not familiar with, in stressful un-relaxed circumstances. Why would you expect to get some kind of definitive answer about 16/44.1 vs 24/192 for instance, that somehow trumps the opinion of highly regarded recording engineers?
"When the CD was designed, 44kHz at 16bits was chosen because that exceeds the limitations of human hearing."
No it wasn't, it was designed to be implementable given the technology of the time. Philips thought they were working on a 14 bit system, until Sony changed the spec to be 16 bits. That wasn't because Sony changed their minds about 'the limits of human hearing', it was because they thought they could implement the technology. 30 years later we can implement a bit depth of 24 bits with no problems.
According to the Wikipedia article on the history of the Compact Disc (http://en.wikipedia.org/wiki/Compact_Disc) the sampling rate was defined for the following reason:
"the exact sampling rate of 44.1 kHz was inherited from a method of converting digital audio into an analog video signal for storage on U-matic video tape, which was the most affordable way to transfer data from the recording studio to the CD manufacturer at the time the CD specification was being developed."
So again this has absolutely nothing to do with 'the limits of human hearing'.
Recording engineers, such as Barry Diament of Soundkeeper Recordings, think that the sound of 24/192 digital matches the output of the live microphone input of their recording desk. Barry Diament doesn't think 16/44.1 is nearly as good.
If you buy a recording at a high resolution you can always encode it as an MP3 or ACC so that it fits on your portable player. On the other hand if you buy an MP3 or AAC recording you can't bring back the lost resolution. So if I can fit my entire CD collection onto a cheap 1 TB hard drive, why do we care about how much disk space high resolution 24/96 or 24/192 audio will take up? When you don't have physical media it is trivial for a site to offer a range of resolutions according to the needs of the buyer. If I want 24/96 and someone else is only interested in 128 kps MP3s, then we can both download from the same site and only pay for the quality we need.