Human Brains Can Tell Deepfake Voices From Real Ones

Although it’s generally accepted that synthesized voices which mimic real people’s voices (so-called ‘deepfakes’) can be pretty convincing, what does our brain really think of these mimicry attempts? To answer this question, researchers at the University of Zurich put a number of volunteers into fMRI scanners, allowing them to observe how their brains would react to real and a synthesized voices.  The perhaps somewhat surprising finding is that the human brain shows differences in two brain regions depending on whether it’s hearing a real or fake voice, meaning that on some level we are aware of the fact that we are listening to a deepfake.

The detailed findings by [Claudia Roswandowitz] and colleagues are published in Communications Biology. For the study, 25 volunteers were asked to accept or reject the voice samples they heard as being natural or synthesized, as well as perform identity matching with the supposed speaker. The natural voices came from four male (German) speakers, whose voices were also used to train the synthesis model with. Not only did identity matching performance crater with the synthesized voices, the resulting fMRI scans showed very different brain activity depending on whether it was the natural or synthesized voice.

One of these regions was the auditory cortex, which clearly indicates that there were acoustic differences between the natural and fake voice, the other was the nucleus accumbens (NAcc). This part of the basal forebrain is involved in the cognitive processing of e.g. motivation, reward and reinforcement learning, which plays a key role in social, maternal and addictive behavior. Overall, the deepfake voices are characterized by acoustic imperfections, and do not elicit the same sense of recognition (and thus reward sensation) as natural voices do.

Until deepfake voices can be made much better, it would appear that we are still safe, for now.

Lindroid Promises True Linux On Android

Since Android uses Linux, you’d think it would be easier to run Linux apps on your Android phone or tablet. There are some solutions out there, but the experience is usually less than stellar. A new player, Lindroid, claims to provide real Linux distributions with hardware-accelerated Wayland on phones. How capable is it? The suggested window manager is KDE’s KWIN. That software is fairly difficult to run on anything but a full-blown system with dbus, hardware accelerations, and similar features.

There are, however, a few problems. First, you need a rooted phone, which isn’t totally surprising. Second, there are no clear instructions yet about how to install the software. The bulk of the information available is on an X thread. You can go about 4 hours into the very long video below to see a slide presentation about Lindroid.

Continue reading “Lindroid Promises True Linux On Android”

Programming Robots Is Hard, Figuring Out How To Make It Easier Is Harder

[Benjie Holson] is an experienced roboticist and wrote an interesting article published on IEEE Spectrum about how the idea most people have of non-roboticists is a myth, and efforts to target this group with simplified robotic frameworks tend to be doomed.

Now, let’s make a couple things absolutely clear right up front: He is not saying robots shouldn’t be easier to program, nor is he saying that non-roboticists literally do not exist (of course they do.) The issues he’s highlighting really come down to product design.

[Benjie] points out that programming robots is super hard, but it’s also hard in more than one way and for more than one reason. And when people try to create a product to make it easier, they tend to commit two big product design no-no’s: they focus on the wrong hard parts, and they design their product for a vaguely-defined audience that doesn’t really exist. That group is the mythical non-roboticist.

These are actually very solid points to make in terms of product design in general. Designing a product that solves the wrong problems for a poorly-defined group isn’t exactly a recipe for success. [Benjie]’s advice on making a truly effective and useful API framework that genuinely lowers the bar of complexity in a useful way is similarly applicable to product design in general.

His first piece of advice is not to design for poorly-defined amorphous groups. Your product should serve actual needs of actual users. If you cannot name three people you have actually spoken to who would be helped by your product, you are designing for an amorphous (and possibly imaginary) group.

The second is to design as though your users are just as smart as you are, just less tolerant of problems stemming from rough edges like compatibility and configuration issues. Remove those so that your users can get useful work done without having to re-invent the wheel, or resort to workarounds.

Robotic frameworks like ROS are useful and extensible, but whenever someone attempts to focus on creating a simplified framework, [Benjie] says they tend to step on the same rakes. It’s a mistake [Benjie] has committed himself, and see repeated by others. We think his advice is good product design advice in general, whether for designing APIs or something else.

Upper stage of a Japanese H-2A rocket which has been in orbit since 2009. It's one of the largest pieces of orbital debris. (Credit: Astroscale)

Astroscale’s ADRAS-J Satellite Takes Up-Close Photo Of Discarded Rocket Stage

Although there is a lot of space in Earth orbit, there are also some seriously big man-made objects in those orbits, some of which have been there for decades. As part of efforts to remove at least some of this debris from orbit, Astroscale’s ADRAS-J (“Active Debris Removal by Astroscale-Japan”) satellite has been partaking in JAXA’s Commercial Removal of Space Debris Demonstration (CRD2). After ADRAS-J was launched by a Rocket Lab Electron rocket on February 18, it’s been moving closer to its target, with June 14th seeing an approach by roughly 50 meters, allowing for an unprecedented photo to be made of the H-2A stage in orbit. This upper stage of a Japanese H-2A rocket originally launched the GOSAT Earth observation satellite into orbit back in 2009.

