Mickey Mouse’s introduction to the world was the 1928 cartoon, Steamboat Willie. Not only was it the first appearance of Mickey with sound, it was also one of the first cartoons to employ synchronized sound. The problem is, the sound is awful. Sure, after nearly a century, what do you expect? But [Oona Räisänen] thought it wasn’t just age, but flutter from the original recording. Could it be made better? What follows that question is a self-described geek’s journey into the depths of recorded sound.
The first step was to find a high quality source. The Internet Archive had a copy that was mostly clean. But it also has a lossless scan of the movie including the original optical soundtrack. A quick script played back the original soundtrack and — you guessed it — the flutter is already there. You can see the original 7-minute short from Disney’s channel, below.
This week Jonathan Bennett and Jeff Massie talk with JP Mens about Owntracks, the collection of programs that lets you take back control of your own location data. It’s built around the simple idea of taking position data from a mobile phone or other data source, sending it over MQTT to a central server, and logging that data to a simple data store.
From there, you can share it as trips, mark points of interest, play back your movement in a web browser, and more. And because it’s just JSON inside MQTT, it’s pretty trivial to make a connector to interface with other projects, like Home Assistant. We’ve even covered the process!
With many words which are commonly used in everyday vocabulary, we are certain that we have a solid grasp of what they do and do not mean, but is this really true? Take the word ‘robot’ for example, which is more commonly used wrongly rather than correctly when going by the definition of the person who coined it: [Karel Čapek]. It was the year 1920 when his play Rossumovi Univerzální Roboti was introduced to the world, which soon saw itself translated and performed around the world, with the English-speaking world knowing it as R.U.R.: Rossum’s Universal Robots.
Up till then, the concept of a relatively self-operating machine was known as an automaton, as introduced by the Ancient Greeks, with the term ‘android’ being introduced as early as the 18th century to mean automatons that have a human-like appearance, but are still mechanical contraptions. When [Čapek] wrote his play, he did not intend to have non-human characters that were like these androids, but rather pure artificial life: biochemical systems much like humans, using similar biochemical principles as proteins, enzymes, hormones and vitamins, assembled from organic matter like humans. These non-human characters he called ‘roboti’, from Old Czech ‘robot’ (robota: “drudgery, servitude”), who looked human, but lacked a ‘soul’.
Despite this intent, the run-away success of R.U.R. led to anything android- and automaton-like being referred to as a ‘robot’, which he lamented in a 1935 column in Lidové Noviny. Rather than whirring and clunking pieces of machinery being called ‘automatons’ and ‘androids’ as they had been for hundreds of years, now his vision of artificial life had effectively been wiped out. Despite this, to this day we can still see the traces of the proper terms, for example when we talk about ‘automation’, which is where automatons (‘industrial robots’) come into play, like the industrial looms and kin that heralded the Industrial Revolution.
Missing the feel of physical keys on your phone, but not ready to give up your fancy new touchscreen phone? [Dakkaron] has attached a BlackBerry keyboard to a slightly more recent device.
Designed for the FairPhone 4, [Dakkaron]’s hack should be transferable to other smartphones as it connects to the phone over USB without any of that tedious mucking about with Bluetooth. There’s even a handy OpenSCAD-based generator to help you along in the customization process.
[Dakkaron] started with an Arduino Pro Micro-based implementation, but the most recent iteration uses a custom board that can be obtained partially-populated. Unfortunately, the Hirose connector for the keyboard isn’t available off-the-shelf, so you’ll have to solder that yourself if you’re planning to do this mod. Sounds like a perfect opportunity to practice your surface mount soldering skills!
Throughout the last few years’ time, I’ve been seeing sparks of an eternal discussion here and there. It’s a nuanced one, but if I could summarize, it’s about different feature development strategies we can follow to design things, especially if they’re aimed at a larger market. Specifically – when adding a feature, how complete and perfect should it be?
A while back, I read a Mastodon thread about VLC not implementing backwards per-frame skipping. At the surface level, it’s about an indignant user asking – what’s the deal with VLC not having a “go back a frame” button? A ton of video players have this feature implemented. There’s a forum thread linked, and, reading it could leave you with a good few conflicting emotions. Here’s a recap.
In what appears to be one of multiple threads asking about a ‘previous frame’ button in VLC, there’s an 82-post discussion involving multiple different VLC developers. The users’ argument is that it appears to be clearly technically possible to add a ‘previous frame’ button in practice, and the developers’ argument is that it’s technologically complex to implement in some cases – for certain formats, even impossible to implement! Let’s go into the developers’ stated reasoning in more details, then – here’s what you can find in the thread, to the best of my ability.
If you want to start an argument in certain circles, claim to have a random number generation algorithm. Turns out that producing real random numbers is hard, which is why people often turn to strange methods and still, sometimes, don’t get it right. [Hillel Wayne] wanted to get a “good enough” method that could be done without a computer and found the answer in an old Usenet post from random number guru [George Marsaglia].
The algorithm is simple. Pick a two-digit number — ahem — at random. OK, so you still have to pick a starting number. To get the next number, take the top digit, add six, and then multiply by the bottom digit. So in C: n1=(n/10+6)*(n%10). Then use the last digit as your random number from 0 to 9. Why does it work? To answer that, the post shows some Raku code to investigate the behavior.
In particular, where does the magic number 6 come into play? The computer program notes that not any number works well there. For example, if you used 4 instead of 6 and then started with 13, all your random digits would be 3. Not really all that random! However, 6 is just a handy number. If you don’t mind a little extra math, there are better choices, like 50.
If you think humans are good at picking random numbers, ask someone to pick a number between 1 and 4 and press them to do it quickly. Nearly always (nearly) they will pick 2. However, don’t be surprised when some people pick 141. Not everyone does well under pressure.
What is the essential element which separates a text written by a human being from a text which has been generated by an algorithm, when said algorithm uses a massive database of human-written texts as its input? This would seem to be the fundamental struggle which society currently deals with, as the prospect of a future looms in which students can have essays auto-generated from large language models (LLMs) and authors can churn out books by the dozen without doing more than asking said algorithm to write it for them, using nothing more than a query containing the desired contents as the human inputs.
Due to the immense amount of human-generated text in such an LLM, in its output there’s a definite overlap between machine-generated text and the average prose by a human author. Statistical methods of detecting the former are also increasingly hamstrung by the human developers and other human workers behind these text-generating algorithms, creating just enough human-like randomness in the algorithm’s predictive vocabulary to convince the casual reader that it was written by a fellow human.
Perhaps the best way to detect machine-generated text may just be found in that one quality that these algorithms are often advertised with, yet which they in reality are completely devoid of: intelligence.