The challenges with this kind of approach is that the orbital debris does not actively broadcast its location, ergo it requires a combination of on-ground and on-satellite tracking to match the orbital trajectory for a safe approach. Here ADRAS-J uses what is called Model Matching Navigation, which uses known visual information to compare it with captured images, to use these to estimate the relative distance to the target.

Although the goal of ADRAS-J is only to study the target from as closely as possible, the next phase in the CRD2 program would involve actively deorbiting this upper stage, with phase start projected to commence in 2026.

Thanks to [Stephen Walters] for the tip.

Continue reading “Astroscale’s ADRAS-J Satellite Takes Up-Close Photo Of Discarded Rocket Stage”

Recovering An Agilent 2000a/3000a Oscilloscope With Corrupt Firmware NAND Flash

Everyone knows that you can never purchase enough projects off EBay, lest boredom might inadvertently strike. That’s why [Anthony Kouttron] got his mitts on an Agilent DSO-X 2014A digital oscilloscope that was being sold as defective and not booting, effectively just for parts. When [Anthony] received the unit, this turned out to be very much the case, with the front looking like it got dragged over the tarmac prior to having the stuffing beaten out of its knobs with a hammer. Fortunately, repairing the broken encoder and the plastic enclosure was easy enough, but the scope didn’t want to boot when powered on. How bad was the damage?

As [Anthony] describes in the article, issues with this range of Agilent DSOs are well-known, with for example the PSU liking to fry the primary side due to soft power button leaving it powered 24/7 with no cooling. The other is corrupted NAND storage, which he confirmed after figuring out the UART interface on the PCB with the ST SPEAr600 ARM-based SoC. Seeing the sad Flash block decompression error from the Windows CE said enough.

This led him down the rabbithole of finding the WinCE firmware images (nuked by Keysight, backed up on his site) for this scope, along with the InfiniiVision scope application. The former is loaded via the bootloader in binary YMODEM mode, followed by installing InfiniiVision via a USB stick. An alternate method is explained in the SPEAr600 datasheet, in the form of USB BootROM, which can also be reached via the bootloader with some effort.

As for the cause of the NAND corruption, it’s speculated that the scope writes to the same section of NAND Flash on boot, with the SPEAr600’s Flash controller documentation not mentioning wear leveling. Whether that’s true or not, at least it can be fixed with some effort even without replacing the NAND Flash IC.

The Guinness Brewery Invented One Of Science’s Most Important Statistical Tools

The Guinness brewery has a long history of innovation, but did you know that it was the birthplace of the t-test? A t-test is usually what underpins a declaration of results being “statistically significant”. Scientific American has a fascinating article all about how the Guinness brewery (and one experimental brewer in particular) brought it into being, with ramifications far beyond that of brewing better beer.

William Sealy Gosset (aka ‘Student’), self-trained statistician. [source: user Wujaszek, wikipedia]
Head brewer William Sealy Gosset developed the technique in the early 1900s as a way to more effectively monitor and control the quality of stout beer. At Guinness, Gosset and other brilliant researchers measured everything they could in their quest to optimize and refine large-scale brewing, but there was a repeated problem. Time and again, existing techniques of analysis were simply not applicable to their gathered data, because sample sizes were too small to work with.

While the concept of statistical significance was not new at the time, Gosset’s significant contribution was finding a way to effectively and economically interpret data in the face of small sample sizes. That contribution was the t-test; a practical and logical approach to dealing with uncertainty.

As mentioned, t-testing had ramifications and applications far beyond that of brewing beer. The basic question of whether to consider one population of results significantly different from another population of results is one that underlies nearly all purposeful scientific inquiry. (If you’re unclear on how exactly the t-test is applied and how it is meaningful, the article in the first link walks through some excellent and practical examples.)

Dublin’s Guinness brewery has a rich heritage of innovation so maybe spare them a thought the next time you indulge in statistical inquiry, or in a modern “nitro brew” style beverage. But if you prefer to keep things ultra-classic, there’s always beer from 1574, Dublin castle-style.

PCB Design Review: Switching Regulator Edition

This article was prompted by a friend of mine asking for help on a board with an ESP32 heart. The board outputs 2.1 V instead of 3.3 V, and it doesn’t seem like incorrectly calculated feedback resistors are to blame – let’s take a look at the layout. Then, let’s also take a look at a recently sent in design review entry, based on an IC that looks perfect for all your portable Raspberry Pi needs!

What Could Have Gone Wrong?

Here’s the board in all its two-layer glory. This is the kind of board you can use to drive 5 V or 12 V Neopixel strips with a firmware like WLED – exactly the kind of gadget you’ll want to use for LED strip experiments! 3.3 V power is provided by a Texas Instruments TPS54308 IC, and it’s the one misfiring, so let’s take a look.

Continue reading “PCB Design Review: Switching Regulator Edition”